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