Daily news, dev blogs, and stories from Game Developer straight to your inbox
Book Excerpt: Patterns in Game Design: Using Design Patterns
This excerpt from Staffan Björk and Jussi Holopainen's intriguing book Patterns in Game Design illustrates a number of uses of 'game design patterns', which, the authors suggest, can be combined and tailored for specific real world uses.
January 12, 2006
18 Min Read
Author: by Staffan Bjork
The following is a selected excerpt of Chapter 4 from Patterns in Game Design (ISBN 1-53450-354-8) published by Charles River Media, Inc.
Game design patterns, either those in this book or patterns made by you or others, can be used in many different ways. This chapter illustrates a number of uses of patterns. Explicit methods or instructions are not included, because the methods would vary considerably between different game types, and no single method is best for all uses. All methods for examining or creating games need to be modified for their specific context. There are several books and papers that more explicitly describe game design methods (see for example [Costikyan94], [Church99], [Falstein02], [Adams03], [Fullerton04]) that can be strengthened by using game design patterns but game design patterns are not limited to these methods. However, a common set of concepts, such as game design patterns, offers valuable support for making such modifications of methods. The use of patterns described in this chapter can, and in most cases should, be combined and tailored for specific real world uses.
Target users are not specified for these uses because they can be applied in many contexts, for example, identifying patterns in a game may be used by critics writing reviews or gamers making decisions about purchases. However, we stress that game design patterns are beneficial to multidisciplinary groups as they ease communication by providing neutral definitions based on interaction in games, and they are not based on any professional jargon found in a specific research field.
The implementation of game design patterns can be roughly divided into two different categories: analysis and design. Analysis requires an existing game—or a prototype or a design document describing a game—so one can study what game design patterns exist within the game. Design can refer to the creation of an idea, concept, or description of a game by using game design patterns, or of formalizing a game idea or concept into a more structured description.
Analysis: Identifying Game Design Patterns
Analyzing entails identifying game design patterns in games, game prototypes, or design documents. Finding game design patterns in games or game prototypes can be done by test playing the game, either doing it oneself or through observing others. With design documents, this is not possible, but by analyzing the descriptions of the games, it is possible to make a structural analysis to identify game design patterns in the game. Although not all game design patterns are easily identifiable by structural analysis, and for many, the certainty of their existence during gameplay cannot be guaranteed, it is usually quicker and more ordered than play testing. This is because play testing causes a conflict of interest between studying the game design and trying to play the game when doing it oneself, and from the vast amount of data generated when observing others.
Structural analysis cannot only be made from design documents but also from static descriptions in games and prototypes, such as instruction manuals or code. This flexibility allows for play testing and structural analysis to be combined to perform more efficient and reliable examinations. For example, one can first make a quick structural analysis of a game to determine the easily identifiable game design patterns then observe people playing the game to confirm these game design patterns and identify new game design patterns. A second round of structural analysis can then be performed to understand how the identified game design patterns relate to each other, possibly through previously unidentified game design patterns.
For categorization purposes, game design pattern analysis of collections of games can be performed to allow them to be sorted by their similarities or differences. Besides offering a multitude of dimensions for measuring how games compare to one another, collections of patterns can be used to identify or understand genres.
Identifying patterns in a game design can be beneficial from a business perspective, because it helps in analyzing the products of competitors.
The aim of structural analysis is to understand what patterns exist in a game design without actually playing the game, regardless of whether the game design is expressed through an actual game, a prototype, or a design document. Many game design patterns are formed around concepts already existing in gamer and game designer communities. Making a quick sweep through a game design to find these well-known concepts and matching them against game design patterns is an efficient way of getting an initial understanding of the game.
From an initial set of game design patterns, one can then expand the set through many different methods, but two more structured ways are based upon using either the component framework or the relationship lists of the initial set. Using the component framework described in Chapter 2 allows the initial set of identified game design patterns to be placed on a treelike structure. By focusing on each branch of the tree in turn, the analysis will have considered holistic, boundary, temporal, and structural game components and the different subcategories of these. The relationship lists of the initial set can be used to identify additional game design patterns simply by systematically going through the patterns mentioned in the lists and by considering whether they appear in the game design.
When no further game patterns can be identified in a design, the structural analysis of the game design can be considered concluded, or the appearance of similar patterns in different parts of gameplay can be examined to try and identify potential design decisions above the game design pattern level. The robustness of the analysis can also be tried at this stage by seeing if there are any isolated groups of patterns that are not interrelated to other patterns.
Example: The analysis of Pac-Man in Chapter 2 provides a basic understanding of the game. For a more detailed description, the analysis can be expanded by identifying game design patterns in each category and then identifying subpatterns and how all patterns in the game relate to each other. The existing analysis gives many game design patterns to start with: the holistic category gives Lives, High Score List, and Meta Games; the boundary category gives goals of Collection, Levels, and Role Reversal (through the power pill); the temporal category gives Time Limit, Movement, Geometric Rewards for Investments (regarding the number of captured ghosts); and the structural category gives Enemies, Power-Ups, and Inaccessible Areas.
Play testing can aid in identifying game design patterns as they appear in gameplay. The primary advantage of this type of analysis is that it can detect unintentional and emergent game design patterns that structural analysis has problems detecting. The negative aspect of play testing is that it makes focusing on particular areas of gameplay more difficult without ruining the gameplay and risks totally missing game design patterns depending on what composition of players one has. This can partially be mitigated by having the people doing the analysis also play the game, but this divides their intentions and may prevent the fully intended gameplay to take place and may lessen players' immersion in the game.
Play testing requires additional tools and material to be used while the game is being played so that the play sessions can be recorded. To create fully normal play sessions, these have to be set up so that they do not disturb the players, and the people doing the observations need to be unobservable or ignorable by the players. Many of the methods used for understanding user behavior in human-computer interaction and interaction design can, with minor changes, be used to study people playing games (see for example [Preece02]).
Analyzing the material collected from play sessions typically takes a significantly longer time than the actual sessions. Understanding the reactions or reasoning of players, or their social interaction, can be particularly difficult and take a long time. Questioning or interviewing players after the play sessions can help but may not be completely accurate since their answers are interpretations of how they perceived their own actions.
Example: Many of the more abstract design goals of games, for example player balance and emotional responses, are impossible to predict without play testing. If the results of play testing are used to identify game design patterns, for example the presence or absence of Illusion of Influence and Perceived Chance to Succeed, the knowledge contained in the pattern descriptions can be used to adjust the game design to the intended gameplay. This can become easier if the more abstract design goals have been described as game design patterns also, for example, that the game should have Tension in the Social Interaction and Player Constructed Worlds.
Design: Applying Game Design Patterns
Implementing patterns in game design allows the designer to control what will occur in the game. Unlike previous uses of patterns in other fields, our patterns are not primarily a problem-solving method. Instead, the patterns and the component framework are generic tools. Game design patterns are useful for several potential user groups who have inherently different working methods. Not only can the patterns be used more often if more groups can use them, but communication between those groups becomes easier and thereby cross-disciplinary work.
Some may object that the use of patterns takes the creativity out of game design or renders the designers into “mere pattern cranking machines” that automatically churn out games. Another fear is that the use of patterns will lead to a situation where all games follow the same pattern and fall into stereotypes where nothing new is or can be created. Such potential objections stem from confusing the everyday meaning of patterns as something repetitive with the main idea of design patterns as introduced by Alexander et al., in which design patterns can be considered hypotheses, and collections of patterns can be considered a language that can, and should, evolve over time. In one sense, the choice of the term pattern might be regarded as a mistake, but as the term has clear and firmly established meaning in professional fields, e.g., in computer programming for example, it is unnecessary to invent new terminology, something that would indeed lessen the usefulness of the pattern concept as a tool to overcome communication difficulties in various professions. A more appropriate view on the use of patterns is to compare it to artistic endeavor in general: artists have a much better chance to create something novel when they are, though not necessarily consciously, familiar with the works of other artists. Not only can they position their own work within a community of peers, but they can also be more certain when they are innovating and creating something novel.
Game design patterns support design in four main ways: idea generation, structured development of game concepts, communication between members in design groups or projects, and solving design problems regarding gameplay.
Somewhat paradoxically, the game industry has become what can be called conservative, due to the economically successful model of sequels and branding. The unwillingness to go beyond existing frames is found not only in thematic and gameplay styles but also in the limited use of mediums or hardware platforms. We believe that the use of patterns can help the exploration of new types of games, as they can provide a structured way of detecting how gameplay changes with changes in gameplay environments. This is especially likely for novel game mediums such as games on mobile phones or pervasive gaming, which are developments of computer games but need to function in social conditions similar to those in which more traditional games are played.
Game design patterns can help idea generation both in unstructured or structured ways. Simply choosing a set of patterns randomly and trying to imagine a game using them is one unstructured way of generating ideas; the use of patterns in brainstorming is a bit more structured and precise than traditional brainstorming. Patterns give descriptions of recurrent features in game design and sometimes the target for brainstorming is how to break, modify, or add to the patterns. A more structured approach is possible when one knows that some specific game design patterns, or gameplay that is related to some specific game design patterns, should be part of a game design. In these cases, game designers can study individual game design patterns to try to implement the patterns in ways that are different from the ones in the examples studied.
Example: Assume generating ideas from three random patterns, for example, Last Man Standing, Shared Resources, and Safe Havens. The first pattern gives several associated patterns, but one, Dynamic Alliances, is close to the pattern Alliances that is modulated by Shared Resources. This sparks the idea of having all players cooperate against a common enemy and although they cannot kill each other directly, they can make it more difficult for other players to survive by depleting the Shared Resources. Looking at the related patterns to Resources in general, it becomes apparent that either Non-Renewable Resources or Limited Resources should also be used. Safe Havens also mention Dynamic Alliances in the context of providing safe areas to negotiate, but if the places with Shared Resources are also Safe Havens, this would promote players to gather there when under attack and also to probably restock on Shared Resources. The game designer can then expand this basic game idea by defining what Enemies the players have, how they can fight them, and what the end and winning conditions are for the game.
Development of Game Concepts
Once an initial game concept exists, game design patterns can be used to develop and structure it. By first describing the concept as a small set of patterns, it can then gradually be fleshed out, and more specific design choices can be made as to how to instantiate those patterns through subpatterns and how the different design patterns interact. The process can be iteratively refined by examining the chosen subpatterns until the preferred level of detail is achieved. A form of stress testing can then be performed by picking random patterns not included in the game design to see if they do not provide the intended gameplay, if they make the game too complex, or if they have been overlooked.
Example: Assuming that one is to design a team-based FPS, the game design patterns Team Play, Cooperation, Aim & Shoot, and First-Person View give natural starting points to think about the gameplay in such a game: by looking at Team Play a game designer can see that Shared Rewards, Shared Penalties, Asymmetric Abilities, and other patterns can affect how team play actually occurs in the game; Cooperation points to the potential use of Collaborative Actions, Delayed Reciprocity, and Social Dilemmas; Aim & Shoot unsurprisingly can be used together with Eliminate goals but can also be used to create Capture or Delivery goals, and can be made more difficult through Obstacles; finally, First-Person View points out that this pattern gives players the limited overview known as Fog of War and can be modulated by Status Indicators. Ideas for specific game design choices may be inspired by looking at the presence of some patterns in several of the initial patterns. The presence of Extended Actions and Collaborative Actions can, for example, give the idea of splitting Aim & Shoot into two actions so that one player has to aim for a certain period of time while another player does the actual shooting.
Game design patterns contain information about how games have achieved certain types of interaction within gameplay. This information can be used by game designers who know they want a specific type of interaction by identifying the correct game design patterns and seeing what possibilities for instantiating them exist in the designer's current work. This can be done by inserting new patterns that have the instantiates relation to the wanted pattern, by modifying existing patterns that have instantiated by or modulated by relations to the wanted pattern, or by introducing a pattern from scratch.
The same approach can be used to remove unintended or unwanted interaction from games. Once this interaction has been identified, game designers can identify the corresponding pattern and see what typically causes it to occur. The game design can then be analyzed to see which of these causes exists, and the design can be changed to eliminate them.
Example: Assume that a team-based game with strong elements of Conflict does not have enough Tension . Going through the many patterns that instantiate Tension , the game designer notes that Betrayal is not used. Examining the Betrayal pattern, the game designer notices that it not only increases tension but (naturally) Conflict , which is in line with the general gameplay. However, the game does not give any motivation to betray one's own team, so the designer introduces a possibility of one team giving Individual Rewards to a player on the other team if that player agrees to a Committed Goal . This is a form of Negotiation , which is difficult to perform in a game where the teams are in permanent Conflict , so the game designer introduces Safe Havens where players cannot attack each other. Based upon this addition, the original game design needs to be reexamined, especially the consequences of adding Safe Havens : not only are they Strategic Locations and points to go when conducting negotiation but also points to guard against possible betrayers.
Using patterns to describe a game offers advantages when presenting the game design to people. Besides allowing a structured description of the design, motivations for particular design choices (described as patterns) can be made in two ways: by
relating the choices to other games using the same patterns or by describing how
replacing the pattern with other patterns would change the gameplay. This advantage is increased if people already have been introduced to design patterns from previous game designs as they can more easily compare the designs.
In contrast to common sense concepts, game design patterns offer a way to check a static definition whenever there is uncertainty. The definitions do not have to be those found in this book: definitions may be made more specific for particular projects or written completely from scratch.
Improved communication can help the design and creation of games on many levels: initial ideas, design concepts, and design documents can be more clearly expressed; members working on the same part of a game design have a smaller risk of misunderstanding each other; members within the same project can more easily communicate with people that have different backgrounds and professions; the agreement between developers and distributors can become more exact on what should be developed; and comparing the final game with the initial description is easier.
Example: Game design patterns can allow producers to more specifically describe what game they intend to make, for example “an FPS where we increase the Tension by not having Safe Havens and only allowing saving at specific Save Points .” This also makes it easier to verify that the game design contains agreed game features, since they are more explicitly described.
In this chapter, we have presented several ways of using game design patterns. For analytic use, we have described how game design patterns can be identified through structural analysis or play testing. For use in game design, we have described how game design patterns can support the design process by supporting idea generation, structuring the development of game concepts, providing solutions for problem solving, and aiding communication.
[Adams03] Adams, Ernest and Andrew Rollings. Andrew Rollings and Ernest Adams on Game Design. New Riders Publishing, 2003.
[Church99] Church, Doug. “Formal Abstract Design Tools.” Game Developer Magazine (August 1999). (Also available online at http://www.gamasutra.com/features/19990716/design_tools_01.htm.)
[Costikyan94] Costikyan, Greg. “I Have No Words and I Must Design.” Interactive Fantasy 2 . Hogshead Publishing, 1994. (Also available online at http://www.costik.com/nowords.html.)
[Falstein02] Falstein, Noah. “Better by Design: The 400 Project.” Game Developer Magazine (March 2002).
[Fullerton04] Fullerton , Tracy , Christopher Swain, and Steven Hoffman. Game Design Workshop: Designing, Prototyping, and Playtesting Games. CMP Books, 2004.
[Preece02] Preece, Jenny, Helen Sharp, and Yvonne Rogers. Interaction Design: Beyond Human-Computer Interaction. John Wiley and Sons Ltd., 2002.
© 2004. Charles River Media. All Rights Reserved.
Read more about:Features
You May Also Like
Exploring the 2024 State of the Game Industry report - Game Developer Podcast ep. 39Feb 2, 2024
Phantom inspiration and the ethical auteur with Xalavier Nelson Jr.Dec 8, 2023
Designing Killer Queen: from playground experiment to modern arcade sensationOct 18, 2023
Rod Humble and King Choi illustrate the ambition of Life By YouSep 22, 2023
Get daily news, dev blogs, and stories from Game Developer straight to your inbox
Subscribe to Game Developer Newsletters to stay caught up with the latest news, design insights, marketing tips, and more