[MOD][WIP] FTL: Overdrive

Discuss and distribute tools and methods for modding. Moderator - Grognak
John Luke Pack Hard
Posts: 112
Joined: Thu Nov 15, 2012 8:45 am

Re: [MOD][WIP] FTL: Overdrive

Postby John Luke Pack Hard » Sun Jun 23, 2013 11:58 am

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
Posts: 792
Joined: Thu Oct 25, 2012 12:01 pm

Re: [MOD][WIP] FTL: Overdrive

Postby Vhati » Sun Jun 23, 2013 3:35 pm

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


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


John Luke Pack Hard wrote:EDIT: By the way, I checked the list of requested features, saw a new column "progress" and...
Wasn't me. :)


John Luke Pack Hard wrote: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
Posts: 792
Joined: Thu Oct 25, 2012 12:01 pm

Re: [MOD][WIP] FTL: Overdrive

Postby Vhati » Sun Jun 23, 2013 3:48 pm

@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).
User avatar
Estel
Posts: 465
Joined: Sat Jun 22, 2013 4:03 am

Re: [MOD][WIP] FTL: Overdrive

Postby Estel » Sun Jun 23, 2013 5:35 pm

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
Posts: 792
Joined: Thu Oct 25, 2012 12:01 pm

Re: [MOD][WIP] FTL: Overdrive

Postby Vhati » Sun Jun 23, 2013 7:17 pm

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

Estel wrote: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
Posts: 112
Joined: Thu Nov 15, 2012 8:45 am

Re: [MOD][WIP] FTL: Overdrive

Postby John Luke Pack Hard » Mon Jun 24, 2013 11:27 am

... 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.
User avatar
Estel
Posts: 465
Joined: Sat Jun 22, 2013 4:03 am

Re: [MOD][WIP] FTL: Overdrive

Postby Estel » Mon Jun 24, 2013 1:17 pm

Vhati wrote: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
Posts: 792
Joined: Thu Oct 25, 2012 12:01 pm

Re: [MOD][WIP] FTL: Overdrive

Postby Vhati » Mon Jun 24, 2013 4:09 pm

John Luke Pack Hard wrote: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?
User avatar
Estel
Posts: 465
Joined: Sat Jun 22, 2013 4:03 am

Re: [MOD][WIP] FTL: Overdrive

Postby Estel » Mon Jun 24, 2013 9:36 pm

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.
John Luke Pack Hard
Posts: 112
Joined: Thu Nov 15, 2012 8:45 am

Re: [MOD][WIP] FTL: Overdrive

Postby John Luke Pack Hard » Tue Jun 25, 2013 12:45 am

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.

Who is online

Users browsing this forum: No registered users and 5 guests