8
\$\begingroup\$

I'm having some trouble figuring how to deal with state management in my entities.

I don't have trouble with Game state management, like pause and menus, since these are not handled as an entity component system; just with state in entities/components.

Drawing from Orcs Must Die as an example, I have my MainCharacter and Trap entities which only have their components like PositionComponent, RenderComponent, PhysicsComponent.

On each update the Entity will call update on its components. I also have a generic EventManager with listeners for different event types.

Now I need to be able to place the traps: first select the trap and trap position then place the trap.

When placing a trap it should appear in front of the MainCharacter, rendered in a different way and following it around. When placed it should just respond to collisions and be rendered in the normal way.

How is this usually handled in component based systems?

(This example is specific but can help figure out the general way to deal with entities states.)

\$\endgroup\$
2
  • 1
    \$\begingroup\$ Can you add and remove entities' components based on input events? Perhaps you can change the trap's components when the states change. For example, while placing the trap it will have FollowComponent and RenderEffectComponnent. When it gets placed, you remove both Components and add CollisionComponent. (Edit: More clearly expressed by Martin Sojka) \$\endgroup\$
    – Asakeron
    Commented Oct 25, 2012 at 21:17
  • \$\begingroup\$ Yes, i can, every input gets translated from a "HumanView" into game events, which, most of them, get first processed by my GameLogic class, which will check for example if the MainCharacter has enough money to place a trap, how it happens after that is what i'm trying to figure. \$\endgroup\$
    – GriffinHeart
    Commented Oct 25, 2012 at 23:03

2 Answers 2

Reset to default
5
\$\begingroup\$

One interesting application of a component system is that you can change an entity's components at runtime if you designed it to be able to handle such. The state of an entity thus becomes the sum of both which components are assigned to it and which values those hold.

For your example, you can first create the trap with a BuildControllerComponent (governing the reaction to player controls in build phase), a PositionComponent and a RenderComponent. The last one has one data field which governs the pixel shader(s) used, and one of them gives the trap-to-be-build a "ghostly" look. You'll notice there are no physics components assigned yet.

Upon placing the trap, the components get exchanged. The BuildControllerComponent isn't needed anymore, so it gets removed. The RenderComponent's shaders get replaced with your normal standard view of the trap. Finally, PhysicsComponent as well as whatever else is needed for the trap to work are added to the entity.

In an inheritance-based approach, this is equivalent to having a constructor for an ActiveTrapEntity class which takes a BuildTimeTrapEntity class as its arguments, the second one being used to render the trap during building it, the first one being used for the trap after it's in place.

\$\endgroup\$
5
  • \$\begingroup\$ This is clever. \$\endgroup\$
    – Cypher
    Commented Oct 25, 2012 at 21:28
  • 1
    \$\begingroup\$ This is good strategy for applying the state of an entity. It doesn't address the issue of how to track the state of each entity. How do you know which state the entity is currently in? \$\endgroup\$
    – House
    Commented Oct 25, 2012 at 22:14
  • \$\begingroup\$ @MartinSojka This comes near what i was thinking about after asking the question. I was considering adding a BuildTrapProcess (Something that is updated at GameLogic) that will manage the runtime aspect of changing components to achieve the state changes needed to build a trap. When the button for building a trap gets pressed the game logic would create the Process and start it. any thoughts on this approach? \$\endgroup\$
    – GriffinHeart
    Commented Oct 25, 2012 at 23:21
  • \$\begingroup\$ @Byte56: In general, you can query the associated components and its values. In practice, you often only need to know the relevant subset of the whole state, for example "Does this entity have BuildControllerComponent?" or "What is the position of this entity as recorded in its PositionComponent, if it has any?" - those you do by checking the component list for the ones you're interested in and optionally querying (some of) their values. \$\endgroup\$
    – Martin Sojka
    Commented Oct 26, 2012 at 4:34
  • 1
    \$\begingroup\$ @GriffinHeart: I'd just implement whatever is needed to "build" the trap in the system associated with managing BuildControllerComponents. It already needs to process player character's (or camera's) viewpoint changes and key and mouse press events. \$\endgroup\$
    – Martin Sojka
    Commented Oct 26, 2012 at 4:39
5
\$\begingroup\$

I don't like the idea of entities calling updates on their components (systems should be doing the work), and that's going to lead to issues with keeping components unaware of each other.

You can add an additional component called "State". It will be accessed by your render and collision systems. The state component is just a flag that has multiple states available to it. For the situation you describe the states would be Play and Build. When the render system sees that the state is Build it will draw the object translucent. When the collision system sees the Build state, it will not process collisions with the player.

But really, if you don't have systems and you're relying on components to do all the work you're going to run into a lot of issues. Components shouldn't know about each other and they shouldn't be doing processing.

\$\endgroup\$
15
  • \$\begingroup\$ What you're saying is conflicting, first they should be unaware (which i agree) then you follow by having a component that is accessed by others. Can you clarify? I'm keeping components decoupled by the event system. \$\endgroup\$
    – GriffinHeart
    Commented Oct 25, 2012 at 18:42
  • \$\begingroup\$ I'm saying both. I'm saying they should be unaware and trying to tailor my response to how I think you're handling components. When you say "Entity will call update on its components" it makes me believe that you don't have systems processing entities. I've removed the confusing language and just made it say systems. I was saying components because I was understanding that that is how you were updating. \$\endgroup\$
    – House
    Commented Oct 25, 2012 at 20:39
  • 1
    \$\begingroup\$ I like the idea of a StateComponent that can be consumed by multiple systems. \$\endgroup\$
    – Cypher
    Commented Oct 25, 2012 at 20:50
  • 1
    \$\begingroup\$ It's polite to provide reasoning for downvotes. Thanks. \$\endgroup\$
    – House
    Commented Oct 25, 2012 at 21:19
  • 3
    \$\begingroup\$ On a different note, your objection to the asker's approach is based on the assumption that all component based design must update components from separate systems (like an entity system design). That is one way to do it, but certainly not the only one, and there's no reason to dissuade such an approach for a game that has no need for cache-optimizing component update loops. \$\endgroup\$
    – Sean Middleditch
    Commented Oct 25, 2012 at 21:29

You must log in to answer this question.

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