Input & Component Desires
For real players, there are 2 possible ways how to provide values to simulation:
Quantum.Input
data structure which is polled for every simulation frame; and,- 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):
- Player touches the screen.
- At the start of the Unity frame,
InputSystem
andEventSystem
are updated which in turn invokes the input actions and UI event handlers. - Values from invoked input actions are locally cached in the
InputSystemInput
class including commands to be sent. - The
GameplayInput
service update is invoked which sets the default state in locally cachedQuantum.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. - Quantum simulation polls input - locally cached
Quantum.Input
fromGameplayInput
. 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. - At the start of the Quantum frame,
ResetComponentDesiresSystem
is updated which effectively resets all component desires to their default state. - The
PlayerSystem
andPlayer
components are updated and convertQuantum.Input
and Deterministic Commands intoInputDesires
structures - If implemented,
IInputController.ProcessInputDesires()
is invoked on the controller of the controlled entity (NOT the player entity!). The controller is responsible for processingInputDesires
; it checks the internal state of the entity and sets values in component desires or immediately invokes desired actions. PreProcessComponentDesires()
is called on all entity controllers which implement theIPreProcessComponentDesiresController
interface. This allows the controller to set specific values to component desires before any of the following systems are updated (checkSystemSetup.cs
for the exact order). An example usage is theDash
ability which locks the look direction of the owner - i.e. overridesLookDesires.LookRotation
each frame to a specific rotation as long as it is active.- 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
), ... . PostProcessComponentDesires()
is called on all entity controllers implementing theIPostProcessComponentDesiresController
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 (checkSystemSetup.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 overridingWeaponsDesires.Fire
to false during the lifetime of the effect.- Late/Action systems are updated based on corresponding component desires; this includes things like Effects, Projectiles, Actors, Weapons (
WeaponsDesires
), Abilities (AbilitiesDesires
), ... .
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:- The
InputDesires
structure is stored insideAI
component instead ofPlayer
component - HFSM is executed to generate AI input into
InputDesires
instead of convertingInput
structure and commands inPlayer.ProcessInput()
- 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)