Game Development Reference
In-Depth Information
By designing general patterns rather than individual cases, you can more easily
understand how your game will really work, and you will also make it easier for the
programmers to program it. The programmers will write general-case code that
applies most of the time, rather than having to write separate subroutines for each
creature. You can still create a few special cases for variety or when circumstances
require it. In
Monopoly
, the rules for collecting rent on colored properties (the ones
named after streets) are the general case, while the railroads and utilities are special
cases that create additional interest. But try to avoid creating large numbers of spe-
cial cases.
DON'T TRY TO GET EVERYTHING PERFECT ON PAPER
Unless you're designing a trivially simple game, you won't get everything perfectly
right on paper, because you won't be able to compute the effects of all your mechanics
in your head. Designing core mechanics (and just about everything else in a video
game, too) requires iterative refinement. Create a first draft of your mechanics and
then build a prototype that implements them, either in a spreadsheet program or
in software. Test and adjust your mechanics using the prototype. If you try to get
everything exactly right on paper, you won't ever get the project finished. Although
this may sound odd, it is more important to be clear and precise in your documen-
tation than it is to be accurate. You will find it much easier to correct a mechanic
that doesn't work quite the way you expected than to try to resolve ambiguous lan-
guage late in the development process.
FIND THE RIGHT LEVEL OF DETAIL
You can design core mechanics at any level of detail, but there are tradeoffs. If you
document the core mechanics minutely, with no detail left unaddressed, the pro-
grammers can turn your mechanics directly into code very quickly. That seems like
a good idea in principle, but in practice you will almost certainly be swamped with
work. Designers who try to document every single thing about the core mechanics
delay their projects—or cause them to be canceled.
The problem at the opposite end of the spectrum, leaving too much unclear, is
almost as bad. Either the programmers will have to come and ask you for further
details, or they will make their best guess for themselves. If you have clearly com-
municated your vision to them, and you see eye to eye about how the game should
work in principle, then their guesses may be good ones. But in practice, the pro-
grammers will often make assumptions other than what you intended, and you'll
notice the mistake in the tuning phase. It can be time consuming to go back and
correct bugs introduced by ambiguous design decisions.
To find a happy medium, use traditional gaming conventions where appropriate to
avoid overloading yourself. If your game features some very ordinary scenarios and
you are confident that the programmers will know what you mean, you can afford
to use general language. You don't have to write, “When a car's
number of laps
