A Data-driven Animation Manager

Introduction
An animated character in a game is usually made up of more than one animation sequence. These sequences (or states) normally represent a distinct movement of the character, such as jumping or walking. When the sequences are chained together in game they provide a realistic animation. For example a character may run, then jump followed by a skid when they land, this whole animation could be created by chaining 3 or 4 separate sequences. As game development progresses characters can gain extra sequences (e.g. jumping and shooting) and sometimes a series of events may force you to make a decision about which animation should be played, do we perform the rolling animation when the character lands, or the skidding animation? If these decisions are hard coded into the game logic, they can be troublesome to alter.

This article explains a simple data driven animation manager which is designed to make adding/removing animations easy, without requiring heavy changes to the code.

The manager is a layer between the game state and the graphics engine. It takes as input the character state, and as output it plays the right animation sequence from the character animation set. It can be used in combination with any engine.


Implementation
To keep the explanation simple, we are going to use plain C-style enums to represent states and events. A more elegant implementation could be achieved in higher level languages (such as C++) with a signal/slot implementation or member function pointers (e.g. boost::signals, boost::function). Also dictionary style data types (e.g. std::map, std::tr1::unordered_map) could simplify the implementation. Some graphic engines have an index number for each animation sequence .Each state of the manager can match an animation sequence, this way we don´t need to define our own, duplicated states.

We need access to an array of states that the character can be in, and also a list of all the possible triggers that may cause that state to change. These states and events are used in the event table.

The key to the animation manager is an event table which holds the following values:

• The initial animation sequence ( this event can only be triggered from this state).
• The change condition (what happened that would cause this sequence to change?)
• A priority (if the conditions of several animations are fulfilled in the same game frame, which to use?)
• A final animation sequence

The event table can be loaded at runtime from file (which is the more flexible method) or stored statically in an array, like so: //Array of events. int events [] [5] = ( / / Initial state , change condition ,priority, final state (ANY_STATE , TRIGGER_LEFT_PRESSED , 10 , LEFT_START), (JUMP_START, TRIGGER_ANIM_FINISHED, 200 , JUMP_CYCLE), (SKID_CYCLE, TRIGGER_SKID_FINISHED, 100 , SKID_END) ... ... ) From this event table we can associate a state, with a series of conditions (triggers) that may cause that state to change. The following logic can then be used to calculate the correct state to change to during the game loop: for(each event associated with the initial state) { if(IsFulfilled(event[change_condition]) && event[priority] > priority_of_the_current_state) { current_state = event[final_state]; } } “IsFulfilled” would simply return true if the change condition had occurred that frame, e.g. switch (change_condition) { case TRIGGER_LEFT_PRESSED: if left key pressed, return true. case TRIGGER_ANIM_FINISHED: if the current animation has finished, return true. case TRIGGER_SKID_FINISHED: if you are skidding, return true. ... ... ... } This implementation provides an efficient, extensible and flexible way to control animation sequences.