About
OverdriveGDX is an attempt to rewrite the FasterThanLight engine from scratch with extra features, open source, and an emphasis on moddability.
Be advised: this is a huge project. To maintain sanity, I'll treat this as a coding exercise and focus on laying the foundation for other programmers to eventually join in (not ready for that yet).
Link: GitHub - OverdriveGDX
It's written in Java (1.6+), with the following dependencies:
- Link: Maven - Easy building and dependency management.
- Link: libGDX - Gfx/Audio for Win/Linux/OSX and potentially Android.
- Link: BeanShell2 - Scripting. It looks very much like Java (examples, manual).
- Link: KryoNet - Networking (pending).
- Link: Kryo - Serialization (pending).
Background
- Thread: The other Overdrive thread.
- Post: My generic roadmap from that thread.
- GoogleDoc: John Luke Pack Hard's compilation of requested features.
- GoogleDoc: John Luke Pack Hard's crowdsourced documentation for the original engine's XML.
- Link: GitHub - The Profile/SavedGame Editor's classes describing FTL's game state.
Design
The engine breaks down into these sorts of objects.
- Blueprint: Factories for models.
- Model: Runtime state of a game element: Ship, Crew, System, Incident (can't call it event), etc. Passively manipulated by event handlers. Models implement interfaces to describe what can be done to them: Damageable, Ambulator, Powerable, etc. Many Models contain a list of arbitrary string-int pairs (Ships have 'Hull' and 'Scrap' for example). 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 events that change the Model it cares about. 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 engine itself (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 performed by an event handler (to alter Models), then repeated to any registered event listeners, so they can react. These will be things like DoorEvent, PowerEvent, AmbulationEvent, etc.
- ReferenceManager: Models are referenced with unique int IDs, rather than directly assigning objects to variables. This allows a server and all players to unambiguously describe changes to everyone's model tree in events. Models also reference each other indirectly to avoid complications when saved games (serialization) are one day implemented.
Article: O'Reilly - What's So Tough About Distributing Objects? - ScreenManager: Central means to set or progress through screens, like LoadingScreen, MainMenuScreen, HangarScreen, CampaignScreen, etc.
- Screen: 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. A script's source will be interpreted once to create a long-lived callback-laden object and register it with various managers.
A separate setup tool - called the Packer - finds the original FTL's resources and transforms them into something OverdriveGDX can understand. Part of the process involves cramming lots of little PNGs into large square images.
Again, this is a long-term project. I like how it's gone so far, but there are still some important milestones to reach before I can feel confident that this might be viable - much less deliver a finished product.
