1. Games Development 2 Component-Based Entities
Week 7 - 1

2. Contents Entity Hierarchies Problems with OO Component Based Entities
Component Update/Messaging

3. Entity Class Hierarchy
Have assumed that entities form a class hierarchy:
Is a class hierarchy / OO approach suitable for a game?

4. Problems with OO
Many programmers naturally architect their systems into rich OO hierarchies
But deep OO hierarchies have many drawbacks:
Tight coupling between parent and child, features of parent affect or limit the features of the children
E.g. Vehicle class has numWheels - what about boats? So use a LandVehicle class, what about tanks, so a WheeledVehicle class…
Adding to (rather than replacing) functionality through derivation can be contrived
Enemy class has EnemyWithShield child, just to support additional functionality of shield – not elegant
Hierarchies are static, games often need more flexibility
E.g. A dragon is an AIEntity, but if we get on it, it becomes a VehicleEntity – how to manage this?
Multiple inheritance can by used - but causes much confusion

5. Component Based Organisation
Consider a single class for all entities
Instead of deriving further classes with new properties, we add a set of properties or components
The entity holds a dynamic list of components
GameEntity* ship = new GameEntity;
ship->AddComponent( new RenderComponent );
ship->AddComponent( new AIComponent );
...
Game Entity
Type=“Ship”
Render Component
Collision Component
AI Component
Health Component

6. Component Usage Each component has an update function
Called when the entity is updated
E.g. Render component draws the entity, AI component decides where to go, Health component monitors life
Messages to entity passed to each component
The Health component reacts to a damage message
The AI component to a suspicious sound message
They in turn send messages
To other entities or to components in the same entity
E.g. the health component sends a destroy message to all components when HP = 0
Component acts like a “mini-entity”

7. Component Example Consider the dragon example again
This time the dragon has an AI component along with Render, Collision and other components
When the player gets on the dragon:
It discards the AI component
Replaces it with a PlayerControl component
Resolves the earlier issue
Must make sure that the component swap doesn’t have unintended consequences
E.g. other entity behaviour dependent on dragon being an AI (formations of AI dragons – now following player?!)

8. Component Pros / Cons Little coupling between components
Easy to add or remove functionality to an entity
Very dynamic, even at runtime
Very simple to conceptualise
Easily built from data/script files
Much more message passing
Performance can be an issue
May be too flexible
Interaction between many independent components may be difficult to predict
Order of component processing may be important