[MOD][WIP] FTL: Overdrive

[5thHorseman]

Rally on! I hope you get this off the ground.

I'd help but I'm really useless on large code projects. If it's more than automating file movement or something I get all

[UltraMantis]

Awesome job Vhati. \o/

[kartoFlane]

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

[Vhati]

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.

[kartoFlane]

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

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.

[Hyperdrive]

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.

[5thHorseman]

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.

[Vhati]

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.

Code: Select all

img/
Vanilla: 1876 files (52 MB)
Packed:   187 files (39 MB)

[kartoFlane]

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

A cursory glance at code ended in me accidentally reading through most of it 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...

[Vhati]

.
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.


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?