Game Development Reference
if another job changes slightly, but the bulk of the system is meant to be stable.
Along with the feedback, a richer set of actors and a richer set of jobs may be
required to get a critical mass of interactions. It certainly appears plausible that
with a few changes, we could get the job market part of the simulation to give us
This example illustrates the critical concerns with emergent behavior. Since we
do not have running code, we do not know if we will get emergent behavior at all.
We think that we can get it, but we cannot predict if we will like what emerges.
Even if we like it, the architecture offers little guidance as to how we will control it
or tune it. Experience from Chapter 5 suggests that some numbers and some
equations will be more sensitive to change than others. That experience also
suggests that we will see substantial run-to-run variations in the outcomes. That
variation causes a particular fear for AI programmers; what if the players play the
game differently from how it was tested, and a new and utterly inappropriate
behavior emerges after the game ships? The fact that other AI techniques can
exhibit a similar vulnerability is a small consolation.
Good emergent behavior gives the illusion of higher-order organization and
coordination than are actually present. The method can be very cheap to pro-
gram and is robust. The results typically have lifelike qualities that would be
extremely difficult to achieve using other methods.
The drawbacks to emergent behavior tend to relate to the unknowns. Game
designers and quality-assurance staff tend to place a very high value on control
and predictability. Neither group will be pleased if the herd of water buffalo
wanders out of the mouth of the ravine and makes itself unavailable for a
stampede that would kill the evil tiger that the player has lured into place. The
unknowns increase if the envisioned system is far from what others have done
before; the AI programmer does not know if he or she will obtain good emergent
behavior until after the system is programmed.
The Cars and Trucks project differs from a typical flocking implementation
in that the vehicles are not expected to stay in a flock. The desired speeds
of our vehicles cover a wide range—from 50-pixels-per-second trucks to