[MOD][WIP] FTL: Overdrive

[John Luke Pack Hard]

Alright gents, I just finished compiling all the ideas into an excel spreadsheet.

So the roundtable discussion has officially begun! Here's how it will work.

KuroSaru or I will present one of the suggested ideas and discuss how it would possibly work and how easily it can be implemented.

Then the rest of you can share your insight on the topic.

After that, KuroSaru and I will grade the idea on three subjects: feasibility, importance, and dependency. We use a 1-10 scale with this relative level of grading:

Feasibility: How easily this feature can be implemented
1 - A year
3 - Several classes
5 - A class
7 - Several functions
10 - A function

Importance: What priority this feature has in implementing/cutting features.
1 - Negligible
5 - Should be included
10 - Mandatory

Dependency: How integrated this feature is in other modules.
1 - Encapsulated in its own function/class, easily removed.
5 - Standard integration, bugfixing requires average (read - massive amounts of) work.
10 - Core Element, should be handled as Jenga blocks

In addition, there will be live discussions on the IRC channel on weekend dates at GMT 7pm. I will try to be present at most of them.

[John Luke Pack Hard]

We'll go through the list category-by-category A-Z.

The first topic: a beam projectile sprite image.

Given that the normal projectiles already have images, I don't believe this will be off from much. However, what keeps this feature, in my opinion, from a perfect 10 on feasibility, is the fact that, in order to produce a beam with a single projectile sprite, the beam has to be overlayed repeatedly from a certain angle.

This fact adds an additional level of complexity where there's more than one speed variable: projectile image speed, and beam sweep speed. However, I believe that can be take care of easily by splitting each of those variables into their respective weapondata and animations files.

I'm assuming the beam sprite will be similar to the other projectiles in the sense that the image will be static. If the beam *also* needs animation features, might as well implement that for *all* projectiles.

[kartoFlane]

Well, projectiles are already animated in FTL, so it would be a matter of extending this feature over to beams. What do you mean by projectile image speed, though? That the beam wouldn't appear instantenously, but instead "extend" towards its target, depending on projectile speed? Guess it could be useful for harpoon-like weapons...

As for beam animation, I imagine many people would find it useful. Also, beams could be more customizable - for example, instead of repeating a 1-pixel thin image (as I imgine it is done now) people could give the beam a single image (or whole animation sprite) that would span the beams length - sort of like this

[speedoflight]

Hi, im glad to see things are working out.

About beams, if u played gratuitous space battles, u will have an idea on how u can make the beam sprites. Basically u will have a sprite divided in 2 zones, the left is the effect that will be overlaped in the beam (to produce the sensation of movement and other effects that will be moving repeteadly along the first part of the main body) , and the right is the blast of the beam (top) and the first part of the main body (bottom). Lets see better with an image ->



Then u have other option , instead of that, the sprite will have just a single beam that will repeat along the beam line ->



These are examples, but can be useful and give u ideas.

Of course, the problem of this (as happened in GSB) is the transition between the blast of the beam and the moving body of the beam (the first example), can be very inconsistent, but since we have time to think of it it can be done in another way. Other problem is , the main body of the beam (the bottom-right sprite in the first example) is streched to fith the lenght of the beam, so this could be really implemented in other way, since thats one of the reasons the consistency between the blast and the main body is not really perfect.

In addition to this, will be great to be allow to control the beam body velocity, rotation, and so on..

So, if u guys can implement this on FTL (the way sprites works) will be a good place to start.

About the behaviour of the weapon, we can have different speed values, one for the time the beam fires once its charged, but this will be no sense in FTL since the point of this is to simulate a charge effect between various beams (convergence) like a super weapon (gsb players know wat im talking about). Since in FTL this doesnt exist and we only have 4 weapons, there is no utility in this.

[John Luke Pack Hard]

@kartoFlane

One of the other points was introducing scripting consistency, so I may have to bump dependency up to a two or three.

@speedoflight

Yes... you may have to clarify it... as I am not a Gratuitous Space Battles player.

[speedoflight]

@kartoFlane

One of the other points was introducing scripting consistency, so I may have to bump dependency up to a two or three.

@speedoflight

Yes... you may have to clarify it... as I am not a Gratuitous Space Battles player.

Well, its not too much to clarify, if u like those ideas, ask and i will answer if i know wat u are asking lol.

Lets see if another case of the example 2 its more clear ->

[John Luke Pack Hard]

In order to expedite the discussion, I'll be going through the list in blocks, give how so few posts are generated day-by-day.

@speedoflight, yes, I can understand. That is essentially the same method FTL uses to animate.

The last question would be how to stagger those animations, i.e., have the overlayed animations along the beam's length start at different frames.

The other two topics in the Animations category were:

Introduce better consistency in animation scripting
Animated Ship Sprites

[DryEagle]

Would it not be easier to just allow both PNG and GIF file types for images? Gifs should be perfectly fine for pixelart even with their limitations, and you can just create your animation as frames and make a GIF out of it, then load that into the game, rather than have the game bouncing between frames in an image file.

That way you can have static images for the static parts (or freezeframe the GIF if the game engine could do that, even better).

Components of a weapon animation:

1. static image, unpowered (could be 1st frame of charging gif)
2. charging animation
3. static image, ready to fire (could be last frame of charging gif)
4. firing animation

So, the ways you could do this are:

1. have a single PNG image strip for all frames, and use the software to determine which frame goes in which phase (as per current FTL)
2. have 2 PNGs for stages 1 and 3, and 2 GIFs for stages 2 and 4, and load/overlay them sequentially as needed
3. have 2 gifs, one responsible for charging animation (freezeframe the 1st and last frame for the static images), and one for firing animation
4. have a single GIF for the whole animation, and use the code to tell the game which frames to freeze for stage 1 and 3. somewhat like the png image strip except the animation timings, cycle lengths would be set in the gif file instead of as code

Animated weapon projectiles are then trivial as you can simply have a gif instead of frames of a static image for the shot. Same goes for beams.

Allowing animated gifs also gives many other benefits:
- better animation of room sprites, and no more need to have 3 layers of glow images etc
- better animation of ship gibs (think sparks coming off the different parts as they drift apart etc)
- dynamic shield images, e.g. you could have a light pulse moving across your shield
- animating parts of the ship hull e.g. spinning radar dish
well, the list could go on and on, but the advantage is fairly clear and answers all questions apart from picking what you do with weapons (i'd go with option 4 as primary choice, and 3 as secondary choice, out of the above).

[John Luke Pack Hard]

Would it not be easier to just allow both PNG and GIF file types for images?

That solves many problems, and creates many new ones. That is, GIF files add many possibilities, and code is not the kind of art that takes kindly to possibilities. In addition to weapons and laser beams, we also have all other animations in the game that might possibly benefit from this. Each of those animations requires a different sort of logic and regulation.

I believe we can cover all possibilities by allowing access to third party plugins for regulating GIF animations.

[speedoflight]

But honestly, i dont see the point of allow gif animations, since u already can have multi-sprite png files. And png is far better format than gif. A gif with a strip graphic of 20 parts will be really big in size, we need to be aware of that. U can do the same with a multi-png or a gif file, is all the same. And in that case i think png will be better and just enough. But of course u can make it compatible with gif as well, but thats another story...