[MOD][WIP] FTL: Overdrive

[Hyperdrive]

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

Where did you read that?

page 26 :

I just had a thought about per pixel damage vs damage repair behaviors.

In a sense, damage already functions on a floating-point basis;

• When crew repair an system
• When boarders damage a system
• When fire damages a system

Each one progresses by slowly turning a unit of power (a bar on the interface) red or yellow, based on damage or repair. When the action fully fills the bar, the system is repaired a unit or damaged a unit. If the action's source is extinguished, the bar reverts back to its original state of damaged or intact.

To integrate per-pixel damage, all we simply have to do is
1. Incompletely damaged or repaired power units don't have their progress reverted if the operator source disappears.
2. Per-pixel damage beams inflict damage in the same style of fires or boarders as they travel along a room.

This only requires coding the systems so that "system damage" and/or "hull points" is/or stored as a floating point value. Nothing too intensive.

I also found the idea of per-pixel damage for beams strange. Can you imagine ? "Yeah, I play with the maximum screen resolution. I need to put three screens side by side, but I have a über beam that does 200% damage"

[Vhati]

The difficulty I might envision is that beams would need some indirect form of damage measurement if they dealt effects on a per-pixel basis, and would *definitely* need floating point decimal numbers in there at some point.

This only requires coding the systems so that "system damage" and/or "hull points" is/or stored as a floating point value. Nothing too intensive.

Part proposal, part rebuttal...

Beams are particularly troublesome in that they aren't instantaneous, and crew/drones are moving targets.

A) Calculating the beam intersection based on the endpoints to declare a 'hit' when the line segment is at least half a sprite/square's width (see pic) is confounded if they dodge in advance or break contact early by limping away.

Beam.png

B) Pixel tallying is dependent on how often collisions are being checked, so a slooow beam would do massive damage to stationary targets repeatedly hitting the same pixels, and a fast one would skip.

You could combine the two by remembering where the beam was at the last collision detection, imagining a line from {there} to {where it is at this moment}, counting intersected pixels, adjusting the pixel total for resolution scaling (i.e., room-square width). Then assign damage based on that total and float multipliers (a per-weapon attribute, circumstance modifier, etc).

That doesn't mean the final HP value needs to be float; just round to int.

Likewise the repair/sabotage progress is also an accumulation of ints toward a goal, which only affects a system upon completion. In FTL:Official, normal fire ignition (of empty squares by existing fire) counts 0-100, then spawns a fire sprite. To treat beam vs system the same way would mean hitting enough resolution-adjusted 'pixels' in a pass to meet a quota for system damage. I guess a weapon would have separate multiplier attributes to use against crew, hull, and systems.

Breaches are all or nothing, so they're more like setting odds in a 'pixel'-to-play lottery. Beam fire chance could be a per-weapon multiplier to increment ignition, but more likely it'd also be a spawn lottery like breaches.

There'd be an object tracking these quotas across collision detections for a pass, to know how many 'pixels' in aggregate were hit within each square/system-room. Non-beam weapons could use multiplier attributes in the same way, except using a hardcoded constant in place of 'pixel' counts (e.g., a bomb always hitting X in every square of a room for hull, and Y of every square for crew, etc).

[Hyperdrive]

Beams are particularly troublesome in that they aren't instantaneous, and crew/drones are moving targets.

A) Calculating the beam intersection based on the endpoints to declare a 'hit' when the line segment is at least half a sprite/square's width (see pic) is confounded if they dodge in advance or break contact early by limping away.

Beam.png

B) Pixel tallying is dependent on how often collisions are being checked, so a slooow beam would do massive damage to stationary targets repeatedly hitting the same pixels, and a fast one would skip.

I guess that's a real problem. I suppose what should be considered for crew/drones is the square they are in and not their exact pixel position ; I think that's how vanilla works.
To avoid the moving target problem, a square hit by a beam could have a flag ; at every instant, any crew/drone/system present in the flagged square takes damage and the square memorizes the damaged target(s) so that damage in not applied a second time. When the beam leaves the square the flag is removed.
The difference with this :

You could combine the two by remembering where the beam was at the last collision detection, imagining a line from {there} to {where it is at this moment}, counting intersected pixels, adjusting the pixel total for resolution scaling (i.e., room-square width). Then assign damage based on that total and float multipliers (a per-weapon attribute, circumstance modifier, etc).

That doesn't mean the final HP value needs to be float; just round to int.

is that in your proposition, a square that the beam just grazes (crosses for less than 1 square length) takes no damage at all. In vanilla, it is sometimes hard to know whether the beam will cross a room (and it would be an improvement to be informed) ; but it would also be hard to know whether the beam will cross long enough in each room.

[Thunderr]

it would also be hard to know whether the beam will cross long enough in each room.

Maybe you could find a way to highlight the affected squares?

[Vhati]

counting intersected pixels, adjusting the pixel total for resolution scaling (i.e., room-square width).

in your proposition, a square that the beam just grazes (crosses for less than 1 square length) takes no damage at all.

Not so.
I mentioned resolution scaling (i.e., the ratio between room-square=35 and room-square=70) to standardize the maximum possible found pixels in a square. Grazing would count, a little, but it would not count more at high resolutions. Example: Hit 12 pixels at double-res anywhere in a square, count that as 6, this weapon subtracts 0.8 hp per 'pixel' from crew = -4.

The first approach A) was only there to introduce evaluating pieces of the line.
Not really to propose corner-ignoring as shown in the image.
I was mainly trying to imagine how pixel counting could be made to work in practice.

a square hit by a beam could have a flag ; at every instant, any crew/drone/system present in the flagged square takes damage and the square memorizes the damaged target(s) so that damage in not applied a second time. When the beam leaves the square the flag is removed.

A sequence of painful floor tiles on a timer.
Also a good idea.

A) could be used for that, to find whole squares that were hit directly enough, when initially scheduling the sequence.

[Hyperdrive]

Well, I saw the planned scripting features list, and other documents, and it's good that we have some planning and concertation . But I haven't found if the programming language (and the scripting language if the programming language is not interpreted) has already been decided.
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, since it'd be open source.
What do we need to start towards that milestone ?
- a programming language
- a rough delimitation of the different parts
- anything else ?

[kartoFlane]

It is my understanding that the project is already past that phase. Overdrive's core engine is being written in Java, with scripted extensions to add key features as well as mods.
Reading through several last pages of this thread may give you an estimate of how the work is progressing.

[Estel]

Just wanted to say that i support this project from deep of my heart, especially, that I'm FOSS activist and enthusiast.

At the same time - despite that I'm very grateful for Authors due to bringing this game to us all-together - I'm really disappointed, that rebuild author needs to RE everything, instead of getting source code of vanilla game released. With all due respect, if Relic was able to do it with Homeworld (thus HomeworldSDL was born, and now I can play Homeworld natively *everywhere*, including my debian-based mobile "phone" [!!!]), our dear original Authors surely could do it with FTL.

After all, opened sources of game still require original game assets (no change from "we need to reverse-engineer" state), and as OP have written, if anything, it would only make developers more money. Not to mention, that it would be quite a nice way of saying "thank you" for loyal fans, kickstarter founder, etc. Really, really, shame on you, for. that such titanic work of reverse-engineering is needed, if actual engine sources could be made available in no time (and no loss for anyone).

Nevertheless, keeping my thumbs for this engine rewrite!

/Estel

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