Game Development Reference
In-Depth Information
uninteresting details. It moves the player out of the flow state and into boredom.
Likewise, any gameplay decision that has no real effect on the game world, or any
decision that requires the player to pick from a slate of options that includes only
one reasonable option, is trivial. Let the computer handle it. (This doesn't apply to
non-gameplay decisions, such as self-expressive acts—choosing a team color may
not affect the gameplay, but the player should still be allowed to do it.)
Sid Meier's Alpha Centauri
handles this magnificently. In this game, the player can
choose to handle every decision from overall control of the planet all the way
down to production and direction of individual units, or she can let a computer-
controlled manager control her bases and her units. This accommodates players
who want to micromanage every aspect of the game as well as those interested
only in grand strategy. This is a superior design because it gives the player a choice.
Other games force the player to do all the micromanagement, whether she wants
to or not.
Triviality can add to the player's enjoyment when you use it well and not too often.
Consider a cops and robbers game. The player's avatar, a police officer, patrols the
city as usual, on the lookout for crime, when he spots a group of suspicious-looking
characters on the corner. He stops the car, and they immediately run down an
alleyway and vanish; the player won't meet these particular characters again, and
they do not form part of the game's story. These characters provide local color
rather than part of the gameplay. If you don't lead the player
too
far down the
wrong path, you can use such trivial interaction to give the impression that there
is more to the city than meets the eye.
In the later stages of game development, you will spend a great deal of time tweak-
ing and tuning your game to improve its balance and remove any dominant
strategies or difficulty spikes that may have crept in. Here you'll find a few sugges-
tions to make this process easier.
Chapter 10 explains that you should seek to generalize when you can, to create a
set of mechanics that apply to a wide variety of entities rather than creating sepa-
rate mechanics for each entity. So, for example, in any game that involves combat,
try to create one set of mechanics that governs combat between units regardless of
what types of units the combat involves. Not only does this simplify the program-
ming—the developers can concentrate on implementing the core mechanics and
then adding entities on top of those core rules, rather than coding each entity sepa-
rately—it also simplifies tuning the design.
If each entity has its own mechanics, the mechanics for each entity must be tuned
separately, which could potentially cause balance problems. If you use generalized
mechanics as described in “Look for Patterns, Then Generalize” in Chapter 10,
