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

care about, and other subsystems send events as needed. These events get sent to only
the subsystems that have subscribed to them.
Chapter 11, “ Game Event Management, ” will dig into this system and show you how

it works.

Process Manager
Any simulation of a game world is usually composed of discrete bits of very simple
code, such as a bit of code to move an actor along a linear path or parse a Lua script.
Acting on a single game object has the effect of combining these simple state changes
into something more complex. These bits of code are usually organized into classes,
and they can be instantiated for any game object. If you were to create a “ move along
this path ” class and a “ run Lua script ” class and instantiate them both on one object,

you d create an interesting and complicated interaction from two simple pieces of code.

This is the heart of another important game subsystem: the Process Manager. It
keeps a list of processes and gives each one a little CPU time by calling it once
every game loop. A great example of this is a pathfind process. It acts to move an
actor from one place to another, and when the destination is reached, it simply ter-
minates and ceases acting on the actor.

'

Learning Our Lessons from Ultima VII

After UltimaVII, all of the programmers met in the courtyard of Origin Systems
with a plan to redesign the Ultima technology for Ultima VIII. We had a nice
sunny day, a whiteboard, and real motivation to make a much better system.
We realized that any code that operated on an actor or group of actors for a
period of time could be encapsulated in a cooperative process, and it could
even be responsible for its own lifetime. When its job was done, it would kill
itself off. The best thing of all was that the entire thing could be managed
from a single class that contained a list of every running process. This
technology eventually evolved to become almost as useful and complex as a
simple operating system, managing both cooperative and real-time processes.

On Ultima, we found it very useful to allow processes to have dependencies on one
another, where one process would wait for another to complete before starting. A
good example of this is something you might use for a Molotov cocktail: One process
tracks the parabolic movement of any game object until it collides with something,
and another process manages a fireball explosion. Your game can string these pro-
cesses together to create some amazingly cool effects.
You ' ll learn more about this system in Chapter 7.