Games Development 2 Component-Based Entities

CO3301

Week 7 - 1

ContentsContents

• Entity Hierarchies

• Problems with OO

• Component Based Entities

• Component Update/Messaging

Entity Class HierarchyEntity Class Hierarchy

• Have assumed that entities form a class hierarchy:

• Is a class hierarchy / OO approach suitable for a game?

Problems with OOProblems 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

Component Based OrganisationComponent 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

Game Entity

Type=“Ship”

Collision Component

AI Component

Health Component

Render Component

GameEntity* ship = new GameEntity;

ship->AddComponent( new RenderComponent );

ship->AddComponent( new AIComponent );

...

Component UsageComponent 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”

Component ExampleComponent 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?!)

Component Pros / ConsComponent 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