CHAPTER 11
GAME EVENT MANAGEMENT

by David “Rez” Graham

So far, you’ve learned about actors, the resource cache, the main loop, and a number of other systems. Communication between these various systems can get very complicated and even start to break down completely if you’re not careful. Consider this example: A game script wants to create an object, such as a ticking time bomb. The game logic needs to insert the time bomb into the game object list, and the various view objects need to know that a new object has been created. The human view will need to render it, while the AI views need to know it exists so that NPCs will react appropriately, such as running away in a panic. You’ll also need to schedule future explosion events.

A naive programmer might code this complicated system by using a series of API calls to various subsystems of the game engine. This approach could get extremely messy and could require a morass of #includes at the top of every CPP file. I’m sure that you have come across code like this before. Each system would have to know about the public API of every other system that it interacted with. I’ve worked on a number of games that were built this way, and each experience was pretty horrible. Whenever even a trivial modification was made to a subsystem, it seemed that the whole game would have to be recompiled. This can also be the source of hard-to-find bugs.