Jump to content

  • Log In with Google      Sign In   
  • Create Account


A Data-driven Animation Manager

By Diego B.S. | Published Oct 20 2009 02:07 PM in General Programming

animation state event change sequence character game events sequences
If you find this article contains errors or problems rendering it unreadable (missing images or files, mangled code, improper text formatting, etc) please contact the editor so corrections can be made. Thank you for helping us improve this resource

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.


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

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)
    if left key pressed, return true.
    if the current animation has finished, return true.
    if you are skidding, return true.

This implementation provides an efficient, extensible and flexible way to control animation sequences.


Note: Please offer only positive, constructive comments - we are looking to promote a positive atmosphere where collaboration is valued above all else.