Game Development Reference
In-Depth Information
At this point, if you want to change the mechanics, you ask the programmers to
change the code or the data files. You should in principle also change the design
documents; in practice, designers seldom do this because the code and files have
become the authorized implementation of the core mechanics. In short, the core
mechanics are wherever your team considers their
official
implementation to be:
in the design documents, the spreadsheets, or in the code and data files.
The player does not experience the core mechanics directly. She can't point to
something on the screen and say, “Those are the core mechanics.” If you apply
player-centric design principles, all of the core mechanics work together to provide
a good game experience even though players don't know what core mechanics are
and can only infer the functionality of the core mechanics from the way the game
behaves.
DESIGN RULE
Design the Game, Not the Software
The
game engine
is the part of the software that implements the game's rules. While the
core mechanics spell out the rules of the game in detail, so that in practice they specify
what the game engine will do, the core mechanics do not dictate exactly
how
the game
engine will do it. Don't worry about defining the precise algorithms the programmers
should use to build the game engine. That decision is theirs to make. In short, if there is
more than one way to achieve the same effect in the game, let the programmers decide
which one to use.
You don't have to k now how to program to design the core mechanics, but you
must be generally familiar with algorithmic processes. The later section “Mechanics”
addresses this in more detail.
The Core Mechanics as Processes
If you get a job in the game industry, you will hear industry professionals talk
about the core mechanics as if the mechanics actively take part in the game: The
core mechanics “talk to the storytelling engine” or “signal the UI.” But rules can't
act. You would never say of
Monopoly
that the rules do anything beyond perhaps
“allowing” the player to take a particular action or “specifying” a penalty. So what's
going on?
The relationship between the core mechanics and the game engine is extremely
close, because the core mechanics specify how it will behave. So references to the
core mechanics may sound like references to the engine itself. As long as you
understand that the core mechanics consist of algorithms and data that precisely
define the rules, it doesn't really matter. When these algorithms exist only in the
core mechanics design document, they obviously can't do anything, but when the
programmers turn them into code, they can.
