The Animation System of Velocity 2X

James Marsden from FuturLab allowed us to repost his article on the animation principles behind fast-paced 2D game called Velocity 2X. It appears that the project is based on traditional hand drawn sprite animations. Find out the reasons for this decision in the article below.

The beauty of 2D

The animation system for Velocity 2X is based on traditional hand drawn sprite animations to give the artists full control over style and fluidity. Given the wide range of actions performed by Kai, it meant that we needed to tackle potentially thousands of frames of animation.

For instance consider 360° shooting; we have 64 frames for Kai firing in all directions. Now consider all the different situations in which Kai can fire in 360°: standing, running, jumping, falling and sliding.

Let’s just take a look at Kai’s run animation, which consists of 30 frames. For each one of those 30 frames, she can be firing in any direction that requires one of the 64 shooting frames.

This means we would need 64*30 = 1,920 frames of animation just for Kai’s running and 360° shooting. That is almost 2,000 frames of animation just for one set of actions!

If we multiply that by 5 (to consider all the cases above where she can fire in 360°) we end up with an art requirement for OVER 9000 (frames of animation)…

Obviously this was impractical from both a production and physical memory point of view, so to get around this issue we split each frame of Kai’s animation into two halves. We have the bottom half (waist and legs) independent of the top half (torso, head and arms). The following image shows the actual in-game sprite sheet for Kai:

In the game we render the bottom and top halves of these sprites with the appropriate scale, offset and overlap values so that Kai appears as a single seamless sprite:

This means that we just have the 30 frames of animation for her running, and the 64 frames for her 360° shooting. The system works as long as the frames are authored in a way that they can be stitched together. Kudos to our artists for figuring out they needed to draw her back arm so it never overlaps her waist…

For those keeping stats, we have over 1000 hand-drawn frames of Kai’s animation that are stitched together at run time to give us over 10,000 total frames of motion.

Bob’s your (slightly irritating) uncle

One last note, even though this system worked for us, it was the most complicated section of code in the game. Not because of the complexity of the system, but because the human body bobs up and down as it runs. Therefore we needed offset values for the top halves to match the action of the legs in the bottom halves. These offset values needed to be hard coded for each and every frame to make sure the animation of her bobbing up and down as she runs remains fluid and seamless no matter what the player decides to do in the game.

Needless to say, this is one aspect of our codebase that I’m happy to never look at again!

It was all worth it. Check out the smooth animation in the trailer below: