1. Games Development Game Architecture: Entities
CO2301 Games Development 1
Week 22

2. Today’s Lecture Game Architecture: Beyond 3D Entities Entity Content
Entity Architecture
Update
Identification & Communication

3. Game Architecture: Beyond 3D
Previously looked at 3D engine architecture
Advice relevant for other parts of the game structure (interfaces, factory functions etc.)
Now, consider other program components:
Game Logic / Data, AI, Physics, Networking, Sound etc.
Some have well understood architectures
Networking, physics and other hardware interfaces
Rather specialist and beyond the scope of this module
Other components are very game specific and their architecture varies greatly
Game logic / data, AI

4. Entities
All games are similar in that they manage a collection of entities, sometimes called actors
The architecture of the game-play code is driven by the architecture of these entities
What is an entity?
A single game element
Self-contained - not part of another entity
Interactive – needs to be updated periodically
Examples:
A character (or NPC), monster or vehicle etc.
Objects (pick-ups or interactive scenery), triggers
Cameras, lights, particle systems, level geometry (?)

5. Entity Common Features
What features do all entities have in common?
Can be instantiated in the game (i.e. created) – at set-up time, when loading a game or upon a game event
Need to be updated periodically
They can be uniquely identified
Other features shared by sub-classes of entities
Some can be positioned in the scene
Many have a visual representation (mesh, animations)
Can be rendered
Most have attributes, statistics or state
Can often interact with other entities
Complex entities can have scripted behaviour

6. Entity Classes This suggests that Entities form a class hierarchy
The exact hierarchy will depend on the needs of the game
Here’s an example:

7. Entity Content E.g. Consider a Character object (a kind of Entity):
This is rather like an IModel as used in the TL-Engine
An instance of a mesh with positioning
We could render this
But it contains game data too - it can be used by the AI and game logic
This is a general character class, we may inherit more specific versions
Character ID
Mesh
Animations
Position / Rotation
Max Hit Points
Hit Points
Script
E.g. A Wizard class may be a Character with additional stats (MP) and some extra script

8. Entity Templates However, imagine 500 of these characters
The mesh, animation, max HP and script are constant
This data will be duplicated 500 times
So we divide the entity data:
The entity template has common data for all entities
The entity instance contains data for a specific entity
Character Instance 1 ID
Position / Rotation
Hit Points
Character Instance 2 ID
Position / Rotation
Hit Points
Character Template
Mesh
Animations
Max Hit Points
Script

9. Architecture for Entities 1
How to store entities in our game?
Keep a central list of entities somewhere
In an entity manager (recall manager classes)
Entities are dynamic, a list allows insertion / deletion
Can step through this list every frame to update / render / perform AI on entities
Bad idea, not all entities are renderable or have AI
Also, some might not be visible, or be inactive
Nor will all entities need to be updated every frame, e.g. distant or hidden entities (see later)
Maybe we need a different structure…

10. Architecture for Entities 2
Every game is different with regards entity organisation
An RTS might arrange entities in a grid
An FPS might use a quadtree
A 3D spatial subdivision – will see in 3rd year
Different components of the same game may actually have different organisational needs
Renderer / Collision detection / AI
Might organise entities into many structures simultaneously
E.g. Store a list in a scene manager
Have a quadtree and a grid structure, both containing pointers to entities in the overall list

11. Entity Update 1 Each entity will have an Update function
To perform AI, run scripts, trigger events etc.
Exact tasks depend on the entity
Using classes / polymorphism here
One update function per entity type, not just one for the entire scene
Can update the entire list of entities each frame
Will use a timed game loop
However, not all entities need to be updated
i.e. distant or inactive entities
Need to make a decision about importance of each entity, before deciding to update

12. Entity Update 2
Can use a priority queue to do decide which entities to process each frame
Entities are placed in the queue depending on how long before they need their next update
Distant / inactive entities go at the end
Nearby / important entities go at the front
Step through the queue:
Update each entity and put back on the queue with an updated time
Stop on first entity that doesn’t need an update this frame
This process updates the minimum number of entities

13. Entity Rendering We usually give each entity a render function
This is called every frame
May do nothing if entity is not visible (e.g. a sound)
Typically, the entity instance passes its current position / animation etc. to its entity template
The entity template can render any of its own instances given these specifics
Recall that the template stores the mesh
This is fairly similar to model/mesh rendering
Entity template – similar to mesh
Entity instance – similar to model

14. Entity Identification
Each entity needs a unique identifier so we can refer to it during the game
We could give each a name (a string)
Not so efficient, especially for look-up
Or we could use a pointer to the entity
Like a IModel* in the TL-Engine
Difficult to update pointers when entity is destroyed
Better to use a UID, a unique identifier for an entity
Usually just as a simple integer
Then provide a system to map UIDs to entities
A hash map or similar, must be efficient

15. Entity Communication
Entities can communicate by calling each other’s member functions
E.g. “PickUp”, “EmitSound”
But this increases class coupling - makes the game less flexible
Better to implement a messaging system
An entity can send a message to another entity (addressed with its name or UID)
Messages are distributed by the game system
Entities pick up their messages during their update function and decide what (if anything) to do with them
Very flexible system
Similar to network communication