[MOD][WIP] FTL: Overdrive

[Vhati]

If I understand correctly, the goal of this project is to add moddability to FTL by making an open source scriptable clone of it. So a good milestone could be a program that runs quite like vanilla and can use all vanilla resources correctly. From that point we could easily add some more moddability

Scripting has to be done from the beginning (reducing even vanilla actions to scripts).
Trying to bolt-on an interpreter after the fact would not go well.

The SavedGame Editor is already a working demo of how resources can be read (though JAXB will not be the specific xml parser used here) and translated into a game state.

- Current demo code is still trying to passively display aspects of a hardcoded static game state.
- Then resource loading can dynamically generate some of that state
(eg, load the name list, to randomly label crew).
- Then scripting can dynamically manipulate that state.
- Then the player can interact with the GUI to trigger scripting events to manipulate that state.
- Then, hypothetically, the game state can be managed by a server and synchronized among players: doing much of the scripting itself, taking players' requests to change the state, and distributing changes to everyone (or dropping requests it doesn't like).

But I haven't found if the programming language (and the scripting language if the programming language is not interpreted) has already been decided.
[...]
What do we need to start towards that milestone ?
- a programming language
- a rough delimitation of the different parts
- anything else ?

- The engine will be java (while trying to avoid incompatibility with the Android dialect).

- The interpreted-at-runtime embedded-in-java scripting language has not been decided.
(Android support is the limiting factor here)
viewtopic.php?f=12&t=2866&p=48271#p48271
viewtopic.php?f=12&t=2866&p=48965#p48965

- The primary candidate for the graphics library is TWL. If it proves to be too inflexible for this project, other options may need to be explored.

- The SavedGame Editor has already broken down the game into parts, though the playable engine will organize them differently (separating multiplayer-agnostic game state, from local player's sprite states, from GUI widgets depicting the sprite states).

[Thunderr]

Could someone update the OP with the new decisions? It's getting difficult to find current information about the project.

[John Luke Pack Hard]

Hi guys, back again, the TWL wiki opened back up. Give me several weeks or so to familiarize myself with the library and I may be of some use once again.

To the topic of per-pixel beams. It does not necessarily have to be per-pixel.

We can seperate the game engine and the rendering engine. Within the sphere of the game engine operating on pure data, the distance within a given "tile" can be scaled to a single number. Say, for instance, a basic unit of 1 damage/tile length (assuming tiles are square), or in the case of breaches/fires, 10%/tile length.

When the information is sent to the rendering engine, the graphics can simply scale it back to the resolution settings.

EDIT: By the way, I checked the list of requested features, saw a new column "progress" and...

What are you guys doing?

[Vhati]

Hi guys, back again, the TWL wiki opened back up.

Heh. I'd been using google's cache and these.
http://l33tlabs.org/dist/javadoc/index. ... idget.html
http://pieintheskysoftware.com/download ... index.html
http://l33tlabs.org/themeformat.html

To the topic of per-pixel beams. [...] the distance within a given "tile" {distance between what and what} can be scaled to a single number. Say, for instance, a basic unit of 1 damage/tile length (assuming tiles are square) {aren't all distances within a tile less than that unit?}, or in the case of breaches/fires, 10%/tile length.

When the information is sent to the rendering engine, the graphics can simply scale it {it?} back to the resolution settings.

My confusion is bolded.
How does this relate to assigning damage (or reduced damage) to mobile sprites?

Hyperdrive's shocking floor suggestion is my favorite so far. And when the player draws the beam, the about-to-be scheduled squares could be highlighted.

EDIT: By the way, I checked the list of requested features, saw a new column "progress" and...

Wasn't me.

What are you guys doing?

My uncommitted test store stalled on an open question.
viewtopic.php?f=12&t=2866&start=320#p49351

DiEvAl's distracted at the moment.
viewtopic.php?f=12&t=2866&start=320#p49375

[Vhati]

@John Luke Pack Hard:
Do you mean: for each square the line passes through, assign damage to any sprites in that square equal to {weapon's base damage} * ({a falloff constant}*{radial distance of the beam's travelling endpoint to the square's center, as a percentage of the square's width})?

That could go well with the shocking floor (each square's varying damage decided upon initial scheduling, then doled out as it activates, or as new sprites enter the square while it's active).

[Estel]

Just a note - why not SDL for graphic library? It runs pretty much everywhere, hardware accelerated or software calculated, basing on machine type, it's awesomely documented, well tested in practice of zillion projects, etc.

Using JAVA is enough blow already (for mobile devices - yes, android isn't everything...) lets not limit adaptability further.

/Estel

[Vhati]

why not SDL for graphic library?

Depending on the language, bindings for that library can be ancient.
Using C to match the library, it can be a pain for volunteers that come and go to micromanage everything properly, for building and running consistently on different compilers, across multiple archetectures, and platforms (and OS/lib versions).

Article: Sparkrift - Love2D vs Allegro vs ClanLib vs LibGDX vs Cocos2D-X vs MonoGame vs XNA vs SFML vs SDL

Using JAVA is enough blow already [...] lets not limit adaptability further.

Java itself is not a limiting factor. It's doing the same sort of cross-platform abstraction you were praising SDL for, but for the entire language - and by extension, for many libs written in that language.

Android support IS presently a limitation, primarily because it uses another compiler that scripting language libraries haven't adapted to just yet (options should open up later this year).

[John Luke Pack Hard]

... The rabbit hole goes far too deep on this one...

Seems I have to learn 3 entire libraries...
On the upside, perhaps I might be able to make a living learning this.

Now, as for my ideas, I might actually be thinking about an entirely new mechanic for per-distance beams (just for clarity, i'll be referring to it by this name now).

To clarify, the basic "distance unit" I'm referring to is the single side length of a tile, or the length of a single unit of wall. Therefore, going diagonally along a tile results in 1.41 units of distance. If you have a beam that deals .5 damage/tile crossing a tile diagonally, it will deal .705 points of damage to the relevant system.

As for how we resolve floating point units of damage, I will prepare a presentation on that via google drive.

[Estel]

Depending on the language, bindings for that library can be ancient.
Using C to match the library, it can be a pain for volunteers that come and go to micromanage everything properly, for building and running consistently on different compilers, across multiple architectures, and platforms (and OS/lib versions).

I see it a little differently from my experience, sane approach is to focus on PC version for Linux/Windows, and any ports to specific platforms/OS'es should come *only* from 3rd people, interested in bringing FTL: Overdrive to their devices. If such ports are stable, their code can be, then, integrated into our "mainstream", as branch still maintained by those people.

Of course, we should plan ahead to make it easier for them - thus suggestion for using most widespread graphic library in the world, and (already considered and approved, as I see) non-hardcoded resolutions Now, there is a huge benefit to this approach - people interested in porting, usually, have 100% fresh experience with their own platform - thus, things like weird bindings and compiling hatches are known for them. Also, they have physical access to device in question (using it daily, in most cases).

Now, - again from practice - I have yet to see a real-life case, where SDL fails at this. No wonder, that countless of engine rewrite projects (from Jagged Alliance, through Homeworld, to 100% custom things like Lincity, to name a few - there are thousands others...) are using SDL.
---

Now, as for Android, I wouldn't care for compatibility with their standards-violating dialect. Adjusting to custom mess created by some over-confident corporations (google, looking at you!) is BAD practice, assuring them (and future ones), that they can make our life harder for no reason, everytime they feel fancy. After all, *if* 3rd party projects adjust to standards violations, they're, basically, legitimizing it, contributing to making bend standards even more popular.

Furthermore, porting it to Android should still be trivial for any Andro-guru (or andro-kiddo, depending on who's looking) - like it happened with many other PC-oriented projects. Sure, using Java as base language complicated thing for almost every non-Android portable ARM MPU linux device (which I'm certainly *NOT* happy about, but, I understand motivations), but it shouldn't be a deal-breaker. Or, it's just my personal dislike for Java, as opposed to other, native languages

Just some food for thoughts,
/Estel

[Vhati]

To clarify, the basic "distance unit" I'm referring to is the single side length of a tile, or the length of a single unit of wall. Therefore, going diagonally along a tile results in 1.41 units of distance. If you have a beam that deals .5 damage/tile crossing a tile diagonally, it will deal .705 points of damage to the relevant system.

As for how we resolve floating point units of damage, I will prepare a presentation on that via google drive.

I still don't see float damage there. That seems to be a multiplier, to vary the damage dealt among squares.
{weapon's base per-square damage} * {length of the beam's segment within the square, as a percentage of diagonal square length}?
You can still easily round the end result to an int for subtracting hit points.
Are you actually suggesting crew with 0.001 HP?