At the Game Developers Conference this week in San Jose, two roundtable discussions  will be dedicated to the topic of "game design methods" - that is, methods for planning and defining gameplay. To set the stage, this article presents a cursory overview of past and present efforts to define structured, formal game design methods. Some of the proposals referenced here were originally started several years ago, others were conceived as recently as a few months ago. This survey does not claim to be complete, and introductions to efforts not presented here will be welcomed to the GDC roundtables.
The Aim Of Game Design Methods
Compared with the vast body of operational knowledge found in the world of filmmaking, the game design community is just beginning to articulate the concepts and techniques specific to our medium in order to establish methods of game design. What should we expect of a game design method? To borrow from Doug Church , game design methods should:
- Relate to game design. The method has to be applicable to the actual interaction structure and mechanics of a game, not to concerns related to marketing, production, or management. This restriction is debatable (as it is easily violated), but it does define the scope of this article as well as the roundtables. While methods addressing the development process and its constraints are certainly needed (whether or not their substance is specific to games), they are not considered "design methods".
- Have utility - it should be a "tool". A method has to be more than just a list of concrete examples or a definition of a building block. A method involves a procedure, a step-by-step recipe, at least parts of which can be applied by simple, even automatic repetition. In particular, it should address specific and concrete issues occurring during the design stage of game development.
- Be abstract. A method has to apply to a large, presumably infinite number of game situations or instances. The actual level of abstraction can vary (e.g., genre-specific, or applicable to any interactive medium, etc.) but it has to be at least one step removed from the concrete instance (game or game element).
- Be formalized. A method needs some degree of formal structure, some amount of specific organization. Typically this consists of a template structure used repeatedly to contain information. Rollings' use of fictional dialog and anecdote  and Rouse's reliance on interview  are examples of forms found outside the context of game design.
This article focuses on design - how to plan and define gameplay, and how to make it work. As such, process and production methods are beyond the scope of this discussion. According to Cerny , design is properly part of the pre-production stage. In comparison, most of the conceptual work of movie making is performed before the actual shooting begins, relying on tools such as script and storyboard that have also been applied to game production. To progress beyond adoption, game designers have to ask:
- What are the equivalents of script or storyboard for game pre-production?
- To what extent are such movie-making methods applicable to making games?
- How can movie-making methods be adapted to fit the design of interactive games?
Campbell's "Hero's Journey"  is the most prominent example of an abstract framework which, established in the movie industry, has been discussed extensively with respect to its applicability to games. Freeman  proposes using his approach to scene and dialogue construction for game scriptwriting, while others refer to Polti .
Possibly the earliest attempt to define a game design method is the game design document. Church's suggestion of "Formal Abstract Design Tools"  in 1998 marks an early explicit demand for a shared vocabulary. It was also the introduction to conceptual tools specific to game design problems. Hal Barwood's "400 Rules", introduced at GDC 2001 , led to the "400 Project" spearheaded by Noah Falstein (whose quest for "Fundamental Principles of Interactive Entertainment" dates back at least to 1996 ).
Derivatives of Alexandrian "patterns" have been proposed by several authors (see [17,19] for recent efforts). The latest addition to this line-up is the "Lexicon Project", an effort hosted at the University of Texas in Austin . These examples of game design methodologies will be summarized briefly, opening the door for further discussion at the GDC Roundtable .
Game Design Documents
The design document (or "Design Bible Method") is a common attempt to organize the development process. On the surface, it is a standard method (there is consensus that some amount of documentation is always needed), yet the details a design document should contain are often debated. To be considered a method, the proposal has to specify what type of information to include, how to organize that information, and how to maintain it. Additionally, questions of revision control and editing privileges must be addressed. The design document approach has been rejected by some (e.g. ). Taken to its extreme, it is often found unworkable. Detailed recommendations (such as ) on game design document structure might ultimately be self-defeating: by adding more details to the prescription, the maintenance overhead is only increased. In practice, it appears that primarily the smaller design documents used in the early stages of the development process, i.e. treatments and outlines, are the most helpful application of the design document approach.
On some level, most discussions about game design methods can be considered part of a discourse on how to write a design document. Methods are tools used to extract, identify, refine, and organize knowledge. They should encourage introspection and observation, and turn reactive choice into conscious, proactive planning decisions. Game design is typically a process of iterative refinement , and documenting intermediate results is an inherent part of any such refinement process. Methods help us improve the process, and propose ways to organize the results. In that sense, many methods are specific recommendations on how to write parts of a design document.
If we had a unified, ultimate design document template, it would likely resemble some kind of spreadsheet or document template full of empty fields, each field named and clearly labeled as to what type of information was to be inserted, with pull-down menus enumerating design choices and checkboxes to list options. A typical sample of this treatment or outline template offers exactly that. The archetypical design document can thus be seen as a form into which the designer fills in the details of a given design-in-progress. The document's hierarchical structure embodies a decision tree, which, once all branches are traversed, places the designer in a leaf representing his game. In other words, design document templates are a structured way of asking the designer questions, thereby forcing decisions.
It is certainly possible to implement structured queries as software tools, even with off-the-shelf text editing software (DTDs and XML schemas, i.e. structured editing through XML). It is even possible to conceive documents that incorporate spreadsheet-like elements to ensure consistency and help you visualize the consequences of design (e.g., score/balancing) decisions. The problem with the structured query approach is that it attempts a single top-down solution at a time when game design as a craft is lacking both overarching concepts and complete foundation.
Furthermore, the structured query approach is sequential, which does not suit well a game development process based on prototyping, iteration and progressive refinement. Capturing document iterations by revision control raises issues of depth of the revision history. For production purposes, only the most recent change is relevant. There are also issues of granularity: for most team members, the decision itself and its immediate implications are more relevant than annotation capturing objectives and concerns, or rejected alternatives. This explains why structured query by design document templates seems to work better for treatments than outlines, and better for outlines than full reference documents. Issues of granularity might be resolved to some degree using marked sections and other means to create partial renderings of a unified document. However, given the complexity of the document maintenance task, it is possible that design documents approach cannot be taken much further. It is possible that design document structures for production use simply do not exist outside specific domains, such as certain well-understood game genres.
However, the concept of structured query is important, even if one rejects the attempt to create any kind of unified structure. To preserve the concept of structured query in the absence of such a unified top-level structure, methods are needed to conduct design analysis piecemeal, discussing specific design concepts in isolation. Ideally, such methods will enable the designer to make connections between such isolated concepts for purposes of design by composition, as well as to progress from building blocks to higher levels of abstraction.
Discourse by Anecdote
The collection Game Design Perspectives is the most recent example of discussing game design with minimal formal constraints. One of the earliest examples is Chris Crawford's Art of Computer Game Design. In these and similar texts, game design experience is presented as a narrative, e.g., as a series of anecdotes and invented dialogs , sometimes as recommendations derived from interviews , or simple as annotated transcript .
The narrative, anecdotal representation of knowledge is the predecessor of Alexandrian patterns. Thus Alexandrian patterns appear intuitive and accessible without prerequisites in training or adherence to strict form. Typically, a particular insight is described as a specific incident or concrete example. The rules of the 400 project also attempt capture concrete experience as instruction. The most common problem with anecdotes is that they do not lend themselves to placing individual insight into a context of established knowledge. Anecdotes often don't use existing terminology, or worse, they redefine established terms.
For example, Crawford describes non-transitive relationships between game units as both "triangularity" and "asymmetric relationship". The term "asymmetric game" (see also [22,30]) is often used referring to other concepts. Essentially, Crawford and also Adams discuss which payoff matrices for unit-unit encounters deny the player a "dominant strategy". A matching "400 Rule" formulation would be "Prevent dominant strategies". Rollings  presents the game theory analysis of "dominant strategy" in some depth. This analysis dates back to 1944 , yet discussions of game design rarely make references to game theory explicit, or employ established terminology and notation. This appears to be a natural consequence of the anecdoctical form. Clearly, while anecdotes are a natural choice to begin the game design discourse, the time has come to advance beyond this form.
Formal Abstract Design Tools
In 1999, Doug Church proposed  a more specific approach that he called "Formal Abstract Design Tools" (FADT). As he described, "formal, implying precise definition and the ability to explain it to someone else; abstract, to emphasize the focus on underlying ideas, not specific genre constructs; design as in [game design]; and tools since they will form the common vocabulary [needed as an instrument for design]". Church presented a comparative analysis of aspects of several games, and presented three FADT examples:
- INTENTION: Making an implementable plan of one's own creation in response to the current situation in the game world and one's understanding of the game play options.
- PERCEIVED CONSEQUENCE: A clear reaction from the game world to the action of the player.
- STORY: The narrative thread, whether designer-driven or player-driven, that binds events together and drives the player forward towards completion of the game.
Here, INTENTION is just a definition of a factor to be taken into account: the player's ability to plot and plan independently. PERCEIVED CONSEQUENCE comes closest to a concept or rule (e.g. "Ensure the Player Perceives Consequences of Her Actions"). Introducing STORY, a term burdened with implications and connotations, by mere re-definition ignores the complexity of narrative concepts. Church even articulates explicit reservations on narrative structures in games in his article; hence the reference to "player-driven narrative thread[s]" not further specified. STORY, presented as a tool, would amount to a recommendation like "Define a narrative thread to guide the player". By not clearly separating the idea of a vocabulary from that of methods, Church seems to restrain himself to definition instead of recipe. "Tool" describes devices of intervention as as instruments of observation.
Indeed, Church's FADTs are more than just mutually agreed upon definitions of game design terms. PERCEIVED CONSEQUENCE is not only specific to interactive media, it also lends itself directly to explicit implementation requirements. Further examples can be harvested from the "Game Design Lexicon" forum (, no longer accessible) that Gamasutra hosted following the electronic reprint of the original Game Developer magazine article. In 1999, at least 25 terms were submitted by almost as many contributors:
DETERMINISTIC FINITE OPPONENT
EVENT BASED MUSIC
FORMAL ABSTRACT DESIGN TOOL
GLOBALLY CONSISTENT RESPONSE
NONDETERMINISTIC FINITE OPPONENT
PARALLEL INTERFACE ANIMATION
RULE OF LOGIC
UNIVERSALLY ANTICIPATED RESPONSE
WILLING SUSPENSION OF DISBELIEF
Some of these terms are synonyms, a few cross-referenced other terms, and several were related to software implementation (illustrating the problem of separating design concept from implementation issues). The fact that these submissions existed on varying levels of abstraction and within different contexts is a natural consequence of performing a query within a "lexicon" template structure. The choice of "lexicon" instead of "tool" was a natural consequence of the way Church originally introduced FADT. Others entries, like GLOBALLY CONSISTENT RESPONSE (and its synonym submitted as HOMOGENEITY), are clearly conceived to match PERCEIVED CONSEQUENCE, and share its quality. CONSISTENT RESPONSE is at the core of Harvey Smith's description of systemic level design , yet Smith never explicitly defines systemic design as a FADT. Randy Smith (like Doug Church and Harvey Smith, a designer at Ion Storm) in his GDC 2002 presentation  of "Analog Interaction Structures" (and its presumed opposite, "Discrete Interaction Structures") explicitly calls the concept of analog interaction structures an "analytical tool…for deconstructing [stealth gameplay] in Thief", but does not introduce the concept as a FADT, once referring to it as "data analysis tool" instead.
If one considers Church's FADT proposal an attempt to introduce a specific form and overarching principle to game design methods, it seems that the instrumental notion of "tools" has outlived both FADT and its complement, the "game design lexicon". Definitions are instruments only in the most abstract sense; why not aim for recipes, procedures, or instructions?
The 400 Project: Rules
Hal Barwood (left) and Noah Falstein deliver their lecture "More of the 400" at the 2002 Game Developers Conference.
Hal Barwood, in his GDC 2001 presentation "4 of the 400"  proposed representing game design experience as a series of rules. Subsequently, Noah Falstein and Barwood initiated the "400 Project", introduced in Falstein's "Better By Design" Game Developer magazine column and in the duo's "More of the 400" presentation at GDC 2002 .
The project has progressed steadily since March 2002, averaging about one rule per month. The rules published so far (months refer to print issues, also see the 400 web pages ):
1. "Fight player fatigue" (Barwood, GDC 2001)
2. "Maximize Expressive Potential" (Barwood, GDC 2001)
3. "Maintain Level of Abstraction" (Barwood, GDC 2001)
4. "Concretize Ideas" (Barwood, GDC 2001)
5. "Provide Clear Short-Term Goals" (Barwood/Falstein/Horneman, GDC
2002, also March 2002)
6. "Identify Constraints" (Barwood/Falstein, GDC 2002)
7. "Maintain Suspension of Disbelief" (Barrett, GDC 2002, also May 2002)
8. "Emphasize Exploration and Discovery" (Barwood/Falstein, GDC 2002)
9. "Let Player's Turn the Game Off" (Barwood/Falstein/Geist, GDC 2001, again July/Sep/Nov 2002)
10. "Build Subgames" (Barwood/Falstein, GDC 2001)
11. "Provide Parallel Challenges with Mutual Assistance" (Falstein, April 2002)
12."Distribute game assets asymmetrically" (Falstein/Weidemann, August 2002)
13."Begin at the middle" (Falstein, Oct 2002)
14."Make the game fun for the player, not the designer or computer" (Falstein/Meier, Dec 2002)
15."Make the effects of the AI visible to the player" (Falstein, Jan 2003)
16."When simulating a real system, use real-world formulas and cheat as little as possible" (Falstein, Jan 2003)
17."Add a small amount of randomness to your AI calculations" (Falstein, Jan 2003)
20."Create the AI in the mind of the player through suggestion" (Falstein, Jan 2003)
21."Don't take away points or other hard-won possession from the player" (Feb 2003)
For clarity, "Rules" or "400 Rule" refers to rules published as part of the "400 Project", while lower-case "rules" will refer to the general concept of representing design insights in the formulation of a rule. The Rules published so far focus on content design and avoid production issues (such as "develop the hardest part first" or "throw away the first level you do"). Barwood and Falstein define a clear structure for Rules [10,14]:
1. A concise, imperative statement of the rule
2. Its domain of application
3. Rules that it trumps (over which this rule takes precedence)
4. Rules that it is trumped by
5. Examples of following and counter-examples of not following the rule.
Barwood and Falstein state : "Rules are tools... Rules are instructions: reasonably concrete, can be consciously followed, can be broken and ignored...". Particular emphasis is given to precedence among rules and how rules trump one another. Trumping defines a bi-directional web of precedence between individual rules, a solution that does not scale well. From a maintenance and editing point of view, the alternative would be to codify trumping as explicit meta-rules in "Rule A trumps Rule B" statements.
Falstein further discusses  Rules as a method, describing game design as a process of iterative refinement that requires knowledge of human nature. Consequently, Rules are inspired from linguistics, "avoiding potentially rigid software engineering techniques as the template for game design". The assertion that "Rules can be bent, others can be broken..." would defeat the assertive, authoritative choice of imperative rules in the absence of explicit trumping hierarchy. Falstein writes: "Rules are tools that provide instructions to the designer, not just observations on the nature of what has been done previously. To be most useful, they must be reasonably concrete and aimed at practical use, not pure academic discourse." A similar point from a later installment  formulated a rule about rules: "Use common sense when applying rules".
While new rules have been introduced steadily, the revision and refinement of existing rules has not been systematic. Perhaps the 400 Rule to receive the most thorough peer review so far is "Let Players Turn the Game Off". Most of the peer discussion has focused on trumping. "Name That Trump" ) observes that trumping rules are sometimes implied by the recognition that counter-examples to a rule exist. The issue of whether or not Rules are limited by a scope defined through design objectives is still open. Rules apply within specific contexts, but the 400 Rule does not make that context explicit. The concept of scope is not to be confused with the Rule definition of "domain".
Alexandrian patterns originated in architecture and have since been successfully applied in more rigid domains such as software engineering (see  for an overview). At its core, a pattern is a template structure in which experiential knowledge is entered. Like the 400 Rule format, pattern templates preserve the idea of structured query, yet by themselves lack the unified global structure implied by the design document method. Alexandrian patterns incorporate a mechanism resembling trumping, as they attempt to capture side effects of, and interactions between, patterns in annotation sections. The notion of hierarchy is inherent to pattern formats, as new patterns can be defined by combining two or more existing ones. Pattern languages appear to offer a roadmap to arrange individual patterns within a higher level structure, however, pattern languages beyond a mere collection of patterns are a complex topic best considered separately. Examples of pattern published so far (see ) include the following:
The Lexicon Approach
Rules, patterns and FADT require definitions - a vocabulary. Without definitions specific to game design, statements about game design are restricted to terms not specific to game design. In other words, in the absence of a game design vocabulary, rules and patterns will describe games using terminology borrowed from other media. "SUSPENSION OF DISBELIEF"  is a good example of this.
Patterns, rules and FADT alike exhibit in varying degrees the capacity to bundle a name, definition, and implementation description. Consequently these forms could be specific even in the absence of a shared vocabulary. The risk, however, is a growing set of increasingly disconnected rules, patterns or FADT that establish different and even contradictory definitions within each individual scope. Thus patterns, rules etc. cannot replace definitions, even if they could theoretically serve as a means of definition. The problem is that patterns, rules and FADT themselves are not by default definitions, and that the attempt to use them as such biases the designer to create, say, a pattern where just a simple definition is needed . Methods are no replacement for a shared vocabulary. Every pattern or rule can define a part of a vocabulary, but not every vocabulary term is a pattern, or warrants its own rule.
The earliest demands (e.g. [4,5]) for improvements in game design called for a shared vocabulary - a dictionary of game design terms. The game design community is taking the first steps taken to names concepts and mechanisms. Collecting these terms and organizing them into a coherent whole is the objective of the recently begun "Game Design Lexicon" project . The collaboration between multiple institutions is hosted by IC² and headed by Patrick Burkat, currently affiliated with the University of Texas in Austin. The lexicon project will deliver an HTML thesaurus and an XML compatible lexicon of a polyhierarchical vocabulary, distinguishing three user groups: video game production, game designers and developers, and players. The project relies on local focus groups and surveys, and ethnographic methods, taking another step towards a more commonly shared language of design. Efforts like the "Game Lexicon Project" close the circle: while a lexicon on its own will never suffice as a tool, it is the indispensable complement to any conceptual tool or method.
How do these three examples of game design methods -- FADTs, 400 Rules, and Patterns -- relate to each other? To what extent are they similar? The use of examples -- instances found in published games -- is the common denominator. However, our goal is to abstract from individual examples. We need a representation of knowledge that, to paraphrase, is "as abstract as necessary, but not more abstract". Taking abstraction too far simply deprives it of meaning. Examples are the empirical foundation, and relevant data is not just found in published games, but can also be drawn from usability testing, behavioral psychology, and the research literature on human-computer interaction.
Game design is an iterative process. Consequently, any structured query as exemplified by game design documents constitutes only the very first step. Each specific game design decision, each project-specific design statement is implicitly a challenge: Is this the best choice? What are the alternatives? Why is this solution preferred? The same principle of iterative refinement applies on the level on which we discuss design itself. By describing a mechanism (e.g., FILTER), by stating a requirement (PREDICTABLE CONSEQUENCE, SHORT-TERM GOALS), by defining a term (STORY), questions about limitations, consequences and alternatives are raised.
Even the methods themselves should be questioned and refined. Is the pattern format adequate for instruction? Can rules be observational? How do we address purpose within a problem-oriented representation? Can trumping capture scope or purpose? Can rules be conditional? Can design insights be derived from first principles, and can these also be represented as patterns, rules, FADT? What is the proper level of abstraction, and how do we maintain it? Do we need a method to identify building blocks? Do we need the top-down approach of unified design documents? How well does trumping scale with larger numbers of rules? Do patterns really accommodate detailed descriptions? These questions, and countless others, will have to be addressed as our methods progress and our ability to employ them improves. The "Game Design Methods" roundtable at the Game Developers Conference this week  will offer us another chance to advance towards better answers.
 Hal Barwood and Noah Falstein. "More of the 400: Discovering Design Rules" (GDC 2002 lecture) http://www.gdconf.com/archives/2002/hal_barwood.ppt
 Mark Cerny. "Method" GDCE 2002 Web Lecture http://www.gamasutra.com/features/slides/cerny/index.htm, also http://www.gamasutra.com/gdce/2002/mark_cerny.zip
 Doug Church. "Formal Abstract Design Tools." (Gamasutra, 1999. Originally Game Developer magazine, Vol 3, Issue 28, July 1999.) http://www.gamasutra.com/features/19990716/design_tools_01.htm
 Greg Costikyan. "I Have No Words & I Must Design". Originally published Interactive Fantasy #2, 1994. See http://www.costik.com/nowords.html
 Chris Crawford. The Art of Computer Game Design, Chapter 6: "Design Techniques and Ideals." 1984. http://www.erasmatazz.com/free/AoCGD.pdf
 Troy Dunniway. "Using the Hero's Journey in Games." Gamasutra, 1999. See http://www.gamasutra.com/features/20001127/dunniway_pfv.htm
 Noah Falstein. "Interactive 'Show, Don't Tell': Fundamental Principles of Interactive Entertainment", 1996. See http://www.theinspiracy.com/ArShowDT.htm
 Falstein, "The 400 Project" website. See http://www.theinspiracy.com/400_project.htm.
 Georges Polti. "The Thirty-Six Dramatic Situations" (translation). The Writer, Inc., Boston, 1916, 1917, 1921, 1931, 1940. See http://harris-donahue.tripod.com/harrisdonahue/id15.html
 Jussi Holopainen and Staffan Bjork "Computer Game Design Patterns", workshop at Computer Games and Digital Cultures Conference, June 6-8, Tampere, Finland. http://www.gamesconference.org/pf_workshop.html
 Jussi Holopainen and Staffan Bjork", "Game Design Patterns", upcoming GDC 2003 lecture with Bernd Kreimeier, See https://www.cmpevents.com/GDx/a.asp?option=3&V=11&SessID=796
 Bernd Kreimeier, "The Case for Game Design Patterns" See http://www.gamasutra.com/features/20020313/kreimeier_pfv.htm
 Bernd Kreimeier (moderator): IGDA Roundtable on "Game Design methods", GDC 2003. Thursday https://www.cmpevents.com/GDx/a.asp?option=3&V=11&SessID=489 and Saturday https://www.cmpevents.com/GDx/a.asp?option=3&V=11&SessID=910
 Harvey Smith, "Systemic Level Design", GDC 2002. http://www.gdconf.com/archives/2002/harvey_smith.ppt
 Randy Smith, "Design Fundamentals of Stealth Gameplay in the Thief Series", GDC 2002. http://www.gdconf.com/archives/2002/randy_smith.ppt
 Warren Spector, Patrik Burkat, Aaron Thibault, private communications, 2003.
See http://www.ic2.org/ for more information on IC².
 Ernest Adams, "A Symmetry Lesson". Gamasutra, October 1998.