Games Development 2 Overview & Entity IDs and Communication CO3301 Week 1

Module Overview Two parts: –Semester 1 with me: Various Game and Entity Architecture topics Plus any requests(?) –Semester 2 with Gareth: Various Real-Time AI topics Some topics will be extended in Tech for Games 1 Assignment on my material Two 2-hour exams, one at end of each semester

Today’s Lecture 1.Entities Recap 2.Referencing Entities 3.Use of Entity Pointers 4.Entity UIDs / Handles Hash Maps 5.Entity Messaging System

Entities Recap Entity = interactive self-contained game element Each type of entity has a generic template Each instance has some specific data: Character 1 ID Position / Rotation Hit Points Character 2 ID Position / Rotation Hit Points Character Template Mesh Animations Max Hit Points Script This instance/template pair for an entity replaces the model classes that we have previously used Also corresponds to a game agent from AI work

Entities Recap Entities can be held centrally in a list –To easily add/remove them and for overall control Most games will need to store entities in other data structures as well: –E.g. in a map grid for an RTS –Or an BSP tree for a FPS Entities need to be updated periodically –For AI, movement etc. But not all entities need to be updated simultaneously –A priority queue can be used to order updates –Nearby entities at front of queue, distant/inactive at end

Entity IDs and Communication Entities need to communicate with each other –“I have hit you” –“I have picked you up” –“What is your HP”, etc. To do so they need to be able to identify the other entities: –But how? By name? pointer? ID? Also they need to have a means of interaction: –Direct member data access? function calls? messages? These are related issues We will look at some of the possible approaches

Use of Entity Pointers Very tempting to have entities to hold pointers to each other and use these for communication and interaction: –A character drops a mine –The mine entity retains a pointer to the character entity –A vehicle drives over the mine and is damaged –The mine uses the character pointer to award some score Sounds OK, but problems when entities are destroyed: –What if the character has died, or left the area? –The pointer is invalid (unless we track all ex-entities) –Could cause exception (or worse…) –Variants on this situation occur frequently Need something more robust than pointers…

UIDs A UID (Unique IDentifier) or handle is a value that uniquely identifies some resource –Can be used for any kind of resource Hold UIDs instead of pointers whenever possible Use a function to safely convert a UID into a pointer to the associated resource –When we need to interact with the resource Exactly how the function maps UIDs to resources is implementation dependent It just returns an error if the resource doesn’t exist –Game can respond to the missing entity sensibly –Removing the problem of invalid pointers

How to Map UIDs to Entities? Store pointers to all entities in an array or container Maybe UIDs could be indexes into this array? –If array[N] = 0 then entity N doesn’t exist But would need an entry for every entity that ever existed –Not likely to be possible (might be in simple cases) Couldn’t we reuse empty array indexes? –But if we have an entity UID 35, and array index 35 contains an entity pointer… –…how would we know if this is the entity 35 we want or a new one reusing that entry? Need a more robust solution

Hash Tables A hash table or hash map associates each of a set of keys with a specific value –The keys & values are data of any type E.g. A hash table might associate names (the keys) with telephone numbers (the values): The goal of a hash table is to provide efficient lookup of a value given a key Even if the keys are complex types

Hash Tables To efficiently perform the mapping, we provide a hash function to convert keys into integers –Used to look up the values (in an array or container) An ideal function gives a unique index for each key –This is rarely easy or efficient and most functions have collisions – same index for different keys

Hash Tables There are several general functions to efficiently convert a block of arbitrary data to a single integer –Usually creating some collisions Resolve the collisions by storing a bucket of key/value pairs for each index –Given a bucket, we search for value matches our key

Hash Tables for UIDs We make the UIDs globally unique integers –Initialise a global integer – when we add a new entity, use this integer as its UID –Increase the global integer for each entity –This process can be encapsulated by an entity manager class to avoid the use of actual global variables Use static class member variables instead Use a hash table to map the UID an entity pointer The hash function can be very simple: –Index = UID%ArraySize; will work, but many collisions –Index = RandomiseFn(UID)%ArraySize; is better Resolves the problems of using a simple array

Entity Interaction Now we have UIDs to safely get entity pointers, should we use them for entity-entity interaction? Certainly we won’t have entity objects accessing each other’s private data –A health pack isn’t going do this: character->HP += 10; However, using entity member functions seems OK: Entity* character = EntityManager->GetEntity(charID); character->IncreaseHP( 10 ); But this means each entity class will need to know all the available functions of the other entity classes –Too close coupling, difficult to maintain code Also such interaction is processed immediately –We may wish to manage the timing differently

Entity Messaging More flexible to use a messaging system If one entity wishes to interact with another: –Send a message to the UID of the other entity –The system has a messenger class, which collects, queues and sends message between entities It works with UIDs (no need for entities to use pointers) Can also hand messages to groups, broadcast messages, system messages etc. –The entity receiving the message can act on it or ignore Entities only need to know the message types –Coupling is kept to a minimum Can make some interaction more complex –E.g. If there is a need for a reply message etc.

Example Messaging Sequence Two tanks, UID 5 (leader) and 11: –Leader: SendMsg(11,"Status Report"); Assume Tank 11 receives message –Tank 11: SendMsg(5,"HP=100,Idle"); –Tank 5: SendMsg(11,"SupportMe"); Tank 11 follows order, until a shell hits it: –Shell 58: SendMsg(11,"Damage=500"); Later… –Tank 5: SendMsg(11,"Retreat"); Ignored, second tank is dead Would use variables, not constants, for UIDs, e.g. –SendMsg(Leader,"Status Report"); // Leader = 11

Message Types System messenger class is fairly trivial to implement –But it must be efficient – will be many messages The data type for the messages is important –Simple system – one data type holds all possible messages Message ID (type) + generic data –More complex – a class hierarchy of message types More flexible, less efficient In any case, message code may need optimisation –Minimise message copying (reference parameters etc) –Avoid new and delete (use static containers)

In Practice Using messages for all entity entity interaction can be cumbersome –The examples above show where they work well –But, for example, finding the position of another entity is clumsy using messages –Also they introduce latency waiting for responses Possible solutions: –Entity UIDs can be converted to pointers to access generic or commonly used data, position, velocity, etc. –Implement an ImmediateMessage function Message sent directly to the entity, return value is response Many of the same benefits as messaging Target entity response limited since it is not in its update function