Abstracting Entity System animation states

Question

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.

Answer 1

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.