I've begun stabbing at a "Component Based" game system.

Basically, each entity holds a list of components to update (and render) I inherit the "Component" class and break each game system into it.

RenderComponent - Draws the entity
MovementComponent - Moves the entity, deals with velocity and speed checks
DamageComponent - Deals with how/if the entity gets damaged...

So, my system has this:

Now maybe my design is off, but the InputComponent should say things like

if (w key is down)
    add y speed to movement

if (x key is down)
    Trigger primary attack

This means that the InputComponent sort of relies on these other components. I have to do something alone the lines of:

if (w key is down)
    MovementComponent* entityMovement = mEntity->GetMovement();
    if (entityMovement != NULL)
        add y speed to movement

which seems kinda crappy every update.

Other options? Better design? Is this the best way?


  • \$\begingroup\$ Make an InputController system that knows to act on the entity the player is controlling, and hooks into how you normally handle actions. \$\endgroup\$
    – ccxvii
    Commented Nov 26, 2012 at 9:47

1 Answer 1


"Input" isn't really a feature, it's data that components can use. The way I handle input in my game's component-based entity system is that I send a UserInputMessage to all components, and they can manage it themselves.

If you don't have a messaging system, just add a virtual method to your Component class that takes in the current keyboard/mouse state and add it in later.

As for component dependency in general, you can send a message to all the components in an entity when a component is added or removed, and those components can store the reference. That way you aren't constantly requesting different component types.

Again, if you don't have a messaging system, just make it a virtual method.


In general, the purpose of a component-based entity system is to decouple features and functionality from each other. Obviously, when you build the system up and start working on the actual game, there are going to be some dependencies, but when you see that a component is a dependency of basically every other component, you're defeating the purpose of the entire system and you should think about other implementations that reduce inter-component dependencies.

I've found that typically messages fit the role of things that shouldn't be components.

  • 1
    \$\begingroup\$ This system works well for me, thank you! I haven't played much with the message system. I think what i'll try instead is the Interface system. I create a class, IInput, and have the MovementComponent inherit from IInput, register with the Input Controller, and pass messages like that. Thank you! \$\endgroup\$
    – MintyAnt
    Commented Nov 26, 2012 at 5:25

You must log in to answer this question.

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