[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 » Tue May 07, 2013 4:29 am

I just recently had a discussion with someone at r/ftlgame and it reminded me of a point I wanted to bring up:

Vanilla FTL's beams behave differently when it comes to damage and effects. Damage is applied by room, whereas damage effects (fire and breach), are rolled by tile.

I want to see what the modding community as a whole thinks about this.

So, beam behavior: keep, stricly by tile, strictly by room, optional by mod.

I will point out that it will take minimal amounts of work from we, the coders, to implement "optional behavior by mod", but I will forewarn that doing so may decrease the overall quality of the mods due to the extra layer of complexity that potential players may have to learn. Personally, if we do implement the option, I believe the modders should agree on a standard convention with warnings in mods containing exceptions to the rule.
DryEagle
Posts: 363
Joined: Thu Oct 04, 2012 11:17 am

Re: [MOD][WIP] FTL: Overdrive

Postby DryEagle » Tue May 07, 2013 10:26 am

I'd prefer all beam effects to be per-tile, that seems to make more sense. If you go across 3 tiles of a room, that should hurt just the same as going across a corner and clipping 3 rooms.

Also, not sure how possible this would be to implement, but how about beam effect based on how much of a room you hit? i.e. if your fire beam goes clean across a tile you would get a guaranteed fire in that tile, but if you just clip the corner of it you'd have 10-20% fire chance or so, based on how much of the room the beam actually covered.

That is to say, if a tile is 35px across, possible to set it so each 3-4px your beam travels across the room adds 10% chance of effect, starting from 0? or 5% if you want the max chance to be 50, etc.

Again yes this would add complexity, but on the other hand, it would be more visually intuitive and make for deeper choices when you go to attack...
All ships I have created include custom weapons, graphics etc:
Image
ImageImageImageImage
User avatar
kartoFlane
Posts: 1479
Joined: Mon Jan 14, 2013 10:20 pm

Re: [MOD][WIP] FTL: Overdrive

Postby kartoFlane » Tue May 07, 2013 10:36 am

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.
Superluminal2 - a ship editor for FTL
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 May 07, 2013 2:28 pm

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
Posts: 40
Joined: Tue May 07, 2013 6:27 am

Re: [MOD][WIP] FTL: Overdrive

Postby featherwings » Wed May 08, 2013 7:45 pm

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

Re: [MOD][WIP] FTL: Overdrive

Postby John Luke Pack Hard » Wed May 08, 2013 9:36 pm

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

Re: [MOD][WIP] FTL: Overdrive

Postby John Luke Pack Hard » Wed May 08, 2013 9:42 pm

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
Posts: 363
Joined: Thu Oct 04, 2012 11:17 am

Re: [MOD][WIP] FTL: Overdrive

Postby DryEagle » Thu May 09, 2013 1:54 pm

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.
All ships I have created include custom weapons, graphics etc:
Image
ImageImageImageImage
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 May 12, 2013 11:17 am

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
Posts: 1
Joined: Sun May 12, 2013 3:36 pm

Re: [MOD][WIP] FTL: Overdrive

Postby shinr » Sun May 12, 2013 3:47 pm

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

Who is online

Users browsing this forum: No registered users and 8 guests