http://my.safaribooksonline.com/print?xmlid=9780321685377...

Username: Barry James Book: Fundamentals of Game Design, Second Edition. No part of any chapter or book may be reproduced or transmitted in any form by any means without the prior written permission for reprints and excerpts from the publisher of the book or chapter. Redistribution or other use that violates the fair use privilege under U.S. copyright laws (see 17 USC107) or that otherwise violates these Terms of Service is strictly prohibited. Violators will be prosecuted to the full extent of U.S. Federal and Massachusetts laws.

What Are the Core Mechanics?

Isnt the greatest rule of all the rules simply to please? MOLIRE You first read about core mechanics in Chapter 2, Design Components and Processes. There you learned that the core mechanics are the heart of the game, generating the gameplay and implementing the rules. This chapter examines the core mechanics in further detail and offers a formal definition: Core Mechanics The core mechanics consist of the data and the algorithms that precisely define the games rules and internal operations.

Turning Rules into Core Mechanics

In the early stages of design, you may have only a hazy idea of the details of your games 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 filling 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 avatars face, and if by that time the avatar is still in the swamp, the avatar dies. If the avatar 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 algorithms, 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,

1 of 6

10/06/2012 10:52 PM

http://my.safaribooksonline.com/print?xmlid=9780321685377...

take up less than three full pages. However, the rules printed on the paper are not sufficient to build a computer game: They dont 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 considerably more detailed than the general rules.

Where Are the Core Mechanics?

The core mechanicsthe precise definition of the rules and internal operations of the gameremain 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 youve 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.

2 of 6

10/06/2012 10:52 PM

http://my.safaribooksonline.com/print?xmlid=9780321685377...

The player does not experience the core mechanics directly. She cant 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 dont 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 games 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. Dont 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 dont 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.

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 cant 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 whats 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 doesnt really matter. When these algorithms exist only in the core mechanics design document, they obviously cant do anything, but when the programmers turn them into code, they can. Therefore, when you read, The core mechanics send triggers to the storytelling engine, its just shorthand for a longer sentence that reads, The game engine,

3 of 6

10/06/2012 10:52 PM

http://my.safaribooksonline.com/print?xmlid=9780321685377...

using algorithms specified by the core mechanics, sends triggers to the storytelling engine.

Functions of the Core Mechanics in Operation

During play, the core mechanics (as implemented by the game engine) operate behind the scenes to create and manage gameplay for the player, keep track of everything that happens in the game world, and work with the storytelling engine to help tell the story. The following list details what core mechanics do: Operate the internal economy of the game. The core mechanics specify how the game or the player creates, distributes, and uses up the goods on which the game bases its economy. This function is the most important role of the core mechanics. The later section The Internal Economy addresses this in detail. Present active challenges to the player via the user interface, as the level design specifies. Active challenges are those governed by mechanics. Passive challenges, such as a chasm that the avatar must jump over, dont have mechanics of their own. The later section Challenges and the Core Mechanics discusses the distinction between active and passive challenges. Accept player actions from the user interface and implement their effects upon the game world and other players. Detect victory or loss, and the termination conditions of the game. More generally, the mechanics detect success or failure in all challenges in the game, and apply whatever consequences the rules call for. Operate the artificial intelligence of nonplayer characters and artificial opponents. Switch the game from mode to mode. The core mechanics keep track of the current gameplay mode and, whenever a mode change occurs (either because the nature of the game requires it or the player requests it), the core mechanics switch modes and signal the user interface to update the UI accordingly. Transmit triggers to the storytelling engine when game events or player actions that influence the plot occur.

Real-Time Games Versus Turn-Based Games

Your specification of the core mechanics will read somewhat differently depending on whether your game is turn-based or takes place in real time.

4 of 6

10/06/2012 10:52 PM

http://my.safaribooksonline.com/print?xmlid=9780321685377...

Most video games operate in real time, so the core mechanics specify the parameters of a living world that operates on its own whether the player acts or not. Many of the mechanics you design will be processes that operate continuously or for extended periods. AI-driven characters go about their business, traps check to see if they should spring upon anyone, banks collect and pay interest, and so on. When you specify one-shot events rather than continuous processes, the events will often occur as a direct or indirect consequence of player actions or because some process detects a special condition, such as when a runner crosses the finish line in a race. (The later section Mechanics discusses events and processes in greater detail.) In a turn-based game with no artificial opponents, the core mechanics dont do anything at all until a player takes his turn. Once he has done so, the core mechanics can compute the effects of his actions on the game world. Then the mechanics remain idle while the next player takes her turn, and so on. In some games, all the players enter their intended actions simultaneously while the mechanics remain idle; once the players finish for that turn, the core mechanics compute the effect of all players actions. In a turn-based game, then, your design for the mechanics will read like a specification for a sequence of events rather than a set of processes that operate all the time. You will state the effects of each possible action and what other computations take place as a consequence. Although you may design processes for a turn-based game, you must realize that processes do not really operate continuously; they only run between player turns. Your design for a process in a turn-based game must include points at which the process may safely be interrupted for the next players turn. In a turn-based game that does have artificial opponents or NPCs, the mechanics dont remain entirely idle between turns because they must compute the behavior of these characters. However, the artificial characters still act in turns, just as the player does.

Core Mechanics and Level Design

Most video games for consoles and personal computers present gameplay in separate levels (also called chapters, missions, or scenarios, depending on the genre), each with its own set of initial conditions, challenges, and termination conditions. Level designers plan, construct, and test these levels, as Chapter 12, General Principles of Level Design, discusses. Ordinarily, the level design specifies the type, timing, and sequence of challenges that appear during play, whereas the core mechanics specify how different challenges actually work. When a level starts up, the core mechanics read the level design data from a file, which includes: the initial state of the game world for
5 of 6 10/06/2012 10:52 PM

http://my.safaribooksonline.com/print?xmlid=9780321685377...

each level; the challenges, actions, and NPCs for each level; and the victory conditions for the levels (see Figure 10.1). If the game consists of only one level or creates randomized levels, the core mechanics must also include mechanics for setting up the level before the game first enters a gameplay mode.

Figure 10.1. The core mechanics read the level design data from files.

Therefore, your design for the core mechanics should specify how challenges work in general but not exactly which challenges each level will contain. As you design the core mechanics, concentrate on those features of the game that will be needed in more than one level, and leave special-case features found only in a particular level to the level designer. It may be that the level designer can create code for those features using a scripting language and wont have to ask the games programmers to do it. This doesnt mean that you can push all the work off onto the level designers, though. Think of the features you create in the core mechanics as being like LEGO blocks that the level designers will use to build their level. In a war game, the core mechanics, not the level designs, define how all the units in the game move and fight. Once you design all the units, the level designers can use your information on how the units operate to construct exciting levels featuring those units.

6 of 6

10/06/2012 10:52 PM