The low-level IInput interface abstracts platform and device-specific logic for receiving input events. This is achieved by the IInputDevice interface, traditionally implemented in the CryInput module. Each input device is responsible for communicating with the device API (for example DirectX Input), and then call IInput::PostInputEvent to report input from the user.
Once an event is posted, input listeners (see IInputEventListener) are notified to handle the event. One example of this is the action map system - listening for raw input events and forwarding it to any gameplay actions that should respond.
Represented by the IActionMap interface, an action map represents a group of actions (see IActionMapAction) that are individually triggered by raw input. The concept of grouping allows us to separate gameplay logic into modular parts, for example to toggle an "in air" and "on ground" state, and only allow certain actions to be triggered in a certain gameplay state.
Game code can listen to action map events by implementing the IActionListener interface, receiving callbacks when actions from a specific action map are triggered, see the example below.
Using the Input Component causes it to register its own action maps, and reset the Action Map manager; the Input Component and Action manager cannot be used at the same time.
So you should either:
- Use a single Input Component to handle input logic (for simple inputs per-level/entity)
- Use the Action Map manager manually in code, and not use any Input Components (either in code or in the Sandbox Editor).
It is common for games to implement a user interface for remapping inputs based on their preference. The action map system facilitates this by allowing the rebinding of actions, using the IActionMap::ReBindActionInput function.
This concludes the article on Input and Action Mapping. You may be interested in: