CHAPTER 5

An Introduction to
Patterns in Game Design

WHAT DOES A PATTERN LOOK LIKE,

AND HOW CAN I FIND IT?
This section is the heart of this book. In the following pages, I will explore
the process of deriving patterns from your own experience and research.
Yes, this book will provide 24 useful patterns, but these are just examples—
the by-products of showing you the process that you will use to create pat-
terns yourself.
Earlier I told you that this book wouldn’t teach you game design, and it
won’t. But, the process of creating patterns will teach you game design, or
it will give you the structure to organize the things you already know. The
Pattern Language that you begin with these exercises will turn your learned
and intuitive understanding of games into a usable set of patterns that you
can share with your colleagues and use together to shape your games.
Christopher Alexander’s work is awe-inspiring. The scope of his research
and the eccentric detail of his patterns manage to be practical and con-
crete, while at the same time encouraging designers to apply his ideas in
creative ways. His work suggests that designers should expand the Pattern
Language he began with his 253 patterns and that designers might even
develop entirely separate languages to address their own design needs. His
work describes the parts of a pattern and suggests that all patterns should
have those parts, but he does not give guidance as to how designers should
go about creating patterns that meet his specifications.

53
54 ◾ Pattern Language for Game Design

I have tried to address this problem by providing a robust set of exer-

cises for pattern generation. These exercises do not generate specific pat-
terns, but rather move to a higher level of abstraction and create either a
type of pattern or patterns in a particular area of design. It is beyond the
scope of this book to create a comprehensive set of exercises that would
build a “complete” Pattern Language. However, I believe this subset is suf-
ficient to teach you the skills necessary to continue expanding your own
Pattern Language generated by completing these exercises.
The first sections of this book have presented a lot of background and
theory. In the next section, I’ll give the template that I recommend using
when documenting a pattern. Then I will present a completed pattern and,
finally, the exercise that generated it.

The Pattern Template

Following Alexander’s lead, I have defined a Pattern Template, very simi-
lar to his, to use when documenting my patterns. This template represents
a synthesis of the work of other designers in applying patterns to game
design and my experience in using patterns to teach design. I strongly
recommend using this template until you’re very comfortable with the
process. Even then, maintaining a consistent format will make it easier for
other designers to read and understand your work.
If you’d prefer to see a concrete example of a pattern, feel free to skip to
the “Example Pattern” section later in this chapter and refer back to the
template if the meaning of any of the parts is not clear.

PATTERN TEMPLATE
Name: This should be an easy to remember and evocative name.
Confidence: This number rates the level of certainty you have that a pattern
is viable for use in developing games: how sure you are that it will have the
indicated effects, and any side effects it might have. See the later section
for details on rating your confidence in a pattern.
Image:* An iconic image to represent each pattern. This image can help to
convey the essence of the pattern and to serve as a mnemonic anchor for
remembering it.
Author: This is the name of the pattern creator or creators.

* There is a strong argument for the inclusion of an iconic image to represent each pattern. However,
the effort of finding or creating such an image is high, especially for designers who are not art-
ists. If you do not have the means to generate high-quality illustrations, at least describe what you
would have illustrated or use images from existing games that demonstrate the pattern. If you do
this, make sure to cite your sources and respect copyrighted material.
 An Introduction to Patterns in Game Design ◾ 55

Design problem: Each pattern exists to solve a problem.* Describe

that problem here. If you see a pattern without a problem, look harder.
Identifying the problem is critical to knowing when, and if, you want to
use the pattern.
Description: Provide a detailed description of the pattern here. This sec-
tion should go into as much depth as possible. It should be long enough to
fully capture your pattern. Do not try to be concise to the point of reduc-
ing your description to a single sentence. It can be helpful to start with the
following format: In order to [achieve some design effect], a designer may
[take some design action, use some mechanic, etc.] because [explanation
of how the pattern produces the desired effect].

Games that use this pattern and how:†

1. Game name—Description of how the game applies the pattern. This

section should be at least a full sentence, not just two or three keywords,
that will make sense to another designer. To help you understand this
better, the following two examples illustrate how to do this well, and
how I’ve seen students do it poorly.
2. Good example game—This game uses the pattern in this particular way.
By doing this, the game creates these dynamics in the player experience
that solve the problem.
3. Not great example game (Don’t do this one!)—This game is about these
cool things! In it players do these things that do not relate to the pattern.
It uses these mechanics [a comprehensive list of the mechanics found in
this bad example, many of which are unrelated to the pattern].

Seed: This is the idea that was the starting point for the pattern. For
the exercises presented in this book, it will follow the format: Exercise
XX: Exercise Name—Game Element. This is important to record, as
you will use it in the process of connecting your patterns into a lan-
guage, as discussed in Section VI of this book. It will also allow your
colleagues or instructor to understand what kind of pattern you were
trying to create.

* What is a design problem? The design problem that is addressed by a pattern should describe a
situation you face as a designer. A design problem is not simply the effect of a mechanic stated as a
question. It must capture the purpose and intent of the designer not just mechanically but in terms
of its effect on the player. In this way, a well-constructed pattern will ensure that you are designing
games that intentionally create an experience for the player. If this seems abstract, look over some
of the design problems in the example patterns provided for each exercise.
† In the pattern exercises you will in most cases be asked to analyze at least ten games. You do not

need to list all of those games here. I recommend citing at least three games that show diverse
implementations of your pattern. Having more games is fine if each shows a different use of your
pattern.
56 ◾ Pattern Language for Game Design

Related patterns:
Parent patterns: A pattern or several patterns that are required by this pat-
tern for it to function well.
Child patterns:* Patterns that are suggested by this pattern or require it to
function well.
Keywords: Keywords that relate to this pattern. Use keywords to link this
pattern to others in a non-hierarchical way. The process of choosing key-
words is discussed further in steps 2 and 3 of the “Connecting Patterns into
a Language” section of Chapter 15 which discuss keywords and pattern
categories.

RELATED PATTERNS
This section of the Pattern Template exists to connect this pattern to
the others that you will create as part of your Pattern Language. The
section of the book that will help you create that language comes
much later, after all of the pattern-generation exercises. If you want
to wait to complete this part of the Pattern Template until you get to
that part of the book, that’s okay. If you want to try to fill it in as you
go, that’s okay too. Either way, you will probably be revisiting all of
the patterns you create to fill in or adjust this section.
The Related Patterns section of each example will also suggest other
pattern exercises that you can complete to find additional parent
or child patterns for the example. These are not part of the Pattern
Template, but you may find them useful if you’re having a hard time
thinking of a starting point when completing the suggested exercise.
You may also want to include these kinds of suggestions when writ-
ing your patterns to help other developers, or your future self, extend
your Pattern Language.

PATTERN CONFIDENCE
It’s essential to acknowledge that all patterns aren’t equally valid. Different
exercises create more or less reliable patterns, and you should carefully
consider your confidence in any generated pattern before you use it in your
designs. I recommend using this rubric for assessing your confidence in a
new pattern, and for updating that confidence as you use the pattern over
time. All patterns start with a confidence rating of 0, then add 1 for each of
the following items that apply.

* As you develop more patterns, other sections like Related Patterns or Alternate Patterns might
make sense.
 An Introduction to Patterns in Game Design ◾ 57

Some of the items are related and “stack.” For example, a Common
Pattern (+1) would also have to meet the requirements for being a Limited
Pattern (+1) and a Singular Pattern (+1) for a total of 3. You should apply
all the applicable labels. So if you had used this hypothetical pattern and
another developer had independently described the same pattern, you
would also apply Demonstrated Pattern” (+1) and Independent Sources (+1)
for a total confidence score of 5.
(+0) Theoretical Pattern: The Theoretical Patterns exercise (Exercise 24)
generates this type of pattern. You might also create a theoretical pattern
by adapting a pattern from an existing repository that doesn’t cite example
games. This pattern may be valid, but you don’t generate it from observa-
tion. Instead, you create it by imagining how a theory about game design
would fit the pattern format.
(+1) Single Example Pattern: This level of confidence comes from a
pattern that was generated based on one example. It’s entirely possible to
look at a single game and derive a valid pattern from it. However, it can
be challenging to determine whether what you see is an actual pattern or
just the results of a design technique or element that would yield a different
pattern if you looked at its use across many games.
(+1) Limited Pattern: If you’ve observed the pattern in fewer than ten
games, it’s a limited pattern. If you have a hard time providing the ten
examples in an exercise, this level of confidence may result.
(+1) Common Pattern: The pattern is visible in at least ten games,
probably many more. You have found a “common pattern” when you
stop recording examples at ten but could go on, and it’s a good sign
that you’ve done an excellent job formulating a pattern based on your
observations.
(+1) Demonstrated Pattern: A pattern is a demonstrated pattern if you,
or another developer, have used it in development, and the effect was as
intended.
(+1) Validated Pattern: This confidence level describes a pattern that’s
in common use among a variety of game developers and has been proven
effective through widespread use. At the time of the printing of this book,
it’s probably not possible to find a pattern validated through use. As you
work with patterns throughout your career, it may become more common.
A pattern might also be a validated pattern if you conducted empirical user
research to show that the pattern was effective.
(+1) Independent Sources: If more than one developer derives a pat-
tern, it has independent sources. In teaching, it’s common to discover this
kind of pattern as more than one group of students arrives at the same pat-
tern from different starting points. As the community of developers using
the exercises in this book increases and shares patterns, this will become
more common.
58 ◾ Pattern Language for Game Design

EXAMPLE PATTERN: MYSTERY-DRIVEN EXPLORATION

I have used this example in many classes to teach the concept of patterns
and how they apply to game design. It’s not the simplest possible example,
but it demonstrates the process well. The exercises in the book begin with
a slightly more straightforward process and escalate in complexity to a
level considerably beyond this example.

Name: Mystery-Driven Exploration

Image:

FIGURE 5.1 Interesting but incomplete information can motivate explora-

tion in a variety of ways.

Confidence: 3
Author: Chris Barney
Design problem: Designers need to motivate their players to explore the
worlds they create.
Description: To motivate players to explore the worlds they create, a
designer may present the player with compelling but incomplete pieces
of information, and then give the player gameplay avenues that will allow
them to seek out more information and solve the mysteries of the game
world.
 An Introduction to Patterns in Game Design ◾ 59

Games that use this pattern and how:

• Journey—Journey opens with the view of a bright light shining from a

split atop an imposing mountain. The game does not explain the sight,
prompting you to investigate. The path in the direction of the mountain
is visibly open.
The second example of this pattern is also from Journey. As you play,
you regularly encounter small ruins. In the first ruin and many after that,
there are murals depicting scenes from the game world. These scenes
are usually incomplete and ambiguous, raising as many questions as
they answer.
• Grand Theft Auto—A map of the game world shows the quests you can
do in the area surrounding you at the moment. The rest of the map is
visible, but you can’t see the available quests in the other areas unless
you explore.
• Skyrim (and many other Elder Scrolls games)—As you move through
the world, a horizontal compass in your HUD shows nearby quests and
points of interest. Since the indicated locations are nearby, unknown,
and often yield mechanical and narrative rewards, they motivate you
to divert your travel to seek them out, wandering off of the direct path
between primary game objectives.
• Bastion—As you explore the levels of Bastion, you can only see the
world directly around you. The rest of the world literally does not exist
yet. As you move forward, the ground rises into existence just in front of
the character’s feet. On a first playthrough, there’s no way to know what
will appear as you move forward. That might cause a lack of motivation
to explore if you don’t have an active imagination! The game avoids
that problem by coupling the visual mystery of the missing world with a
charismatic and omniscient narrator speaking in a god-like voice-over,
always prompting you to act and describing the world as it appears.
• Dear Esther—At first glance, this game seems to offer no clear direction.
There’s no HUD and no obvious path. However, the game presents
you with a narrative voice-over that’s compelling but vague. The world
appears to be open in all directions, but in actuality, the levels give you
a limited area to explore. The game avoids feeling on rails by presenting
you with a constant stream of visual cues to investigate. Some are small,
like a candle or farmhouse in the middle distance; others, like the radio
tower, are visible throughout the game. The narrative and visual weight
of the clues are generally proportional—things that look more important
turn out to be more important.
• Draugen—The world of Draugen is somewhat similar to Dear Esther,
except that the game also offers intriguing visual and narrative avenues
that are not immediately available to pursue. A sign indicating the
entrance to a mine, for example, is blocked by a locked gate. If you
60 ◾ Pattern Language for Game Design

approach, a companion suggests climbing the gate to explore. However,

your character only has the option to decline, which primes you to
explore in that direction as soon as possible.

Seed: Exercise 2: Higher-Order Patterns—Architectural Weenies*

Parent patterns:
Greater Choice Requires Greater Motivation† (Confidence: 2)—As you
apply Mystery-Driven Exploration, you are creating choices for the player.
The more mysteries you present the player with, the more important this
pattern becomes to maintain the player’s motivation to explore.

SUGGESTED EXERCISE
Use Exercise 6: Emotional Patterns to generate a pattern based on
curiosity.

Child patterns:

SUGGESTED EXERCISE
Use Exercise 12: Embedded and Environmental Narrative Patterns
to generate a pattern based on a level that presents a mystery through
embedded or environmental narrative.

Keywords: Navigation, Motivation, Narrative

The seed of this pattern is “a tall structure visible from many points in
the game world,” which is a technique known as an “architectural weenie.”
In case you aren’t an architecture student or a theme park designer, an
architectural weenie is a tall structure placed in a theme park or even in
a city. This technique lets people use it to navigate from a great distance
and also draws them to it when they’re exploring. The Imagineers coined
the term at Disneyland, and the Matterhorn is the archetypical example.
However, buildings like the Eiffel Tower or the Dom in Cologne are also
great examples that predate Disney by decades or centuries. It would be
easy just to use that as a pattern (Kreimeier 2002, p. 9). It certainly sounds
like a pattern, a technique that exists to solve a problem. However, it is

* Pattern exercises are given in the next two sections of the book. For each exercise I show my work
for the exercise and give the pattern that my work produced as an example. The exercise I used to
produce this pattern, the Higher-Order Patterns exercise, is a little difficult. When I present that
exercise, I give another example.
† Example pattern from Exercise 16: Patterns from Core Mechanics.
 An Introduction to Patterns in Game Design ◾ 61

missing an essential aspect of a well-formed pattern: being general. “Use

architectural weenies to provide wayfinding” is too specific. When you
use an architectural weenie to solve the problem of wayfinding, you can
spot it a mile off.* The goal of pattern exercises is to get the designer to
dig deeper than the immediate technique that inspired the pattern, to ask
what problem the technique is solving. Thus architectural weenies become
Mystery-Driven Exploration and can be applied in weenie-free ways. If
you structure a pattern correctly, you can apply it in many ways outside of
those used in the analyzed games.
Initially, when you are creating a pattern, you leave the last three items
blank. You may not be able to identify parent and child relationships when
you first complete the pattern, because you will have such a small set of
patterns. As you develop more patterns, you will add these fields when you
recognize that two of your patterns are connected. I cover the process of
integrating patterns into a language in the sixth section of this book.
Keywords are also part of that process, and, initially, you may wish
to leave that field blank as well. While you can decide on keywords for
your first pattern immediately, you will likely find yourself revising them
repeatedly as you add more and more patterns and develop a standardized
set of descriptors. It’s fine to skip them in the beginning, as they have lim-
ited utility when you only have a handful of patterns to track. Eventually,
though, they will become a critical tool that will let you filter and search
your library for patterns on a specific topic. Again, I will cover that process
in Chapter 15.

INTRODUCTION TO PATTERN EXERCISES

The following pattern exercises will help you identify useful patterns.
Looking randomly at the games you play and trying to find patterns can
work sometimes. It might even yield helpful or exciting patterns. However,
given that there is an almost infinite number of patterns you could iden-
tify (superb pattern recognition machine that you are), it’s useful to have
tools to focus the patterns you observe toward the specific problems you
face. You should also do all you can to make sure that the patterns you
recognize are as flexible and insightful as possible.
As you work through this book, I encourage you to do the exercises in
order. They build in complexity and specificity, and passing through all of
them once will give you the start of a structure for the language you will

* See what I did there?