-
Notifications
You must be signed in to change notification settings - Fork 1
3. Important Concepts
Entity Component Tree focuses on separating data into 3 categories; Serialized, Non-Serialized, Scene-Reference.
Serialized data is data that is persistent and saved, such as the player's jump height.
Non-Serialized data is data that is changed during runtime, such as the player's velocity.
Scene-Reference data is data that only exists within the world, such as a reference to the player's camera.
Components are responsible for serialized data.
This means components CAN'T change data, but all of their data can be modified from the inspector.
Ex. A component that stores the rotation speed of an entity that rotates towards the player.
Systems are responsible for non-serialized data.
This means systems can change data, so this is usually where actual logic is stored.
Ex. A system for rotating an entity towards the player.
Scene References are responsible for scene-reference data.
This means Scene References can be used to store serialized references to scene objects.
Ex. A scene reference for accessing the main camera and camera target.
Entities are responsible for grouping these and creating one cohesive unit, as well as grouping all entities of the same type.
Technically entities can use all types of data, though you will lose most of the benefits that come with ECT.
The only type of data you should store in your entity is scene-reference data, and only if it is integral to the concept of the entity itself.
Ex. An entity that can be interacted with by the player.
Now our data is all separated, but this leaves a glaring issue, how are we supposed to put these pieces together?
Thankfully ECT handles this for you using only a few easy-to-understand connections.
This is less of a unique concept and more of an important feature.
Each component necessitates the user define a system, which is subsequently instantiated upon the component's loading.
Moreover, each component embeds a System subclass that automatically comprises all of the requisite references.
Ex.
RotateTowardshas a nested system namedSystemthat inherits the components subclassSystem.
SystemData allows systems to gain access to the data stored in their corresponding component and their root or parent.
Ex.
PlayerMovement.Systemhas access to their componentPlayerMovementto use the serialized dataMovementSpeed.
Actions allow you to subscribe methods to them, in which they are all executed when the action is executed.
Ex.
PlayerAnimation.Systemsubscribes to theOnLand()action in thePlayerMovement.Systemto play an animation when the player hits the ground.
Arguably the most important feature to be familiar with, validations allow you to pull data from somewhere else and verify that it is valid.
When writing a system, you should only ever reference the Component directly.
Since systems are created by components, we can always guarantee that the corresponding component exists.
This however does not apply to, say, the player's camera.
If for some reason the player camera is destroyed, we don't want to be attempting to use it.
Systems can have a list of validations to pull data from before executing, in which all validations must succeed to execute.
Ex.
PlayerAnimation.Systemneeds access toPlayerMovement.System, but what if this component doesn't exist?
To prevent this the user is forced to pull in
PlayerMovement.Systemvia a validation to prevent a NullReferenceException.