Content Patterns in Game Design
 Bernd Kreimeier 
Table of Contents
Introduction	1
Discussing Patterns	2
How do Pattern Languages work?	3
Do Patterns work for game design?	6
What are typical game design Patterns?	8
Bibliography	12

Introduction
Game design, like any other profession, requires the development and establishment of formal means to document, discuss, and plan. Over the past decades, the designer community could refer to a steadily growing body of published computer games. Knowledge was also extracted from the analysis of board games and other classical games implemented and played without computer assistance, including attempts to draw insights from the rigorous formal analysis employed in the discipline of mathematical game theory.
However, while our experience with, and knowledge about, computer games, has grown rapidly, little progress seems to have been made with respect to written expression of our individual experience and knowledge - documentation that is mandatory if the profession is to advance. It has been observed before [Chur1999] that game design suffers from a lack of a language: lack of a vocabulary to name the objects and structures we are creating and shaping, and lack of a grammar to express how these building blocks fit together. 
From the very first interactive computer games, game designers have worked around this deficiency relying on techniques and tools borrowed from other, established media, predominantly narrative media: cinematography, scriptwriting, storytelling. Computer games are a visual medium, and especially since recent improvements in graphics technology and general purpose processing, reliance on techniques originally developed for movies has increasingly competed with attempts to identify a genuine formalism of game design. The discussion of narrative techniques has come to dominate the discourse on game design, almost to the point of extinguishing alternative approaches.
If the techniques borrowed from other media (see e.g. [Dunn2000]) were sufficient to express and address game design issues, there would be no need to search for alternatives. However, the metaphors and devices borrowed from narrative media are, more often than not, insufficient or even inadequate to capture the essence of the medium interactive game. The community is aware of this [Chur2000] although a common response is an attempt to reconcile the contradiction by redefining narrative [Lebl2000]. Taken to the extreme of an artificial playwright (Laur1991, Crawford's Erasmatron), this constitutes proposing a technological solution to a conceptual problem. The real issue is not the shortcomings of narrative techniques with respect to their utility in game design, but the lack of techniques genuinely suited for interactive media.
This supplementary article offers an outline of a pattern-based formalism [Alex1977], [Alex1979] for game design, as a reference for the related GDC 2002 roundtable discussions. The scope of this article focuses on content patterns (see also Roll2002), as opposed to software engineering patterns Gamm1994, specializations of which that have been proposed for game programming [Simp1998], [Heck2000], or process patterns to organize and manage game development projects.
Discussing Patterns
This supplement will not attempt to answer the questions raised here, it merely provides background information in an attempt to aid the roundtable discussion, serving as a complement to the roundtable report to be published after the conference. The discussion of a pattern based approach could be broken down into three distinct steps: 
•	 How do Pattern Languages work? 
 Before we can debate the merits of a given solution, we have to arrive at a common understanding of the problems we attempt to solve, and the precise approach that is proposed. To establish a baseline, a short review of the history, evolution, and past application of patterns and pattern languages is given, with references for further investigation. 
•	 Do Patterns work for game design? 
 How do pattern-based formalisms compare to alternatives, what are the strengths and weakness of pattern descriptions? Do game designers already use patterns in formal or informal ways, within isolated groups, across the community, or in interaction with other team members (e.g. programmers)? Do we have examples of past success or failure? Have there been variants and combinations of the Alexandrian approach that were found to work better? Have there been examples of pattern languages in other (e.g. narrative) media? Have patterns been used under other names? How rigid or flexible are pattern-based methods? How would they be used practically, in day-to-day life? These questions are at the heart of the roundtable discussion, and their answers will have to lay the foundation for any actual use. 
•	 What are typical game design Patterns? 
 Once pattern languages are understood, and in the event they are chosen as a method for semi-formal game design, the real work of proposing candidate patterns, refining their description and ultimately accepting or rejecting it has only begun. Pattern languages only provide a harness, a way of formulating and documenting isolated insights, and to subsequently weave them together to a loosely or tightly connected semantic network. Examples of possible pattern candidates can serve as anchors of the roundtable discussion, especially if patterns are used to express insights previously described in other, less formal ways. 
Each of the above steps is addressed in its own section, which an emphasis on the background information on pattern languages, and a small set of example patterns offered as references.
How do Pattern Languages work?
This section describes some of the history and use of patterns, and pattern-like concepts, in different areas of application, and provides references for further exploration of the question. 
What makes a Pattern?
[Gamm1994] quotes Alexander: "Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of a solution to that problem, in such a way that can you can use this solution a million times over, without ever doing it the same way twice" [Alex1977]. In other words, at the very least a pattern documents the observation that a problem-solution pair is recurrent: that we encounter variations of the same problem repeatedly, and that we often wind up applying a certain kind of solution to it. There might be several alternative solutions, each of them defining its own pattern, but the combination of problem statement and solution proposal is the essence of any individual pattern.
Consequently, [Gamm1994] lists these four essential elements: 
•	 Name: Any pattern needs a name. "Naming a pattern immediately increases our design vocabulary. It lets us design at a higher level of abstraction" [Gamm1994]. Names have to be mnemonic and evocative, but the connotations also pose problems. Aliases, usually part of pattern templates, are actually an indication of a naming problem: "Finding good names has been one of the hardest parts of developing our catalog" [Gamm1994]. 
•	 Problem: This describes the problem in itself: its inherent trade-offs, the context in which it occurs. It is a design problem, implying a goal that we want to accomplish, and the obstacles we encounter when we attempt to do so. 
•	 Solution: Describes a general arrangement of entities and mechanisms that can be used to solve the problem. This is not a particular design or concrete implementation, but an abstract structure that describes an entire family of solutions that are essentially the same. 
•	 Consequences: Each solution has its own trade-offs and consequences. Solutions can, in turn, cause or amplify other problems. To take a design decision for or against a given solution, its costs and benefits have to be understood and compared against those of alternatives. This section describes the likely or possible consequences of applying the solution suggested by the pattern. 
Around this essential core, pattern templates often add other elements, or subdivide a core element. Gamm1994 uses Name - Intent - Also Known As - Motivation - Applicability - Structure - Participants - Collaborations - Consequences - Implementation - Sample - Known Uses - Related Patterns . [Mesz] describes pattern writing as such in patterns organized as Title - Problem - Context - Forces - Solution - Indications - Resulting Context - Related Patterns - Examples - Samples - Rationale - Aliases - Acknowledgements . [Alex1977] uses Name - Example as Picture - Context within larger patterns - Problem - Solution - Solution as Diagram - Relation to smaller patterns. It helps to define the pattern template, the description format, before attempting to describe actual patterns. The details of the format do not matter as much as the fact that one format has been elected and is used throughout. For more details on how to write patterns, see also [Sane1995a], [Vlis1996a], and [Appl2000]
Origins: Architecture
The methodology of pattern languages was created and introduced by the architect Christopher Alexander. Alexander's work can be described as a lifelong quest to find semi-formal ways of capturing the essence of solutions to complex problems. His first attempt, originally published in 1964 [Alex1964], strives to describe the complex problems found in the context of architecture as optimization problems. Such problems typically do not have simple, fixed solutions, but instead are characterized by constraints and trade-offs between competing objectives. For architecture, solutions are implemented creating and shaping spaces for the purpose of accommodating, guiding and reinforcing human behavior. 
Alexander believed that earlier, unselfconscious human cultures had found workable solutions to their architectural needs by a process of trial and error spanning generations. This process can essentially be described as an evolution defined by individual experimentation (variation) and collective review (selection). Alexander recognized that the problems, as well as their solutions, are not mutually independent and often tightly connected: problems travel in groups, and so do their solutions. He also described them to exist on different levels of a conceptual hierarchy, that they are, semantically and practically, nested, and that the resulting groups in turn can be found over and over again.
The key idea defining the Alexandrian approach is that of recurring patterns. Observing the solutions found in the architecture of older cultures, Alexander attempted to name and extract the knowledge embodied in existing structures. Architecture creates spaces and spatial arrangements, and his first attempt at documentation and labeling was graphical, using diagrams expressed in a pictoral language almost resembling chinese or japanese calligraphy. In his 1971 preface to the paperback edition of [Alex1964] Alexander states that he has come to replace the original diagrams with a concept he calls patterns, and that he considers the approach an example of the larger field of design methods.
Alexander and his co-workers reported on the application of their own evolving methods in a book on the planning process of an entire university [Alex1975]. "A Pattern Language" [Alex1977] summarized their method listing a total of 253 patterns separated into three groups (towns, buildings, construction). Later, Alexander published "A Timeless Way of Building" [Alex1979], which attempts to describe the rules that govern pattern languages and their creation - in a way, the patterns of pattern languages. While "Timeless" [Alex1979] is as focused on architecture as its predecessors, it shares with "Notes" [Alex1964] a claim that pattern-based design methods are applicable in other problem domains.
Alexandrian patterns are informal. The pattern language described in [Alex1977] is almost narrative, in sections that share a loose structure consisting of the name that also serves as section title, a short summary of the problem and its essential trade-off in one or two sentences, a discussion of the details in one or two pages, followed by a short (again, a few sentences) authorative recommendation, a solution then detailed in another paragraph or two. Drawings and photos are used to illustrate the words, and the text features statistics and references, but at its core the patterns in [Alex1977] are formalized only to the extent of Problem - Details - Therefore: Solution - Details. This is the essence of patterns: a recurring solution to an equally recurring problem, documented in a more or less rigid manner.
Application: Software Engineering
According to the seminal book "Design Patterns" [Gamm1994a;], Alexander's pattern-based approach began what might well be their biggest success story with the PhD thesis of Erich Gamma, a computer scientist involved in the engineering of ET++, a large class hierarchy that became a textbook example of object-oriented design. By 1991, a core group was working on a pattern catalog (a collection, which is somewhat different from the Alexandrian notion of an actual language) which was announced on a 1993 conference, and subsequently published as a book in 1994 [Gamm1994]. The group (Erich Gamma, Richard Helm, John Vlissides and Ralph Johnson) became known as the "Gang of Four".
[Gamm1994] summarizes the potential appeal of patterns to software engineers by describing patterns as a way to aid the process of developing reusable solutions to problems of object-oriented software-design. Engineers do not solve a problem from first principles if they can reuse a solution that has worked in the past. However, the knowledge implicitily available to experienced software designers is not readily available to novices. In its conclusion, [Gamm1994] lists the benefits of patterns as: 
•	 a common design vocabulary, that allows the experienced designers to talk to each other efficiently 
•	 a documentation and learning aid, that allows the experienced designers to extract their experience, converting it to written knowledge, and thus to communicate it efficiently to less experienced designers, to engineers and coders, and even outsiders 
•	 a tool for redesign (for software engineers, patterns are targets for a process called refactoring) 
•	 an adjunct to existing methods (e.g. "Use Cases" capture recurring ways of how the software will be experienced by the user, patterns capture recurring details of the implementation) 
 
[Gamm1994] adopts Brian Foote's concept of a lifecycle of software that breaks down into a sequence of stages of prototyping - expansion - consolidation Prototyping leads to added and refined requirements, which in turn cause expansion. The cycle is closed by reorganizing the expanded software in an engineering step known as refactoring , identifying recurrent code and separating it to permit reuse. Patterns become a means to express and implement this process.
Patterns and other Tools
Software engineering operates in an abstract domain, a space much closer to a Platonian Ideal than architecture or game design. However, the mechanisms that govern human undertakings are universal. [Gamm1994] refers to the use of patterns by novelist and playwrights, and indeed Campbell's "Hero's Journey" [Vogl1998], [Dunn2000] seems an excellent example of a pattern language. The pattern structure of screenplays also illustrates an important benefit of pattern use omitted in [Gamm1994]:
 
•	 a foundation for software tools guiding and supporting the design process and the maintenance of the result 
The diverse design methods developed for software engineering (Jacobson's "Use Cases", Booch's subsystems, OMT, Gamma's patterns) lead to attempts to create tools, e.g. editors, specifically made to support the method, ultimately leading to efforts like UML (Unified Modeling Language, see [Mull1997]). A similar development can be found in scriptwriting: a number of word processors can be configured for, or has been written explicitly to, write screenplays in a standard format established throughout the movie industry. Pattern languages naturally lead to expression by use of descriptive markup languages like XML, with a huge potential for tool support based on off-the-shelf software. 
It is possible to express existing concepts as patterns: take, for example, the notion of narrative devices in literary theory [Shlk1990]. UI metaphors are UI design patterns, recurring solutions to a communication problem. Behavior shaping, a problem domain that can be expressed in terms of communication problems [Pryo1999], relies on patterns (e.g. specific schedules [Hops2001]) of reinforcement.
Patterns can also be specialized and adapted for specific problem domains (e.g. genres). Zachary Simpson's collection of "Game Programming Patterns" [Simp1998] attempts to define a subset of patterns that dominate software engineering for games. Sometimes the need to differentiate patterns on distinct levels of abstraction leads to different labels: "One person's pattern can be another person's primitive building block" [Gamm1994]. Software engineers distinguish idioms, algorithms, techniques. Alexander's [Alex1977] maintains pattern sets for "Towns, Buildings and Construction". Doug Church's FADTs [Chur1999] are patterns in anything but name, as their description can be rewritten to fit a given pattern template.
Do Patterns work for game design?
Do patterns work? Do patterns work within a game design context? This question will ultimately be decided by each individual game designer's decision. Here are some potential issues with design method proposals based on patterns that are likely to surface during the roundtable discussion.
Patterns a fad
Within the software engineering community, patterns initially enjoyed what appeared to be a resounding success. Since then, the momentum seems to have been diffused to some extent. The software engineering community is well organized in conferences and workshops, some of which still dedicated partially or fully to the topic of patterns and pattern languages, however, patterns have hardly come to dominate the discourse. Alternative approaches (Use Cases, UML) have been introduced. Patterns are merely an addition to the "proliferation of object-oriented methods" [Mull1997]. It is possible that patterns have become popular for reasons unrelated to their actual utility, and that they will effectively be ignored at some point. It is also possible that the mere perception as a fad will turn out to be a self-fulfilling prophecy: that whatever inherent utility software engineering patterns might have, critical mass has not and might not be reached.
Pattern methods too formal
From the point of view of an artist, attempts to dissect, analyze, reduce, and formalize the profession are often perceived as an existential challenge. A certain degree of mysticism has been a job security device since the early days of shamanism, and the mechanism is still at work in professions in which performance, quality and efficiency is difficult to measure and quantify. Objections that have been raised in some way against literary theory, image composition, or even color theory, will be similarly be raised against any attempt to formalize game design. Creativity is commonly perceived as the brightest spark of what we consider the foundation of the human mind, by the analytically minded no less than by anybody who sees himself solidly rooted in the "other" of Snow's "two cultures". 
Consequently, many game designers will reject pattern based approaches as a delusional attempt to break down an organic whole into irrelevant smaller pieces, predicting "DIY" toolkits and "artificial designers" . For the freewheeling artistic mind, patterns, despite their lack of formal rigor, are already too strict a tool to capture or aid the true spirit of game design. 
Patterns not formal enough
To the engineer or mathematician, pattern languages do not seem impressive compared to the rigorous formal tools already available to them. A discipline like physics is unlikely to embrace methods that appear to be unfocused and arbitrary, too dependent on human language with all its connotations and hidden references. A formula exists in an ideal, abstract space that is not contaminated by the vagaries of the real world. In software engineering, a craft largely deprived of any meaningful ability to conclusively settle a dispute by a "question to nature" (an experiment) and with limited opportunities to employ the full power of formal logic and mathematical proof in the hands-on, day-to-day issues, patterns appear to be somewhat unprofessional, and are often perceived as a superficial means to talk about problems without making any actual progress in solving them.
Patterns too arbitrary
Initially, using a pattern language means little more than commitment to a specific form of expression. Deciding to accept the formal harness in which they are documented in no way predetermines the actual patterns themselves. Pattern methods seem deceptively simple, and often the ease with which the few formal requirements can be mastered is mistaken for ease of application: "Finding patterns is much easier than describing them" [ Gamm1994 ].
It is the process of refinement and documentation that takes time and discipline. The problem with a context like game-design is that it is so feature-rich, so close to the complexity of the real world our virtual realities try to resemble, that within the formal structure of a suitable pattern language, any number of patterns can be expressed. The less enforced a pattern seems by the very nature of the system we are trying to describe, the more conscious effort is required to test and verify the pattern is meaningful. Even within a shared formal harness, an agreed-upon method, the actual sets patterns and their ordering into groups and within hierarchies has to be debated. The same flexibility that allows us to use patterns to suit our specific needs also opens the door to fragmentation.
Patterns not invented here
Game design is a developing craft, in its early, exciting stages. Every participant is a pioneer, discovering new connections and laying foundations. Despite our borrowing excessively from other crafts (e.g. scriptwriting), there are legitimate questions to what extent methods derived in other, very different contexts (be it architecture or storytelling) could and should be applied to game design. However, any given method might also be rejected simply because it did not originate within the game design community. In many cases, it is not so much utility but acceptance that determines success. Having a method (any method) is still better than having none.
What are typical game design Patterns?
This section presents a few pattern candidates, it does not claim these to be actual pattern. The formal structure used to describe the pattern candidate is minimal. The examples are chosen to illustrate various issues, and not because of particular relevance for design. 
Proxy is a game design pattern candidate. There is a software engineering pattern with the same name [Gamm1994], however, there is no inherent connection. The example has been chosen to illustrate potential problems in using the same name for different patterns existing in different contexts. A similar case can be made for Simpson's Ethereal Void (see Privileged Move below). On the other hand, in some cases a given pattern language might translate into a sensible OOP implementation hierarchy, if there is a correspondence between the purpose of a given game design entity within the design context, and its implementation in the software that constitutes the game engine.
 Predictable Consequence is my rewrite of the formal abstract design tool (FADT) Perceivable Consequence introduced by Church [Chur1999]. Aside from changes to the description itself to refine its meaning (as I see it), this pattern candidate illustrates how FADTs can expressed as patterns.
 Paper-Rock-Scissors is a recurring game design device that may have been the first to be subject to formal attempts of definition [Craw1984], [Roll2000]. It can also be presented as a pattern. There is no new information in this rewrite, the existing knowledge has merely been reorganized to match the other examples. 
Privileged Move is a pattern proposal for a mechanism rarely discussed, but frequently used for a multitude of purposes. Note that a single device or object can serve as a solution to multiple problems, a situation that is not clearly addressed in pattern languages that emphasize the problem-oriented aspect of pattern use.
Proxy
 
 Problem: 	
 It might not be possible or desirable to require that a game action is applied to the target object directly. In other words, we have to avoid proximity to or collision with the ultimate target of a given action. 	

 Solution: 	
 Introduce another entity (object) that is used as a proxy, standing in for the target object. The proxy can be placed and moved independently of the target object or objects. The restrictions that apply to the target(s) do not by default apply to the proxy. Multiple proxies can be used for the same target or targets. 	

 Consequence: 	
 The link between the proxy and the actual target has to be communicated to the player, if the player is supposed to exploit this connection and indirection. Restrictions on placement of proxy and target with respect to player field of view, and restrictions on player view control might apply, to ensure that the player perceives the effect on the target. 	

 Examples: 	
 
 Munch's Oddyssee has several proxies for the player characters: the possession orb which enables Abe to take over other game characters (thus turning them into proxies), and the Snoozer robot and H-Crane, which served as proxies for Munch. One benefit of player character proxies is that of a safe death: loosing a proxy does not end the game. 
 Buttons/Switches/Levers that open doors or start/stop machinery are often placed in different locations, instead of being part of the target object. In these cases, the designer wants to separate trigger from target to permit more elaborate puzzles. 
 Half-Life's final boss had a vulnerable location inside its head. That vulnerable spot could be considered a proxy for the entire (invulnerable) boss. As a second order vulnerability, the boss was dependent on three crystals that supplied energy for healing and attack. Attacking the crystals destroyed them, thus permitting effective attacks on the boss monster itself. 	

Predictable Consequence
 
 Problem: 	
 The player has to perceive failure as a consequence of her mistakes, not as a random or predestined event unrelated to, and unavoidable by, any reasonable choice of actions on her part. 	

 Solution: 	
 The player can not take a meaningful decision to act (or not to act) if the result of a possible action can not be anticipated. A meaningful player decision is an informed decision: she has to be able to guess the result of her action before she ever takes it. Choose game mechanisms that communicate predictable behavior by visual appearance relying on knowledge the player already has (either from real world experience, or from experience with other games, or from experience with preceding parts of your game). Do not break consistency of your visual language, i.e. make sure that objects that behave identical look identical. 	

 Consequence: 	
 
 It is no longer possible to implement surprises that are impossible to anticipate. The player might rely on the out-of-context assurance to anticipate the designer's ambush, and either outwit the designer, or find herself locked into performing an action against her better judgment as the designer has prevented alternative courses of action. Ultimately, the designer might arrange for actions that the informed player will never perform, as they are predictably to her disadvantage. 
 The designer might have to go to considerable length to communicate the rules that govern the outcome of actions, to the player. The design might be biased towards using mechanisms resembling real world objects, to minimize the need for explanations. A lack of uncertainty on the player's side makes the game more transparent, potentially removing the need for exploration and experimentation. Ultimately, the need for Predictable Consequence is determined by the need for backtracking (severity of failure) and costs of backtracking (latency between choice and consequence, see also behavioral science on timing issues). 
 Another possible consequence is that the design might have to restrict itself to a smaller set of player actions, in order to be able to enable them consistently throughout the game world. Actions only available once or in a very few locations do not amortize the costs of communication and teaching/learning on the designer's/player's part. The design might also have to exaggerate the differences between distinct objects to avoid ambiguities. Any kind of variation or range has to follow rules that can easily be observed and complied with. 	

 Examples: 	
 
 Mario 64 [Chur1999]. Any game with a consistent physics approximation, e.g. the common ballistic or bouncing grenades in FPS games. Crates and barrels that are marked as explosive and do explode. Fireballs thrown at the player that hurt when hitting. Fire that damages, water in which you drown if you do not swim, lava that will kill. 
 Counter-examples are plentiful: switches and buttons that say "Push Me" to unleash a necessary ambush (an ambush that also opens the only way to move on) anticipated only as such. Openings in which to jump without knowing what is on the other side (Opposing Force, Ico): this is often a necessity imposed by the level partition/transition mechanism the engine uses. 	

 References: 	
 History: Doug Church [Chur1999] introduced the concept of perceived/perceivable consequence, which he uses also do describe predictable outcomes. There is a difference between the requirement for immediate feedback that the player can connect to her actions, and the requirement that the player has to have a chance to anticipate the likely outcome of her action. This pattern was derived from the latter, the former would require another pattern. 	

Paper-Rock-Scissors
 
 Problem: 	
 Avoid a dominant strategy that makes player decisions a trivial choice. 	

 Solution: 	
 Introduce nontransitive relationships within a set of alternatives, as in the game of paper-rock-scissors. 	

 Consequence: 	
 The player is no longer able to find a single strategy that will be optimal in all situations and under all circumstances. She has to revisit her decisions, and, depending on the constraints imposed by the game, adjust to changing situations, or suffer the consequences of an earlier decision. 	

 Examples: 	
 
 The example given by Rollings [Roll2000] is the set of warrior-barbarian-archer from the Dave and Barry Murray game "The Ancient Art of War" (Broderbund 1984). Rollings also describes Quake's weapon/monster relations in similar terms: Nailgun beats shambler, shambler beats rocket launcher, rocket launcher beats zombie, zombie beats nailgun. 	

 References: 	
 History: Crawford ( [Craw1984], in the section entitled "Triangularity") provided the first explicit description of the use of nontransitive relationships. Rollings [Roll2000] provides discussion of examples including payoff matrices in terms of game theory as well as informal fictional "designer dialogs". 	

Privileged Move
 
 Problem: 	
 Sometimes a given game entity cannot be permitted to interfere with others, or other entities cannot be permitted to interfere with it. 	

 Solution: 	
 Game entities can be protected by introducing exclusive moves and locations that cannot be entered or left without being able to perform the move in question. By introducing different, separate spaces or media, the game environment is broken down into areas that can serve as safe zones or safe passages. 	

 Consequence: 	
 Depending on the implementation, this can be a very heavy-handed way to ensure protection. Unless protection is implemented in a way that is at the player's disposal (a door that only she can open and close), the player might perceive the constraint as annoyance and disappointment. If the restriction is meant to be temporary, the mechanism to allow it to be lifted has to be communicated to the player, and initiated by her. 	

 Examples: 	
 
 In DOOM, monsters could traverse acid pools, but the player could only at the expense of damage that quickly turned to be lethal. 
 In Half-Life and Halo, enemy soldiers can be dropped from flying vehicles, a transportation mechanism not available to the player, and impossible to interfere with. Half-Life also had a spider-like boss that was capable of breaking through its own nets, which blocked the player's way until she forced the monster to retreat. 
 In Thief, the player traverses rooftops in relative safety, permitting preview and outlook on the level bottom. 
 In Ico, the ghostly opponents traverse the world in a different dimension, and emerge from portals without apparent restriction. 
 In Munch's Oddyssee, water was inaccessible to enemies, providing one player character a privileged swim move and safe passage (in the absence of snipers and mines). In many games, water enemies are in turn restricted to that medium (e.g. Quake, Half-Life). 
 In many games flying opponents (e.g. the harpies in Heretic 2) can perform moves the player cannot, and thus enjoy some amount of safety. 	

Bibliography
[Alex1964]  Christopher Alexander Notes on the Synthesis of Form Harvard University Press 1964, 1966, 1971, 1979 ISBN 0-674-62750-4 (cloth) ISBN 0-674-62751-2 (paper) 
[Alex1975]  Christopher Alexander , Murray Silverstein , Shlomo Angel , Sara Ishikawa , and Denny Abrams The Oregon Experiment Oxford University Press 1975 ISBN 0-19-501824-9 
[Alex1977]  Christopher Alexander , Sara Ishikawa , Murray Silverstein , Max Jacobson , Ingrid Fiksdahl-King , and Shlomo Angel A Pattern Language: Towns, Buildings, Construction Oxford University Press 1977 ISBN 0-19-501919-9 
[Alex1979]  Christopher Alexander Oxford University Press 1979 The timeless way of building ISBN 0-19-502402-8 
[Appl2000]  Brad Appleton Patterns and Software: Essential Concepts and Terminology Last update: Feb. 2000 See: http://www.enteract.com/~bradapp/docs/patterns-intro.html 
[Chur1999]  Doug Church Formal Abstract Design Tools See: http://www.gamasutra.com/features/19990716/design_tools_01.htm 
[Chur2000]  Doug Church Abdicating Authorship: Goals and Process of Interactive Design GDC 2000, San Jose, Lecture 5403 (not in proceedings). 
[Craw1984]  Chris Crawford The Art of Computer Game Design, chapter 6: Design Techniques and Ideals 1984 See: www.vancouver.wsu.edu/fac/peabody/game-book/Coverpage.html 
[Dunn2000]  Troy Dunniway Using the Hero's Journey in Games Gamasutra 1999 Originally Game Developer Magazine, Aug 1999 See: http://www.gamasutra.com/features/20001127/dunniway_pfv.htm 
[Gamm1994]  Erich Gamma , Richard Helm , Ralph Johnson , and John Vlissides Design Patterns: Elements of Reusable Object-Oriented Software Addison Wesley Longman, Inc. 1994 ISBN 0-201-63361-2 
[Heck2000]  Chris Hecker and Zachary Booth Simpson Game Programming Patterns & Idioms CMP Sep. 2000 Game Developer Magazine. Introduction to a column maintained until the Feb 2001 issue. 
[Hops2001]  John Hopson Behavioral Game Design Gamasutra April 2001 See: http://www.gamasutra.com/features/20010427/hopson_pfv.htm 
[Laur1991]  Brenda Laurel Computers as Theatre Addison Wesley Longmasn, Inc. 1991, 1993 ISBN 0-201-55060-1 (paper) 
[Lebl2000]  Marc LeBlanc Formal Design Tools: Emergent Complexity, Emergent Narrative GDC 2000, San Jose, Lecture 5304 (not in proceedings). 
[Mesz]  Gerard Meszaros and Jim Doble A Pattern Language for Pattern Writing See: http://hillside.net/patterns/writing/patternwritingpaper.htm 
[Mull1997]  Pierre-Alain Mueller Instant UML Wrox Press, Ltd. 1997 ISBN 1-861000-87-1 
[Pryo1999]  Karen Pryor Don't shoot the dog! Bantam Doubleday 1999 ISBN: 0-55338-039-7 (revised paperback edition) 
[Roll2000]  Andrew Rollings and Dave Morris Game Architecture and Design The Coriolis Group 2000 ISBN 1-57610-425-7 
[Roll2002]  Andrew Rollings and Ernest Adams Patterns in Game Design Coriolis To be published May 2002 ISBN 1-57610-873-2 
[Sane1995]  Aamod Sane The Elements of Pattern Style Dec. 1995 See: http://choices.cs.uiuc.edu/sane/elem.pdf 
[Shlk1990]  Viktor Shklosvsky Theory of Prose Dalkey Archive Press 1990, 1991 ISBN 0-916583-54-6 (cloth) ISBN 0-916583-54-6 (paper) 
[Simp1998]  Zachary Booth Simpson Design Pattern for Computer Games 2000 CGDC Austin, TX, Nov 1998, also San Jose, CA, May 1999. See: http://www.totempole.net/patterns/gamepatterns.html 
[Vlis1996]  John Vlissides Pattern Hatching - Seven Habits of Successful Pattern Writers C++ Report Nov/Dec 1996 See also: http://hillside.net/patterns/papers/7habits.html, and "Pattern Hatching: Design Patterns Applied" (Addison Wesley, 1998) 
[Vogl1998]  Christopher Vogler The Writer's Journey: Mythic Structure for Writers Michael Wiese Productions 1998 ISBN 0-941188-70-1