The Common Elements of CMSs

Most CMSs give the player the chance to build and manage some entity ”a city, a building, an anthill, or whatever ”using two general sets of tools: one for building and one for managing. Building is easy, but managing is tricky indeed; we discuss that aspect of the simulation first.

Rules

The rules of a CMS define its internal economy and the ways in which the player can influence that economy. Creating and balancing an economy is one of the most complex and difficult jobs a game designer can do, and you can be sure that no matter how carefully you have worked it out, there will be consequences and relationships that you never considered . This is sometimes called emergent behavior , and whether it's desirable or not is up to you. Only playtesting and tuning will get the game right in the end.

Resources

An economy is a system in which resources are produced, consumed, and exchanged. In many CMSs, the primary resource is money. The characteristics of the resources affect the way a game is played . For example, resources can be tangible , requiring storage space that must be constructed and paid for, or intangible, occupying no physical space and costing nothing to move from place to place. Money is usually treated as an intangible resource, but food and building materials are generally treated as tangible entities. There are occasional exceptions: Dungeon Keeper (another hybrid game) treated gold as a tangible resource that had to be mined and transported back to a treasury, and the player had to expand the treasury when it got full.

A number of games treat resources in a mixed fashion, sometimes tangible and sometimes intangible. Both Dungeon Keeper and Age of Empires required that resources be transported from their production points to a storage facility; during this period, the resource was vulnerable to destruction or seizure by an enemy. However, in Age of Empires , when a resource was stored, it could not be seized or destroyed even if the enemy demolished the storage pit. In effect, resources became intangible when they were stored.

Similarly, most CMSs don't require a resource to be physically transported to be spent or consumed; the commodity simply vanishes from its warehouse. When constructing a building in Age of Empires , the player doesn't need to transport the stone from the storage pit to the construction site. This takes an extra management burden off the player.

One game that treats all resources as tangible, including money, is The Settlers from Blue Byte Software. In The Settlers , every kind of resource (and there are many) must be transported from where it is produced, either to storage areas or directly to places where it is consumed. Grain, for example, must be carried from the grain farm to the windmill for grinding, the flour must be carried from the windmill to the bakery, and the bread must be carried from the bakery to the mines, where the miners eat it.

Sources

Every resource, intangible or tangible, must have one or more sources ”that is, ways in which they come into the game. In Monopoly , for example, money comes into the game from the bank. All the players start with a certain amount of money, and they get more each time they pass Go. They can also mortgage their properties for money, and they might get more money from the bank through the actions of the Chance and Community Chest cards.

Unlike Monopoly , which is turn -based, CMSs usually have a production rate for each resource. This production rate can be fixed or variable, and rates can be different at different sources ”that is, some sources might produce the resource faster than others.

Finally, regardless of production rate, sources can be limited or unlimited . A particular source might contain a limited amount of a resource and might cease production when it is depleted. If the entire game contains only a limited amount (that is, all possible sources contain limited amounts), the game can be said to be closed-ended. The game must eventually end or fail when the essential resource is gone. On the other hand, if the amount of the resource is unlimited, the game is open -ended ”it can continue indefinitely. Dungeon Keeper again provides examples of both. Gold mines in Dungeon Keeper produced only a certain amount of gold. Because various activities consumed gold, eventually the dungeon must run out of money. Some dungeons, however, contained gem mines as well as gold mines (a misnomer because what they actually produced was also gold). The difference was that a gem mine could never be exhausted. It continued to produce gold indefinitely.

Drains

A drain is an activity that consumes resources. The two most common drains in CMSs are construction , building or buying new things to serve some purpose, and maintenance , ongoing spending required to prevent loss or decay. Construction happens only when the player wants it. Maintenance can be player-controlled, but it is often an automatic function that occurs whether the player wants it to or not.

Because resources are valuable , the player wants to know why a resource is disappearing from the world and what she is "getting" to compensate 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, a reason is given: The player has been fined, has to pay certain expenses, and so on.

Maintenance seems like a sort of meaningless cost. It bothers some players, who would rather buy something once and never have to worry about it again. If you characterize it as a "rental" rather than a purchase, it makes more sense to them. Paying employees is a good example of a maintenance cost. You can't own employees ; you can only pay their wages on an ongoing basis.

Converters

A converter is a location or activity that turns one or more resources into another. In effect, it drains one resource while serving as the source for another at the same time. The Settlers is full of converters (see Figure 14.1). The bakery, for example, turns flour and water into bread. The iron smelter takes iron ore and coal (or charcoal) and produces iron bars. In designing a converter, you must specify the input-to-output ratio between resources consumed and resources produced, as well as its production rate. For example, the windmill in The Settlers converts grain into flour at a rate of one to one: One bag of grain produces one bag of flour; none is wasted . This takes 15 or 20 seconds to do. The iron smelter turns one load of ore into one iron bar, consuming one load of coal in the process. However, if it is using charcoal instead of coal, it requires three loads of charcoal for each iron bar because charcoal is less efficient than coal. (That's the given reason, anyway; the real game-design reason is that charcoal is an unlimited resource because it comes from wood, which is renewable, whereas coal has to be mined and eventually runs out. To discourage players from simply using charcoal for everything, the designers made it a less efficient mechanism.)

Figure 14.1. The Settlers III . The iron smelter is in the center. The coal and iron ore mines are immediately below.

Deadlocks

A deadlock is a condition that occurs when you need a resource to construct a production mechanism to produce more of the same resource, or when two processes are each waiting for the other to complete. The chicken-and-egg problem is a classic deadlock. To use an example from a real game, in The Settlers , a player must have stone to build a stonecutter's hut, which then produces more stone. Ordinarily, the game starts with some stone already in storage, so if the player builds a stonecutter's hut right away, it will produce 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. Fortunately, The Settlers gives players a way to break the deadlock: They can demolish another building and get back enough stone to build a stonecutter's hut after all.

In designing a CMS, 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, even if its value is minimal. This is the point of collecting $200 when you pass Go in Monopoly . If you have no properties, you can't earn money by collecting rent, but if you can't collect rent, you can't buy properties. 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.

Static and Dynamic Equilibrium

It's possible to design a system in such a way that, left alone, it returns to a state of equilibrium. Static equilibrium is a state in which everything remains constantly the same: Resources are flowing 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 we then perturb 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 equilibrium because the key factors ”the production and consumption rates of the mill and the bakery ”are the same (see Figure 14.2).

Figure 14.2. An example of static equilibrium.

Now let's suppose that there's only one person who has to do both jobs herself. She mills for a while, then she bakes for a while, then she mills again, and so on. This is an example of dynamic equilibrium: Things 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 again later, again the flour builds up. When she resumes baking, the system settles into a new state of dynamic equilibrium (see Figure 14.3).

Figure 14.3. A new state of dynamic equilibrium.

When a CMS 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 what they're seeing is the result of a natural process or something they've done. We have a similar problem making ecological decisions about our planet. For many years , people believed that the environment should be in a state of static equilibrium: that there should always be exactly enough plants for the herbivores and exactly enough herbivores for the carnivores, and any deviation from this was caused by environmental mismanagement. More recently, we've come to realize that there are natural fluctuations in the sizes of animal populations and that big changes are not necessarily the result of human actions; they can occur in the ordinary course of events. This makes environmental management all the more difficult.

If your system does settle into a state of equilibrium, static or dynamic, it takes the pressure off the player to do anything. She can simply watch it go for a while and make adjustments when she feels like it. Some CMSs do work that way, but most give the player more of a challenge. Rather than settling into equilibrium, there is an imbalance somewhere. Entropy in the system causes it to "run down" unless the player takes action to keep it going. To use our milling/baking metaphor, perhaps the player has to personally 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.

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 of its own accord, there's no reason for the player to interfere. This is the player's essential challenge: figuring out how to produce growth using the many levers and knobs that you have given him. In effect, the player is himself an element of the simulation, and growth should be dependent on his active participation.

Disasters

Random disasters are another way to force the player to act. Sim City tends to settle into a very slow decline if left alone, chiefly because the roads become worn out. To put more pressure on the player, fires, tornadoes and monster invasions crop up periodically, doing considerable damage. If the player does not take action to repair the damage, the city eventually dwindles down to nothing as a result of repeated disasters.

Case Study: Sim City

Although it isn't the oldest CMS, the spiritual father of them all is Sim City , published by Maxis (now a part of Electronic Arts). Sim City was originally designed for the Commodore 64, although it was most successful on the IBM PC, and the first version of the game is now playable for free on the Web. (Visit http://simcity.ea.com/play/simcity_classic.php if you're interested.) It was followed by a host of other games in the same mold: SimAnt , SimTower , SimFarm , and so on, which met with varying success.

The object of Sim City is to build a city and attract people (called sims ) to live and work there. The basic economic unit is money, which the player can spend in various ways to improve the city. The player's primary job is to zone tracts of land into one of three types: residential, commercial, or industrial. As people move into the city, these areas begin to be occupied and to produce tax revenue, thereby replenishing the city's coffers. This produces a straightforward positive feedback loop: Zoning costs money, but occupied zones produce more money, thereby enabling the player to do more zoning.

The positive feedback is kept in check by other demands on the city's purse. Sims will not move into any zoned region; it has to have other benefits as well. Every zoned region requires electricity, and the player has to buy power plants and electrical lines to provide it. The sims also need a way to travel from the residential to the industrial zones to work and to the commercial zones to shop. This requires a road and a rail network, which also cost money. If the roads are inadequate to meet the traffic, or if the sims have to travel too far to work, they will begin to move out of the city, with a resulting loss of tax revenue. Finally, when the city reaches certain population thresholds, the sims begin to demand expensive amenities: a sports stadium, an airport, and so on. Again, if these are not provided, the sims begin to leave.

In addition to the electricity, roads, and civic amenities, there are other cost centers. Fires break out from time to time; if left unchecked, they destroy the buildings and leave the land unzoned. To combat this, the player has to build and maintain fire stations. Industrial areas are a source of crime, which depresses property values and reduces tax revenues . Crime can be suppressed by building police stations , at yet more cost. Industrial areas and roads also cause air pollution, which further depresses the value of nearby residential property. There is no way to reduce air pollution; you simply have to keep industrial and residential areas separate.

The vital calculations in the game are the ones that determine whether people move into the city or move out, and how valuable a given zone is. The more valuable a zone is, the higher its population density becomes and the more tax revenues it produces. The player can build parks and situate residential zones near woods and rivers to increase their attractiveness.

Although Sim City is now an old game, it serves as an excellent model to study (see Figure 14.4). Because it was designed for low-performance machines, it couldn't be too complex, and its internal economy is reasonably easy to understand.

Figure 14.4. The original Sim City , showing industrial, commercial, and residential zones.

Setting

It's easy enough to say that CMSs are about a process, but the process has to be meaningfully displayed on a computer screen, and it must fire the player's imagination . Most CMSs take place in the context of a physical space, usually a two-dimensional world in which buildings or other objects can be constructed. Caesar is about building an ancient Roman town, so the setting is a landscape near a river . Civilization is about exploring a world while at the same time advancing a civilization both culturally and technologically, so its setting is an entire continent , or several of them.

A few pure business simulations don't take place in a physical setting, and they're discussed at the end of the chapter.

Gameplay

The challenges in a CMS are largely economic. The player must understand how the internal economy of the game works and how to manipulate it to produce economic growth. Growth provides the resources required for the construction that is usually the overall goal of the game.

Indirect Control

A war game is a game of direct control. The players tell their troops exactly where to go and what to do, and they do it. The simulated soldiers have little or no autonomous behavior or artificial intelligence. If told to stand and wait someplace, they'll wait there forever.

The majority of CMSs, on the other hand, are games of indirect control. The game simulates a process, and the player can alter that process only in limited ways. The process must be manipulated indirectly, and the player has to learn how the controls affect its inner workings. If there are simulated individuals in the game (see the "Simulating Individuals" section later in this chapter), for the most part, they can be controlled only indirectly. They have a behavior model that governs what they do, and it responds to stimuli, but they can't be given direct orders.

However, the dividing line between direct and indirect control is a fuzzy one. Certain player activities, such as choosing the location of new construction, will be direct. Others, such as trying to boost sales by reducing prices, will be indirect. Reducing prices is direct, but the (hoped for) consequent rise in sales is indirect.

Construction

Construction itself isn't the challenge in a CMS; the challenge is in obtaining the resources needed for the construction. Construction is the part of the game that lets the player exercise her imagination and create something unique and personal. Accordingly, you, as the designer, need to find a way to make this easy and enjoyable.

Construction mechanisms in CMSs tend to be one of two types: buy or design-and-build. When the player buys an object (a segment of wall, say), the resources to build it are deducted from stockpiles, and the object immediately appears in a designated location. This lets her build rapidly , adding pieces like using Lego bricks . You should use this mechanism if construction is the primary activity in your game. If so, it needs to be easy and continuous, not something the player has to wait for. This is how Sim City worked: Zoning property and constructing civic amenities such as police stations and airports happened instantly because it was the primary activity in the game.

The design-and-build mechanism is more often seen in games in which the player does a little construction, then some management, then more construction, and so on. In design-and-build, the player marks out an area where new construction will appear. The game often displays the new building in a ghostly, semitransparent form to indicate that it is under construction. However, it takes time to build. If the game includes simulated people, you might be able to see them at work on it; if those people go away or die for some reason, the building might be left in a partially completed state.

In design-and-build, you don't have to remove all the required resources from storage at once because the construction takes place over time. In The Settlers, wood and stone had to be physically transported a little at a time from stockpiles to the construction site. This puts an extra burden on the player to manage his resource flow, but it does give him more control. In contrast, Age of Empires deducted the resources necessary for construction immediately when it was designed. They drained out of the game rather than being transported to the site. Although this was unrealistic , it meant that the player could build something only after he definitely had enough resources for it, and he didn't have to worry about moving things around all the time.

Dungeon Keeper was particularly interesting because construction was actually excavation: It took place underground , and the player couldn't see the area he was excavating into. Excavations often led into immovable rock or to existing caves, underground rivers, or pools of lava. It was also irreversible: When an area had been excavated, there was no way to close it up again. This encouraged players to be cautious. Suddenly excavating into an area full of enemy creatures was a major hazard of the game.

Demolition

In addition to letting your players construct things, you might need to give them a way to demolish things. A big part of the fun of a CMS is building your city, theme park, or whatever the way you want to build it. If a construction decision is irreversible, it means whatever the player is building can get only bigger, never smaller, and the player cannot change his mind or react to new circumstances. This might be okay for strategy games (many war games, for example, allow you to build factories and defenses but not demolish them), but in CMSs, it prevents the player from exercising his full creative freedom; hence, the need for a demolition feature.

You should consider whether you want demolition to cost something, cost nothing, or actually earn money. If it costs money to demolish something, you are, in effect, penalizing the player for changing his mind and perhaps encouraging him to plan more carefully in the future. He has lost not only his initial construction cost for the item, but the demolition costs as well. If it costs nothing, the player has lost only his construction costs. If he actually gets something back, it's usually called "selling" the item rather than demolishing it, and it further reduces the price the player pays for changing his mind. If he can sell it back for exactly as much as he paid, there is no net cost at all for building a thing and destroying it later. This is rare in CMSs because it removes some of the challenge. Players can build madly, secure in the knowledge that they can always get their money back by selling.

A player must never be able to sell an item back to the computer for more than he paid for it, unless he has expended further resources to upgrade it somehow. If the players can buy from and sell to the computer at will, and there exists any mechanism by which 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. There are various ways to prevent this. One is to make sure that it is simply impossible to make a profit; all sales must be for less than the original purchase price. If you want players to be able to make a limited profit, you have to place limits on the amount of buying and selling they can do. The computer can refuse to sell items to them after a while or can refuse to buy them back. The computer itself can have a limited amount of money and be unable to buy if it has run out. And in a multi-player game, you can let players buy and sell at a profit to one another, but not to the computer itself. Transactions among the players don't change the total amount of money in the game; it's selling things back to the computer that have the potential for abuse.

Victory Conditions

A good many CMSs have no victory condition; the player simply builds whatever she likes as effectively as she can within the constraints of the system. These games might well have a loss condition, however: total depletion of resources (or, in monetary terms, bankruptcy). This is the loss condition in Monopoly, for example. Victory in Monopoly consists simply of bankrupting all the other players.

If you do want to define a victory condition, it's best to do it in the context of a scenario of some kind. Give the player a partially constructed city (or whatever) and a set of initial conditions, and then define the victory condition as achieving some other condition. It could be as simple as, "To win, your enterprise must be worth $5 billion," but it can be as complex as you like. You can also start the player in rapidly deteriorating conditions and challenge her to turn them around or simply to survive for a certain length of time.

Competition Modes

CMSs are almost always single-player games. It's possible to make them two-player or even multi-player, but it's not a natural way to play. CMSs encourage planning and thought, not frantic action. If the players are competing for the same resources, it becomes a race to see who can grab the most, ignoring the other aspects of the game. If the players are separate and have symmetric starting and victory conditions, the game tends to be about optimizing efficiency. If the conditions are asymmetric, the game will be difficult to balance.

CMSs let the player be playful, to build and experiment in the world you've given him. That's seldom consistent with competition. One major exception is in hybrid games, those that have a military element as well as construction and management elements. They're discussed in the "Hybrid Games" section later in this chapter.

The Player's Role

When designing any game, the first question you have to ask yourself is, what is the player going to do? The answer to this question usually arises out of a clear statement of the player's role in the game: pilot, general, adventurer, irradiated hedgehog , and so on. In a CMS, however, it's less easy to define the player's role because it seldom corresponds to an actual job in real life. The mayor of a city doesn't really lay out its streets or make zoning decisions personally.

This is one of the few genres in which we don't think you have to define the player's role in familiar terms. You still have to concern yourself with what the player is going to do, of course, but it doesn't matter that much what you call him.

Interaction Model

The player is almost always omniscient in a CMS because she needs to see what is happening all over the game world. It's difficult to control a global process from a local perspective. Most CMSs don't give the player any kind of avatar. Those that do usually make it temporary. If the player is building a city or a space station or some other structure, she could well want to see what it would look like from the perspective of someone inside it. For example, in Dungeon Keeper , it is possible for the player to "possess" a creature in her dungeon: to take control of that creature and walk around the dungeon in the first-person perspective (see Figure 14.5), seeing through its eyes. However, this feature is mostly cosmetic. It is occasionally useful in the military aspects of the game, but not at all in the management aspects. In short, we think the "down inside" view is a fun one and the player will enjoy it, but the primary interaction model in a CMS needs to be omnipresent.

Figure 14.5. Dungeon Keeper 2 , omnipresent view (top) and inside view (bottom).

User Interface

Because CMSs aren't trying to create an illusion of reality in the way that first-person shooters or flight simulators are, their user interfaces can be more "computerlike," using pull-down menus and rows of buttons along the edges of the screen. In a CMS, the emphasis is more on convenience than verisimilitude.

Perspective

The user's perspective in a CMS naturally depends on what's being simulated. Most CMSs simulate a process taking place over a land area ”whether it's a city, a farm, or an entire planet. As a result, they tend to use an isometric perspective and enable you to view the world from one of four angles. The isometric perspective requires little CPU time, an advantage even in these days of 3D hardware accelerators, because CMSs do a lot more computation behind the scenes than other kinds of games. Its disadvantage , at least from a development standpoint, is that your art team will have to draw sprites of everything in the game from four different perspectives ”and still more if you offer multiple zoom levels. It also doesn't let the player zoom in to any degree he likes. CMSs are sometimes frustrating in that the closest -in zoom level is a little too close, and the next one out is a little too far out.

If your game simulates a process taking place in a three-dimensional space, you might find it useful to divide the space into layers (either physical or conceptual) to make it easier for the player to navigate around and view. It's also helpful to provide a button that returns the camera instantly to a default perspective so that the player can reorient himself if he gets lost.

Analysis Tools

In a CMS, the player is trying to understand and control a mathematical model. To do this, she needs convenient access to key variables within the model. You should display the most important scalar (single-value) variables ”for example, the amount of money she has to work with at the moment ”on the screen at all times. The display can be in digits, if that's most appropriate, or a bar graph or some other kind of monitoring device, depending on the nature of the simulation.

Often the player needs to know not only the current value of a variable, but also how that variable has changed over time. This lets her track trends and respond to them before trouble occurs. In Theme Park , a business simulation about building and managing (surprise!) theme parks, visitors came in, spent a while in the park, and left again. The player could see them wandering around, but it was difficult to get a sense of the park's popularity just by counting heads. One of the information pop-ups available was a graph that showed how the population had changed over the past 1, 3, or 12 game years.

With vector (multivalued) variables, you'll need a different approach. In Caesar , for example, every area of the Roman town that the player was trying to build needed a water supply of some sort. The amount of water available was therefore a vector; it had a separate value for each square on the grid. There were a variety of types of water supplies (wells, pipes, fountains, and so on), and each provided water to a given area around it. In the game's default perspective, showing all the buildings of the town, the player could see the structure supplying the water, but it was difficult for her to visualize exactly how far its coverage extended. To get a clearer picture, she could bring up a different view that hid most of the buildings and instead showed only the amount of water available in each area. The different values were indicated as squares in different shades of blue, from light blue, indicating very little water, to dark blue, indicating plenty. If an area had no water supply, there was no blue at all. The water supply buildings themselves were left visible on the map as landmarks .

These sorts of analysis tools are essential to give the player an understanding of what's going on inside the simulation. Sim City had several: fire danger, crime, pollution, and so on. They allow the player to quickly locate trouble spots and take remedial action. These kinds of map overlays should not be a snapshot at a moment in time, but should be continuously updated by the simulation. That way, the player can watch them for a while and tell whether particular situations are getting better or worse ”and, most important, whether her actions are having the desired effect.