8
\$\begingroup\$

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?

\$\endgroup\$
2
  • 5
    \$\begingroup\$ 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. \$\endgroup\$
    – Tetrad
    Commented Jun 15, 2011 at 19:07
  • \$\begingroup\$ @The Communist Duck, was a little low... haha \$\endgroup\$
    – hiddensunset4
    Commented Jun 15, 2011 at 23:54

3 Answers 3

Reset to default
9
\$\begingroup\$

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.

\$\endgroup\$
2
\$\begingroup\$

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.

\$\endgroup\$
2
\$\begingroup\$

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: https://github.com/thelinuxlich/starwarrior_CSharp

And the engine itself: https://github.com/thelinuxlich/artemis_CSharp

\$\endgroup\$
2
  • \$\begingroup\$ 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. \$\endgroup\$
    – Tetrad
    Commented Jun 22, 2011 at 16:56
  • 1
    \$\begingroup\$ 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. \$\endgroup\$
    – thelinuxlich
    Commented Jun 22, 2011 at 18:38

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .