Sign up ×

This is not a question about how to implement a component based system. I have my own system implemented and working fairly well, just can't figure out a good way to split some entities to fit the componnet based paradigm.

The entity is fairly simple, it can walk,jump and fire. It can get into some states like "frozen" that avoids movement of the player. It has other restrictions like can't do double jump.

In my current system, I have an input manager that has a target entity that receives events mapped to actions with semantics. I mean, my entity doesn't know about 'D' key or 'Left mouse click', it knows about Up,Down, Button1, etc...

Now the problem, when the user presses for example SPACE, the target entity is notified with a Left action and all the components are notified, but how would for example the Movement Component know that the entity is in "Frozen State" and it shouldn't be applying movement to it?.

Would you throw all this properties into an entity properties component and let all the other components check for them? Would you split entity in such a granulated level that a component for every property would be created? In this case we could have a component that has the "can be frozen" property and when it receives the collision with an ice projectil (it would be receiving a collision message) it can set the main entity state (that I would place it into the brain component) to frozen.

Could you suggest how you handle this tasks? The question could be rewritten as, How would you execute actions from an input system taking into account the restrictions of the entity.

Thanks in advance.

share|improve this question

1 Answer 1

up vote 2 down vote accepted

There is an approach which is used to abstract input and translate inputs from multiple sources like gamepad, joystick, keyboard, touchscreen into game commands. It comes as an intermediate "intent system" used to capture most input messages.

The intent system can send intent commands/messages to all entities impacted if they have an intent component.

In the implementation I currently use, when an input event is trapped (keyboard, mouse, pen, touch...) the input system is notified, and if not handled by this system then the intent system is in charge... There only the relevant intent components are notified.

These components will then pass the resulting commands to other components like position, animation, particle and projectile generation, etc...

In your case the system will probably be simpler. All input can be collected and directly passed as intent (startAcceleratinToLeft, startJump, stopJump, startJump)... And your intent component will have access to all necessary data to manage the intents.

For example it will ignore the 2nd startJump because while your character is not colliding with a surface which can be used for jump the behavior component will simply ignore it or stash it for the post collision onTime() where it will be discarded if no collision with ground has happened.

I think this is the way to go, and if you want to scrap the intermediate messages (startJump, stopJump, etc) then handle the input directly in the intent component.

Additionally if there is no need for more intent handling (from AI, network or other sources) then you can directly handle intent in a dedicated module where the player entity is registered. But it's better to have this stem for later and to keep the game organized.

share|improve this answer
I don't know if I fully followed you but there's a key sentence here: "All input can be collected and directly passed as intent (startAcceleratinToLeft, startJump, stopJump, startJump)... And your intent component will have access to all necessary data to manage the intents.". Where should this data live? It seems your itent component is what I see like my Brain component. It receives the actions and broadcasts messages like startjump, etc... A brain must be coded for every entity because it defines the features this entitiy supports and which can be active at same time. –  Notbad Jan 12 '12 at 15:36
Example: Jump + Frozen is a no no. So when the input system notifies a Jump action the brain will not notify the jump because it is not possible. –  Notbad Jan 12 '12 at 15:40
Example: Jump + Frozen is a not valid combination. So, when the input system notifies a Jump action the brain will not notify the jump (inter object message broadcast) because it is not possible. In my design I see the brain like a filter. When it is a brain not controlled by the player it autogenerates events based on its own logic, and when it is controlled by the player the events are "forwarded" from the input system to all the components interested. But only if they follow the rules. –  Notbad Jan 12 '12 at 15:46
The problem here is the coupling.For example, I will have to code a brain that knows if it will contained in an entity that has a "frozen property" component. Because if it is notified with a move action it musn't generate a "Move Left" event for the entity. The way I can solve this is having chained components, setting the restrictions at the head of the chain to avoid the action be notified if the filter is not passed (The frozen component is a filter here if a movement action is notified). Well, perhaps I'm doing overenginiering here but it is such a difficult subject :/. –  Notbad Jan 12 '12 at 15:52
Nice explanation. Anyway, I thikn I'm going to move to a more less general aproach and use this game as the transition to the real component system. Sometimes trying to do all 100% best at first is not possible. –  Notbad Jan 13 '12 at 8:54

Your Answer


