FUNDAMENTALS OF GAME DESIGN, SECOND EDITION
Mechanics
Mechanics document how the game world and everything in it behave. Mechanics state the relationships among entities, the events and processes that take place among the resources and entities of the game, and the conditions that trigger events and processes. The mechanics describe the overall rules of the game but also the behavior of particular entities, from something as simple as a light switch up to
the AI of a very smart NPC. The earlier section "Functions of the Core Mechanics in Operation" gave a list of the kinds of things mechanics do in a game.
Some mechanics operate throughout the game, while others apply only in particular gameplay modes and not in others. A mechanic that operates throughout the game is called a global mechanic. Any game with more than one gameplay mode needs at least one global mechanic that governs when the game changes from mode to mode, and an entity that records what mode it is in.
If the value of one entity depends upon the value or state of one or more other entities, you need to specify the relationship between the entities involved. In the case of numeric entities, you express the relationship mathematically. Many role-playing games, for example, define character levels in terms of experience points earned; when a character earns a certain amount of experience, his level goes up. The formula may be given by a simple equation, such as character level = experience points x 1,000, or a more complicated equation, or it may require looking the value up in a table.
If the nature of this relationship remains constant throughout the game, you need not worry about specifying when it should actually be computed; let the programmers decide that. Just specify the relationship itself.
When you describe an event or a process, you state that something happens: A change occurs among, or to, the entities specified in the mechanics.
An event is a specific change that happens once when triggered by a condition (defined in the next section) and doesn't happen again until triggered again.
"When the player picks up a golden egg" specifies a trigger condition, and "he gets two points" defines an event.
A process refers to a sequence of activities that, once initiated, continues until stopped. A player action or other game event starts a process that runs until something stops it.
Both events and processes may consist of whole sequences of actions that the computer must take. When you document such a sequence, be clear about the order in which things should happen. Part of the sequence getting dressed might be, "First put on socks, then put on shoes." If you leave the language ambiguous and the programmer misinterprets your meaning, you will introduce a bug into the game.
|
Use conditions to define what causes an event to occur and what causes a process to start or stop. Conditional statements often take the form if (condition) then (execute an event, or start or stop a process); whenever (condition) take action to (execute an event, or start or stop a process); and continue (a process) until (condition). Mechanics defining victory and loss conditions conform to this style.
You can also define conditions in negative terms, such as if (condition) then do not (execute an event, or start or stop a process), although a condition in this form is incomplete. "If the mouse is wearing its cat disguise, the cat won't attack it," doesn't provide enough information because it doesn't tell the programmers when the cat does attack the mouse. Use this form of conditional mechanic for indicating exceptions to more general rules already specified: "When a cat sees a mouse, the cat will attack it. But if the mouse is wearing its cat disguise, the cat won't attack it."
ENTITIES WITH THEIR OWN MECHANICS
Some mechanics define the behavior of only one type of entity and nothing else in the game, in which case you should figure out the details and document the entity and its associated exclusive mechanics together. This makes it easier for the programmers to build the game and for you to find the documentation if you need to change something. This is very like object-oriented programming. In object-oriented programming, you think about the variables and the algorithms that manipulate them together as a unit.
Examples of entities with their own mechanics include symbolic entities that require special mechanics to indicate how they change state (such as a traffic light); numeric entities whose values are computed from other entities by a formula (such as the amount of damage done in an attack under Dungeons & Dragons rules—it is computed from several other factors, some of them random); nonplayer characters with Al-controlled behavior (the definition of the artificial intelligence consists of mechanics); and entities that act autonomously even if their behavior doesn't really qualify as artificial intelligence, such as a trap that triggers whenever a character comes near. In the case of a triggered trap, you define its various attributes, both functional and cosmetic, and a set of mechanics that indicate exactly what sets it off and what kind of damage it does to the character who triggers it.
