Entity Component System is a pattern that separates game objects into three main parts - entities, components, and systems. An entity is a discrete object representing an actor. A component describes a singular behavior of an entity. Systems iterate over components to perform tasks like rendering graphics or physics. This pattern avoids issues with classical inheritance by using composition - entities have flexible sets of components without being tied to a class hierarchy. It promotes code reusability and emergent behavior through mixing and matching components on entities.
3. ECS is a pattern that makes a distinction between
entities, components and systems.
4. An entity is a discrete object representing an actor in a
simulated space. Realize first that we are simulating a
universe - the game’s universe. All the visible, tangible
‘things’ in the universe can be represented as entities.
Entity
9. A component describes a singular behavior ascribed to an
entity. The name of a component should ideally communicate
what behavior the entity will exhibit, even to someone who
isn’t familiar with the implementation.
Component
10. Component Behavior
Transform Transforms the entities position, rotation and scale (from the origin).
Health
Attributes a health value, which can be increased or decreased by receiving
‘heal’ or ‘damage’ messages. At zero, it fires the message ‘died’.
Collider
Entity can collide with others. The implementation will depend on the physics
system, but this could be an abstract base component.
DamageOnCollision
Will send a ‘damage’ message with a data-defined value to any entities it
collides with. Requires its entity to have a Collider component.
ParticleEmitter
The entity will emit particles, the nature of which depends on data-defined
values.
11. Systems iterate over lists of components to perform low level
functions such as rendering graphics, performing physics
calculations, or pathfinding. Not every component needs to
be managed by a system. Components should use systems
to offload computationally difficult or shared workloads.
System
12. If a system is totally unrelated to gameplay it
might actually be a service.
17. Classical Inheritance Entity Component
Pros
● Sub-classing can feel
intuitive
● Lots of existing research
● Shorter, less complex code
● Promotes thinking in terms
of behaviors
● Very flexible
● Emergent behavior
● Enables scripting of
behavior by non-techies
Cons
● Leads to highly complex
code
● Less flexible
● Difficult to apply correctly,
easy to mis-use
● Good components require
more thinking about design
20. Components
● Should be generic and re-usable.
● Configure via parameters from data, or from a system.
● Should describe a singular behavior.
● Avoid depending on other components too much.
● Try to avoid writing very large or complex components. It’s
usually a sign you could split up your code further.
21. Think in terms of behavior
What do I want my entity to do? What is that
behavior called? Can I simplify it?
23. Exercise: Components
● Think about the game you’re currently working on.
● As a group, brainstorm components that the game
currently uses, or new ones that you could write for it.
● Write them down on post it notes.
● Try organizing them a bit, are there similarities or overlaps
in functionality?
● Do the component names make it obvious what they do?
25. Messages
● Should be generic and re-usable.
● Pass useful information as parameters.
● Whenever you need to react to an event, first look if a
suitable message is being sent.
● Don’t use messages if a component has a hard
dependency that can only be solved by one specific kind
of component, just use a reference in that case.
27. Exercise: Messages
● Brainstorm messages that your components might send
or receive.
● Write them down on post it notes.
● Can you show which components send which messages?
● Are all messages sent by components?
● Do the message names make it obvious what data or
event they are conveying?
