How to update entity states and animations in a component-based game?

Question

I'm trying to design a component-based entity system for learning purposes (and later use on some games) and I'm having some troubles when it comes to updating entity states.

I don't want to have an update() method inside the Component to prevent dependencies between Components.

What I currently have in mind is that components hold data and systems update components.

So, if I have a simple 2D game with some entities (e.g. player, enemy1, enemy2) that have Transform, Movement, State, Animation and Rendering components I think I should have:

• A MovementSystem that moves all the Movement components and updates the State components
• And a RenderSystem that updates the Animation components (the animation component should have one animation (i.e. a set of frames/textures) for each state and updating it means selecting the animation corresponding to the current state (e.g. jumping, moving_left, etc), and updating the frame index). Then, the RenderSystem updates the Render components with the texture corresponding to the current frame of each entity's Animation and renders everything on screen.

I've seen some implementations like Artemis framework, but I don't know how to solve this situation:

Let's say that my game has the following entities. Each entity have a set of states and one animation for each state:

• player: "idle", "moving_right", "jumping"
• enemy1: "moving_up", "moving_down"
• enemy2: "moving_left", "moving_right"

What are the most accepted approaches in order to update the current state of each entity? The only thing that I can think of is having separate systems for each group of entities and separate State and Animation components so I would have PlayerState, PlayerAnimation, Enemy1State, Enemy1Animation... PlayerMovementSystem, PlayerRenderingSystem... but I think this is a bad solution and breaks the purpose of having a component-based system.

As you can see, I'm quite lost here, so I'd very much appreciate any help.

EDIT: I think the solution to make this work as I intend is this one:

You make statecomponent and animationcomponent generic enough to be used for all entities. The data they contain will be the modifier for changing things like which animations are played or which states are available. – Byte56

Now, I'm trying to figure out how to design these 2 components generic enough so I can reuse them. Might having an UID for each state (e.g. walking, running...) and storing animations in a map into the AnimationComponent keyed by this identifier be a good solution?

Answer 1

IMHO the Movement component should hold the current state (Movement.state) and the Animation component should observe changes of Movement.state and update its current animation (Animation.animation) accordingly, using a simple lookup of state id to animation (as suggested at then end of the OP). Obviously this means Animation will depend on Movement.

An alternative structure would be to have a generic State component, which Animation observes, and Movement modifies, which is basically model-view-controller (state-animation-movement in this case).

Another alternative would be to have the entity dispatch an event to its components when its state changes. Animation would listen to this event and update its animation accordingly. This eliminates the dependency, although you could argue that the dependent version is a more transparent design.

Good luck.

Answer 2

About your problem, if the STATE is only used in Animations, then you don't even need to expose that to other Components. If it has more than one use, then you need to expose it.

The system of Components/Subsystem that you describe feels more hierarchy-based than component-based. After all, what you describe as components are in fact data structures. It doesn't mean it is a bad system, just that I don't think it fits the component-based approach too well.

As you noted, dependencies are a big problem in component-based systems. There are different ways to deal with that. Some require each component to declare their dependencies and do a strict check. Others query for components implementing a specific interface. Still others pass reference to the dependant components when they instantiate each of them.

Independently of the method you use, you will need a GameObject of some sort to act as collection of Components. What that GameObject provides can vary a lot and you can simplify your inter-component dependencies by pushing some often-used data to the GameObject level. Unity does that with the transform for example, force all game object to have one.

Concerning the problem you ask of different states/animation for different game objects, here's what I would do. First, I wouldn't get too fancy at this stage of the implementation: only implement what you need now to get it working, then add bells and whistles as you need them.

So, I'd start with a 'State' component: PlayerStateComponent, Enemy1State, Enemy2State. The state component would take care of changing the state at the appropriate time. State is something pretty much all your objects will have, so it can reside in the GameObject.

Then, there would be an AnimationCompoment. This would have a dictionary of animations keyed to the state. In update(), change the animation if the state changes.

There's a great article about building framework that I can't find. It said that when you don't have experience in the domain, you should pick one problem and do the simplest implementation that solves the current problem. Then you add another problem/use-case and expand on the framework as you go along, so it grows organically. I really like that approach, particularly when working with new concept as you are doing.

The implementation I proposed is quite naive, but here are some possible improvements as you add more use-case:

• replace the GameObject variable with a dictionary. Each component use the dictionary to store values. (make sure to handle collision properly...)
• replace the dictionary of plain values with references instead: class FloatVariable() { public value [...] }
• Instead of multiple state component, create a generic StateComponent in which you can build variable state machines. You need to have a generic set of condition upon which a state can change: key presses, mouse input, variable changes (you can tie that to the FloatVariable above).

Answer 3

In addition to the answer of ADB you could use http://en.wikipedia.org/wiki/Dependency_injection, which helps when you need to construct a lot of components via passing them as references to their constructors. Obviously they will still depend on each other (if that is required in your code base), but you can put all that dependency in one place where the dependencies are setup and the rest of your code does not need to know about the dependency.

This approach also works well if you use interfaces because each component class just requests what it needs or where it needs to be registered and only the dependency injection framework (or the place where you set everything up, usually the app) knows about who needs what.

For simple systems you might get away without using DI or clean code, your RenderingSystem classes sounds like you need to call them statically or at least have them available in each component, which pretty much makes them dependent on each other and hard to change. If you are interested in a more clean approach check the links of the DI wiki link above and read about Clean Code: http://clean-code-developer.com/