The HotCW Animation System

For the past few weeks I’ve been working on improving the Heroes of the Cold War animation system.  This is a huge part of our engine, and has also caused us more trouble than almost any other part of the game over the course of its development.

In previous versions of the game the artist would export each individual frame of animation as a 128×128px PNG image.  These images were then combined into a number of larger (2048×2048px) sprite sheets.  For each set of these sheets (there was one “set” per character) we would have a .xml file defining a set of animation sequences.  For example, to define an animation sequence called “bc_alert” going from frame 0 to frame 9 on a 2048×2048 sheet using 128×128 frames we would add the following to our xml file:

<sheet size="2048" spritesize="128" name="civ_e_m_01_bc_combat">
<sequence startframe="0" endframe="9" name="bc_alert" />
</sheet>

This worked, but we ran into a few problems.  We wanted to be able to create animations that were not constrained to the 128px width and not constrained to a square.  Death animations are a good example of this, when the character fell over he would fall off the edge of the sprite, and the only way around that was to move to a 256×256px frame, adding tons of wasted whitespace to the sprite sheets.  We also needed to streamline our content pipeline as the system we were using required the animator to keep track of which animation started and ended on which frame, and manually add those to the .xml file.  We also began to run in to memory usage problems, we had to have a large number of these sheets loaded into memory at the same time.

We realized that with some animations there was a lot of extra white space on either side of the character that was being wasted, some sprite sheets had large blank sections because there was not enough space on the sheet to fit the next sequence in its entirety (sequences could not span multiple sheets).

Setting out to fix all of these problems I wrote a new animation system from the ground up, as well as easy to use tools for the artist to use to build the animations into a format that would be useable in game.  This new animation system solves many of the problems we had with the old system by trimming excess whitespace from each frame of the animation, searching for duplicate frames and removing them, displaying one frame for twice as long instead of displaying two identical frames, and allowing sequences of animation to span more than one sprite sheet.

The tool that does all of this writes metadata to a separate file (a .WHAT file) which is later loaded by the game engine and used to correctly draw the animations.

This new system does increase the ammount of processing power used by the animation system, for example just determining where to look on the sprite sheet for the next frame takes quite a few more steps than the old system.  However our game isn’t terribly cpu-intensive, and this new system allows us to overcome some limitations of the old system as well as reduce memory usage by storing fewer sprite sheets in memory while the game is running.  Overall I think the slightly increased processor usage is outweighed by the benefits of the system.

Below is an example of a sprite sheet from the old system (containing 247 frames (of a maximum of 256) of animation) and an example of a sprite sheet using the new system (containing…a lot more frames of animation):