14.1. Components of the Gameplay Foundation System 713
packs disappear once they have been picked up, explosions appear
and then dissipate, and enemy reinforcements mysteriously come from
around a corner just when you think you’ve cleared the level. Many
game engines provide a system for managing the memory and other re-
sources associated with dynamically spawned game objects. Other en-
gines simply disallow dynamic creation or destruction of game objects
altogether.
z Linkage to low-level engine systems. Every game object has some kind of
linkage to one or more underlying engine systems. Most game objects are
visually represented by renderable triangle meshes. Some have particle
eff ects. Many generate sounds. Some animate. Many have collision,
and some are dynamically simulated by the physics engine. One of the
primary responsibilities of the gameplay foundation system is to ensure
that every game object has access to the services of the engine systems
upon which it depends.
z Real-time simulation of object behaviors. At its core, a game engine is a real-
time dynamic computer simulation of an agent-based model. This is just
a fancy way of saying that the game engine needs to update the states
of all the game objects dynamically over time. The objects may need to
be updated in a very particular order, dictated in part by dependencies
between the objects, in part by their dependencies on various engine
subsystems, and in part because of the interdependencies between those
engine subsystems themselves.
z Ability to defi ne new game object types. Every game’s requirements change
and evolve as the game is developed. It’s important that the game object
model be fl exible enough to permit new object types to be added easily
and exposed to the world editor. In an ideal world, it should be possible
to defi ne a new type of object in an entirely data-driven manner.
However, in many engines, the services of a programmer are required
in order to add new game object types.
z Unique object ids. Typical game worlds contain hundreds or even
thousands of individual game objects of various types. At runtime, it’s
important to be able to identify or search for a particular object. This
means each object needs some kind of unique identifi er. A human-
readable name is the most convenient kind of id, but we must be wary
of the performance costs of using strings at runtime. Integer ids are
the most effi cient choice, but they are very diffi cult for human game
developers to work with. Arguably the best solution is to use hashed
string ids (see Section 5.4.3.1) as our object identifi ers, as they are as