Game Development Stack Exchange is a question and answer site for professional and independent game developers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Component-based entity systems are all the rage these days; everyone seems to agree they are the way to go, but no one really has a definitive implementation of such a system. I was wondering, what role do entity states (walking-left, standing, jumping, etc) have in a CBS? Do they act like controllers (i.e. they handle events and change the entity's attributes based on those events)?

What about cases where a state would, for example, require that the entity enters no-clip mode? Should, that state, when it enters, maybe set the CollisionComponent of the entity to a null pointer or something? (Then, on exit, the state should restore the entity's CollisionComponent to its previous state.)

Also, I guess it's the current state's job to change the entity's state to something else, right?

share|improve this question
I would argue there's no "definitive implementation" because all games have different requirements, and each decision you make in the design of a system has its own set of tradeoffs. Just do what make sense to you, and be sure to refactor when things get messy. – Tetrad Jun 15 '11 at 19:07
@The Communist Duck, was a little low... haha – dcousens Jun 15 '11 at 23:54
up vote 9 down vote accepted

I was under the impression that in a components based design the entities are essentially components containers (with possibly some message thrown in). Viewed from this perspective the each components would store a little of the state. For instance if the ghost-behavior-components decides it needs to enter the intangible mode it also sends a message to the physics component telling it to enable no-clip. It would probably also send a message to the ghost-model-components telling to kick up the alpha.

share|improve this answer

State machines and components are orthogonal techniques. You can have states in your components or not, just as you can have states in any class. You can have a component observe (see Observer Pattern) and change another component's state. State machines have many uses and the implementation will depend on your needs.

For character the character states you described (walking, standing, jumping), I have seen implementations where the various components all maintain their own state machines... physics, animation, controls, ai. The components should have a clear authority about which other components they react to, and which component states they can change.

share|improve this answer

Design Components as structures with data only, no logic more complex than getters and setters. Don't create dependencies between Components or you'll end losing most of the benefits of an Entity System.

See an example of this approach(close to t-machine vision) here:

And the engine itself:

share|improve this answer
I pretty strongly disagree with "no logic more complex than getters and setters", but I'm coming from the Unity frame of reference where everything is a component. I would think that components should be able to manage themselves. – Tetrad Jun 22 '11 at 16:56
It is because Unity does not have anything as Systems attached to the game itself, which process the entities whose components compose the system aspect. – thelinuxlich Jun 22 '11 at 18:38

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.