Fundamentals Game Design Ch10 Internal Economies

Transcript

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. The Internal Economy An economy is a system in which resources and entities are produced, consumed, and exchanged in quantifiable amounts. Most games have an internal economy, though the complexity and importance of the internal economy varies considerably from genre to genre. Chapter 18, “Construction and Management Simulations,” provides more discussion of internal economies. A game designer spends part of her time designing and tuning her game’s economy, and the more complex the economy, the more time she needs to spend. This section introduces aspects of an internal economy, which it explains by reference to both a simple action game (a shooter) and a complex game (a construction and management simulation). Mechanics Outside the Internal Economy The internal economy of a game includes those resources and mechanics that the player knows about and tries to manipulate. These include data that may be displayed by the user interface or that form part of the victory and loss conditions. Designers generally do not consider those mechanics over which the player does not exert control to be part of the internal economy. The mechanics that define the AI of nonplayer characters, for example, make up part of the core mechanics but not part of the internal economy of the game. A mechanic governing avatar and vehicle movement may or may not be considered part of the internal economy, depending on whether movement produces or consumes any resource. A serious car racing simulation treats fuel as a resource that the engine converts to kinetic energy (another resource) as the engine drives the car forward. The brakes consume kinetic energy, slowing the car down, and this wears out the brakes. Only the most realistic racing games bother to simulate fuel consumption, kinetic energy, or brake wear, and in those games, such factors can legitimately be considered part of the internal economy. Less sophisticated vehicle simulations make the vehicle stop 1 of 10 10/06/2012 10:55 PM http://my.safaribooksonline.com/print?xmlid=9780321685377... and go at the player’s command without incorporating any concept of resource production or consumption. Similarly, in most games featuring a humanoid avatar, the avatar can walk, climb, jump, and fight indefinitely without ever needing food; these processes do not consume anything. For the most part, then, the mechanics of movement don’t form part of a game’s internal economy unless the physics simulation is sophisticated enough to justify its inclusion. Sources If a resource or entity can come into the game world having not been there before, the mechanic by which it arrives is called a source. In a simple shooter, the game begins with some resources, such as enemies, already in the game world, but more enemies may appear at spawn points. A spawn point is a designated location where the core mechanics insert new resources into the game world and therefore into the economy. Enemies are part of the economy, a resource that is produced at spawn points and consumed by conflict with the avatar. Each spawn point is governed by a mechanic that specifies its location, what kind of resource it generates (spawn points in shooters can also produce weapons, ammunition, or health packs), and at what frequency. Sources often produce resources automatically (or at least produce resources automatically once the player starts them going, for example, by building a factory). You will need to define a production rate, either fixed or variable, and different sources may produce the same resource at different rates. In The Settlers games, rivers produce fish at a constant rate. A mechanic also defines the maximum number of fish that may be in a river at any one time, so the river stops producing fish when it gets full. Sources can be global mechanics: A mechanism that pays the player interest at regular intervals on the money he owns would be one example. An interestpayment mechanism applies throughout the game regardless of anything else, so it is global. Sources can also make up part of the mechanics governing the behavior of entities. In The Settlers, a stream that produces fish is an entity, one of whose attributes is the number of fish it contains. Sources can be limited or unlimited. In Monopoly, the “Go” square constitutes an unlimited source—according to the rules, it can never run out of money. (If the bank runs low, the banker may make more money by writing on paper.) But the collection of houses and hotels stored in the bank is a limited source: Once the banker sells all the houses and hotels, no more may come into the game. The 2 of 10 10/06/2012 10:55 PM http://my.safaribooksonline.com/print?xmlid=9780321685377... stream in The Settlers is an unlimited source of fish. Although it can be temporarily empty if too many fishermen are catching fish from it, it goes on producing fish until it is full, as long as the game is running. Drains A drain is a mechanic that determines the consumption of resources—that is, a rule specifying how resources permanently drop out of the game (not to be confused with a converter, which we’ll look at next). In a shooter game, the player firing his weapon drains ammunition—that’s what makes ammunition, a resource, disappear. Being hit by an enemy shot drains health points. Enemies drain out of the game by dying when their health points reach zero. The most common drain in a construction and management simulation is decay—ongoing damage to the objects the player constructed, which he must spend resources to reverse or repair. (Decay is also sometimes called entropy, although technically entropy refers to increasing disorder rather than loss of resources.) Typical decay mechanics look something like this: “Each section of road includes a numeric attribute indicating its level of decay as a percentage, with 0 (zero) indicating that the section is new and 100 indicating that the section is fully decayed and impassable. Sections of roads begin to decay 3 months after they are constructed, and 3 percent is added to their level of decay every year, plus an additional 1 percent for every 100,000 car trips over the section in the course of that year. When decay reaches or exceeds 100 percent, the road section becomes impassable and it must be replaced.” Because resources are valuable, the player wants to know why a resource disappears from the world and what benefit compensates for its loss. In Monopoly, players get money from the bank by passing “Go”—in effect, for no reason at all—but whenever a player has to give money back to the bank, the game provides a reason: The player owes income tax, incurs a fine, or something similar. Players don’t mind getting money for free, but when they have to spend it, they want to know why. Explain your drains. Converters A converter is a mechanic—and usually an entity, too—that turns one or more resources into another type of resource. In designing a converter, you must specify its production rate and the input-to-output ratio that governs the relationship of resources consumed to resources produced. The Settlers offers several examples. The windmill converts grain into flour at a rate of one to one, so one bag of grain produces one bag of flour. It takes 20 real-time seconds to turn one bag of grain into one bag of flour, so the rate of production of flour works out to three bags per minute. The iron smelter turns one load of ore into one iron bar, consuming one load of coal in the process. However, if fed charcoal instead of 3 of 10 10/06/2012 10:55 PM http://my.safaribooksonline.com/print?xmlid=9780321685377... coal, the smelter requires three loads of charcoal for each iron bar because charcoal is less efficient than coal. Traders A trader mechanic governs trades of goods, generally between the player and the game. In a stock-trading game, the trader may be a faceless financial construct; in a role-playing game, the trader usually comes in the form of a blacksmith who trades in swords or something similar. Note A trader is different from a converter. A trader changes the ownership of things, but does not change the things themselves. A converter turns something into something else, consuming the first item and producing the second one. Traders cause no change in the game world other than reassignment of ownership. If you trade your old dirk and a gold coin for a new short sword, then in theory the game still contains that dirk, that coin, and that short sword, although all three articles have been assigned to new owners. The trader can, if your game permits it, sell the old dirk to the next player who comes along. The Problem of Runaway Profits A player must never be able to repeatedly buy an item from a trader at a low price and sell it back at a higher price unless you set limits on the process. If players can buy from and sell to traders indefinitely and rapidly and they can sell something for more than they paid for it, they will exploit this ruthlessly, piling up huge fortunes by endlessly buying and reselling and ignoring the rest of the game. You can use various schemes to prevent this. You can make it impossible to make a profit by requiring all subsequent sales to be for less than the original purchase price. If you want players to be able to make a reasonable profit, place limits on the amount of buying and selling they can do: Require that they wait a while before selling an item back again, or have the trader refuse to sell items to them more than a certain number of times or refuse to buy goods back. The trader itself 4 of 10 10/06/2012 10:55 PM http://my.safaribooksonline.com/print?xmlid=9780321685377... can have limited funds and be unable to buy if funds run out. In a multiplayer game, you can let players buy and sell at a profit to one another but not to an automated or NPC trader. Transactions among the players don’t change the total amount of money in the game; but selling things back to an automated trader mechanic that has an unlimited supply of money has the potential for abuse. You can also build a bargaining feature into the mechanics of a trader, such that it sells at a high price but can, via a user interface mechanism designed for the purpose, lower its price after a little haggling. Your scheme might make some traders more flexible than others, thereby encouraging players to shop around for the best deal. Production Mechanisms Production mechanism describes a class of mechanics that make a resource conveniently available to a player. These include sources that bring the resource directly into the player’s hands, but they can also include special buildings, characters, or other facilities that gather resources from the landscape and make them available to the player. Many real-time strategy games employ special characters to perform this function. For instance, in the Command & Conquer series, a harvester vehicle collects a resource called tiberium and carries it to a refinery where it is converted into money that the player can use to buy weapons. The harvester is a production mechanism; the refinery is a converter. Tangible and Intangible Resources If a resource possesses physical properties within the game world, such as requiring storage space or transportation, the resource is said to be tangible. On the other hand, if it occupies no physical space and does not have to be transported, it is intangible. In a shooter game, ammunition is tangible—it exists in physical form in the environment, and the avatar has to carry it around. Most construction and management simulations treat money as intangible: It exists as a meaningful resource in the game world but takes up no space and has no particular location. A number of games treat resources in a mixed fashion, sometimes tangible and sometimes intangible. In Age of Empires, food and building materials have to be transported from their production points to a storage facility; during transport, these items can be stolen or destroyed by an enemy. Once stored, however, materials become intangible: They cannot be seized or destroyed even if the 5 of 10 10/06/2012 10:55 PM http://my.safaribooksonline.com/print?xmlid=9780321685377... enemy demolishes the storage facility. Similarly, most construction and management simulations and real-time strategy games don’t require a resource to be physically transported before it can be spent or consumed; the commodity simply vanishes. When constructing a building in Age of Empires, the player doesn’t transport the stone from the storage pit to the construction site. This takes an extra management burden off the player. The section “Logistics” in Chapter 14, “Strategy Games,” discusses the gameplay implications of intangible resources at greater length. Feedback Loops, Mutual Dependencies, and Deadlocks A production mechanism that requires some of the resource that the mechanism itself produces constitutes a feedback loop in the production process. Note that this use of the term feedback is not related to the feedback elements discussed in Chapter 8, “User Interfaces.” In the context of a user interface, feedback refers to a means of giving the player information about the effects of his actions upon the game world. In the context of an internal economy, feedback refers to resources that are fed back into a production mechanism. So long as the mechanism has a supply of the resource to start with and the mechanism produces more than it requires, there’s nothing wrong with using a feedback loop. But if for any reason the system runs out of the resource, the mechanism won’t be able to produce any more. This condition, called a deadlock, locks up that part of the economy unless you provide some other supply of the resource—a way to break the deadlock. The Settlers III contains a feedback loop. The player needs stone to build a stonecutter’s hut in order to house a stonecutter who produces more stone (see Figure 10.3). Ordinarily, the game starts with some stone already in storage, so if the player builds a stonecutter’s hut right away, the stonecutter produces the stone needed for other activities. However, if the player uses up all her stored stone constructing other buildings, she might not have enough to build a stonecutter’s hut, and she will be in a deadlock—hut building can’t proceed without stones; stones can’t be produced without a hut. The Settlers III provides a way to break the deadlock: The player can demolish another building and get back enough raw stone to build a stonecutter’s hut after all. Note that the stonecutter’s hut doesn’t actually need stone to operate, but the player does need stone to build it in the first place. As long as the player builds and retains one stonecutter’s hut, she shouldn’t get into a deadlock. Figure 10.3. The feedback loop in The Settlers III 6 of 10 10/06/2012 10:55 PM http://my.safaribooksonline.com/print?xmlid=9780321685377... Two production mechanisms that each require the other’s output as their input in order to work are mutually dependent. Again, there’s a loop in the process. If the resources produced by either one are diverted elsewhere and production stops for lack of input, this, too, can produce a deadlock. In designing your game’s internal economy, you need to watch out for deadlocks, which can occur whenever there’s a loop in the production process. To avoid deadlocks, either avoid such loops or provide an alternative source for one of the resources. This is the point of collecting $200 when you pass “Go” in Monopoly. A player who owns no properties can’t earn money by collecting rent, but without rent, the player can’t buy properties: a deadlock. Monopoly solves this by giving the players money to start with and by giving them $200 every time they pass “Go.” As the game progresses, that $200 becomes less significant, but it is enough to break a deadlock. Design Rule: Provide Means to Break Deadlocks If your internal economy contains either feedback loops or mutual dependencies, be sure you include a means to break a deadlock if one occurs 7 of 10 10/06/2012 10:55 PM http://my.safaribooksonline.com/print?xmlid=9780321685377... Note The terms static and dynamic equilibrium are borrowed from economics, not from physics. In physics, static equilibrium means that all forces on an object are equally balanced, so the object does not move. In economics, static equilibrium means that supply and demand for goods are balanced, and although the goods themselves move, the amounts do not change. Static and Dynamic Equilibrium It’s possible to design a system in such a way that, left alone, it enters a state of equilibrium. Static equilibrium is a state in which the amounts of resources produced and consumed remain constantly the same: Resources flow steadily around without any significant change anywhere. Dynamic equilibrium occurs when the system fluctuates through a cycle. It’s constantly changing, but it eventually returns to a starting point and begins again. Here’s an example of static equilibrium. Suppose you have a miller grinding wheat to make flour and a baker baking bread from the flour. If the bakery consumes the flour at exactly the same rate at which the mill produces it, then the amount of flour in the world at any one time will remain static. If you then upset the system by stopping the bakery for a while, the flour will build up. When the bakery restarts, the amount of flour available will be static at the new level. The system returns to static equilibrium because the key factors—the production and consumption rates of the mill and the bakery—have not changed (see Figure 10.4). Figure 10.4. An example of static equilibrium 8 of 10 10/06/2012 10:55 PM http://my.safaribooksonline.com/print?xmlid=9780321685377... Now let’s suppose that only one person does both jobs. She mills enough to bake three loaves of bread; then she bakes the three loaves; then she mills again; and so on. This is an example of dynamic equilibrium: Conditions are changing all the time, but they always return to the same state after a while because the process is cyclic. If we tell the woman to stop baking and only mill for a while, and then resume baking later, again the flour builds up. When she resumes baking, the system settles into a new state of dynamic equilibrium (see Figure 10.5). Figure 10.5. A new state of dynamic equilibrium 9 of 10 10/06/2012 10:55 PM http://my.safaribooksonline.com/print?xmlid=9780321685377... When a game such as a construction and management simulation settles into a static equilibrium, players can easily judge the effect of their actions on the system by making one small change and watching the results. This makes the game easy to learn and play. Dynamic equilibrium is more difficult for players to handle. With the system in constant flux, it’s hard to tell whether the changes players see result from a natural process or from something they’ve done. Settling into a state of equilibrium, static or dynamic, takes the pressure off the player. She can simply watch the game run for a while and make adjustments when she feels like it. Some construction and management simulations do work that way, but most give the player more of a challenge. Rather than settling into equilibrium, the designers build in a factor that requires the player to take action to prevent the system from running out of some needed resource. To use our milling–baking metaphor, perhaps the player has to take action to keep the mill supplied with wheat. If the player doesn’t keep an eye on the wheat supply, both milling and baking come to a halt. In Age of Empires, farms produce food automatically, but after a while they stop working and the player must intervene to rebuild them. In SimCity, the roads wear out and the player has to repair them. Whether your system settles into equilibrium or runs down without player action, one thing is certain: The player should always have to do something to obtain growth—he should have to press on the gas pedal of your game, as it were. If the system can grow constructively and profitably of its own accord, there’s no reason for the player to interfere. This is the player’s primary challenge: figuring out how to produce growth using the many (metaphorical) levers and knobs that you provide via the core mechanics. In effect, the player is himself an element of the economy, and growth depends on his active participation. 10 of 10 10/06/2012 10:55 PM