Gamasutra.com Game Design Document

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:

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 [22] and Rouse's reliance on interview [29] 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 [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:

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



	Doug Church.

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.