Game Design Methods: A 2003 Survey

At the Game Developers Conference this week in San Jose, two roundtable discussions [20] 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 [4], game design methods should:

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 [3], 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:

Campbell's "Hero's Journey" [7] 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 [15] proposes using his approach to scene and dialogue construction for game scriptwriting, while others refer to Polti [16].

Possibly the earliest attempt to define a game design method is the game design document. Church's suggestion of "Formal Abstract Design Tools" [4] 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 [1], led to the "400 Project" spearheaded by Noah Falstein (whose quest for "Fundamental Principles of Interactive Entertainment" dates back at least to 1996 [9]).

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 [26]. These examples of game design methodologies will be summarized briefly, opening the door for further discussion at the GDC Roundtable [20].

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. [3]). Taken to its extreme, it is often found unworkable. Detailed recommendations (such as [8]) 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 [11], 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[21] 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[6]. In these and similar texts, game design experience is presented as a narrative, e.g., as a series of anecdotes and invented dialogs [22], sometimes as recommendations derived from interviews [23], or simple as annotated transcript [29].

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 [22] presents the game theory analysis of "dominant strategy" in some depth. This analysis dates back to 1944 [27], 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 [4] 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:

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 ([28], 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:

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 [24], 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 [25] 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, in his GDC 2001 presentation "4 of the 400" [1] 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 [2].

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 [14]):

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]:

Barwood and Falstein state [2]: "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 [11] 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 [13] 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" [12]) 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".

Patterns

Alexandrian patterns originated in architecture and have since been successfully applied in more rigid domains such as software engineering (see [19] 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 [19]) include the following:

Patterns were the focus of a workshop at the 2002 CGDC conference in Tampere [17]. Pattern approaches will also be presented at GDC 2003 [18].

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" [2] 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 [17]. 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 [26]. 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.

Open Questions

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 [20] will offer us another chance to advance towards better answers.

References

[1] Hal Barwood. "Four of the Four Hundred". (GDC lecture, 2001.)

[2] Hal Barwood and Noah Falstein. "More of the 400: Discovering Design Rules" (GDC 2002 lecture) http://www.gdconf.com/archives/2002/hal_barwood.ppt

[3] 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

[4] 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

[5] Greg Costikyan. "I Have No Words & I Must Design". Originally published Interactive Fantasy #2, 1994. See http://www.costik.com/nowords.html

[6] Chris Crawford. The Art of Computer Game Design, Chapter 6: "Design Techniques and Ideals." 1984. http://www.erasmatazz.com/free/AoCGD.pdf

[7] Troy Dunniway. "Using the Hero's Journey in Games." Gamasutra, 1999. See http://www.gamasutra.com/features/20001127/dunniway_pfv.htm

[8] Troy Dunniway. Professional Game Design. Originally scheduled to be published June 2002.

[9] Noah Falstein. "Interactive 'Show, Don't Tell': Fundamental Principles of Interactive Entertainment", 1996. See http://www.theinspiracy.com/ArShowDT.htm

[10] Noah Falstein. "Better By Design: The 400 Project". (Game Developer magazine, Vol. 9, Issue 3, March 2002, p. 26.)

[11] Noah Falstein. June 2002, "Better By Design: Game Design at GDC 2002" (Game Developer magazine, Vol. 9, Issue 6, June 2002, p. 30.)

[12] Noah Falstein. July 2002, "Better By Design: Turn-Offs", (Game Developer magazine, Vol. 9, Issue 7, July 2002, p. 24.)

[13] Noah Falstein, September 2002, "Better By Design: The Story So Far" (Game Developer magazine, Vol. 9, Issue 9, June 2002, p. 28.)

[14] Falstein, "The 400 Project" website. See http://www.theinspiracy.com/400_project.htm.

[15] David Freeman, "22 Secrets of Dialogue and Scene Flow". Proceedings CD ROM, GDC 2002.

[16] 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

[17] 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

[18] 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

[19] Bernd Kreimeier, "The Case for Game Design Patterns" See http://www.gamasutra.com/features/20020313/kreimeier_pfv.htm

[20] 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

[21] Francoise Dominic Larame's (ed), Game Design Perspectives, ISBN 1-58450-090-5, Charles River Media 2002.

[22] Andrew Rollings and Dave Morris. Game Architecture and Design. (The Coriolis Group, 2000.) ISBN 1-57610-425-7

[23] Marc Saltzman (ed), Game Design - Secrets of the Sages, 2nd edition., ISBN 1-56686-987-0, Brady Publishing, Macmillan 2002.

[24] Harvey Smith, "Systemic Level Design", GDC 2002. http://www.gdconf.com/archives/2002/harvey_smith.ppt

[25] Randy Smith, "Design Fundamentals of Stealth Gameplay in the Thief Series", GDC 2002. http://www.gdconf.com/archives/2002/randy_smith.ppt

[26] Warren Spector, Patrik Burkat, Aaron Thibault, private communications, 2003.
See http://www.ic2.org/ for more information on IC².

[27] J. Von Neumann and O. Morgenstern, Theory of Games and Economic Behavior, Princeton Univ. Press, 1944.

[28] "Game Design Lexicon", Forum at Gamasutra.com, 1999-2002, defunct.

[29] Richard Rouse. Game Design: Theory & Practice. (Wordware, Inc., 2000) ISBN 1-55622-735-3

[30] Ernest Adams, "A Symmetry Lesson". Gamasutra, October 1998.
http://www.gamasutra.com/features/designers_notebook/19981016.htm