State changes in entities or components

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.)

Answer

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.