Subset Games Forum

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.

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

Where did you read that?

Vhati wrote:

Hyperdrive wrote: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 :

John Luke Pack Hard wrote: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"

John Luke Pack Hard wrote: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.

John Luke Pack Hard wrote: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.

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

Vhati wrote: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 :

Vhati wrote: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.

Hyperdrive wrote: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?

Hyperdrive wrote:

Vhati wrote: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.

Hyperdrive wrote: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.

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 ?

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.

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