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 particu­lar 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.

RELATIONSHIPS AMONG ENTITIES

If the value of one entity depends upon the value or state of one or more other enti­ties, 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 program­mers decide that. Just specify the relationship itself.

EVENTS AND PROCESSES

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 some­thing stops it.

Both events and processes may consist of whole sequences of actions that the com­puter 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 pro­grammer misinterprets your meaning, you will introduce a bug into the game.

image061

ANALYZING A MECHANIC

Let's go back to the sample mechanic that Chapter 2 introduced in the sidebar “Game Idea Versus Design Decision” and identify its various components. To specify the idea “Dragons should protect their eggs,” we create a mechanic that reads: “Whenever they have eggs in their nests, female dragons do not move out of visual range of the nest.

If an enemy approaches within 50 meters of the nest, the dragon abandons any other activity and returns to the nest to defend the eggs. She does not leave the nest until no enemy has been within the 50-meter radius for at least 30 seconds. She defends the eggs to her death.”

This mechanic makes up one small part of the specification of a female dragon's artificial intelligence. It applies to all female dragons at any time, so it belongs in the core mechanics, not in the design of a level. (However, if dragons appear in only one level, this mechanic should be part of that level's design, and if the dragon is a unique entity, you should specify the mechanics relating to its behavior wherever you define what a dragon is, and nowhere else.)

Here's how this mechanic looks with the components identified:

“Whenever they have eggs in their nests (a condition about a relationship between a resource, eggs, and an entity, the nest, such that eggs in nest > 0), female dragons (each one an entity) do not move (a process) out of visual range of the nest (a condition placed on the movement process). If an enemy (an entity) comes within 50 meters of the nest (a condition), the dragon abandons any other activity (end her current process) and returns to the nest (a process) to defend the eggs (a process). She does not leave the nest (initiate a process) until no enemy has been within the 50-meter radius for at least 30 seconds (a complicated condition that prevents her from initiating the process of leaving the nest).

She defends the eggs to her death (a condition indicating that the dragon does not initi­ate any other process while defending the eggs, such as running away).”

Even this, complex as it is, isn't complete. It doesn't say whether or not eggs can be destroyed or removed from the nest and, if so, what the dragon does about it. It doesn't state how visual range should be computed, how the dragon goes about returning to her nest, or what defending the eggs actually consists of. It also includes a negative condi­tion (“she does not leave the nest until. . . ”) without a general rule stating when she does leave the nest in the first place. All that information must be included elsewhere in the definition of the dragon's AI and the definition of a nest and an egg. If you don't define these things specifically, the programmers will either come and ask you to, or they will make a guess for themselves.

 

CONDITIONS

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 excep­tions 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 pro­grammers 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-ori­ented 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.

Добавить комментарий

FUNDAMENTALS OF GAME DESIGN, SECOND EDITION

Arcade Mode Versus Simulation Mode

Switching into arcade mode skews the play toward lots of action and relatively few slow-paced game states, such as strikeouts or walks. Arcade mode makes the game more exciting at …

THE SECRET OF MONKEY ISLAND

The Secret of Monkey Island, now nearly 20 years old, remains worth studying because it spawned a highly successful franchise. Although it is ostensibly set on a Caribbean island in …

Human Intelligence Instead of Artificial Intelligence

In single-player games, the player competes against the computer, so the computer has to have enough artificial intelligence (AI) to be a good opponent; building the AI for a complex …

Как с нами связаться:

Украина:
г.Александрия
тел./факс +38 05235  77193 Бухгалтерия

+38 050 457 13 30 — Рашид - продажи новинок
e-mail: msd@msd.com.ua
Схема проезда к производственному офису:
Схема проезда к МСД

Партнеры МСД

Контакты для заказов оборудования:

Внимание! На этом сайте большинство материалов - техническая литература в помощь предпринимателю. Так же большинство производственного оборудования сегодня не актуально. Уточнить можно по почте: Эл. почта: msd@msd.com.ua

+38 050 512 1194 Александр
- телефон для консультаций и заказов спец.оборудования, дробилок, уловителей, дражираторов, гереторных насосов и инженерных решений.