Game Development Reference
In-Depth Information
Chapter 11
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 com-
plicated 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
#include
s 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 hor-
rible. 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.
In this chapter, you
'
ll learn that you can solve the problems of communications
between game subsystems and how they interact with game objects by using a
'
307
