Game Development Reference
In-Depth Information
Figure 2.3
Game logic and its subsystems.
Every game will have a container for game objects. Simple games can use a list
structure, but more complicated games will need something more flexible and opti-
mized for quick local searching or streaming. Your game engine must be able to
traverse the object data structures quickly to change an object
'
s state, and yet it
must be able to hold a flexible array of properties for each object. These two
requirements are frequently at odds with each other; one is quick to search, the
other is easy to extend.
Ultima used a simple two-dimensional array of object lists. It was easy to find objects
within a given range of a map location, and each grid square was small enough to
have a quickly traversable list of objects. Thief: Deadly Shadows, on the other hand,
used a simple list of objects, but it was heavily tangled by internal pointers. If two
objects needed to know about each other, such as an elevator button and the elevator
door, they were linked by the game editor. This solution actually worked quite well
and is commonly used.
Object properties, such as hit points, engine horsepower, and wacky things like that
tend to be stored in custom data structures whose efficiency can be anything from
fantastic to dismal. Ultima Online used text strings to define properties on objects,
which had the benefit of easy and flexible development at some cost in memory stor-
age. Thief: Deadly Shadows had an extremely complicated property system that was
actually object oriented; you could define object properties for an archetype, like a
barrel, but overload existing properties or even create totally new ones for a particu-
lar barrel that was placed only once in the game universe. The system was memory
efficient since it never copied property data, but it ran at some extra cost in CPU
time because the property system was essentially a tree structure. There are trade-
offs no matter how you do it.
