[MOD][WIP] FTL: Overdrive

Discuss and distribute tools and methods for modding. Moderator - Grognak
User avatar
kartoFlane
Posts: 1480
Joined: Mon Jan 14, 2013 10:20 pm

Re: [MOD][WIP] FTL: Overdrive

Postby kartoFlane » Fri Sep 27, 2013 12:19 pm

I'd be happy to help out, though I'd need to familiarize myself with Maven & BeanShell first... I have scribbled around a tiny bit with libGDX some time ago (preliminarily), but I definitely wouldn't be comfortable working with it yet.

Though I'm afraid that anything I contribute would have to be reviewed, and would end up being more trouble that it's worth :E
Superluminal2 - a ship editor for FTL
Vhati
Posts: 792
Joined: Thu Oct 25, 2012 12:01 pm

Re: [MOD][WIP] FTL: Overdrive

Postby Vhati » Fri Sep 27, 2013 3:43 pm

kartoFlane wrote:I'd be happy to help out, though I'd need to familiarize myself with Maven & BeanShell first... I have scribbled around a tiny bit with libGDX some time ago (preliminarily), but I definitely wouldn't be comfortable working with it yet.

The nice thing about Maven is: once it's set up, you don't need to mess with it.
You just run the same couple commands over and over. When I got started with the Profile Editor after ComaToes set it up, I only ever bumped the version and ran build commands. Setting this up is more complicated to be sure, but I'll put the routine commands in a readme, as I did for SMM.

For BeanShell, just imagine if Java didn't need compiling, and didn't complain if you slipped into Python habits (it'll let you omit semicolons, too). It's got lots of other features you could read about, but you don't need to.

For libGDX, yeah it's a bit intimidating. Though I hope I'll have taken care of the tricky stuff in advance, so other devs will really only need to subclass Actor, fill in a paint method, and maybe GDX event listeners for clicks. ( link ) Then it's all about firing and handling the custom Overdrive events.


Edit (2013-10-02): Correction: semi-colons are still necessary. That it lets you omit them is a bug. :roll:
Last edited by Vhati on Wed Oct 02, 2013 9:42 pm, edited 1 time in total.
User avatar
kartoFlane
Posts: 1480
Joined: Mon Jan 14, 2013 10:20 pm

Re: [MOD][WIP] FTL: Overdrive

Postby kartoFlane » Sat Sep 28, 2013 3:37 pm

Vhati wrote:The nice thing about Maven is: once it's set up, you don't need to mess with it.
...
For BeanShell, just imagine if Java didn't need compiling, and didn't complain if you slipped into Python habits (it'll let you omit semicolons, too). It's got lots of other features you could read about, but you don't need to.

That's nice. And BeanShell really looks indistinguishable from Java... That's definitely encouraging

Vhati wrote:For libGDX, yeah it's a bit intimidating. Though I hope I'll have taken care of the tricky stuff in advance, so other devs will really only need to subclass Actor, fill in a paint method, and maybe GDX event listeners for clicks. (link) Then it's all about firing and handling the custom Overdrive events.

Yeah, It is. Frankly, having to deal with the low-level classes was one of my main concerns, since I doubt I could code it efficiently / appropriately.
Superluminal2 - a ship editor for FTL
Hyperdrive
Posts: 11
Joined: Sun Jun 16, 2013 1:06 pm

Re: [MOD][WIP] FTL: Overdrive

Postby Hyperdrive » Sun Sep 29, 2013 7:07 pm

Hi, guys !
Like each one of you wanting badly for a fully moddable version of FTL to come out, I've been working on a rewrite in python (using pygame, SDL for python) for a little time now, and it's time I give notice of it.
First I'd like to say that my goal is absolutely NOT to distract people from working on Overdrive or other project ; the code I've written so far is still too rough to be of any practical use and it's too early to say how well it will evolve. But I should at least say that it exists.
A few months ago I came briefly on this discussion thread, but I ended up starting this rewrite on my own because I wanted to use the occasion to hone my skills in python and to start a big project from the beginning.
Here is a screen showing most of what the current state can display :
3rd_kind_encounter.jpg

Next, I plan on putting the source on git soon, in a few days tops. Just need time to figure out how (g)it works, clean the source, and maybe sprinkle a few comments.
User avatar
5thHorseman
Posts: 1669
Joined: Sat Mar 02, 2013 2:29 am
Location: On the bridge of The Potential
Contact:

Re: [MOD][WIP] FTL: Overdrive

Postby 5thHorseman » Sun Sep 29, 2013 8:32 pm

Hyperdrive wrote:Hi, guys !
Like each one of you wanting badly for a fully moddable version of FTL to come out, I've been working on a rewrite in python (using pygame, SDL for python) for a little time now, and it's time I give notice of it.
First I'd like to say that my goal is absolutely NOT to distract people from working on Overdrive or other project ; the code I've written so far is still too rough to be of any practical use and it's too early to say how well it will evolve. But I should at least say that it exists.
A few months ago I came briefly on this discussion thread, but I ended up starting this rewrite on my own because I wanted to use the occasion to hone my skills in python and to start a big project from the beginning.
Here is a screen showing most of what the current state can display :
3rd_kind_encounter.jpg

Next, I plan on putting the source on git soon, in a few days tops. Just need time to figure out how (g)it works, clean the source, and maybe sprinkle a few comments.


Any and all attempts at this are welcome. I figure if 2 of you are working on this it just doubles our chances that one of you will succeed. And who knows, maybe you both will and we'll have *gasp* too many moddable FTL clones out there.
My Videos - MY MOD HUB
Simo-V - The Potential - Automated Scout - "Low O2" Icons
The Black Opal - The Asteroid - The Enforcer - The Pyro

"Every silver lining has a cloud..."
Vhati
Posts: 792
Joined: Thu Oct 25, 2012 12:01 pm

Re: [MOD][WIP] FTL: Overdrive

Postby Vhati » Tue Oct 01, 2013 1:14 am

OverdriveGDX is on GitHub now.

Nothing to see at the moment though. Really.
It's all invisible infrastructure: build environment, texture mosaic packer tool, base classes, and some warm-up exercises with the libraries. Stuff to make what's to come easier.

BeanShell just got updated, and I got some tips from the developer.


Heh, texture loading should be waay more efficient now. :lol:

Code: Select all

img/
Vanilla: 1876 files (52 MB)
Packed:   187 files (39 MB)
User avatar
kartoFlane
Posts: 1480
Joined: Mon Jan 14, 2013 10:20 pm

Re: [MOD][WIP] FTL: Overdrive

Postby kartoFlane » Tue Oct 01, 2013 2:31 pm

Installing maven was much less painful than I had anticipated... It was actually pretty pleasant

Downloaded OVD-GDX, successfully built, packed the images (37MB!), ran the engine and admired the pretty animations. Crashed when I tried to go fullscreen, though :lol:

A cursory glance at code ended in me accidentally reading through most of it :P Guess I'll fork and play around with it, try to get a handle of things.

Edit
Eclipse needed a little bit more persuasion, but managed to get it working (relatively) neatly...
Superluminal2 - a ship editor for FTL
Vhati
Posts: 792
Joined: Thu Oct 25, 2012 12:01 pm

Re: [MOD][WIP] FTL: Overdrive

Postby Vhati » Thu Oct 03, 2013 1:40 pm

.
OverdriveGDX Status Update

Oversized images (1280x768) were shattered by the packer into small pieces and tiled into a 1024x1024 square. The engine can load that square, render the pieces in their original rows/cols, and recreate the appearance of the original large image... plus scale it to fit the screen.

The engine can load ttf fonts and show wrapped text in a draggable popup window (the sort FTL uses for events), and the window can have an arbitrary size.

kartoFlane's been experimenting with graphics.



The event system is still just dispatching TickEvents. That severely limits what non-experiment code can be written - bypassing the event system to directly change Models is bad.


Any further events must be able to reference a specific object, an action that object should perform, and arguments for that action. And they need to do this without directly pointing at the object. Different players will have similar - but technically different - objects, so they need to communicate in terms of "obj#1" doing "thisAction" and translate that reference to the appropriate object at the receiving end.

Even if multiplayer never acutally happens, I get the feeling that pointing directly at objects is a cheat that'll come back to bite me when it comes time to save the game. :roll:


So I need to read up on serialization and distributed objects...

Article: O'Reilly - What's So Tough About Distributing Objects?


Edit: Hmm, maybe the KryoNet library?
And it's sibling library, Kryo, for serialization?
User avatar
kartoFlane
Posts: 1480
Joined: Mon Jan 14, 2013 10:20 pm

Re: [MOD][WIP] FTL: Overdrive

Postby kartoFlane » Thu Oct 03, 2013 5:17 pm

Well, all I thought of was covered by the book excerpt.

Kryo/Kryonet certainly looks promising... But I can't really say much else since I have no networking experience whatsoever :X It does seem to be solving most of the issues outlined in the chapter...

Regarding the code, some things I felt capable of tackling myself seem to require much more groundwork to be laid down first -- like scripts (needs the game to actually supply some sort of API for the scripts to work with), or /data/ loading (needs the actual classes that will use the data).

I'll try to do something in the model / game object department over the weekend *shrug*
Something like being able to create an instance of a model, and getting it to show on test screen.

Also, a thing occured to me while playing around with the packer -- every time a new mod is installed/uninstalled, the resources will have to be repacked.
Unless we'll have a "mod compiler" that'll pack mods before they're distributed. Then a new manager would have to implement the functionality to add/append/overwrite those files...

It appears to me that no matter what, replacing textures will not be as easy as it is now.
Superluminal2 - a ship editor for FTL
Vhati
Posts: 792
Joined: Thu Oct 25, 2012 12:01 pm

Re: [MOD][WIP] FTL: Overdrive

Postby Vhati » Sun Oct 06, 2013 6:06 pm

I've sort of worked out a revised plan for events...

Code: Select all

// Create a new ShipModel.
int shipRefId = context.getNetManager.requestNewRefId();

ShipCreationEvent newShipEvent = Pools.get( ShipCreationEvent.class ).obtain();
newShipEvent.init( shipRefId, "Kestrel" );
context.getScreenEventManager.postDelayedEvent( newShipEvent );


// Make it the player ship.
int gameRefId = context.getGameModelId();

GameSetPlayerShipEvent setShipEvent = Pools.get( GameSetPlayerShipEvent.class ).obtain();
setShipEvent.init( gameRefId, shipRefId );
context.getScreenEventManager.postDelayedEvent( setShipEvent );


// Damage its hull.
ShipIntPropertyEvent propEvent = Pools.get( ShipIntPropertyEvent.class ).obtain();
propEvent.init( shipRefId, ShipIntPropertyEvent.INCREMENT, "Hull", -20 );
context.getScreenEventManager.postDelayedEvent( propEvent );


// Lookup an existing object by its reference id.
GameModel gameModel = context.getReferenceManager().getObject( gameRefId, GameModel.class );

Events are posted to an outbound queue where veto listeners can cancel any action they don't like (undamageable ship). Any events that make it through are shipped to the server via serialization. The server ships the events back (in the order received) to each player's inbound queue.

Then as events exit the inbound queue, a handler performs the described action to modify the models. Then the event gets forwarded to after-the-fact listeners like UI elements (instead of the direct observer strategy).


Still working on implementing all that.
For saving the game, refIds should make serializing the model tree painless. Saving the state of scripts and UI is still up in the air, however. Supposedly BeanShell objects can be serialized (or their NameSpace? or their Interpreter?) but I haven't succeeded at that yet.

Who is online

Users browsing this forum: No registered users and 44 guests