     |
 |
 |
 | | | | |
 |
|||
 |
||||||
          |
 |
 |
||||
|
Game Design Methods: A 2003 Survey 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. 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].
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Features
|
|
|