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

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

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

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 (?)

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

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:

Entity Content E.g. Consider a Character object (a kind of Entity): Character ID Mesh Animations Position / Rotation Max Hit Points Hit Points Script 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

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

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…

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 3 rd 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

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

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

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

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

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