OverdriveGDX

Discuss and distribute tools and methods for modding. Moderator - Grognak
Vhati
Posts: 792
Joined: Thu Oct 25, 2012 12:01 pm

OverdriveGDX

Postby Vhati » Tue Oct 29, 2013 6:11 am

.
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.
Last edited by Vhati on Tue Feb 25, 2014 4:22 am, edited 2 times in total.
Vhati
Posts: 792
Joined: Thu Oct 25, 2012 12:01 pm

Re: OverdriveGDX

Postby Vhati » Tue Oct 29, 2013 6:11 am

( Reserved for future use. )
Vhati
Posts: 792
Joined: Thu Oct 25, 2012 12:01 pm

Re: OverdriveGDX

Postby Vhati » Tue Oct 29, 2013 6:12 am

( Reserved for future use. )
Vhati
Posts: 792
Joined: Thu Oct 25, 2012 12:01 pm

Re: OverdriveGDX

Postby Vhati » Tue Oct 29, 2013 6:13 am

( Reserved for future use. )
Vhati
Posts: 792
Joined: Thu Oct 25, 2012 12:01 pm

Re: OverdriveGDX

Postby Vhati » Tue Oct 29, 2013 6:14 am

( Reserved for future use. )
Vhati
Posts: 792
Joined: Thu Oct 25, 2012 12:01 pm

Re: OverdriveGDX

Postby Vhati » Tue Oct 29, 2013 6:14 am

.
Status

As of this post, it's nowhere near a playable demo.
But thanks to Maven, it's relatively easy to compile (instructions are provided in a readme on GitHub).

When run, the engine currently displays a single screen with few UI and Actor tests, representing Models, created via events, fired by Blueprints.

  • An early draft of a ShipActor represents Kestrel-A with hull images, floor tiles, floor lines, walls, and room decoration images.
  • TickEvents periodically increment the test ship's 'hull' number, and grow the bar on a visible meter.
  • An animation of a human walking is shown.
  • A reticle sprite flits around in an ellipse.
  • TTF fonts are rendered in a draggable window of arbitrary size.
  • Full-screen rectangular background - shattered into tileable pieces by the packer, so it'd fit into a square - is reassembled, stretched, and rendered.
  • A number of Models have been partially implemented (and some of their corresponding events) as I work through writer's block on the bigger issues.
  • Scripts play no role yet.


Todo

In the other Overdrive thread, I outlined a plan for linking ship systems to rooms.

The event pipeline needs more work: Client EventManager's outbound queue -> Server's inbound queue -> Server's outbound queue -> All clients' inbound queues. And Scene switching probably needs to swap out event handlers (eg for cutscenes).

Incident Models (FTL 'events') have not been revised in light of reference IDs.

Walkpaths have not been attempted yet. CrewModels - when they're written - will set an adjacent floor-tile's ShipCoordinate to travel into, and the CrewActor will have to slide in that direction at a certain rate and arrive about the time the model sets the next ShipCoordinate to continue walking.
Last edited by Vhati on Sun Dec 29, 2013 10:36 pm, edited 1 time in total.
richeygator
Posts: 39
Joined: Fri Nov 01, 2013 10:59 pm
Location: south bend,indiana

Re: OverdriveGDX

Postby richeygator » Thu Dec 05, 2013 5:03 am

Nice idea very ambitious
Nevertheless wish the best of luck
And will download it sometime later once its updated a little more
I dont have a god complex,you have a mortal complex
Vhati
Posts: 792
Joined: Thu Oct 25, 2012 12:01 pm

Re: OverdriveGDX

Postby Vhati » Sun Dec 15, 2013 3:14 am

It's been quiet here for a while.

To try and kickstart ideas with something more straightforward, I've started retrofitting an unrelated project I developed years ago to use KryoNet... translating old non-blocking socket-fu that passed tokenized strings - into KryoNet Connections ferrying (de)serialized message objects.
DryEagle
Posts: 363
Joined: Thu Oct 04, 2012 11:17 am

Re: OverdriveGDX

Postby DryEagle » Sun Dec 29, 2013 5:09 pm

( Reserved for future use. )
All ships I have created include custom weapons, graphics etc:
Image
ImageImageImageImage
Omen267901
Posts: 31
Joined: Thu May 30, 2013 10:22 pm

Re: OverdriveGDX

Postby Omen267901 » Mon Jan 13, 2014 10:33 pm

I really hope this doesn't just die like the original Overdrive did. I don't know how to code so I can't help though. :(

Who is online

Users browsing this forum: No registered users and 7 guests