# Abstracting Entity System animation states

I recently started designing a Game Engine using the Entity System paradigm, i.e. having entities as an aggregation of components, and systems that implement the actual game. Whereas I've had difficulties in various aspects, what concerns me most is the abstraction / modularity of the various Components / Systems. Specifically, let's say my Player has several animation states, eg. Walking, Sleeping, Jumping, and one type of Opponent entity has several (not necessarily the same) states as well, eg. Walking, Hiding etc.

How should I design the engine, so that it handles the various (animation) states of each entity type? Should there be different animation Systems for each Entity type? Should I use flags that signal the animation System to render the correct entity? Also, can I avoid using "hard-coded" enums for the various poses? I can see that a scripting system could probably help, but I'm almost sure there is a simpler solution.

No to different systems for each type, that's cutting the division of responsibility too fine.

This is what I'm doing in my current personal project:

There are many ways to handle state but you probably need one that makes sense to humans, or at least a bridge between human and code. You have to think of the animation system as a big blender instead of one of discrete states, for example you go from idle to walking slowly by adding 50% walk to the system and then later add 100% run.

External to the animation system you can use strings to make working with the system agreeable and easy to scripts and code alike. Internal to the system you build a mapping between that string and the animation data, this can be done with a key-value store like a hashmap (to avoid enums altogether by making the animation data the store) or with a string-to-enum lookup if you like working that way. It's all a matter of taste at that point. I prefer key-value since it can be totally data driven from XML or INI files.

To handle different types you can, at the system layer, allow for creating sets of mapping of animations so that set for "minion" and "run" for the "minion" is different than the set for "run" and "female player" type.

In summary: the animation system is generic and you only have one system; the outside world needs a friendly interface; the inside world needs to map generic states to entity types.

And my list of things I want to do but don't fit into my design yet:

TODO: mapping movement speed to animation type automatically so instead of having the main program know about "walk" versus "run" the animation system can convert "move at x speed" to the proper animation.

TODO: split animations like head and torso tracking in a transparent way.

TODO: reaction animations (like getting punched in the face) handled by the system and not the main program.

• So, you suggest using a couple of if's inside the animation system; I was previously skeptical about using dictionaries of strings (in C++), memory-wise. Having read today about hashtables though, I find your answer simple enough. Regarding, the 'blender' part: Does "adding 50% walk" mean replacing some frames with the 'walk' ones at 50% of the time? – petermer Mar 16 '12 at 21:29
• Blending is a pretty common term in animation, it literally means that you blend two (or more) base animations together to get the final output. In the 50% example I'm assuming a blend of 50% "Idle" and 50% "Walk" which would produce a half speed stroll fowards. In this way you can continuously vary movement from "Idle" to "Walk" and then "Run." Blending will later let you do things like have the lower torso running while the upper torso is shooting a gun, or waving at someone, etc... If your animation engine doesn't support blending, use this as a way to think about it and not a rule. – Patrick Hughes Mar 16 '12 at 21:39
• FYI: worrying about memory for strings in your program at this stage is wasted time, that's called "premature optimization" and generally a bad idea. Later, if strings really ARE causing a huge load they can be turned into short CRC numbers to shrink them all considerably, at the expense of debugging ease and an extra step to your build process. – Patrick Hughes Mar 16 '12 at 21:41