Game Development Reference
In-Depth Information
the core mechanics might read something like, “When the avatar enters the
swamp, the black toadstools begin to emit a poison gas that the player can see fill-
ing the screen, starting at the bottom and rising at a rate of 1 game-world inch
every 3 seconds; by the end of 3 minutes, the gas reaches the height of the avatar's
face, and if by that time the avatar is still in the swamp, the avatar dies. If the ava-
tar returns to the swamp later, the gas is gone but the process starts over again from
the beginning.” In this example, the clauses beginning with
when
and
if
state algo-
rithms, and
1 game-world inch every 3 seconds
and
3 minutes
are examples of data
that also form a part of the rule.
THE RULES AND CORE MECHANICS OF
MONOPOLY
The rules of
Monopoly
, as Parker Brothers ships them with the game, take up less than
three full pages. However, the rules printed on the paper are not sufficient to build a
computer game: They don't include complete documentation of all the data necessary to
play. To properly specify the core mechanics of
Monopoly
, you would have to include not
only the printed rules but the prices of each of the properties on the board, the different
amounts of rent that may be collected at each location (including special mechanics for
the utilities and railroads), the layout of the board, and the effects of all the Chance and
Community Chest cards. A full specification of the core mechanics of
Monopoly
is consid-
erably more detailed than the general rules.
Where Are the Core Mechanics?
The core mechanics—the precise definition of the rules and internal operations of
the game—remain the same whether you keep them in your head, write them on
paper, or implement them in any programming language you like. Although the
mechanics remain the same, their
implementation
varies as your project goes through
the different stages of the design and development process. First you document the
algorithms in ordinary language in a design document; at this point, if you want to
change the mechanics, you edit the document. Later you may build a spreadsheet
containing the algorithms and data and tweak them there. Or you might make a
paper prototype
that allows you to play the game, writing the values of the variables
on pieces of paper and manipulating them yourself according to the algorithms
you've worked out, to see if the algorithms produce the game experience you want
to offer. Using what you learn, you may update the design documents or just let the
spreadsheets become the official implementation. The core mechanics remain the
rules of the game; only the implementation has changed.
Eventually the core mechanics, as complete as you can make them, should be so
precisely stated that the programmers can write code using your core mechanics
document or your spreadsheet as specifications. The algorithms of the core
mechanics become the algorithms in their code, and the data required by the core
mechanics reside in files so that the game software can read them in as necessary.
