Chapter 7. Design Patterns

In this chapter, we address the concept of design patterns and show how you can use the Machinations Tool to build a library of useful patterns. Because there have been many efforts to identify design patterns in the past, the first part of the chapter gives some of the history and theory of the subject. Next, we’ll show you how Machinations diagrams are effective tools to capture and represent these patterns. Finally, we’ll discuss how you can use these patterns to become a better game designer.

Introducing Design Patterns

In earlier chapters, you looked at diagrams representing many different games. You might have noticed that some diagrams look remarkably similar. For example, we used Figure 7.1 to illustrate a feedback loop in Monopoly, and Figure 7.2 shows a single player version of the Harvester game we described in Chapter 6, “Common Mechanisms.” If you ignore the Pass Go source and Pay Rent drain in Figure 7.1 and rotate the remaining nodes 90 degrees counter-clockwise, you will discover that although the details in the labels are different, both feedback loops are the same: A source feeds a pool at a particular production rate. Resources from the pool can be converted into a new type of resource that increases the production rate of the source.

Figure 7.1. Monopoly

Figure 7.2. The Harvester game

If you look closely at the other examples in Chapter 6, you might spot similar structures a few more times. Risk contains a similar feedback loop, too. This is not a coincidence, nor is it likely that the designers of Risk deliberately stole the mechanics of Monopoly. The similarity between the structures simply means that this particular pattern in game mechanics works for many games. There are many more patterns in game mechanics that are found across many different kinds of games.

We call recurrent patterns in the structure of game mechanics design patterns. The architect Christopher Alexander first introduced the idea of design patterns in his book A Pattern Language (1979). That work inspired others to create design patterns for software engineering, and they have become a popular tool in that field. Design patterns for games, as we describe them here, follow the same lines as those used in architecture and software engineering.

A Brief History of Design Patterns

Alexander and his colleagues originally identified design patterns in an attempt to capture objective standards of quality in architecture. They documented the patterns they found to help architects design good buildings. As Alexander himself put it, “There is a central quality which is the root criterion of life and spirit in a man, a town, a building, or a wilderness. This quality is objective and precise but it cannot be named” (Alexander 1979, p. ix).

Alexander describes an entire library of patterns for architecture, which he calls a pattern language. Each pattern represents a solution to a common design problem. These solutions are described as generically as possible so that they may be used in different circumstances. The patterns are all described in the same format. Each pattern also has connections to larger and smaller patterns within the language. Smaller patterns help to complete larger patterns. The works of Alexander describe more than 100 different patterns across a few different domains within architecture (from urban planning to individual buildings).

This idea was transferred to the domain of software design by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides (known to the software engineering community as the “Gang of Four”) in their seminal book Design Patterns: Elements of Reusable Object-Oriented Software (1995). Within software engineering, the principles of object-oriented programming take the place of Alexander’s unnamed quality. By identifying software design patterns, they created a common vocabulary for programmers to discuss object-oriented software features that they all knew about but had no names for. This made it easier for developers to work together but also to create better code. The Gang of Four also organized their pattern language into a set of interrelated patterns that describe generic solutions to common design problems. The original set contained about 20 patterns. Over the years, a number of patterns have been added, while a few have been removed. Today the set of core patterns for software design remains relatively small.

Design Vocabularies in Games

We are not the first to draw inspiration from Alexander and apply the idea of design patterns to game design. Many designers and researchers have noted that game designers have no generally accepted design vocabulary that efficiently allows them to share and discuss ideas. In a 1999 Gamasutra article “Formal Abstract Design Tools,” designer Doug Church set out to create a framework for a common vocabulary for game design. According to Church, “formal” indicates that the vocabulary needs to be precise, and “abstract” indicates the vocabulary must transcend the particular details of a single game. For Church the vocabulary should function as a set of tools, in which different tools are suited for different tasks, and not all tools are applicable for a given game.

As a starting point for his full set of formal abstract design tools, Church describes three of them in his article:

• Intention. Players should be able to make an implementable plan of their own creation in response to the current situation in the game world and their understanding of the gameplay options.

• Perceivable Consequence. Game worlds need to react clearly to player actions; the consequences of a player’s action should be clear.

• Story. Games might have a narrative thread, whether designer-driven or player-driven, that binds events together and drives the player toward completion of the game.

Between 1999 and 2002 the Gamasutra website hosted a forum where people could discuss and expand the framework. The term design tool was quickly replaced by design lexicon indicating that the formal abstract design tools seem to be more successful as an analytical tool than a design tool. Bernd Kreimeier reported that “at least 25 terms were submitted by almost as many contributors” (2003). As a project the formal abstract design tools have been abandoned; however, Church’s article is often credited as one of the earliest attempts to deal with the lack of a vocabulary for game design, even though his framework never caught on.

Design Patterns in Games

The attempts to set up a design pattern language, as opposed to a design vocabulary, have been fewer. Bernd Kreimeier suggested a design pattern framework in his Gamasutra article “The Case for Game Design Patterns” (2002), but he never actually built one. In their book Game Design Patterns (2005), Staffan Björk and Jussi Holopainen describe hundreds of patterns, and you can find many more patterns on the accompanying website. However, Björk and Holopainen choose the following definition as their starting point for their pattern language: “Game design patterns are semiformal interdependent descriptions of commonly reoccurring parts of the design of a game that concern gameplay” (p. 34). In other words, their approach is much more like a design vocabulary than it is like a pattern language. They do not formulate a clear theoretical vision on what quality in games is or where it might come from. Their book is a valuable collection of design knowledge, but it does not really tell you how to use that knowledge effectively to build better games.

Any effort to identify design patterns in games should begin with a clear theoretical vision on what makes a game objectively good—where its intrinsic quality comes from. Based on that vision, it should identify common problems and offer generic solutions to those problems, just as Alexander did for architecture. In that way, design patterns really become a useful tool for game design, not just game analysis. That is how we approach the game design patterns in this book.

Machinations Design Pattern Language

In the previous chapters, we discussed quality in games from the perspective of a game’s internal economy. Our discussion focused on how certain structural features of the game economy (such as feedback loops) create emergent gameplay. It should not come as a surprise that the relation between the structure of a game’s internal economy and its emergent gameplay is the focal point of the pattern language we present in this chapter. In addition, as Machinations diagrams proved to be very useful in describing the structure of a game’s internal economy, it makes sense to use Machinations diagrams to express these patterns.

Pattern Descriptions

In Appendix B you will find complete descriptions of all the design patterns used in this book. You will notice that these descriptions follow a strict format. If you are familiar with software design patterns, you might recognize the format; we took it from the descriptions used in Design Patterns by the Gang of Four.

Each description includes the following items:

• Name. Every pattern has a descriptive name. Sometimes a few alternative names are listed under Also Known As.

• Intent. This is a short statement that describes what the pattern does.

• Motivation. The motivation describes the use of the pattern more elaborately and suggests a few use-case scenarios.

• Applicability. The section describes in what situations the pattern is best used; it describes the problems the pattern might solve.

• Structure. This is a graphical representation of the pattern using Machinations diagrams.

• Participants. This describes and names the elements, mechanisms, and compound structures that are identifiable parts of the pattern. These names are used throughout the pattern’s description.

• Collaborations. Identifies the most important structural relationships between the pattern’s participants.

• Consequences. This section describes what you might expect if you apply this pattern to your design, including potential trade-offs and possible risks.

• Implementation. For most patterns there are many different ways to implement them. This section describes a few alternative ways of implementing a pattern, including the effects of randomness on it.

• Examples. This section lists at least two examples of the pattern in published games.

• Related Patterns. Most patterns are related to another one. Some patterns act against each other, while others complement each other. These and other relationships are described here.

In the next few sections, we’ll introduce the design patterns that we have collected. The patterns described here include a diagram and are organized into categories. This is only a brief synopsis, however. You can find full descriptions of each pattern, along with examples of games that use it, in Appendix B.

Category: Engines

Engines generate resources that may be required by other mechanics in the game.

Static Engine

A static engine produces a steady flow of resources over time for players to consume or to collect while playing the game.

Use a static engine when you want to limit players’ actions without complicating the design. A static engine forces players to think how they are going to spend their resources without much need for long-term planning.

Dynamic Engine

A source produces an adjustable flow of resources. Players can invest resources to improve the flow. Use a dynamic engine when:

• You want to introduce a trade-off between long-term investment and short-term gains. This pattern gives the player more control over the production rate than a static engine does.

Converter Engine

Two converters set up in a loop create a surplus of resources that can be used elsewhere in the game. Use a converter engine when:

• You want to create a more complex mechanism to provide the player with more resources than a static or dynamic engine provides. (Our example converter engine contains two interactive elements while the dynamic engine contains only one.) It increases the difficulty of the game because the strength and the required investment of the feedback loop are more difficult to assess.

• You need multiple options and mechanics to tune the profile of the feedback loop that drives the engine and thereby the stream of resources that flows into the game.

Engine Building

With this pattern, a significant portion of gameplay is dedicated to building up and tuning an engine to create a steady flow of resources. Use engine building when:

• You want to create a game that has a strong focus on building and construction.

• You want to create a game that focuses on long-term strategy and planning.

Category: Friction

Friction patterns drain resources out of an economy, reduce its productivity, or both. You can use them to represent loss or inefficiency.

Static Friction

A drain automatically consumes resources produced by the player. Use static friction when:

• You want to create a mechanism that counters production but that can eventually be overcome by the players.

• You want to exaggerate the long-term benefits from investing in upgrades for a dynamic engine.

Dynamic Friction

A drain automatically consumes resources produced by the player; the consumption rate is affected by the state of other elements in the game. Use dynamic friction when:

• You want to balance games where resources are produced too fast.

• You want to create a mechanism that counters production and automatically scales with players’ progress or power.

• You want to reduce the effectiveness of long-term strategies created by a dynamic engine in favor of short-term strategies.

Stopping Mechanism

This pattern reduces the effectiveness of a mechanism every time it is activated. Use a stopping mechanism when:

• You want to prevent players from abusing particular actions.

• You want to counter dominant strategies.

• You want to reduce the effectiveness of a positive feedback mechanism.

Attrition

Players actively steal or destroy resources of other players that they need for other actions in the game. Use attrition when:

• You want to allow direct and strategic interaction between multiple players.

• You want to introduce feedback into a system whose nature is determined by the strategic preferences and/or whims of the players.

Category: Escalation

Escalation patterns put pressure on the player to deal with growing challenges.

Escalating Challenge

Progress toward a goal increases the difficulty of further progression. Use escalating challenge when:

• You want to create a fast-paced game based on player skill (usually physical skill) in which the game gets harder as the player advances; his ability to complete tasks is inhibited as he goes.

• You want to create emergent mechanics that (partially) replace predesigned level progression.

Escalating Complexity

Players act against growing complexity, trying to keep the game under control until positive feedback grows too strong and the accumulated complexity makes them lose. Use escalating complexity when:

• You aim for a high-pressure, skill-based game.

• You want to create emergent mechanics that (partially) replace predesigned level progression.

Arms Race

Players can invest resources to improve their offensive and defensive capabili-ties against other players. Use arms race when:

• You want to create more strategic options for a game that uses the attrition pattern.

• You want to lengthen the playing time of your game.

Miscellaneous Patterns

The remaining patterns in our library don’t fall into any other category, so we have collected them here.

Playing Style Reinforcement

By applying slow, positive, constructive feedback on player actions, the game gradually adapts to the player’s preferred playing style. Use playing style reinforcement when:

• You want players to make a long-term investment in the game that spans multiple sessions.

• You want to reward players for building, planning ahead, and developing personal strategies.

• You want players to grow into a specific role or strategy.

Multiple Feedback

A single gameplay mechanism feeds into multiple feedback mechanisms, each with a different profile. Use multiple feedback when:

• You want to increase a game’s difficulty.

• You want to reward the player’s ability to read the current game state.

Trade

This pattern allows trade between players to introduce multiplayer dynamics and negative, constructive feedback. Use trade when:

• You want to introduce multiplayer dynamics to the game.

• You want to introduce negative, constructive feedback.

• You want to introduce a social mechanic that encourages players to interact with one another via commerce (as opposed to combat).

Worker Placement

The player controls a limited resource she must commit to activate or improve different mechanisms in the game. Use worker placement when:

• You want to introduce constant micromanagement as a player task.

• You want to encourage players to adapt to changing circumstances.

• You want to introduce timing as a crucial factor in successful strategies.

• You want to create a subtle mechanism for indirect conflict.

Slow Cycle

This is a mechanism that cycles through different states slowly, creating periodic changes to the game’s mechanics. Use a slow cycle when:

• You want to create more variation by introducing periodic phases to the game.

• You want to counteract the dominance of a particular strategy.

• You want to force players to periodically adapt strategies to shifting circumstances.

• You want to require a longer period of learning before achieving mastery of the game. (Players experience slow cycles less frequently, so have fewer opportunities to learn from them.)

• You want to introduce subtle, indirect strategic interaction by allowing players to influence the cycle’s period or amplitude.

Combining Design Patterns

Games rarely implement just one design pattern. Most of the time, you’ll find that a game combines a few of these patterns in a clever construction. For example, Tetris combines escalating complexity (the game gets more difficult as the tetrominoes build up and more and more holes—unfilled spaces—appear at the bottom) and escalating challenge (the tetrominoes start falling more quickly as the player clears more lines). As you can tell from their descriptions, many patterns in the library complement each other, but you’ll find that even more unlikely combinations of patterns can have some interesting consequences.

Certain patterns combine so well that they drive entire game genres. For example, the core of most real-time strategy games is formed by a combination of a dynamic engine with attrition. The players build up their base with a dynamic engine for production to fuel a war of attrition. Larger real-time strategy games complement this combination with an arms race pattern or (less commonly) an engine-building pattern to provide more strategic options and create longer gameplay. Most role-playing games combine playing-style-reinforcement (character building) with escalating challenge (harder challenges as the player progresses).

The descriptions of the patterns in Appendix B include many suggestions on how patterns might be combined, but we encourage you to explore and experiment with different combinations yourself.

Elaboration and Nesting Patterns

Reading through the pattern descriptions in this chapter and in Appendix B, you might have noticed that some of the patterns seem similar. For example, a dynamic engine allows the player to make changes to the production rate of a resource, while the engine building pattern does something very similar, except that it doesn’t dictate a particular implementation. You can think of the dynamic engine pattern as a special instance of the engine building pattern. If you include a dynamic engine in your game, you have implicitly included some form of engine building. Attrition and dynamic friction exhibit the same relationship: Attrition is a more specialized case of dynamic friction. Creating attrition is simply a special case of applying dynamic friction symmetrically.

From the perspective of design pattern theory, this type of relationship between patterns is called elaboration. One pattern (for example, attrition) is a more elaborate implementation of another pattern (for example, dynamic friction). Within the engine patterns, the worker placement pattern elaborates the engine building pattern, while the engine building elaborates the dynamic engine, and the dynamic engine elaborates the static engine.

Elaboration can be an important tool to design games. For example, if a game is too simple, replacing one pattern in the game with a pattern that elaborates the original pattern will make the game more complex. At the same time, when a game is too complex, replacing a complex pattern with a simpler pattern that the original elaborates will make the simpler. Ultimately, all engine patterns elaborate an ordinary source node, and all friction patterns elaborate an ordinary drain node. In your game, you should be able to replace any source with an engine, and vice versa. The pattern descriptions in Appendix B list what patterns elaborate other patterns and by which patterns it is elaborated under the related patterns section.

To illustrate how elaboration might be used as a design tool, consider the Harvester game. As was mentioned in the beginning of this chapter, it implements a dynamic engine pattern. There are a few possible elaborations. For example, we might elaborate the entire pattern to the engine building pattern or even to the worker placement pattern (Figure 7.3).

Figure 7.3. Elaborations of the Harvester game

Another option would be to elaborate elements within the dynamic engine. As we already mentioned, we could elaborate any source to an engine pattern. As the Harvester game contains a source, we could replace that source with a converter engine pattern (Figure 7.4). In turn, because the converter elements themselves actually consist of a combination of a drain triggering a source, we could replace any of them with an engine or a friction pattern.

Figure 7.4. Another elaboration of the Harvester game

Elaboration does not apply only to design patterns; it applies to almost any element in a Machinations diagram. For example, Figure 7.5 displays a number of ways to elaborate a converter. Any game mechanism can be an elaboration of a converter as long as it displays more or less the same functionality: consume one resource to produce another. The elaborated converters cannot be called design patterns, because they don’t present a generic solution to a common problem. However, building up a repertoire of such structures (while being aware of what they originally came from) will allow you to experiment with game mechanics with great ease.

Figure 7.5. Different elaborations for a converter element

Extending the Pattern Language

The patterns in this book are the result of many studies of existing games and also of using Machination diagrams to help design games. However, we do not mean to suggest that the pattern language as presented here is complete. Although the patterns we have described already capture many important aspects of a wide variety of games, we expect that in the near future we will add more patterns to this collection. In fact, we encourage you to keep an eye out for more interesting patterns that emerge from your own designs or from your analysis of other people’s games.

When encountering a new pattern, it is important to try to describe it in generic terms. You might have found a new pattern in a science-fiction game about intergalactic trade, but that doesn’t mean the pattern and its participants should take their names from that game. When describing new patterns, stick to the description format and general terms described in the earlier section “Pattern Descriptions.” Identify and name the most important participants; try to think of a number of different ways to implement the pattern, but most importantly identify the common design problems your pattern solves.

Leveraging Patterns for Design

A pattern language is a tool designed to help you. It does not enforce a particular way to design games. Patterns are guidelines you can use to explore your designs, not rules instructing you what you must do to make a good game. Nevertheless, we advise you to stick to the patterns initially. Implementing these patterns is a great way to build your design experience and learn by copying time-tested structures. Once you have some experience with identifying and applying these patterns, it makes perfect sense to start to break away from them. Moving into new, uncharted territory is exciting and important, but it is best done after you’ve gained some experience.

Improving Your Designs

The most important thing you can do with design patterns is to use them to solve problems in your design. For example, you might notice that your game produces arbitrary outcomes because a strong positive, constructive feedback loop amplifies a small random difference in luck early in the game. Looking at the patterns, a number of solutions suggest themselves. If the game has multiple resources, you might introduce more negative feedback by using the trade pattern. Or you could apply dynamic friction to counter the positive feedback.

To use design patterns in this way, it pays to study the library. Knowing the patterns and their different implementations will enhance your understanding of common problems in game design and provide you with a repertoire of potential solutions. Design patterns represent general design lore in a concentrated form. After all, most of these patterns have evolved in games over a long period. Design patterns allow you to build on that experience without going through a long learning period yourself.

Brainstorming with Design Patterns

Pattern languages make good brainstorming tools, and they allow all sorts of creative exercises. One simple technique is to choose two or three patterns at random from the collection and try to design a game economy around them. There are several ways to approach this exercise. You could choose a pattern at random, implement it in a digital Machinations diagram, and then choose a new pattern and add it to your diagram. You probably want to repeat this until you have implemented three or four patterns. You might also try to create paper prototypes for every step. Don’t worry if you randomly select the same pattern again. Simply find another resource or part of the diagram to apply it to. Alternatively, you can select a number of patterns beforehand and design a game economy that implements all patterns from the start.

You can do a similar thing for games you are currently developing. The patterns suggest many generic terms for resources in your game based on their function in the economy. Identifying what resource in your game functions as the main “energy” that fuels the player’s core actions could help bring your game’s most important economic structures into focus. Randomly pick a pattern and use it as a lens on the game, asking yourself questions like, Is the pattern present in the current design, and if so, does it work the way you want it to? If not, would adding it help counter problems in the design?

You could also use the patterns as a lens to analyze and change existing games. For example, what mechanisms act as a stopping mechanism in StarCraft? What would happen if you changed the basic economy of that same game to include a converter engine instead of a dynamic engine? What patterns would make a good addition?

Summary

This chapter introduced the concept of design patterns: recurring structures that appear in architecture, software, games, and other fields. After an overview of this idea’s history, we identified 16 common patterns from game mechanics, in 3 categories (engines, friction, and escalation), plus several more patterns that don’t neatly fit into a category. We ended the chapter by discussing some ways that you can use the patterns in your own game design practice by combining them and brainstorming about them. The patterns can also be used to analyze games that you already have in development. Another of their benefits is that they give you a common vocabulary to discuss the characteristics of your game’s mechanics with other members of your team.

In the next chapter, we will introduce an even more powerful feature of Machinations: the scripted artificial player. We’ll also conduct an in-depth analysis of two games, Monopoly and SimWar, showing how Machinations can be used to model, simulate, and balance them.

Exercises

1. What design patterns did you use in recent game projects? What design patterns might you have used that you didn’t? Could you have improved your game with one of them? If so, how?

2. Think of a game that you know well. It can belong to any genre except pure adventure games (which have no internal economy). What patterns can you find in it? Try diagramming them in the Machinations Tool.

3. Choose two design patterns at random (we sometimes write the names of the patterns on blank cards for this and then shuffle them and draw from the deck). Can you identify a game in which they both appear? Alternatively, try to think of a game concept that would use the two that you got. Create a Machinations diagram for the game with appropriately labeled sources, drains, pools, and other elements.