Handling input in ECS for multiple characters

Question

I've been reading into Entity-Component-Systems, and they seem rather handy. However, I don't quite understand how input should be handled and after googling and looking thru GDSE posts, I've become even more confused. I see plenty of explanations, but no examples of how to incorporate things like an intent system.

Originally, I planned on polling for keyboard events and passing those events onto a controller. This controller would have a vector of callback functions, which could be rebound to different keys on the fly. But then I realized it doesn't translate well into a game with multiple characters, each with their own set of actions - like a fighting game, or the Megaman X games that allow you to switch between characters.

I thought that if I were to make these callback functions rather generic, so that they just change the state of the character, then have a System that consumes states for different characters to apply different results to the action (IE, the "jump" button would set the currently controlled character's state to JUMPING. But maybe Character 1 jumps faster than Character 2, but Character 2 jumps higher). But that doesn't seem like a wise idea, because now I have a system for every state that each character could possibly have. It smells really bad, basically. And to have a character unsubscribe from one "State System" and resubscribe to another just gives me the feeling that I am not doing something right, but I am at a loss.

How should I handle input that can differ slightly from character to character? I feel like I am on the right track with having the states handle input, but I don't think that each state should have it's own system. A state should be generic and operate on many entities, not just a single instance of one!

Answer 1

In ECS there's the concept that an entity is just a collection of components that can be added or removed at will. Typically which set of components an entity has at a given time determine its behavior. Some implementations of ECS are able to detect when components are added or removed from an entity and then automatically change the behavior of the entity. This could be by a process of automatically registering or unregistering the entity from the systems that implement the behaviors.

For example, being or not being in the state of JUMPING could be represented by a Jumping component that an entity has or doesn't have. The ECS engine would handle registering or unregistering entities from the Jumping system as they gain or lose their Jumping components. Pressing the jump button on a game controller would result in a Jumping component being added to the character's entity that the game controller is controlling. While the entity has a Jumping component, it would be registered with the Jumping system that handles applying the physics forces needed to move the character every frame. After moving the character, the Jumping system could check to see if the character is now on the ground or hit a wall and remove the Jumping component from the character if it has, since that would mean it should no longer be in the JUMPING state. The ECS engine would then automatically unregister the entity from the Jumping system. The entity would stop being updated by the Jumping system every frame and would stop moving.

Since a Jumping component is just an object itself, it could have properties on it that would be available to the Jumping system to use in movement calculations. This way you could get different jumping styles with just a single kind of Jumping component. Each character is an entity with its own Jumping component. The Jumping system just loops through all the entities registered with it and grabs each entity's Jumping component.