Reorganize animation configfiles

[stefanbeller]

Currently we have different animation files which refer to the same image, examples are goblin and goblin runners. The only difference is the starting position of the run animation. (running and hopping).

I would favor if we would have exactly one animation file per animation spritesheet. So in the animation file for the goblins we would need to define 2 sections "run1" and "run2" (or "hopping" and "charging" , names should not matter there) and in the actual enemy definition we could match up the animations, so we connect the "run1" / "hop" section from the animation file to the actual goblins and the "run2" to the running goblin enemy.

This proposal brings advantages:

• When editing the spritesheet, you will only need to adapt one animation definition file. As of now you do not know how many files you need to edit.
• animation of enemies will be changed more easily (just switching one line from "hop" to "run"). As of now you need to exchange the animation file, which might contain multiple changed animations.

Any disadvantages or counterarguments?

[makrohn]

I'd want to see the suggested implementation. If I have to add more lines to every enemies/*.txt file with this suggested implementation, I'd rather stick to copy/pasting animations/goblin.txt and changing the frame.

[makrohn]

I also don't think I would want a 1:1 pairing - in some cases, I actually have it lower, as for instance, several of my humanoids use the same animation definition. In that commit, I'd want just animations/ant.txt, so that I could apply it to ANY ant, fire, ice, or whatever.

[stefanbeller]

The approach with copying the definition files only works if the animation images are all setup the same way. I intend to change this by shrinking the images as much as possible. (Maybe this makes sense to do only in the minicore mod?), so the animation definitions will definitely not fit as the shrinking will be different because the images have different sizes.

[makrohn]

ok, and I see the substituteAnimations=, that makes sense.

[stefanbeller]

The just appended commit shows what I mean:

• The goblin_runnter.txt was deleted as it was nearly all the same as the goblin.txt definition file.
• The running section was added to the normal goblins as "run1"
• goblins which actually use the run animation, need to use the run1 section instead of the run section directly, so a substituteAnimations= was introduced.

[stefanbeller]

The very first commit referencing this issue just introduces one definition file per actual image, so we have the 1 on 1 matching. Indeed that introduces some lines, which at the moment all look the same, but on image reorganisation these files will look different for each image.

[clintbellanger]

Example counterarguments:

• This is essentially a clever data-only trick to have two different types of moving goblins.
• It would be much better for the gameplay if the two goblin types actually had different art instead, so when they're standing still the player could tell what type of fight to expect.
• We're adding code complexity to deal with a one-off data trick that may never be used again
• People may discover other new tricks by having animations decoupled from sprite sheets.
• Existing sprite sheets are almost never edited in a way that requires changing animations, so that's nearly a moot point.
• Now you require one animation per visual variant (e.g. fire ant, ice ant, regular ant). We're back to more duplicate animation files than before.

When people try new things with the engine, they are going to figure out weird ways to bend the expected data rules to get new things showing up in game. I think we need to only integrate those features into the engine when they seem highly important.

[clintbellanger]

Another possible issue that I haven't really raised yet.

Right now we're allowing animation speed to be increased by a percentage, that gets applied through all the animations. It was a great idea, but unfortunately in practice it's really poor. Example: Zombie Brutes walk fast and that's quite fun, but when they die fast it looks wrong.

It's likely we'll remove that animation speed % and go with different animation files instead. Example, zombie_fast.txt or zombie_slow.txt so that each animation can be tweaked.

[igorko]

@stefanbeller I would better put more effort to spritesheets compressing. This idea about animation configfiles reorganization is a little hackish and can confuse moders.

[stefanbeller]

@igorko I am putting effort into spritesheetcompressing. The problem which arises is the problem of multiple definition files using one png (so the tool needs to rewrite multiple definition files, so big deal, but the same definition file is used for another image, which is packed completely different, hence it doesn't work.) so maybe we should not aim for a one on one connection, but rather make sure that one animation defintion file must not be used for more than one png?

[clintbellanger]

Not that it's highly necessary, but would it be possible to compress some sprite sheets exactly the same way? Example, fire + ice + regular antlion are all the same exact pixels, just different colors. It's not a big deal though -- in this case, it would be fine to simply use three animation files. The engine would support that as it currently works.

[stefanbeller]

I did not know that all three kinds have the same widths and heights, so compressing them the same way makes a lot of sense, then we can use only one animation for the 3 antlions.

I guess this is not the case with goblins and elite goblins on the other hand? So there we'd still need to duplicate the animation definition files.

[clintbellanger]

The elite goblins are larger than the regular goblins. The skeleton varieties hold different items and that affects their total sprite size. In both of those cases, we'd expect those creatures to need different animation files when the sheets are packed.

[igorko]

I think the best way would handle spritesheets in the same way as tiledefs. Add spritedefs folder with txt definitions and link each enemy with such definition. If no spritedef present, use standard behavior(current). Animation definitions will stay the same, as they depend only on frame index and number of frames.

[stefanbeller]

I just extended the tool I wrote to handle multiple images for one animation definition file. I'll run the tool for the images and later this weekend I'll present a patch on what would be changed.

[stefanbeller]

In https://github.com/stefanbeller/flare/commit/ec61b1119fc197db446f0e713bb43a90d0ccf5c4 I converted these images.

• cursed_grave.png
• wyvern.png
• zombie.png
• ice_ant.png, fire_ant.png, antlion.png
• minotaur.png
• wyvern_adult.png
• antlion_hatchling.png

I did not touch the flare source code, and I did not introduce new animation definition files for the different antlions, but used one definition file for all three kinds of antlions.

In cave of living bones 1: (That level has 3 types of antlions, so proves my point well :P) Without that patch applied: 200MB and roughly 25 % CPU load. With patch applied 104MB and roughly 23 % CPU

Now still missing: skeletons and goblins. I'll see if I can help out there, without much overhead. For the skeletons, having different outlines I think we need to introduce new animation definitions, let's see.

[clintbellanger]

So upwards of HALF memory savings on maps with a large variety of monsters? That's superb. Your packing code may actually allow some Flare games to run on entirely new devices. Kudos!

[stefanbeller]

So as of now I converted all enemy animations, except the goblins.

To measure the memory I started the game and loaded the same character again and again on different maps. (So I did not walk around and measured, but the numbers are taken after loading the map after character selection screen.)

Memory Improvements:

Cave of Living Bones 1: 89 / 200M = 0.44 Averguard Academy: 90 / 185 M = 0.48

Averguard Prison: 138 / 232 M = 0.59 Averguard Complex: 143 / 230 M = 0.62 Goblin Warrens: 146 / 202M = 0.72 Ydraka Pass 147 / 181 M = 0.81 Averguard Atrium: 139 / 158 M = 0.87

You can see memory improvements from only 44 percent of the original memory amount used up to still 87 percent of the memory amount used.

The first two maps do not contain goblins, so these values are final. The other maps contain goblins, which have not been reduced yet, so these values might become a little better yet.

[stefanbeller]

The pull request was closed here, as the repositories are moved. See pullrequest https://github.com/clintbellanger/flare-game/pull/1