Saturday, 3 March 2012

My experiments with 2d animation

Recently I was playing with the thought to start developing a new game, now that the previous one is finished. One of my ideas is a 2d sidescroller platformer game, similar to the 2d mode of Alice: Madness Returns, with some inspirations from Trine. After considering different options I decided that I would develop my own game engine (I like programming, so that would be the funniest part anyway:), that would use Box2D for physics, Lua for scripting and OpenGL with shaders for rendering.

While planning the game I was thinking much about animation. For The Silliness of the Lambs I have done some basic animations, but they are quite ugly, and creating them was a bit tedious. I realized that drawing animations frame by frame is not my slice of bread, so I was looking for other ways to do it. I wanted something like drawing parts of a character (like body, head, arms, legs), and then putting them together in different poses to form an animation.

Since skeletal animation is the most used method for 3d animations, as a first attempt I designed a 2d skeletal animation system. In this system every character would have:
  • a skeleton: a hierarchical set of bones, defining the main structure of the character
  • a 'skin': a set of images; each bone would have an image
  • poses: a pose would define the position of each bone related to their parents
  • animations: a sequence of poses and the interpolation times between them would form an animation
The advantages of this system would be naturally looking animations, and that the skeleton could be used for ragdoll effects. Existing tools could also be used for this, the animations could be created in a 3d editor, and an engine like Ogre could play them. But I don't have much experience with 3d editors, and I thought that Ogre would be overkill for a simple 2d game, so on paper I designed an animation program that I could use to edit skeletons, skins, poses and animations. After that I realized that I did not really want to implement a such complex program just to create animations, and that this whole system was too complicated.

So I started to think about a simpler method, and I realized that a skeleton is not really needed for an animation, so I designed a new system without a skeleton. In this system the basic structure is the 'animation'; different animations for a character are not related. An animation consists of a set of parts (images), several frames, and the interpolation times between the frames. A frame defines a transformation (translation, rotation and scale) for each image, and these transformations are interpolated between frames (by the way I have learned that interpolating angles is not just that simple...).

This new system does not have the advantages of the previous one, but it was much more appealing for me, so I implemented a simple editor for it. I used Java , because that's what I like to use to create programs with GUIs.

Adding the first part

The left area is for handling the parts. Parts can be added, deleted, named and put in order (the order is important when drawing the animation, it defines the drawing order). The upper panel is the palette. Parts can be selected from the list on the left, and the desired operation on them can be performed with the mouse.

Some more parts, named, ordered, moved and rotated

The area below the drawing canvas is for handling frames (adding, removing them, and setting the duration between them). The transformation operations on the parts always modify the current frame.

Adding and editing frames

The most exciting part of the GUI is the Play button, if it is clicked, a new window is opened which plays the animation. I have recorded a short video of the animation of the wizard that you can see in the pictures:

Yeah, it's quite simple, not really naturally looking, but much easier to create than drawing each frame manually, and easier to use than the skeletal version.

Hopefully one day you will see a game featuring animation created with this program :)


  1. Nice! I wonder what is the unexpected difficulty with interpolating angles?!

  2. When interpolating angles there are two possibilities: you can go clockwise and counter-clockwise, one of them will be shorter and the other longer (except when the difference is 180°).

    For example if you just naively interpolate from 10° to 350° then the object will rotate 340° (counter-clockwise). If you interpolate from 10° to -10° then the starting and ending angles will be the same as in the first case, but the rotation will be only 20° degrees, clockwise.

    I wanted to always have the smallest rotation, so I had to implement the logic which chooses the smallest rotation.