Ultimate Game Design : Building game worlds

Building Game Worlds
124
U L T I M A T E G A M E D E S I G N
There is a natural tendency to over-commit, and to over-design (extend the scope
of the game in too many simultaneous directions). Design-wise, similar to an RTS,
you need to specify in detail all of your unit pieces, their functionality, and their behavior.
Most important, you need to define the rules that govern how they live and
change together.
Simulators often start with a “blank slate” beginning for the player. This is the beginning
of a somewhat open-ended process, although the game may end with a certain
objective reached (for example, a certain sales record, attendance record, or
physical size). These are really akin to digital construction sets with the ability to
track player-edited values and decision points. This is a very appealing aspect for
those who like to see choice or action results played out before them.
Simulators have the advantage of being relatively easy to expand. Once your art
specifications are solid for creating new “pieces” (provided they don’t require complex
code components on the behavior side), many new units can be added to
re-theme the game, extend its replay value, or to specialize it.
These titles offer a more passive and cerebral experience for players who aren’t
necessarily looking for fast-action overkill. It can be very relaxing to build up or to
play a simulation scenario, start adjusting values, make changes, and watch the results
unfold.
A large part of the design backbone for simulation-oriented games lies in defining
and implementing a rule system that will guide or govern the growth process. At the
most basic level, this can be modeled in a standard database program or on paper.
From a “numbers” standpoint, this can be a simple or horrendously complex undertaking.
It can be tempting for aggressive “computation excited” developers to try to
do amazingly complex data models of economies, behaviors, attitudes, and the like,
bringing the results of these computations to bear on the simulation for the player.
Commercially speaking, developers regularly run out of time and end up forcing
rules into the code that sound like “A measure of dissatisfaction results when taxes
outweigh services” or “A measure of dissatisfaction results when admission prices
outweigh perceived value.” I know this is very general, but these are the starting
points for shaping rules that might guide or govern a simulation-based play experience.
Basically, it becomes a bunch of data table comparisons. Do visitors to your complex
recognize that there aren’t enough bathrooms or exciting rides? It becomes a table
comparison, and I think you can see the idea behind it. That’s exactly how you
begin to build up your rule set. The rules cascade and have priority. You have your
“driving” rules that are checked first in comparison, and then the rules that are peripheral
or supplemental to the driving rules.