[MOD][WIP] FTL: Overdrive

[Vhati]

Just out of curiosity, how is this coming along?

It's... inactive.
If anyone were working on it, they'd be reporting what they were up to here.

[Omen267901]

Just out of curiosity, how is this coming along?

It's... inactive.
If anyone were working on it, they'd be reporting what they were up to here.

I see

[XxLOLdudexX]

This project must not die. I am so incredibly eager for its release...

[Unknownhero]

I'm interested in helping out this project as I do wish FTL was more modable. My only beef with this project is that by starting out trying to make the engine modable more work has spent trying to make things easier to change than actually building the engine to run a vanilla version of the game.

My suggestion would to make the game first run in code mimicking vanilla at about 90% accuracy then move on to porting in scripts that can be easily changed by modders.

I'll dive into this project and see what I can change or not. I may have the urge to throw a few things out if it makes the project easier to complete.

[Vhati]

My only beef with this project is that by starting out trying to make the engine modable more work has spent trying to make things easier to change than actually building the engine to run a vanilla version of the game.

My suggestion would to make the game first run in code mimicking vanilla at about 90% accuracy then move on to porting in scripts that can be easily changed by modders.

See: this post.

Additionally, no time was spent trying to make it moddable, because development hasn't gotten far enough for that to matter yet. There was plenty of discussion of what modding features would be desired, but they were only plans. Discussion of vanilla was the reverse engineering of the xml spec, which has largely been done in other threads.

There's no point crippling the engine as a shortcut to end up with a game just like the one that already exists.

Wrestling the code, my biggest source of frustration was was TWL. Its gui theme-ing just wasn't designed to be modified after the fact. If that were dropped, libgdx looks like a good replacement (I used it a couple times, though not on large enough projects to be proficient with it), but it'd mean handling graphics manually, near the OpenGL level (for better or worse).

[Vhati]

I just revisited the scripting language candidates. Nothing new there but...

BeanShell is viable: embeddable live scripts without going through a bytecode phase.

I used it a little in JEdit. Scripts are basically Java snippets with predefined variables set by the app.

[Unknownhero]

TWL is looking to be a problem for me too. Once it loads the theme I have no easy control over the background or menus or the flashy text.

If I want to have clicking on new game bring up a new screen with a ship and doors I can't do that. Because whatever is in the xml controls whats in the game and I'm just out of luck. I have to dig around and find out what thememanager is. Which means more time spent learning how and less time actually working. libgdx may be an option to look into.

What i'll try to accomplish is with starting game, main menu comes up, click new game and background changes to space with a ship on it with interiors exposed. Then I can work on the actual mechanics like doors/power/crew and fire hopefully.

[UltraMantis]

Good luck hero. Welcome to the project and the forums.

[Vhati]

TWL is looking to be a problem for me too. Once it loads the theme I have no easy control over the background or menus or the flashy text.

I have to dig around and find out what thememanager is.

From what I could tell, it replaces the entire theme hierarchy - not parts of it. The xml determines the structure of what is, or can ever be, on the screen, and the code modifies position, visibility, etc.

You can define a widget in xml, then set its background with programmatically determined pixels (to swap images at runtime, but not layout or collections of parented widgets). I discovered that when I was working on a shop here (not committed).

I didn't do that for the shop, but here are my notes.

There's this, to convert a BufferedImage into a TWL Image, for a Widget's setBackground. Each platform has its own way of creating BufferedImages (Oracle's ImageIO / Android's BitmapFactory).

Or this to use TWL's built-in image decoder.

Code: Select all

LWJGLRenderer r = overdrive.renderer;
LWJGLTexture tex = r.load( textureUrl, ... )
Image image = tex.getImage(crop args)
widget.setBackground(image);

a ship on it with interiors exposed. Then I can work on the actual mechanics like doors/power/crew and fire hopefully.

DiEvAl had an experimental ship branch on github, as illustrated by posts here.

Which means more time spent learning how and less time actually working.

Time spent learning is time spent not reinventing the wheel... at least when you're learning about a wheel you'd ultimately want.

[Unknownhero]

I downloaded the c# Overdrive and wow is it more readable than java. I may be biased but Java gives me alot of trouble to even compile to run the program. I downloaded SharpDevelop compiled the c# and ran it and it worked perfectly the first try.

So instead of juggling with Java, I'll work on c# instead. Though that may leave cross platform out of the question atm.