Subset Games Forum

Why over-complicating? AIUI, we want to work around problem with vanilla version, that beam range was set in pixels (which work for fixed resolution, but fail, if we want to allow custom resolutions). Still, beam was meant to do n (literally, n, no 1.45n or 0.47n. or whatever) damage for every room it passes through, and I see no reason why we would need to change it, doing FOSS engine *re-creation*. If someone doesn't like the way beams are working now, creating mod for FOSS game should be trivial.

Lets just have beam ranges in units of "box borders" (aka segment border, as in smallest "box" in FTL, which can be occupied by 1 crew member at a time). for example, 4 box borders of length for this beam weapon, 3 for that, etc (vanilla does exactly this, just uses pixels). If someone set beam diagonally, he "loses" due to bigger part of beam going through single square, but possibly "wins" due to possibility of hitting exactly the systems he want (and/or more systems, depending on way they're arranged on enemy's ship).

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

/Estel

// Edit

Of course it's exactly as simple for crew members occupying squared hit by beam - crew just get his equivalent of n hull damage.

Estel wrote:Why over-complicating?

Come to think of it that *is* a valid concern.

I remember the original argument stemmed from me having a discussing with a modder in IRC. Something about how beams behaving inconsistently.

Estel wrote: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).

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

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

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

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

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

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

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.

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

dra6o0n wrote:And it does it with no reliance on resolutions.

Every method is resolution independent.

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

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.