# How granular should entity states be?

I'm writing a component-based entity system and one of the components is the entity's state, which dictates how it reacts to game events. In case anyone has experience with implementing states, how granular should they be?

To give you an idea about how granular they are in my case, I have a WalkingLeft state and a WalkingRight state (as opposed to simply a Walking state) and I fear that they might be too granular. What do you think?

• Is each state a component, or is there one component which keeps track of the state (in other words, can I attach both the WalkingLeft and WalkingRight components to the same aggregate object)? – user1430 Aug 2 '11 at 4:56
• @josh Currently, each state is its own component. However, the design is subject to many changes since I'm still debating it. (Entity has a pointer to an EntityState object; that pointer can point to any implementation of the base state class.) – Paul Manta Aug 2 '11 at 6:16
• What if the entity is a bird, or a boat, or a projectile? They don't "WalkLeft" – Maik Semder Aug 2 '11 at 6:49
• "WalkLeft" sounds like a state of an animation-controller component, so better store it in this component, if you store it in the entity, you might have the situation, that 2 components have different ideas of the current state, i. e. The health component might be in state "super power mode", still the entity is "walking left" – Maik Semder Aug 2 '11 at 6:59
• Another for thinking you shouldn't have a component to represent the state. I have a 'player controller' component, and that stores the state of the player, which is a node on this graph. omnisu.com/PlayerStateFlowchart.jpg – Blecki Aug 2 '11 at 12:22

It should be as granular as you need the entities to be.

That means that if you don't ever have a case where an entity can walk to the left, but not to the right, you shouldn't split it up and just keep the "walking" component since anything else will just add unnecessary overhead.

And don't worry about how to find out what you're going to need in the future: The advantage of an component based model is that you can very easily exchange and split up small parts.

Always keep in mind: These kinds of architectures are not there to make your code look prettier, but to help you achieve what you want faster and more easily, plus less bug-prone. Splitting up walking to walking left and walking right if you don't ever need it has neither of the qualities above.

I'm writing a component-based entity system and one of the components is the entity's state

You have missed the point. In a component based system, the entity's state is parceled and distributed among different components, each of which has a well-defined and limited data storage and processing task. There is not one component that is "the state component".

As to how many you need, the only correct answer is exactly as many as you need to implement your game logic.

• I'm not sure that we're not just debating terminology here... My state just gets sent events from the EventManager and, based on those events, it gives instructions to the Entity. Isn't that pretty much what a controller component does, except I called it a 'state' instead? – Paul Manta Aug 2 '11 at 14:30
• @Paul Calling it a state is definitely a problem when it is not really a state at all and in fact a controller and you expect others to understand what's going on. – doppelgreener Aug 2 '11 at 14:42
• Seeing as it causes so much confusion I was planning on changing its name anyway. Now it's called a 'controller'... – Paul Manta Aug 2 '11 at 14:50