FUNDAMENTALS OF GAME DESIGN, SECOND EDITION
Actions and the Core Mechanics
The challenges in a game vary from level to level in type, frequency, sequence, and other respects, but the actions available to the player normally do not change from level to level except that, in some games, more actions become available as the player progresses through the game. Consequently, the level designers play a smaller role in determining what actions are available than they do in choosing challenges for a level, though they can choose challenges that tend to require the use of some actions more than others. (Sometimes level designers also specify that familiar actions should not be available. See "Make Atypical Levels Optional" in Chapter 12.)
PLAYER ACTIONS TRIGGER MECHANICS
When you design the core mechanics, you must specify a mechanic that implements each action in each gameplay mode, which will either initiate an event or start or stop a process. When the user interface detects data arriving from an input device, UI routines determine what action the player desires by checking the assignment of actions to buttons (or similar control devices) established by the gameplay mode's interaction model. The UI then triggers whatever mechanic you specified for that action.
Let's look at a simple example from a first-person game. When a player presses a button assigned to the crouch action, the UI triggers a crouch mechanic that implements the action. You must define this mechanic to do two things. First, it changes a symbolic posture attribute of the avatar from the walking upright state to the
crouching state. (This attribute may affect other mechanics—it could influence how big a target the crouching figure presents—but the crouch mechanic does not implement those effects itself.) Next, because all actions should be accompanied by feedback, your crouch mechanic lowers the value of a numeric attribute of the avatar that determines how far the avatar's head is above the ground. The graphics engine detects this and shows the first-person view from a crouching, rather than an upright, perspective.
More complicated actions may involve manipulation or storage of data that arrives from the user interface. In such cases, you must create both an event mechanic that implements the action and an entity that stores the data. The user interface sets the value of the entity for the mechanic to interpret.
Suppose that in our first-person game, the player uses a mouse to control which direction the avatar faces, and he moves the mouse to the right. This input translates into an action, causing the avatar to turn to the right. But a mouse is an analog device, not a binary one like a controller button, so in addition to the information that the mouse moved, the UI also sends data about how far it moved. This event requires a mechanic that must interpret the data and make the appropriate changes to the avatar's direction-facing attribute.