[MOD][WIP] FTL: Overdrive

Discuss and distribute tools and methods for modding. Moderator - Grognak
Omen267901
Posts: 31
Joined: Thu May 30, 2013 10:22 pm

Re: [MOD][WIP] FTL: Overdrive

Postby Omen267901 » Tue Sep 03, 2013 9:07 pm

I hope you can revive this hero. If you do you will be the hero of the modding community.(Coincidence that you have hero in your name? I think not. :roll: ) I would offer my help, but coding isn't among my skillset, and there isn't really any graphics needed. (Just using sprites from FTL) I guess it's always good to know that FTL isn't anywhere close to having a dead community.
Vhati
Posts: 792
Joined: Thu Oct 25, 2012 12:01 pm

Re: [MOD][WIP] FTL: Overdrive

Postby Vhati » Tue Sep 03, 2013 10:58 pm

Having coders with poor impulse control, disdain for research, and disregard for planning (or even primary goals) is worse than having none. If they don't lose interest early, they paint themselves into corners. Either way, if they ever produce anything, it's distracting noise.
Unknownhero
Posts: 6
Joined: Sun Sep 01, 2013 11:17 am

Re: [MOD][WIP] FTL: Overdrive

Postby Unknownhero » Wed Sep 04, 2013 12:10 am

I'm working on a new Space class that will handle any ships in space. A basic main game loop class

Image Uploaded with ImageShack.us

I'm learning how the ships are being put together and only spent a couple hours learning how it's done. Probably the next thing I'll do is have the ship jump from waypoint to waypoint just like ftl but without the fancy graphics.

The ships is a little hard to figure out as I don't know how the rooms are being put together and what does define a room? Once I learn more about the ship I'll be able to move it around as needed. Also I need to learn how to add more crew and get them to move around like the original game.

Its quite a lot of progress for a few hours of my time and no reason I can't keep making progress. I was thinking of making this easily extendable into whatever you want it to be. Two engine rooms with two engines? 10+ shields? Fight two or three enemy ships at the same time? Ram another ship? Your engine explodes which sends a fireball throughout your ship roasting guys in your weapons room unless they are rocks. Or just get swarmed by Mantis.

What about a power generators instead of just assigning power? Those are the many ideas I have and I'll be interested if someone could try them out.
dalolorn
Posts: 532
Joined: Sun Sep 23, 2012 8:06 am

Re: [MOD][WIP] FTL: Overdrive

Postby dalolorn » Wed Sep 04, 2013 8:24 am

Vhati wrote:Having coders with poor impulse control, disdain for research, and disregard for planning (or even primary goals) is worse than having none. If they don't lose interest early, they paint themselves into corners. Either way, if they ever produce anything, it's distracting noise.


If you're referring to Unknownhero here, he seems to be doing pretty well.

So it's not cross-platform. Big deal, at least it works - and once the code is in place, it can be reverse-engineered much more easily than by observing how FTL works.
dalolorn
Posts: 532
Joined: Sun Sep 23, 2012 8:06 am

Re: [MOD][WIP] FTL: Overdrive

Postby dalolorn » Wed Sep 04, 2013 8:50 am

Unknownhero wrote:I'm working on a new Space class that will handle any ships in space. A basic main game loop class

Image Uploaded with ImageShack.us

I'm learning how the ships are being put together and only spent a couple hours learning how it's done. Probably the next thing I'll do is have the ship jump from waypoint to waypoint just like ftl but without the fancy graphics.

The ships is a little hard to figure out as I don't know how the rooms are being put together and what does define a room? Once I learn more about the ship I'll be able to move it around as needed. Also I need to learn how to add more crew and get them to move around like the original game.

Its quite a lot of progress for a few hours of my time and no reason I can't keep making progress. I was thinking of making this easily extendable into whatever you want it to be. Two engine rooms with two engines? 10+ shields? Fight two or three enemy ships at the same time? Ram another ship? Your engine explodes which sends a fireball throughout your ship roasting guys in your weapons room unless they are rocks. Or just get swarmed by Mantis.

What about a power generators instead of just assigning power? Those are the many ideas I have and I'll be interested if someone could try them out.


Ok, I'll respond to each paragraph individually:

1. If you think you can make modders define the animations themselves without making said animations end up terribly wrong, go for it.

2. Well, I believe it would look something like this (if I were coding it in Pascal, which is the only language I'm relatively proficient in):

Code: Select all

TRoom = record
//Using "public" only, as it's more convenient if you don't know what exactly you're doing, which I don't at this point
public
  //X and Y are the coordinates of the room's origin. (top left corner)
  X, Y, XSize, YSize: integer;
  //Okay... this is an interesting one. I don't remember ever declaring a 2D array with limits. Anyway, make it so
  //that it can go from 0 to 100, to imitate the health of the fire/breach in question.
  Burning, Breached: array[XSize, YSize] of integer;
  System: TSystem; //Not declared in the example, because I have no idea how to deal with this one outside of
  //making an exact replica of FTL's code, which would NOT be moddable.
  Crew: array[XSize, YSize] of TCrew; //Again, not declared.
  EnemyCrew: array[XSize, YSize] of TCrew; //I'm assuming TCrew knows who it's owned by, and who the ship is
  //owned by. This is an awkward one for me to handle using nothing but my mind.
  Oxygen: integer[0.. 100]; //This could work. Or it could not. *shrugs* If it does work here, it might also work for
  //Burning and Breached.
end;


Note that the code outlined above doesn't allow for custom room states (like water, plasma, or... stuff...) - another failure on my part. It also fails to provide any information on how a system or crewman should be coded.

3. Hmmm... having 2 separate engine systems contributing to a ship's overall dodge rating might not be a bad idea. Or separate shield generators and weapon rooms, for that matter. Fighting multiple ships is a bit tricky, as is ramming or the engine explosion, but they're all possible with enough hard work and intelligence.

4. The power generator sounds like a nice OPTIONAL system. This one - just like the one above it - should really be left in the very capable hands of whoever would be making mods for Overdrive, as they're the ones who know what their ships are supposed to be like.
User avatar
Kieve
Posts: 952
Joined: Tue Sep 18, 2012 2:21 pm

Re: [MOD][WIP] FTL: Overdrive

Postby Kieve » Wed Sep 04, 2013 9:26 pm

Vhati wrote:Having coders with poor impulse control, disdain for research, and disregard for planning (or even primary goals) is worse than having none. If they don't lose interest early, they paint themselves into corners. Either way, if they ever produce anything, it's distracting noise.


I get what you're saying, but I'll take "rough, limited functionality" over well-designed vaporware any day.
This project has been in the works nearly since the day FTL was released. Anyone who feels they can contribute - or hell, get a working release done - is to be encouraged.
Unknownhero
Posts: 6
Joined: Sun Sep 01, 2013 11:17 am

Re: [MOD][WIP] FTL: Overdrive

Postby Unknownhero » Fri Sep 06, 2013 8:08 pm

I been working on FTL jumps and got the background to load a new image when clicking the FTL button. It also plays the sound too.

I figured out how ships are made using lua scripting that calls c# functions in either ship or shiprenderer class. So modders can just build their own ships using lua no biggie. I'm also able to reposition the ship as needed so it could be possible to have the ship rock when it gets hit by a explosion or missile. If I can tie in the FTL jump to the waypoints in the sector window then I can work on crews and random events.

I may post my changes to git in a fork to original c# project though I never used git before. I could use help in areas of figuring out how to make crews move around the ship, fires and oxygen levels. Also figuring out what other pieces of code do and what they're used for. I'll need to clean up the code a bit then post it later tonight.

I am only going to work on the Krestal ship. I know others would want other ships but it'll just distract me from making just one functional ship.
dalolorn
Posts: 532
Joined: Sun Sep 23, 2012 8:06 am

Re: [MOD][WIP] FTL: Overdrive

Postby dalolorn » Fri Sep 06, 2013 8:31 pm

Unknownhero wrote:I been working on FTL jumps and got the background to load a new image when clicking the FTL button. It also plays the sound too.

I figured out how ships are made using lua scripting that calls c# functions in either ship or shiprenderer class. So modders can just build their own ships using lua no biggie. I'm also able to reposition the ship as needed so it could be possible to have the ship rock when it gets hit by a explosion or missile. If I can tie in the FTL jump to the waypoints in the sector window then I can work on crews and random events.

I may post my changes to git in a fork to original c# project though I never used git before. I could use help in areas of figuring out how to make crews move around the ship, fires and oxygen levels. Also figuring out what other pieces of code do and what they're used for. I'll need to clean up the code a bit then post it later tonight.

I am only going to work on the Krestal ship. I know others would want other ships but it'll just distract me from making just one functional ship.


I know little (read: nothing) about graphics, but I'd guess that if you were to ignore that part and focus on functionality (teleporting crew between rooms, I guess), it'd be a simple procedure.

Time for another Pascal example. :)

This one will only illustrate how to teleport them from one room to another, as, again, I'm useless when it comes to animating stuff.

Code: Select all

procedure TCrew.Transit(aRoom: TRoom)
var
  i, j: integer;
  Done: boolean; //Only making this because I'm not sure if calling "break;" will terminate one or both for loops
begin
  Done := false;
  if OnHostileShip then //This is a boolean value, in case you're wondering.
  begin
     for i := 0 to aRoom.XSize do //XSize and YSize, as well as TRoom, are from my previous example - all of this
     begin                                  //may need adjustment to match whatever you've coded in, not to mention
        for j := 0 to aRoom.YSize do //differences between C# and Pascal
        begin
           if aRoom.EnemyCrew[i, j] = nil then
             begin
                //Insert code moving the officer from wherever he is to aRoom.EnemyCrew[i, j]
                Done := true;
                break;
             end;
        end;
        if Done then break; //Again, only here because I'm not sure calling this in the "for j" loop will terminate the             
     end;                          //"for i" loop
  end
  else //Since you can only be on your ship or somebody else's ship...
  begin
     for i := 0 to aRoom.XSize do //XSize and YSize, as well as TRoom, are from my previous example - all of this
     begin                                  //may need adjustment to match whatever you've coded in, not to mention
        for j := 0 to aRoom.YSize do //differences between C# and Pascal
        begin
           if aRoom.Crew[i, j] = nil then
             begin
                //Insert code moving the officer from wherever he is to aRoom.Crew[i, j]
                Done := true;
                break;
             end;
        end;
        if Done then break; //Again, only here because I'm not sure calling this in the "for j" loop will terminate the             
     end;                          //"for i" loop
  end;
end;


This code checks if the guy's on his ship or an NPC, then checks which squares in the target room are empty, and does nothing if no squares are empty. And... since I haven't included code that actually transfers him between rooms... it does nothing either way. :cry:

As for fires and oxygen, that's a bit trickier, but my earlier example covers some of that already. Not a lot, but...

And as for the last line of your post, once you have a fully functioning Kestrel (and something for it to fight), Lua modding can be used to get the rest of the stuff into the game. :)
Unknownhero
Posts: 6
Joined: Sun Sep 01, 2013 11:17 am

Re: [MOD][WIP] FTL: Overdrive

Postby Unknownhero » Sat Sep 07, 2013 3:42 am

Successfully forked FTL overdrive on github with new changes. https://github.com/Unknownhero2/ftl-overdrive

There are a few graphic issues but I'll get to that later as the basic game functions need to be built first.
Vhati
Posts: 792
Joined: Thu Oct 25, 2012 12:01 pm

Re: [MOD][WIP] FTL: Overdrive

Postby Vhati » Thu Sep 26, 2013 6:18 pm

I've started working on a Java reboot with libGDX (Gfx/Audio for Win/Linux/OSX + Android), BeanShell (Scripting), and Maven (Easy building). No restrictive TWL skins this time.

I focused on laying the groundwork with ancestor superclasses and a roadmap for descendants' interactions.

  • Blueprint: Essentially factories for Models.
  • Model: Runtime state of a game element: Ship, Crew, System, PlotPoint (can't call it event), etc. Passively manipulated by dispatched events. When changed, it directly notifies a callback on registered graphical Actors, special Models that aggregate info for HUD Actors (e.g., Oxygen/Evade Monitor), and probably scripts. Subclasses implement interfaces to describe what can be done to them: Damageable, Ambulator, Powerable, etc. Contains a list of arbitrary string-int pairs (Ships have 'Hull' and 'Scrap'; Conceivably, scripts could assign 'PoisonRate' to CrewModels and constantly decrement 'HP'). Models exist in a hierarchy of other Models acting as containers, ultimately within a GameModel.
  • Actor: Graphical representation of a game element. Passively reacts to changes in the Model it watches. May enqueue a UI event. "Actor" is what libGDX calls it, among other things (Widgets), but I'll create a special ancestor class once I decide what non-stock things Overdrive needs them to do. I haven't entirely settled on a roadmap for them yet (eg, A StageManager with Actor factories registered for specific Model classes; A means to assign Actor positions in a layout, etc).
  • Event: A bundled request for something to change. It's generated by Actors, Scripts, and the render loop (periodic TickEvents to signal the passage of game-time units). Events are put on the queue of a central EventManager and scrutinized by scripts, which may veto and or enqueue additional events in response. An event that makes it through is dispatched to its destination, for now a Model. These are things like DoorEvent, PowerEvent, AmbulationEvent, etc.
  • ScreenManager: Central means to set or progress through screens, like LoadingScreen, MainMenuScreen, HangarScreen, CampaignScreen, etc. I'll probably set up tiers of EventManagers: one per-Screen, occasionally delegating events to a global one for the engine - to do stuff like set the Screen via an event.
  • Screen: Has its own EventManager and multiple Stages rendered on top of each other like layers (e.g., one for the player ship, and one for the HUD).
  • Stage: A 2D region of space, viewed from a 3D camera, and containing Actors to render onto the screen. It should be possible to add a second camera - offset a bit with a clipped view. So a complete enemy ship just outside the first camera's view will be partially rendered inside a rectangle (overlaying cameras' views will have a picture-in-picture effect and projectiles will travel between them normally).
  • Script: I haven't established conventions for writing scripts themselves yet. Technically, they can wield the full might of Java (optionally with looser syntax) to declare custom subclasses and call methods on anything. I only confirmed the interpreter is present and that it works by running hello world. A script's source will be interpreted once to create a long-lived object that will register with the EventManager. Different scripts will be loaded depending on the Screen (LoadingScreen will ask script objects what textures need pre-loading, etc). Like the EventManager, I'll probably have tiers of ScriptManagers as well.
I'm thinking I'll give each ShipModel a CoordinateManager to decide adjacency when queried in different contexts (for Ambulators planning walk paths, teleport doors are adjacent to different squares than the ones visually nearby). ShipCoordinates will unify the vertical-wall, horizontal-wall, and square positions using 3 numbers (x,y,v/h) - converted to normal screen x,y coords as needed. Models would register their locations with the manager as containers (SquareModel) or occupants (Ambulators, Breaches, etc), for lookup, and any containers implementing Traversable could be directly inspected with certain methods (to test if currently enterable, etc).

Right now I'm restructuring the Maven dir tree to accomodate building the engine and a separate setup tool (to locate and preprocess FTL's dats), then bundle everything together in archives for distribution.

At first, I took a shortcut by inefficiently transforming images on-the-fly, directly from the dats, tiled onto canvases of power-of-two dimensions, but that got problematic when it came time to write a cache manager to go with the LoadingScreen. I discovered textures generated that way can't be trusted to stay in the video card. So I'm going back and writing a setup tool to do that properly, so textures can be (re)loaded and used as-is.

I'll start a GitHub repo when the dir tree is stable.