[MOD][WIP] FTL: Overdrive

[kartoFlane]

Sadly, there are quite few modders to begin with...
Either way;
If I recall correctly there was an issue with per-tile effect calculation, where the same effect would be applied to the same tile twice (so, for example, instead of two fires, you end up having only one).
It can be fixed easily, though, and I think that it makes more sense that the beam spreads fire where it touches - ie. on a per-tile basis.

*shrug*
Some people might want to create weapons that behave slightly differently, though, and in the end Overdrive is about making FTL more moddable, so I think it would be good to include the optional behaviour. It wouldn't be too hard to implement it on a per-weapon basis, so instead of warning the players about changed functionality, it could be simply incorporated into the weapon's in-game description.

@DryEagle
Quite simple, could be done by having a variable store how much distance the beam traveled since entering the tile, and then dividing that by 35*sqrt(2), and multiplying that by the beam's fire chance... Though in this case the the effect would have to be applied once the beam exits the tile.
That would require Overdrive to put more emphasis on tiles rather than whole rooms, however, though doing so would ultimately make it easier to implement non-rectangular rooms. Rooms could be a simple array of tiles, and the position would be stored by each tile. Kinda makes walls a little bit tricky, tho.

[John Luke Pack Hard]

All the ideas suggested above aren't too difficult to implement, as they're all simply setting a different scale of measurement out of the same mechanic. 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.

The major argument for or against having these is the quality of the game design. One facet of good game design is that the mechanics have to be intuitive. To be more precise, in the heat of battle, the average player is more likely to think "fire beam, long beam, heavy beam" rather than, "fire and pixel beam, long room beam, heavy tile beam". True, the pause button exists, but I know that KuroSaru wants to extend this game into multiplayer, so it's important to me that Overdrive is conducive to as fluid gameplay mechanics as possible.

This is why I'm arguing towards the case of a "conventional design standard", with only *exceptions to the rule* absolutely needing to be pointed out with in-game descriptions.

[featherwings]

I'm following this project! It sounds really exciting, and I wish you the best of luck.

Just a heads up with regards to the beam question: Even in vanilla FTL there's no consensus on beam effects. Vs personnel they're per-pixel, the fire beam affects individual tiles IIRC, and damage is calculated per-room.

That said, can't honestly see why you'd want to calculate overall damage per-pixel, since a beam has a constant length per-pixel would just give a beam a fixed damage as long as you can fit the entire beam in the enemy ship. By the time beams get long enough to do a lot of swiping around outside of a ship (artillery beam, for instance) there's not much improvement in effect vs. per room/tile.

[John Luke Pack Hard]

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.

[John Luke Pack Hard]

To advance the conversation:

Augment formatting is resolved.
Verdict: 3rd-party lua/xml plugins only with pre-made plugins for vanilla augments

The next category: Beacons & Events with two topics

• Easier and more consistent scripting format
• Beacons that generate events when revisited

[DryEagle]

For beacons/events, here's a few things I'd like to see:

1. store customisation - able to set which categories appear, possibly specific items, custom prices on repairs/fuel/ammo, custom buyback % prices? so some stores are more expensive but also pay more?

2. beacon persistance - the option to set an event or thing at a beacon to repeat each time you go there (e.g. a refueling outpost event) or for enemy ships, for their status to carry over - e.g. if you jump out mid-fight, they will still be damaged on hull at least when you return, systems being repaired is ok. dead crew stay dead too.
also option to set an event to only repeat a few times, e.g. twice, then change to a different event, at that same beacon, would be good.

3. events format - I would prefer to have a quite different style to the current game event texts.
what i'd rather have is a page-by-page event coding, instead of doing whole events at once, as that gives you stacks of nested choices which is not as easy to make or troubleshoot if things break. also a unified way of dealing with all inventory aspects instead of having separate entries for fuel/ammo, scrap, and items, and crew
e.g.

Code: Select all

<eventPage name="trader1_start">
   <text>hi person, want to trade?</text>
   <choice>
      <text>for a bit of fuel i'll give you an augment and a crew</text>
      <item type="fuel" action="reduce" amount="8"/>
      <item type="augment" action="add" augmentName="nano_medbay"/>
      <item type="crew" action="add" crewName="jones" crewRace="human/>
      <eventPage load="trader1_accept"/>
   </choice>
   <choice>
      <text> ignore their offer </text>
      <eventPage load="trader1_refuse"/>
   <choice>
</eventPage>

so what this does it it lets you set up each page of an event as a separate entity. it will have text, choices, and the next page to load (or close the event window). while this is not quite what the default events system is like, it is hopefully easier to use especially when writing complex events, since there is no nesting, everything is screen by screen, so it's more logical to lay out event progression, it makes for easier looping, and it also makes for easier inventory management when you can add/remove any item type using a single set of instructions, instead of having to learn different quirks for different things.

again this is just a very rough example but it is what i think would be easier to use, even if it would be a little slower to write out the xml for each event page, it would still be clearer and more user-friendly at the end of the day.

[John Luke Pack Hard]

https://github.com/Terabix/FTL-Overdriv ... master/src

If you all wouldn't mind observing. I have created the new proposed Animation class.

It extends BufferedImage. It takes another BufferedImage as an animSheet, then splits it into a BufferedImage array based on number of frames specified.

It also applies a changeListener to the new class, FrameDriver. When FrameDriver changes a frame, Animation will advance a frame by redrawing a new image into itself.

On the downside, none of this code has been tested. I have yet to create an applet or a sample animSheet to test the capabilities of this new class.

[shinr]

Been lurking for a while, and I have a suggestion for future Postcyberpunk/Transhuman space/Eclipse Phase mods:

Make it possible to make the ego/mind/soul/AI and the body/shell of the crewmen separate, both with separate stats that either aid or hinder each other depending on the combination (ex: an AI that was designed to be an intellectual will perform even worse than a rookie in the combat-designed body).

[John Luke Pack Hard]

Been lurking for a while, and I have a suggestion for future Postcyberpunk/Transhuman space/Eclipse Phase mods:

Make it possible to make the ego/mind/soul/AI and the body/shell of the crewmen separate, both with separate stats that either aid or hinder each other depending on the combination (ex: an AI that was designed to be an intellectual will perform even worse than a rookie in the combat-designed body).

I happen to be familiar with this series.

The roundtable discussion is currently in progress, so please add ideas to the "table of requested features" found on page... 25 I believe?

I don't know how difficult the above suggestion would be. Java is an object-oriented programming language, so, at the basic level, it would be a simple matter of splitting the object "crew" into "mind" and then "body". However, from what I know from experience, code never works as you expect it.

It's not too complex, rather unique. Implementing it may give us some branching functionality to other mods (being able to transfer EXP rates, for one).

However, first, we would be charting unknown territory, so it would take some time to develop.

Second, since this affects, what I believe will become, core data and functionality, it would have to be planned before hand or developed separately off-hand. In other words, they are both their separate objects; one cannot come after the other.

Third, I do not feel that this is highly important. Should we get to developing the ego/body split idea, we would probably get to it close to last.

[kartoFlane]

I don't know if I should shy away from posting in regards to events, since I've never really dabbled in them, but I suppose the most straightforward solution would be to just implement them in the exact same way as augments - through lua. It would be a win-win situation, I think, since the script interpreter would be already in place (for augments), and modders would only have to learn one scripting syntax instead of two.

Regarding beacons that re-trigger events, it could be easily implemented in a listener-esque fashion - when a ship enters a beacon for the first time, the game sends an event notification. If the beacon has been previously visited, it sends a different notification (or have each beacon store the number of times it's been visited).
The entire system could be structured around that, and could be easily extended to cover weapons firing, hull being damaged, etc.
Modders could then choose which events (programmatic) their event (FTL) is going to use / respond to, and have different effects based on how they were triggered.

Regarding the physical/mental crew split... I like it, gives a lot of possibilities. The physical part would simply be a subclass of the mental part - it's not overly complex. Though I agree that it's not a priority.

Also, I'm following the repository on github... Can't really say that I wouldn't want to help out with coding, though I'm afraid I would be more of a hindrance than an asset, due to my complete lack of game-making experience.