[MOD][WIP] FTL: Overdrive

[DiEvAl]

Apologies for not reading through all 32 pages, but would custom systems/subsystems, custom resources and a more easily editable GUI for various things (store, resources, systems etc.) be a thing?

That's the plan.

[Vhati]

I'm playing around with a store to get the hang of themes, and designing classes in the style of DiEvAl's ship demo. Not sure yet if I'll end up commiting or discarding it as an exercise...

[DiEvAl]

...designing classes in the style of DiEvAl's ship demo...

Design in whatever style you think is the best. I don't want whole project to suck if/because my first couple of classes sucked

[DiEvAl]

I finally fixed a bug in myself that made me think that building a base on Laythe is more fun than programming. Back to working on FTL:OD

[Vhati]

There are a bunch of other scripting languages with good java integration around though. Consider groovy, jruby or jython for starters.

Dalvik bytecode != Java bytecode...
-- Jython doesn't work on Android.

-- Neither does JRuby.

-- Nor Groovy. Addressing that is one of the ideas for the 2013 Google Summer of Code.

-- When Scala 2.11 comes out, it should be capable of evaluating scripts without compiling first (JSR223 spec). Maybe?

-- Oracle's runtime comes with a JavaScript interpreter (Mozilla's Rhino), which isn't guranteed to exist everywhere. Dunno about Android. StackOverflow has code to list available interpreters on a system, and links to a JSR223 primer demoing JavaScript.

-- Edit (2013-09-01): BeanShell is viable: embeddable live scripts without going through a bytecode phase.

[DiEvAl]

SL4A supports Python, Perl, JRuby, Lua, BeanShell, JavaScript, Tcl, and shell. I'm not sure if this is exactly what we want though.

There might be other interpreters for android.

If no scripting language works, there is always a choice of writing mods in java, compiling them to java bytecode and then dxing them. There are 3 places where dxing can take place:

1) Modder can run dx himself and provide both .jar and .dex versions of his mod. But since modders are lazy (at least I'd be ), they'll want to skip this and release only a .jar version. So this is not very good solution.

2) On an android device when installing the mod. I think there is/are port(s) of dx for android (although not necessarily free). How would apps like AIDE compile java to dalvik bytecode without it?

3) If we have a central repository for mods, then we can run dx on the server when modder uploads his mod.

[Vhati]

I'm playing around with a store to get the hang of themes, and designing classes in the style of DiEvAl's ship demo. Not sure yet if I'll end up commiting or discarding it as an exercise...

Stores can sell several different things.
Crew, Augments, (Sub)systems, Weapons, and Drones

There are separate blueprint classes with various attributes. That's a given.

I made StoreShelfItemInfo with standard attributes (icon, description, price). Then subclasses constructed using instances of each blueprint to set those values (StoreShelfCrewInfo sets a "Bob" as its description, etc).

TWL widget+theme pairs render store shelves of each type: Augment renderer for 3 bars, Weapon renderer for squares.

The problem then is how to associate blueprints, store info subclasses, and GUI widgets together.
How flexible should this be?

• Hardcoded if/else blocks are straightforward but rigid.
• A centralized class lookup table would allow code to register new mappings or clobber existing ones (e.g., to change GUI widgets). StoreShelfItemInfo subclasses would each have a buy(gameState) method to manipulate the ship (spawning a crewmember, etc).

TWL can be coaxed into adding new subthemes (use ref="*" within the store window's theme, and include toplevel files for each shelf-type made findable with allowWildcard="true") but only with unique names, no replacement. A widget determines layout, so it's pretty much tied to a specific theme. So to mod appearance beyond simple image swapping would mean changing both the theme name and Widget class used. I don't know how that could be done without a registry.

Abstracting blueprints and looking em up doesn't seem so bad, but handling mystery classes in general might get hairy: {spawned thing} occupying a room square checks if {other thing} nearby implements the FriendOrFoe interface, then calls isHostile(), then checks for Damagable interface, then calls addDamage(amt, type, srcObj), etc. We could restrict spawnables to specific classes (and their subclasses) to mitigate that however.

[Hyperdrive]

Hi guys !
I did read the 33 pages of this thread and am interested in the project (although my interest in things sometimes fades quickly). I could code stuff. My favorite language is python, but all languages are kind of alike, so whatever.
It's cool that the project did not fall into oblivion and that some people take matters into their hands. I kinda agree with the choices so far, except the idea of using float numbers for hull life. It seems like the opposite of simplicity, as float numbers are tricky, and the only reason to use them would be for the sole beam weapon, which is one type of weapon among many. The original game did without float numbers cleverly, and I think people like calculating the trajectory of the beam so that it hits the most rooms. It's kinda fun.
Anyway, good luck guys, let's keep in touch if you have something for me.

[Vhati]

I kinda agree with the choices so far, except the idea of using float numbers for hull life.

Where did you read that?

[DiEvAl]

I have IMO (International Math Olympiad) soon, so I'm spending like 7 hours a day preparing to it. It's not a lot, but it's very exhausting, so I don't feel like working on this project (or pretty much anything related to programming). I'll have a lot more free time in about 3 weeks.