Continuing a series of posts where I try to detail the past, present and maybe have a glimpse at some possibilities of where the Game Entity might evolve in the future.
Game Systems
You might call them systems or managers others call them modules while others prefer singletons. Whatever your pattern of choice at their core they are all the same, they wrap up a mechanism / section of functionality into a self contained handy package.
The Entity Manager
When you have a collection of game entities you are guaranteed that somewhere there is an entity manager lurking in the background creating the entities, maintaining them, handling their delayed deletion, keeping statistical data for profiling, occasionally prodding an entity when it misbehaves, shouting at the youngsters to keep up and trying to keep the world in harmony.
From the Entity Manager’s perspective it believes that it has ownership over the entities. As far as it is concerned no other system touches its entities, no-other system has influence over the entities except through the normal entity / component update.
How the Entity Manager sees the entity / component connections is like so:
Other Game Managers
What the entity manager doesn’t know is that there are a large number of game systems that are not only talking directly to the entities but they are also passing references between systems, compiling them into lists and making major changes to the game entity itself all outside the normal entity update. Some of these systems might include Player Manager, Squad Manager, GUI Manager, Cut-scene Manager, Task Manager, in your average game there are probably more managers that touch entities than those that don’t.
So what are these managers doing?
Let’s consider the Player Manager, it stores a list of the game controllers connected to the hardware and which controller is controlling which entity. The GUI system might ask the Player Manager which entity “player 1″ is controlling so that it can display the correct HUD information or an enemy entity might ask which entity the player is so that it can focus its attention on the Player. Having the manager store a reference to the player controlled entities means that it can quickly provide the information upon request.
A Squad Manager might contain all the information about each squad in the world, which entities are in each squad and each squad’s alliances, etc. It might also handle the higher level thinking required to achieve the objective or goal, once it has planned the required steps it instructs the members of the squad (the entities) to go and do what is necessary. The squad manager might also contain references to other important entities that it needs to track in order to carry out and execute it’s plans, for example kill this character, retrieve that object, move this object from here to here, activate that switch, open this door, etc.
The point I’m trying to make here is that there are plenty of managers regularly interfering with game entities before, during and after the update frame usually without much constraint or control other than mechanisms / interfaces that might have been built into the entity.
And of course managers are not the only ones that reference entities, entities do it themselves as well. If we were to rebuild the diagram above with all the real connections that are going on we end up with something like this:
Connections
How we make these connections to an entity can be done in a variety of methods, the most basic is a pointer to the entity or component. Obviously the biggest issues with this is if the entity itself is deleted you all of a sudden have a dangling pointer with no way of validating before using it. Although I don’t recommend this you would be surprised how many games have shipped using this method with very few issues (mainly because of some good interface design and a fair amount of liquid pixie dust (that’s luck in English) ).
Other methods that have been employed with success have been Weak Pointers or Smart Pointers on one project I even got to use Unique Id’s which was great but costly doing the lookup of Id to pointer. The only reason great is because it made a difference to me at 2am in the morning and looking up variables that read within a human context, i.e. entity 15 is targeting entity 89, instead of 0x5feabeda targeting entity 0xa3922ef1.
I once encountered GUIDS being used once, and I hope never to see them again!
The Core Managers
Let’s consider for a moment three of my favorite core managers, Rendering Manager, Physics Manager and Audio Manager. These three have evolved from very early on to take advantage of multi-threading and part of that evolution has been to isolate the internal low level data and force any external interactions through an interface or handler.
You don’t get the player manager tweaking the audio sample data as it is being played and you don’t have Entities adjusting their vertex data. This is not just because that data might be shared but because this is a good way to protect against multi-threaded issues.
Next Time…
In part five I’m going to try and bring this series of articles to a close by considering where the game entity is and what its future might be.
Coming up
The Game Entity – Part V, Future Ponderings
Previous Posts
The Game Entity – Part I, A Retrospect
The Game Entity – Part II, The Life Cycle and Processing Architecture