FUNDAMENTALS OF GAME DESIGN, SECOND EDITION

Turning Rules into Core Mechanics

In the early stages of design, you may have only a hazy idea of the details of your game's rules. Early on, you may say, "Players will be penalized for taking too long to get through the swamp." or "Players will have only a limited time to get through the swamp." But that description does not supply enough information to build a game. What is the penalty? How long does the player have? When you design the core mechanics, you define the rules precisely and completely. That same rule in

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.

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.

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.

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 know 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.