Game design, like any other profession, requires a formal means to document, discuss, and plan. Over the past decades, the designer community could refer to a steadily growing body of past computer games for ideas and inspiration. Knowledge was also extracted from the analysis of board games and other classical games, and from the rigorous formal analysis found in mathematical game theory.

However, while knowledge about computer games has grown rapidly, little progress has made to document our individual experiences and knowledge - documentation that is mandatory if the game design profession is to advance. Game design needs a shared vocabulary to name the objects and structures we are creating and shaping, and a set of rules to express how these building blocks fit together.

This article proposes to adopt a pattern formalism for game design, based on the work of Christopher Alexander. Alexandrian patterns are simple collections of reusable solutions to solve recurring problems.

Doug Church's "Formal Abstract Design Tools" [11] or Hal Barwood's "400 Design Rules" [6,7,18] have the same objective: to establish a formal means of describing, sharing and expanding knowledge about game design.

From the very first interactive computer games, game designers have worked around this deficiency by relying on techniques and tools borrowed from other, older media -- predominantly tools for describing narrative media like cinematography, scriptwriting and storytelling.

Computer games are a visual medium, and game designers are increasingly relying on design techniques developed for movies - to the detriment of efforts to identify methods genuinely suited for game design. The discussion of narrative techniques has come to dominate the discourse on game design, almost extinguishing alternatives.

If the techniques borrowed from other media 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 usually insufficient (or even inadequate) to capture the essence of the interactive game medium.

The community is aware of this [12], although the response is often an attempt to reconcile the contradiction by redefining the term "narrative" [24]. Taken to the extreme of an artificial playwright [23], 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.

The game design pattern method proposed here is concerned with content patterns, as opposed to software engineering patterns [19], specializations of which that have been proposed for game programming [33,20]. Similarly, process patterns to organize and manage game development projects (such patterns could be extracted from [17,28]) are beyond the scope of this article.

What Are Patterns?

In a nutshell, patterns are simply conventions for describing and documenting recurring design decisions within a given context, be it game design or software engineering.

Specific patterns are the result of applying this method consistently, leading to collections of design patterns which have been assigned a name and are documented by an anecdotal or abstract description. Pattern methods provide semi-formal tools for problem domains in which rigorously formal methods cannot easily be applied, or are simply not available or even conceivable.

Patterns are traditionally expressions of problem-oriented thinking. The seminal book by Gamma et al., Design Patterns: Elements of Reusable Object-Oriented Software, quotes Alexander [3]: "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."

There can be several alternative solutions to a given problem, each one defining its own pattern, but the combination of problem statement and solution proposal is the essence of any Alexandrian pattern.

A game design pattern collection would provide a shared design vocabulary that allows experienced designers to:

• communicate efficiently with each other, with less experienced designers, and with members of other professions (like software engineers and game coders)
• document their insights, organizing individual experience as written knowledge
• analyze their own design as well as the designs of others, e.g. for purposes of comparative criticism, re-engineering, or maintenance

It is important to distinguish between pattern-based methods, which are very generic and general, and specific pattern collections created for a given purpose. The decision to use patterns merely determines form, not content. The conventions of any pattern template do not guarantee (or prohibit) that useful patterns will be found and documented. Pattern methods are simply a successful way to express existing knowledge.

A Pattern Template

Pattern templates typically contain these four essential elements:

1. Name. "Naming a pattern immediately increases our design vocabulary. It lets us design at a higher level of abstraction". Names have to be mnemonic and evocative, but the connotations also pose problems. "Also Known As", frequently part of pattern templates, is actually an indication of a naming problem: "Finding good names has been one of the hardest parts of developing our catalog" (again, Erich Gamma et al.).
2. Problem. This describes the problem, including its inherent trade-offs and the context in which the problem occurs. The description of the problem implies a goal that we want to accomplish, and the obstacles we encounter when we attempt to do so.
3. Solution. A description of 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.
4. Consequences. Each solution has its own trade offs and consequences. Solutions can, in turn, cause or amplify other problems. The costs and benefits of a solution should be understood and compared against those of alternatives before making a design decision. Around this essential core, pattern templates often add other elements, or subdivide a core element.
   
   Gamma et.al. uses Name - Intent - Aliases - Motivation - Applicability - Structure - Participants - Collaborations - Consequences - Implementation - Sample - Known Uses - Related Patterns . Meszaros and Doble describe pattern writing itself in patterns organized as Title - Problem - Context - Forces - Solution - Indications - Resulting Context - Related Patterns - Examples - Samples - Rationale - Aliases - Acknowledgements [25].
   
   Alexander et. al. use Name - Example as Picture - Context within larger patterns - Problem - Solution - Solution as Diagram - Relation to smaller patterns [3]. Ultimately, the details of the format chosen do not matter as much as the fact that one format has been elected and is used consistently (for more details on how to write patterns, see [31,34,5]).