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?
Answer
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.
No comments:
Post a Comment