Games Development Game Architecture: Entities

1. Games DevelopmentGame 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 • 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

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