UserAction Integration
Description
This integration must provide configurable action controls per user.
UserAction
An action can be seen as a control, a UserAction is an action triggered by a specific user. For example in a game it would be something like Attack, Open Inventory, Move Up....
The idea of the action is to give an interface between an event and an application actio…
Description
This integration must provide configurable action controls per user.
UserAction
An action can be seen as a control, a UserAction is an action triggered by a specific user. For example in a game it would be something like Attack, Open Inventory, Move Up....
The idea of the action is to give an interface between an event and an application action in order to configure the action triggers (keybinds).
When an action is triggered, it must know its id, the sender (ie which user triggered it) and should have a float value between [-1, 1] . This allow to call the action to start/update and stop it.
Action bindings
The action must be linked at least with the following inputs:
- Keyboard key (press/release)
- Gamepad button (press/release)
- Gamepad axis (value changed)
It must be possible to enable an action to multiple inputs.
User profiles
In order to save a user action bindings, a class describing a user must be implemented. It must at least contains the user action bindings and allow to read/write to/from a file.
Moreover since having only one user is quite reductant, an other resource class must be created to contains the different user profiles.
Action Listener
Similarly to the event, a listener component class will manage the callbacks.
It must contain a callback called on an action detection.
It must also contain the user id listened.
Program flow
Action detection
When an event is sent to the ecstasy handle event, it should update the associated actions if there is any. This occurs only if the event can be associated to an action (KeyPressed/KeyReleased... but not TextEntered for example)
If the event match with a user action then an Action object containing at least the sender user, the action value and the action id is created.
Action distribution
When an action is detected, it calls all the ActionListener components callbacks if they match the user id with the action as parameter.
Improved Action distribution
The following templated classes should be created to avoid managing all actions in the same callback.
ActionListener<size_t ActionId>
A templated action listener which callback is called only when an action which id match ActionId
PendingActions
A resource to store the actions detected, used by PollPendingActions
PollPendingActions<ATTACK, MOVE_LEFT>
A templated system which retrieve all the actions from the pending actions resource and forward them to the associated ActionListener.
Once this classes have been declared we can have the following program flow:
- Add a PendingAction resource to the registry
- Add a PollPendingAction system with the existing actions/users as a template to the registry
- Add an entity with an ActionListener component with a default callback adding all the detected actions to the PendingAction resource
Then for each call of the PollPendingAction system, for each pending action: call the callbacks of
- All ActionListener components whose ActionId and user id match the pending action one
Doing this will allow upsteam checks from the ecs instead of in the callbacks.
Dependencies
Event integration