Controllers

The EntityController is a core building block for creating gameplay in the FPS Template. It contains the default configuration for a specific entity and every entity is assigned exactly one controller. All controllers are stateless and roll-backable data is stored, as always, in Quantum state (i.e. in a component). Scene entities always have a dedicated controller instance, entities created from an entity prototype at runtime always reference the same (prefab) controller instance.

Controllers are classes and can implement interfaces, which is a recommended development technique when extending functionality of a specific entity.

Controllers are created in Quantum solution by:

1. Deriving from existing controllers provided by the FPS Template, execution is driven by corresponding systems (ActorController - ActorSystem, WeaponController - WeaponsSystem, AbilityController - AbilitiesSystem, ...):
   • public class ExplosionController : UpdatableActorController
   • public class ProjectileWeaponController : WeaponController
   • public class GrenadeAbilityController : AbilityController
2. Deriving from the base EntityController; this requires you to create a custom system to drive the execution of the controller's main logic

In the following diagram the interface of a generic UpdatableActorController and execution paths are presented.

Following diagram shows execution paths of HealthAreaController:

This is what happens throughout health area entity lifetime:

1. When health area is being spawned, all interested systems (implementing ISignalInitializeEntity) are notified of the entity creation (the order is defined by SystemSetup).
2. The ActorSystem checks if the entity controller is derived from ActorController and invokes Initialize() on it.
3. The ActorSystem checks if the entity controller is derived from UpdatableActorController and adds the UpdatableActor component; adding/removing of UpdatableActor is completely driven by the system at runtime, it is not possible to manage it manually from Unity.
4. HealthAreaController is responsible for adding all relevant components (HealthArea in this case) and initializing it.
5. InteractionsSystem checks if the entity controller implements any interface which the system is responsible for (in this case IInteractableTriggerController), adds the InteractableTrigger component and initialize it; this component is runtime only and handled solely by InteractionsSystem, however it is allowed to read its data from outside.
6. When an entity enters a health area -this depends on the physics configuration of both entities-, the OnTriggerEnter3D signal is fired from PhysicsSystem3D. InteractionsSystem reacts to the signal and forwards it to the HealthAreaController where the logic decides if the triggering entity is valid or not. Allowed entities are maintained by InteractionsSystem in the InteractableTrigger component.
7. When an entity leaves a health area (based on OnTriggerExit3D) or the entity is destroyed, InteractionsSystem invokes OnExit() on the HealthAreaController.
8. Every update, the ActorSystem iterates over all entities with an UpdatableActor component and invokes Update() on the corresponding controllers.
9. When entity gets destroyed, the ActorSystem invokes Deinitialize() on the HealthAreaController which is responsible for correctly cleaning up the entity.

The FPS Template supports several interfaces which can be used to extend entity behavior; these are explained separately in their corresponding systems.