[MOD][WIP] FTL: Overdrive

[Vhati]

Lets just have beam ranges in units of "box borders"

Novel. When the player draws the line: determine the squares at the start and end, and get their ship-layout coordinates; highlight up to N squares along that line, in order of distance from the start; where N is the max range of the weapon.

* In ship-layout space, determining whether a line from square (2,4) to (8,7) passes through the border of square (4,5), depends on the perpendicular distance from that square (effectively its center) to the line, and [because they're pointy] the angle of the line (distance >0.5 is outside the square when angle is 90 degrees, versus 0.707 at 45 degrees).

This way, we drop all resolution-related problems (box is box, no matter of resolution on-screen), and don't need to get into advanced math for calculating simple beam, that just does 1 damage per room.

The same trig is involved. Varying damage per-square and varying square-count per angle are comparable in that regard.

Coping with resolution was only ever a matter of multiplication by a scale, but shifting to ship-layout point space early is simpler. An API that could test the intersection of unrendered rectangles in an idealized 35px-square space with an unrendered line, could also test a line's distance to an unrendered point in ship-layout space. The programmer would have to manually account for 'corners' on the points, but it's probably the same math the API would've done had they been 35x bigger, minus all the imaginary rectangles.

And handling one damage value in a blast is a little simpler to code than handling several.

[Hyperdrive]

Hi guys !

Seems like my point about beam damage has spread like fire in a ship without door system
It's great to see that the thread is well alive

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.

We're on the same page.

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

Seconded. Is thomasfn still on the project ?

I didn't feel like learning java yet, so I started programming in python. I'm trying to make an FTL event interpreter. Nothing much, it is mostly a way to reflect on the structure of the game.

[Kiloku]

Guys, I cloned Dieval's branch, but when I tried to use the _overdrive_run.bat (after succesfully running the _overdrive_build.bat and generating the overdrive.jar), nothing happened. I edited the .bat to show the ECHOs, and here's the screenshot of my cmd window:
http://i.imgur.com/ptMxnWx.png

[Vhati]

Guys, I cloned Dieval's branch, but when I tried to use the _overdrive_run.bat (after succesfully running the _overdrive_build.bat and generating the overdrive.jar), nothing happened.

Code: Select all

The system cannot find the path specified.

Oops. Sorry.
Remove this line: "SET JAVA_CMD=D:\Apps\j2sdk1.6.0_13\bin\java.exe"
And change "%JAVA_CMD%" to java.exe


I've sent DiEvAl a Pull Request to remedy that for anyone else who comes along.

[dra6o0n]

EDIT:
Actually you can make beams even simpler.

Give beams a length in units, when this length cuts across rooms, it counts small increments of damage in the decimal values.

So a beam that's 1cm in length that takes 2 seconds to use.
It would do 2 damage per second.
Every 100ms it counts ticks as it crosses the line, and imposes damage on every base damage (1.0, not 0.5).
As a result it does 0.2 damage every 100ms for 2 seconds, resulting in 4 base damage if the entire length of the beam is within a room.

Against certain rooms the damage ticks multiply. And it does it with no reliance on resolutions, the beam cutting line can be drawn out with the ingame units or a image.

[Vhati]

when this length cuts across rooms, it counts small increments of damage [every 100ms]

A tiny dot sprite that floats across the ship in a straight path. Ten times a second, it searches for which square the sprite is currently inside, and it applies damage.

Slow beams would spend more intervals creeping across one square and would be devastating.
Fast beams would be nerfed as they skip by.

You could compensate by remembering the sprite's position from the previous interval, then calculating all the squares along that line, and instantaneously damaging them all... based on the length of the line segment passing through each... and at that point, it's at least as complicated as the rest.

And it does it with no reliance on resolutions.

Every method is resolution independent.

[Estel]

In vanilla FTL, beam does 1 damage to room, no matter if it cuts it in half, or just slipped at the edge for 0.1 second. I still don't get why you guys want to change it in *engine re-creation*. Sure, making it more "realistic" - like adjusting damage in corelation to beam path through the room - may be good idea ... For *MODS*, made possible, thanks to faithful FOSS re-creation of engine.

Changing practical results of using beam damage (end user experience) in engine re-creation itself is silly idea, IMO. Playing experience (end user one) should be as close to vanilla as possible, leaving such changes to modifications.

/Estel

[UltraMantis]

I think that is the plan. To recreate FTL as is but allow for modifications that are currently impossible. Some sacrifices may have to be made though.

[Vhati]

adjusting damage in corelation to beam path through the room - may be good idea ... For *MODS*, made possible, thanks to faithful FOSS re-creation of engine.

Mod != A recompiled engine with modified source.

The goal is to make an engine that is flexible enough that it can be scripted to mimic vanilla gameplay as well as what modders could want... without needing to alter the engine's code.

Not a re-creation with everything hardcoded to be exactly like the original FTL.

[Estel]

That's obvious - but, isn't last (few pages long) talk about beams heading into direction, when *out of the box* beams are going to work completely diferrently than in vanilla? It would be strange, if it would need mod (scripting one or not) to bring original functionality back.

Or, am I understanding it wrong?