Input & Component Desires

For real players, there are 2 possible ways how to provide values to simulation:

1. Quantum.Input data structure which is polled for every simulation frame; and,
2. Deterministic Commands

Input Desires

AI players run completely from within the simulation and therefore cannot send commands. To resolve this problem, the FPS Template introduced the InputDesires data structure which combines input from all sources. Once the inputs have been combined into a InputDesires structure, it can be used for processing by the entity controller and actions can be invoked immediately. This approach, however, does not take intercepting and overriding input values into consideration - for example when an active ability overrides movement direction.

Component Desires

To handle the interception and override behaviour of the input desires, the FPS Template uses the concept of component desires. Each component with generic reusable functionality has its own desires data structure equivalent; for example the Movement component has a matching MovementDesires structure and the Weapons component has a WeaponsDesires.

From Input to Gameplay Actions

The following diagram presents the data flow leading from input actions to gameplay actions.

Input Desires for Players

The complete process of generating a mobile input and transforming it into a gameplay actions, including interception, consists of the following steps (code paths not relevant to input are omitted):

1. Player touches the screen.
2. At the start of the Unity frame, InputSystem and EventSystem are updated which in turn invokes the input actions and UI event handlers.
3. Values from invoked input actions are locally cached in the InputSystemInput class including commands to be sent.
4. The GameplayInput service update is invoked which sets the default state in locally cached Quantum.Input data structure and updates values based on data from step 3. . The sending of Commands is triggered by the service running its update in this step.
5. Quantum simulation polls input - locally cached Quantum.Input from GameplayInput. Afterwards, the cached input is soft reseted. N.B.: The simulation can poll input for multiple frames, please refer to the Caching page for more information.
6. At the start of the Quantum frame, ResetComponentDesiresSystem is updated which effectively resets all component desires to their default state.
7. The PlayerSystem and Player components are updated and convert Quantum.Input and Deterministic Commands into InputDesires structures
8. If implemented, IInputController.ProcessInputDesires() is invoked on the controller of the controlled entity (NOT the player entity!). The controller is responsible for processing InputDesires; it checks the internal state of the entity and sets values in component desires or immediately invokes desired actions.
9. PreProcessComponentDesires() is called on all entity controllers which implement the IPreProcessComponentDesiresController interface. This allows the controller to set specific values to component desires before any of the following systems are updated (check SystemSetup.cs for the exact order). An example usage is the Dash ability which locks the look direction of the owner - i.e. overrides LookDesires.LookRotation each frame to a specific rotation as long as it is active.
10. Early/Non-Action systems (do not create/destroy entities, only calculate and update position, rotation, ...) are updated based on corresponding component desires - e.g. Attributes, Movement (MovementDesires), Look (LookDesires), ... .
11. PostProcessComponentDesires() is called on all entity controllers implementing the IPostProcessComponentDesiresController interface. This allows the controller to set specific values to component desires after the most up-to-date calculations are done by previous systems and before any of the following systems are updated (check SystemSetup.cs for the exact order order). Setting desires related to already updated systems will have NO effect. This can be used, for instance, for an effect preventing its owner from shooting by overriding WeaponsDesires.Fire to false during the lifetime of the effect.
12. Late/Action systems are updated based on corresponding component desires; this includes things like Effects, Projectiles, Actors, Weapons (WeaponsDesires), Abilities (AbilitiesDesires), ... .

The diagram illustrates the execution order of systems and methods relevant to input processing for players (priority left => right, top => bottom).

Input Desires for AI

The following diagram presents the execution order of systems and methods relevant to the input processing for AI agents (priority left => right, top => bottom).

These are main differences from Input Desires for Player:

1. The InputDesires structure is stored inside AI component instead of Player component
2. HFSM is executed to generate AI input into InputDesires instead of converting Input structure and commands in Player.ProcessInput()
3. All logic is executed in components and controller of single entity, compared to Player component (player entity) forwarding input for processing to the controller of a controlled entity (usually an actor)

Back to top