What’s in a Game? - Game Coding Complete - page 38

to yourself by looking at the movements of a stick figure on one of those old Flash
games on the Internet and comparing it to the best human animations in a game like
Battlefield 3.You

' ll forgive the stick figure for moving in weird ways because it is so

abstract, but you ' ll be upset with the Battlefield character for the smallest mistake in

facial animation because the char-

acter looks so realistic we find it difficult to accept when it does anything unrealistic.
This concept has to do with human psychology and how we observe things. It comes
into serious play when you create any game technology that approaches reality, as
physics systems do. You ' ll spend a staggering amount of time making the tiniest
tweaks to your system to remove the smallest movement problems, because that
tiny mistake in reality is glaring.

— (one of the hardest things to animate, by the way) —

Events
When the game logic makes changes in the game state, such as creating or moving
an actor, a number of game systems will respond. Here s an example. Imagine that

one actor in your game is a portable radio. The graphics system will need to create
polygons and textures so you can see the radio. The sound system will create a sound
effect so your radio will play some great music — perhaps a little Jimi Hendrix. AI
processes might respond to the presence of the actor. In this case, they might just
chill out and enjoy the sublime guitar from our boy Jimi. All three of these subsys-
tems

'

— —

need to know
that this radio exists and what it is doing. These systems are notified through events.
Just like a Windows application hears about a WM_MOUSEMOVE event, your game sys-
tems can listen and react to a game event for practically any change in game state or
input from a player. There are also global game events, such as events to inform sub-
systems that a new level has been loaded or the game is being saved.
Many games create an event system that defines these events and the data that
accompanies them. Different subsystems register with the Event Manager to listen
for events that they

the graphics system, the audio system, and even the AI system

ll react to. A good example of this is the sound system; it might
register to listen for object collision events so that it can play the appropriate sound
effect when two objects are smashed together.
Event-based architectures tend to make your game system clean and efficient. Instead
of making API calls to four or five subsystems when an object collision is detected,
the code simply sends an event to the Event Manager, and all the subsystems that
registered to receive event notifications of this type will get notified in turn.
The event code is the glue that holds this entire game architecture together. The
application layer holds the event registry, subsystems register to listen to events they

'