Fundamentals Game Design Ch10 Key Concepts
Content
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.
Key Concepts
To design the core mechanics, you must document the different components that define how your game works: resources, entities, attributes, and mechanics. This section defines these terms. Although you do not have to be a programmer to design a game, you wouldn’t be a game designer if you didn’t intend for your ideas to eventually turn into computer programs. You will need to have at least a nodding acquaintance with how programmers think about data and the relationships between different items of data, ideas that crop up in this discussion.
Resources
The term resource refers to types of objects or materials the game can move or exchange, which the game handles as numeric quantities, performing arithmetic operations on the values. Resource does not refer to specific instances of these types of objects but the type itself in an abstract sense. Marbles constitute a resource in your game if your player can pick up marbles, trade them, and put them down again, but the word resource doesn’t describe a specific marble in your player’s pocket or even a specific collection of marbles; it describes marbles generally. Marbles are a resource, but the 15 marbles in the player’s pocket are an instance of a resource: a particular collection of marbles. Note Purely cosmetic items are not a resource. If you build a level full of flowers but the player can’t do anything with them and nothing ever happens to them, then flowers are not a resource. The flowers set the stage and contribute aesthetically, but the core mechanics will not need to take flowers into account.
The core mechanics define the processes by which the game creates, uses, trades,
1 of 11 10/06/2012 10:54 PM
http://my.safaribooksonline.com/print?xmlid=9780321685377...
and destroys resources; that is, the rules by which specific instances of resources—one lump of gold, the marbles in the player’s pocket, the ammo in her inventory, the water in her reservoir—can legally be moved from place to place or from owner to owner, or can come into or go out of the game. A resource may be of a type that can be handled as individual items, such as marbles, or of a type that cannot be divided into individual items, such as water (although water may be measured in volumetric units). Games often treat nonphysical concepts such as popularity or vague concepts such as resistance to poison as resources, even though we don’t ordinarily think of these as quantities that can be measured and even bought and sold. Part of a game designer’s job involves quantifying the unquantifiable—turning such abstract qualities as charisma or pugnacity into numbers that a program can manipulate.
Entities
An entity is a particular instance of a resource or the state of some element of the game world. (A light may be on or off, for instance.) A building, a character, or an animal can be an entity, but perhaps less obviously a pile of gold or a vessel of water can be an entity. The state of a traffic light that at any given time might be red, green, or yellow can also be an entity. Be sure you understand the difference between resources and entities. Remember that a resource is only a type of thing, not the thing itself. A specific airplane is an entity, but if your game includes a factory that manufactures airplanes, such that management of the supply of airplanes makes up part of the gameplay, then airplanes, as a commodity, constitute a resource even though each individual airplane remains an entity. Earlier, we noted that marbles can be a resource but a marble in the player’s pocket is not; now we can see that each marble in his pocket is an entity. Points in a sports game qualify as a resource, but the team’s score is an entity. The score pertains only to that team, recording a number of points scored.
Simple Entities
The player’s score or the current state of a traffic light can be completely specified by a single datum; this is called a simple entity. The single value stored in this datum can be numeric, such as a score, or symbolic, such as the possible states of a traffic light: red, green, or yellow. The later section “Numeric and Symbolic Relationships” discusses the differences between numeric and symbolic values. Once you decide to add a symbolic entity, such as a traffic light, to the game world, you will need to define it in the core mechanics as a simple entity, specifying its initial state and providing a list of all its possible states. For a
2 of 11 10/06/2012 10:54 PM
http://my.safaribooksonline.com/print?xmlid=9780321685377...
numeric entity, you’ll need to define an initial quantity and the range of possible legal values. In the tuning stage of design, you will spend a great deal of time adjusting these values, so don’t worry too much about getting them exactly right at first.
Compound Entities
It may take more than one data value to describe an entity. In a flying game, in which characterizing the wind requires stating both its speed and its direction, the wind is a compound entity. Each of these values is called an attribute. An attribute is an entity that belongs to, and therefore helps to describe, another entity. To describe the wind, you need to know the values of its speed attribute and its direction attribute. You can specify the wind’s speed with a numeric value and its direction with a symbolic value (one of a set that includes northwesterly, westerly, southwesterly, and so on). In this case, each attribute of our overall entity (the wind) is itself a simple entity, but this is not always, and not even usually, the case. Attributes may themselves be compound entities. In a sports game, a team has attributes such as its name, hometown, and statistics, as well as its collection of athletes, each of whom is an entity with his own attributes such as speed and agility. In a driving game, the car the player drives is a compound entity with attributes that describe its performance characteristics. In a business simulation, factories are compound entities with attributes for rates of production, stock on hand, and so forth. Most of the entities you will define for any game, other than the most elementary of games, will be compound entities. Figure 10.2 shows an example of three types of entities: one simple, one compound containing only simple attributes, and one compound containing both simple attributes and another compound entity. The gray boxes are only labels to aid understanding; their contents are not stored as data.
Figure 10.2. Examples of three different entities
[View full size image]
3 of 11
10/06/2012 10:54 PM
http://my.safaribooksonline.com/print?xmlid=9780321685377...
Both Chapter 5, “Creative and Expressive Play,” and Chapter 6, “Character Development,” discuss attributes at some length, so that information is not repeated here. Be aware, however, that you don’t use attributes only for characters. Any entity in the game may have attributes that describe it: Vehicles have performance characteristics, factories have production rates, and so on. As with any simple entity, you should choose an initial quantity or state for an attribute when you decide to include the attribute in your game.
If You Happen To Be a Programmer...
If you are a programmer, you may have noticed that entities sound a lot like objects in object-oriented programming: They include variables for storing numeric and symbolic values and may be made up of other entities in the same way that programming objects may be made up of other objects. And like classes of objects in programming, entities have associated mechanics (though programmers would call them functions or methods) for manipulating these data. For most practical purposes, you can treat entities and programming objects as identical, and if you happen to program as well as design your game, you will certainly implement entities as objects in your code. This book uses the term entity rather than object because we normally use object in the everyday sense to refer to some physical item in the game world.
Unique Entities
4 of 11 10/06/2012 10:54 PM
http://my.safaribooksonline.com/print?xmlid=9780321685377...
If your game contains only one entity of a particular type, then that is a unique entity. In most adventure games, the objects that the avatar can pick up are unique entities. The avatar itself in most games is a unique entity because there is usually only one avatar. In a football game, the football is a unique entity, because there may never be two footballs in play at any one time. Note that the airplanes mentioned in the previous section are not unique entities even if each carries its own serial number and particular state of repair. They still may be treated collectively, bought and sold in groups, and when treated as a group considered to be a resource.
Defining Entities for Your Game
As you specify your core mechanics, you will need to create entities for any character, object, or substance that the game needs to manipulate and for any value that the game needs to remember. In the case of items such as footballs, vehicles, money, and health, determining what attributes each entity requires will probably seem obvious—although defining their mechanics won’t always be simple. You may also need to create entities that hold quantities or other information that the user interface will display. Every indicator in the user interface needs an entity that reflects the indicator’s state or appearance. Suppose you want to warn the player when a valuable resource, such as fuel in a car’s gas tank, reaches critically low levels. You would normally put a needle gauge in the user interface to show the fuel level, and you may want to add a warning light to draw the player’s attention to the gauge. The light can be either on or off. To support the light, you need to define an entity called fuel warning that can exist in two states. During play, the user interface checks the state of the fuel warning entity to display the appropriate image of the light. You also need to create a mechanic (discussed in the next section “Mechanics”) to define precisely what conditions change the state of the fuel warning entity. You may wonder why you should create an additional entity and mechanic for the state of the warning light rather than have the user interface software check the fuel level and decide for itself whether to turn on the warning light. Professionals keep the mechanics in one part of the design and the UI in another. That way, the UI designer doesn’t have to worry about underlying mechanics; she can concentrate on screen layouts and usability considerations, and if you want to adjust the point at which the light comes on during the tuning stage of design, you can do so without interfering with the user interface itself.
Mechanics
Mechanics document how the game world and everything in it behave. Mechanics
5 of 11
10/06/2012 10:54 PM
http://my.safaribooksonline.com/print?xmlid=9780321685377...
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.
Relationships Among Entities
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 × 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.
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. Note Designing the core mechanics requires the greatest clarity and precision of language. Ambiguous mechanics turn into buggy code.
6 of 11
10/06/2012 10:54 PM
http://my.safaribooksonline.com/print?xmlid=9780321685377...
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.
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
7 of 11 10/06/2012 10:54 PM
http://my.safaribooksonline.com/print?xmlid=9780321685377...
leaving the nest). She defends the eggs to her death (a condition indicating that the dragon does not initiate 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 condition (“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 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-
8 of 11
10/06/2012 10:54 PM
http://my.safaribooksonline.com/print?xmlid=9780321685377...
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 AI-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.
Numeric and Symbolic Relationships
This section discusses the differences between the numeric and symbolic relationships and how you may combine them to achieve your design goals for the core mechanics.
Numeric Relationships
Numeric relationship means a relationship between entities defined in terms of numbers and arithmetic operations. For example, the statement “A bakery can bake 50 loaves of bread from one sack of flour and four buckets of water” specifies a numeric relationship between water, flour, and bread. Here is another example: “The probability of an injury occurring to an athlete in a collision with another athlete is proportional to the weight difference between the two athletes and their relative speeds at the time of the collision.” Although this second example leaves the precise details up to the programmer to decide, it does specify a numeric relationship: Weights and speeds, both numeric attributes of the athletes, go into computing the probability of an injury, a numeric entity. (Remember that an attribute is just an entity that belongs to another entity.) Defining numeric relationships precisely requires some familiarity with algebra and arithmetic. First, you must ensure that you use meaningful equations; if you write that the speed the convoy will travel is in part a function of the quantity defined by (the weight of supplies) ÷ (number of pack horses – number of camp followers), you may very well end up with a divide-by-zero error. Because the resulting value interacts with other parts of the mechanics, changes in the way you calculate that value will have a domino effect, ultimately influencing the gameplay itself, and you must be able to understand and predict these effects.
9 of 11
10/06/2012 10:54 PM
http://my.safaribooksonline.com/print?xmlid=9780321685377...
Chris Crawford’s Balance of Power: International Politics as the Ultimate Global Game (Crawford, 1986) remains one of the best books ever written on numeric relationships in the core mechanics. Although it is out of print, used copies are still available from online bookstores. The text is also available in ASCII form at www.erasmatazz.com/library/Balance%20of%20Power.txt. Numeric relationships lie at the heart of internal economies, and the later section “The Internal Economy” discusses them further.
Symbolic Relationships
The values of symbolic entities—red, on, empty, found, and the like—cannot be added together or otherwise manipulated mathematically. You must specify all the states that a symbolic entity may represent, and the relationships among them, without equations. For instance, the red, yellow, and green states of a traffic light are not related to each other numerically; they’re simply different. To use a traffic light, you must document how it gets into each of its possible states and how the light in each of those states affects the behavior of other entities. To define the behavior of an NPC driver who sees a traffic light, you would write three separate mechanics into his AI, one for each state of the light, to say how the driver reacts to seeing a red light, a yellow light, or a green light. When any entity in the game (such as a driver) interacts with a symbolic entity (such as a traffic light), you must state exactly what happens for each possible symbolic state of the entity. If you leave one state out, no interaction will occur with that state. Tip The values of numeric entities may change according to arithmetic processes, but you must create mechanics that explicitly change symbolic entities from state to state.
A binary (two-state) entity is sometimes called a flag. You will often create flags in your game to document whether the avatar has entered locations, overcome specific obstacles, and so on. This chapter doesn’t discuss symbolic relationships much further because they are relatively easy to define and their results are easier to predict; numeric relationships are harder to create and tune. Although it is possible to create extremely complicated symbolic relationships (think about Rubik’s Cube), most of the symbolic relationships in games tend to be rather simple.
10 of 11
10/06/2012 10:54 PM
http://my.safaribooksonline.com/print?xmlid=9780321685377...
Integrating Symbolic and Numeric Relationships
Although you cannot perform arithmetic operations on symbolic values, you can define how symbolic entities change from state to state in terms of other numeric data. If the symbolic entity fuel warning can take the values on and off, you can define a mechanic for each of the states based on the quantity of fuel available: “When the amount of fuel goes below 2 gallons, the fuel warning value switches to on. When the amount of fuel rises to 2 gallons or more, the fuel warning value switches to off.” A symbolic entity can contribute to a mathematical function if you have a mechanic that associates a symbolic entity into number. For example, the state of a car’s transmission is symbolic; the transmission is either in one gear or another, and you can’t add gears together. But you can make a table that shows the gear ratio of each gear, and use the results to make computations about the speed of the driveshafts. For example you can specify, “In first gear, the ratio is 3.83 to 1. In second gear, the ratio is 2.01 to 1. In third gear, the ratio is 1.46 to 1. In reverse gear, the ratio is 4 to -1. The negative value causes the driveshaft to turn backwards.” This mechanic converts a symbolic entity (transmission state) into a numeric entity (gear ratio).
11 of 11
10/06/2012 10:54 PM
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.
Key Concepts
To design the core mechanics, you must document the different components that define how your game works: resources, entities, attributes, and mechanics. This section defines these terms. Although you do not have to be a programmer to design a game, you wouldn’t be a game designer if you didn’t intend for your ideas to eventually turn into computer programs. You will need to have at least a nodding acquaintance with how programmers think about data and the relationships between different items of data, ideas that crop up in this discussion.
Resources
The term resource refers to types of objects or materials the game can move or exchange, which the game handles as numeric quantities, performing arithmetic operations on the values. Resource does not refer to specific instances of these types of objects but the type itself in an abstract sense. Marbles constitute a resource in your game if your player can pick up marbles, trade them, and put them down again, but the word resource doesn’t describe a specific marble in your player’s pocket or even a specific collection of marbles; it describes marbles generally. Marbles are a resource, but the 15 marbles in the player’s pocket are an instance of a resource: a particular collection of marbles. Note Purely cosmetic items are not a resource. If you build a level full of flowers but the player can’t do anything with them and nothing ever happens to them, then flowers are not a resource. The flowers set the stage and contribute aesthetically, but the core mechanics will not need to take flowers into account.
The core mechanics define the processes by which the game creates, uses, trades,
1 of 11 10/06/2012 10:54 PM
http://my.safaribooksonline.com/print?xmlid=9780321685377...
and destroys resources; that is, the rules by which specific instances of resources—one lump of gold, the marbles in the player’s pocket, the ammo in her inventory, the water in her reservoir—can legally be moved from place to place or from owner to owner, or can come into or go out of the game. A resource may be of a type that can be handled as individual items, such as marbles, or of a type that cannot be divided into individual items, such as water (although water may be measured in volumetric units). Games often treat nonphysical concepts such as popularity or vague concepts such as resistance to poison as resources, even though we don’t ordinarily think of these as quantities that can be measured and even bought and sold. Part of a game designer’s job involves quantifying the unquantifiable—turning such abstract qualities as charisma or pugnacity into numbers that a program can manipulate.
Entities
An entity is a particular instance of a resource or the state of some element of the game world. (A light may be on or off, for instance.) A building, a character, or an animal can be an entity, but perhaps less obviously a pile of gold or a vessel of water can be an entity. The state of a traffic light that at any given time might be red, green, or yellow can also be an entity. Be sure you understand the difference between resources and entities. Remember that a resource is only a type of thing, not the thing itself. A specific airplane is an entity, but if your game includes a factory that manufactures airplanes, such that management of the supply of airplanes makes up part of the gameplay, then airplanes, as a commodity, constitute a resource even though each individual airplane remains an entity. Earlier, we noted that marbles can be a resource but a marble in the player’s pocket is not; now we can see that each marble in his pocket is an entity. Points in a sports game qualify as a resource, but the team’s score is an entity. The score pertains only to that team, recording a number of points scored.
Simple Entities
The player’s score or the current state of a traffic light can be completely specified by a single datum; this is called a simple entity. The single value stored in this datum can be numeric, such as a score, or symbolic, such as the possible states of a traffic light: red, green, or yellow. The later section “Numeric and Symbolic Relationships” discusses the differences between numeric and symbolic values. Once you decide to add a symbolic entity, such as a traffic light, to the game world, you will need to define it in the core mechanics as a simple entity, specifying its initial state and providing a list of all its possible states. For a
2 of 11 10/06/2012 10:54 PM
http://my.safaribooksonline.com/print?xmlid=9780321685377...
numeric entity, you’ll need to define an initial quantity and the range of possible legal values. In the tuning stage of design, you will spend a great deal of time adjusting these values, so don’t worry too much about getting them exactly right at first.
Compound Entities
It may take more than one data value to describe an entity. In a flying game, in which characterizing the wind requires stating both its speed and its direction, the wind is a compound entity. Each of these values is called an attribute. An attribute is an entity that belongs to, and therefore helps to describe, another entity. To describe the wind, you need to know the values of its speed attribute and its direction attribute. You can specify the wind’s speed with a numeric value and its direction with a symbolic value (one of a set that includes northwesterly, westerly, southwesterly, and so on). In this case, each attribute of our overall entity (the wind) is itself a simple entity, but this is not always, and not even usually, the case. Attributes may themselves be compound entities. In a sports game, a team has attributes such as its name, hometown, and statistics, as well as its collection of athletes, each of whom is an entity with his own attributes such as speed and agility. In a driving game, the car the player drives is a compound entity with attributes that describe its performance characteristics. In a business simulation, factories are compound entities with attributes for rates of production, stock on hand, and so forth. Most of the entities you will define for any game, other than the most elementary of games, will be compound entities. Figure 10.2 shows an example of three types of entities: one simple, one compound containing only simple attributes, and one compound containing both simple attributes and another compound entity. The gray boxes are only labels to aid understanding; their contents are not stored as data.
Figure 10.2. Examples of three different entities
[View full size image]
3 of 11
10/06/2012 10:54 PM
http://my.safaribooksonline.com/print?xmlid=9780321685377...
Both Chapter 5, “Creative and Expressive Play,” and Chapter 6, “Character Development,” discuss attributes at some length, so that information is not repeated here. Be aware, however, that you don’t use attributes only for characters. Any entity in the game may have attributes that describe it: Vehicles have performance characteristics, factories have production rates, and so on. As with any simple entity, you should choose an initial quantity or state for an attribute when you decide to include the attribute in your game.
If You Happen To Be a Programmer...
If you are a programmer, you may have noticed that entities sound a lot like objects in object-oriented programming: They include variables for storing numeric and symbolic values and may be made up of other entities in the same way that programming objects may be made up of other objects. And like classes of objects in programming, entities have associated mechanics (though programmers would call them functions or methods) for manipulating these data. For most practical purposes, you can treat entities and programming objects as identical, and if you happen to program as well as design your game, you will certainly implement entities as objects in your code. This book uses the term entity rather than object because we normally use object in the everyday sense to refer to some physical item in the game world.
Unique Entities
4 of 11 10/06/2012 10:54 PM
http://my.safaribooksonline.com/print?xmlid=9780321685377...
If your game contains only one entity of a particular type, then that is a unique entity. In most adventure games, the objects that the avatar can pick up are unique entities. The avatar itself in most games is a unique entity because there is usually only one avatar. In a football game, the football is a unique entity, because there may never be two footballs in play at any one time. Note that the airplanes mentioned in the previous section are not unique entities even if each carries its own serial number and particular state of repair. They still may be treated collectively, bought and sold in groups, and when treated as a group considered to be a resource.
Defining Entities for Your Game
As you specify your core mechanics, you will need to create entities for any character, object, or substance that the game needs to manipulate and for any value that the game needs to remember. In the case of items such as footballs, vehicles, money, and health, determining what attributes each entity requires will probably seem obvious—although defining their mechanics won’t always be simple. You may also need to create entities that hold quantities or other information that the user interface will display. Every indicator in the user interface needs an entity that reflects the indicator’s state or appearance. Suppose you want to warn the player when a valuable resource, such as fuel in a car’s gas tank, reaches critically low levels. You would normally put a needle gauge in the user interface to show the fuel level, and you may want to add a warning light to draw the player’s attention to the gauge. The light can be either on or off. To support the light, you need to define an entity called fuel warning that can exist in two states. During play, the user interface checks the state of the fuel warning entity to display the appropriate image of the light. You also need to create a mechanic (discussed in the next section “Mechanics”) to define precisely what conditions change the state of the fuel warning entity. You may wonder why you should create an additional entity and mechanic for the state of the warning light rather than have the user interface software check the fuel level and decide for itself whether to turn on the warning light. Professionals keep the mechanics in one part of the design and the UI in another. That way, the UI designer doesn’t have to worry about underlying mechanics; she can concentrate on screen layouts and usability considerations, and if you want to adjust the point at which the light comes on during the tuning stage of design, you can do so without interfering with the user interface itself.
Mechanics
Mechanics document how the game world and everything in it behave. Mechanics
5 of 11
10/06/2012 10:54 PM
http://my.safaribooksonline.com/print?xmlid=9780321685377...
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.
Relationships Among Entities
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 × 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.
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. Note Designing the core mechanics requires the greatest clarity and precision of language. Ambiguous mechanics turn into buggy code.
6 of 11
10/06/2012 10:54 PM
http://my.safaribooksonline.com/print?xmlid=9780321685377...
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.
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
7 of 11 10/06/2012 10:54 PM
http://my.safaribooksonline.com/print?xmlid=9780321685377...
leaving the nest). She defends the eggs to her death (a condition indicating that the dragon does not initiate 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 condition (“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 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-
8 of 11
10/06/2012 10:54 PM
http://my.safaribooksonline.com/print?xmlid=9780321685377...
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 AI-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.
Numeric and Symbolic Relationships
This section discusses the differences between the numeric and symbolic relationships and how you may combine them to achieve your design goals for the core mechanics.
Numeric Relationships
Numeric relationship means a relationship between entities defined in terms of numbers and arithmetic operations. For example, the statement “A bakery can bake 50 loaves of bread from one sack of flour and four buckets of water” specifies a numeric relationship between water, flour, and bread. Here is another example: “The probability of an injury occurring to an athlete in a collision with another athlete is proportional to the weight difference between the two athletes and their relative speeds at the time of the collision.” Although this second example leaves the precise details up to the programmer to decide, it does specify a numeric relationship: Weights and speeds, both numeric attributes of the athletes, go into computing the probability of an injury, a numeric entity. (Remember that an attribute is just an entity that belongs to another entity.) Defining numeric relationships precisely requires some familiarity with algebra and arithmetic. First, you must ensure that you use meaningful equations; if you write that the speed the convoy will travel is in part a function of the quantity defined by (the weight of supplies) ÷ (number of pack horses – number of camp followers), you may very well end up with a divide-by-zero error. Because the resulting value interacts with other parts of the mechanics, changes in the way you calculate that value will have a domino effect, ultimately influencing the gameplay itself, and you must be able to understand and predict these effects.
9 of 11
10/06/2012 10:54 PM
http://my.safaribooksonline.com/print?xmlid=9780321685377...
Chris Crawford’s Balance of Power: International Politics as the Ultimate Global Game (Crawford, 1986) remains one of the best books ever written on numeric relationships in the core mechanics. Although it is out of print, used copies are still available from online bookstores. The text is also available in ASCII form at www.erasmatazz.com/library/Balance%20of%20Power.txt. Numeric relationships lie at the heart of internal economies, and the later section “The Internal Economy” discusses them further.
Symbolic Relationships
The values of symbolic entities—red, on, empty, found, and the like—cannot be added together or otherwise manipulated mathematically. You must specify all the states that a symbolic entity may represent, and the relationships among them, without equations. For instance, the red, yellow, and green states of a traffic light are not related to each other numerically; they’re simply different. To use a traffic light, you must document how it gets into each of its possible states and how the light in each of those states affects the behavior of other entities. To define the behavior of an NPC driver who sees a traffic light, you would write three separate mechanics into his AI, one for each state of the light, to say how the driver reacts to seeing a red light, a yellow light, or a green light. When any entity in the game (such as a driver) interacts with a symbolic entity (such as a traffic light), you must state exactly what happens for each possible symbolic state of the entity. If you leave one state out, no interaction will occur with that state. Tip The values of numeric entities may change according to arithmetic processes, but you must create mechanics that explicitly change symbolic entities from state to state.
A binary (two-state) entity is sometimes called a flag. You will often create flags in your game to document whether the avatar has entered locations, overcome specific obstacles, and so on. This chapter doesn’t discuss symbolic relationships much further because they are relatively easy to define and their results are easier to predict; numeric relationships are harder to create and tune. Although it is possible to create extremely complicated symbolic relationships (think about Rubik’s Cube), most of the symbolic relationships in games tend to be rather simple.
10 of 11
10/06/2012 10:54 PM
http://my.safaribooksonline.com/print?xmlid=9780321685377...
Integrating Symbolic and Numeric Relationships
Although you cannot perform arithmetic operations on symbolic values, you can define how symbolic entities change from state to state in terms of other numeric data. If the symbolic entity fuel warning can take the values on and off, you can define a mechanic for each of the states based on the quantity of fuel available: “When the amount of fuel goes below 2 gallons, the fuel warning value switches to on. When the amount of fuel rises to 2 gallons or more, the fuel warning value switches to off.” A symbolic entity can contribute to a mathematical function if you have a mechanic that associates a symbolic entity into number. For example, the state of a car’s transmission is symbolic; the transmission is either in one gear or another, and you can’t add gears together. But you can make a table that shows the gear ratio of each gear, and use the results to make computations about the speed of the driveshafts. For example you can specify, “In first gear, the ratio is 3.83 to 1. In second gear, the ratio is 2.01 to 1. In third gear, the ratio is 1.46 to 1. In reverse gear, the ratio is 4 to -1. The negative value causes the driveshaft to turn backwards.” This mechanic converts a symbolic entity (transmission state) into a numeric entity (gear ratio).
11 of 11
10/06/2012 10:54 PM
