Entities, Components and Message Handling in Games

There has been a trend in the gaming industry for about a decade now to step away from the traditional inheritance programming paradigm to describe game entities and to replace them by a component based system. You can read Bjarne Rene article “Component Based Object Management” in Game Programming Gems 5 (Charles River Media, 2005) for an introduction on the topic.

Basically, game entities describe anything that belongs to the gaming world. They can be evil monsters, treasure chests, lights, ambience sounds, some artificial intelligence triggers for cut scenes… Traditionally, game entities were programmed with a hierarchy of classes which related to their behaviours: you had a master class “Entity” from which derived the “physical” and “non-physical” groups,which themselves divides as “moving” and “non-moving” for the physical branch, “actionable” and “non-actionable”, “with intelligence” and “without intelligence” and so on. Regrouping similar features through hierarchy allowed saving repetition of source code for entities that had the same behaviour. It was also more easy to manage the code that way (imagine there is a bug in the motion of one hundred entities and that you have to update one hundred time the same source code). However, as the complexity of games increased, the programmers started hitting the limits of such hierarchy systems. Namely, how do we implement entities that share behaviours of different branches of the hierarchy tree? And while it is possible to minimize troubles by thinking carefully on how you divide the behaviours into groups, it was often necessary to refactor the hierarchy tree as the game design evolved. At the end, programmers often came up with gigantic classes that could handle every possible situation. This works but does not make good usage of programming patterns whose purpose is to save time and ease code management.

The answer to these increasing problems was the component based system. Here, no more hierarchy: game entities are described as collections of behaviours which are implemented into components. Components are also very specific but highly re-usable. For instance, you have a component handling the health-point/damage behaviour, a component handling the fact that the entity has a physical position and/or orientation in the world, a component for rendering, a component for artificial intelligence and so on. Actually, components are even more specific than that. Imagine, for example, that you have a component for “patrol & seeking target AI” and a component “chase target AI”. At any moment, you can detach one component and attach another to change the behaviour of your entity from patrolling to chasing a target. The same is true for rendering with rendering of 3D models, rendering of sprites, rendering of 3D models with shadows, glows… The goal here is to be as specific as possible.

Such a system is extremely flexible and not only does it allow you to change the behaviour of entities in real-time by loading/unloading components, it also enables you to describe entirely entities by meta-data such as a text file including the components required for the entity and the default parameters (such as life, speed, model file…). And because each component performs individually, you can include new components from dynamic link library (.dll) files, eventually without having to disclose your source code.

There are various ways to implement a component based system in terms of programming paradigms and the first people will usually think of is through multiple inheritances. However, not all programming language supports multiple inheritances and it cannot also produce the dynamic, run-time, behaviour that I described previously. In the past, I have also tried using the Proxy pattern to alter the behaviour of passed functions but I really do not recommend it as it was neither stable nor practical to use. What most people use today, and which is also what Bjarne Rene uses in his article, are has-a relations through entities having collections of objects deriving from a master component interface. This works pretty well, and if you add this to the possibility of [»] instancing objects from strings that I presented some time ago, you get a really powerful tool.

However, there is one glitch in this perfect plan: how do components exchange information with each other? Components are designed as isolated ultra-specific behaviours but they exist in a world where they are a part of a whole. For example, the rendering component needs to know the position of the entity to render it at the proper location; the AI system may need to access the remaining health points to do the most pertinent action (such as not chasing a level 99+ warrior when it has only 1 HP left!) and so on. And it is the precise point here where I beg to differ with Bjarne Rene approach.

In Bjarne Rene approach, to access data located in another component you first locate the component (if it exists!), raw cast a pointer to it and directly read the information through conventional accessing technique such as pComponent->getHP();. But this is a really the last thing you want to do to your component system because it violates the encapsulation principle. To do the raw cast you need to have at least some information on the component specific interface (getHP function in our example) to do this. It may seem like a little trouble, but we are actually losing a lot of flexibility that way.

A better approach can already be found in Matthew Harmon article “A System for Managing Game Entities” in Game Programming Gems 4 (Charles River Media, 2004). In his system, entities communicate with each other by sending messages such as pEntity->sendMessage(MSG_GET_HP); where MSG_GET_HP would be a unique identifier, usually in the form of an integer for speed issues. It also allows every entity to interpret messages as they would like, or even to discard them if not applicable. For example, sending the “update” message to all entities would result in rendering the renderable components, updating the AI of AI component and so on.

I have been working with such systems for a very long time and it works pretty fine. If you have worked with the Half-Life SDK, you will also remember that it was the way used to exchange information between client and server sides so it would not be a too big burden for you to adapt this paradigm for inter-component communication.

Although the system works fine, it also has its downside. Here, it is in how parameters of the messages are handled. In Matthew Harmon approach (and this was also the case in the Half-Life SDK), parameters are sent as chunks of raw data which had to be encoded by the emitter and decoded by the receiving side. This requires having a precise knowledge on the communication packet structure. Actually, we have moved the encapsulation knowledge required from the class to the message packet. This is already much better but it is really pernicious in the long way because you will start to get problems after your game has reached a certain level of complexity. Proper documentation and code follow-up is mandatory to succeed with messaging.

Recently, I then decided to modify the approach of dealing with messages to make it easier for the programmer by adding one more layer of abstraction. The price to pay for abstraction is, on the other-hand and as always, a slower execution time due to added overhead. While this could be an issue if you were working on the next AAA game, the programmer-friendly benefits that it brings surpasses the eventual downsides of slower code execution for smaller amateur projects. Sorry Ubisoft, this won’t work for the next Assassins Creed Vs. Predator Colonial Marines ;-) Jokes put aside, I have done some early test applications with this technology and it performs really well so I would definitively recommend it for the amateurs.

The overall idea is to implement messages as class-deriving objects. That way, we simply send copy of objects and share the interface of the messages classes to other components. One of the nice advantages it has, is that we can implement the reception of the message directly using functions like:

without having to dispatch all the messages from a master message receive function. Also, in the future, automatic packing and unpacking functions could be added to the messages classes such that they can travel through a networking system. I did not cover these aspects so far because multiplayer applications bring a lot more trouble into the game and I already have a lot issues to solve at the moment with my single player game (such as “how to finish my game before 2050” that we all know so well).

The post here will now focus on how to implement the messaging abstraction layer. Please note that messaging can be implemented in any system and not only between game entities and components. For example, you can use the very same messaging system for your user interface or hardware (keyboard/mouse/joypad) management.

In this system, messagees exchange messages through a message manager. Messagees derive from a MessageableObject interface (itself deriving from a MessageableObjectBase class) and messages derive from an IMessage interface. Game object components themselves will then derives from the MessageableObject interface and from an IComponent interface (itself deriving from IInstanciableObject interface and IStorableObject interface. The role of these is to implement the [»] instantiation by string and [»] serialization functionalities that I covered in earlier posts). I will not cover them here. Entities also derive from the MessageableObject interface and configure all its components to share the same messagee id such that they all receive copies of the messages begin send to a given entity. That is an important point because we are addressing messages to entities and not exactly to individual components. Finally, the World master class which contains all the entities is itself a messagee and possesses a MessageManager class which stores a list of all the current messagees in the system and their ids. If you would like to have different messaging systems, simply create several message managers (by the way, this is the reason why the message manager was not implemented as a singleton). A diagram is presented on Figure 1.

Let us now dig a bit further in the actual implementations of these classes. Let us start with the Message class:

As you can see, the Message class is itself based on the IMessage interface which implements a virtual function whose role is to return a unique identifier for each message object type. The Message class is actually a CRTP (Curiously Recurring Template Pattern) template such that we can write:

If you are not familiar with the CRTP pattern, take the time to grab some info on it because it will be very helpful in this article. Concerning the reply function, do not pay too much attention to it as it serves basically as a macro to convert a const reference into something mutable in case we need to write something into the object (usually, in the context of a reply message).

When the REGISTER_MESSAGE macro is called, it invokes a MessageTypesManager class, which is implemented as a singleton, to generate a unique identifier for that class. I will come back on the usefulness of identifiers later. The code for the MessageTypesManager class is a bit long but all it does is to update a hashmap:

And now comes the fun: the MessageableObject class. Like for the Message class, it is a CRTP template deriving from the MessageableObjectBase class which actually contains a lot more feature. The purpose of this CRTP class is to allow the programmer to have one receive function per message, like in our previous example. To do this, the MessageableObjectBase class contains a list of message handlers deriving from an interface IMessageHandler which contains a virtual function whose job is to “handle” a message upon reception. What the MessagableObject CRTP class does is to define a custom message handler deriving from that interface whose handle function actually calls a callback function named onReceive but whose parameter type is different for each message types. The compiler then does all the rest for us by detailing all these functions during the template unwrapping at compilation.

which allows us to write code as simple as:

Now if you look at the “handle” function in the custom message handler class, you see that I have commented out a few lines. This was the former message identification mechanism and was based on dynamic casts. Although it is conceptually better, it performed poorly as it was both too slow and unable to distinguish messages which had inheritance relationship between them. This is normal as you can always dynamic cast a child to its parent. To get better and faster results, I have then replaced the dynamic cast by a static cast and a check based on the message identifiers that I was talking about previously. If you wish to use the dynamic cast version, you can remove the message registering features and the message types manager.

The MessageableObjectBase class is a bit longer but it does mainly a lot of book-keeping. The important thing to note is that it registers itself into the message manager upon creation and maintains the message handlers list. On deletion, it frees itself from the message manager. This will give any messageable object an identifier as soon as it is created, without requiring the programmer to specify anything.

Finally, the MessageManager is the big chunk of meat. It assigns ids to messagees and processes messages between messagees inside the same messaging systems. It does a lot of book-keeping and handles three different types of messagees: objects, hooks and mnemonics. Addressing to an object is the common way of sending messages as you give the messagee id of the recipient. Hooks are special command which allows registering an object under an already existing messagee id. This is how all the components from a given entity to receive and send messages with the same unique identifier. Last but not least is the mnemonic which is a special id that you can use to address messages to a given object that is considered important by the programmer (e.g.: the world manager) or to address message to self, broadcast message etc. The decoding of the messagee type occurs in the dispatchMessage function which sends copy of the message to the different MessageableObjectBase instances.

And that’s all! You can obviously adapt the code to suit your needs. For example, you can make the MessageManager class into a singleton which will make you the life easier in terms of code management. The reason I removed the singleton pattern for that class is that it was easier to manage multiple MessageManager at the same time. Not only to have a message manager for the hardware and UI as stated previously (because you can have a singleton triplet then) but also to have several worlds, each of them with their own message manager. Only one world would be active (be the foreground task or foreground world), the others being inactive in the background but ready to be swapped as the foreground world. The goal would be to stream worlds in and out in a separate loading thread such that when reaching the border of one map (one world), the following one would already be in cache and ready to be drawn. This is nothing but a way of reducing loading issues by splitting the actual whole game into several worlds/maps and having the next maps ready in the cache as we reach doors/trigger point. But that is a complete different story and I will leave that for later :-)