You are on page 1of 85

An Illustration of Applied Ludology

How are Game Design Methods Applied to Game Development?


For

Game Design and Development


Authored by
Micah M. Hrehovcsik

Thesis Guidance
Joost de Wert

GDD-EMMA
August 28, 2006
Version 2.0

Hogeschool voor de Kunsten Utrecht


Faculteit Kunst, Media, & Techologie
An Illustration of Applied Ludology:
How are Game Design Methods applied to Game Development?

Forward

When man first went to sea, he followed the coastlines to be safe. Later he was
equipped with experience of those first sailors, tools for navigation and methods for knowing
his position on the open sea. Mankind was now able navigate anywhere in the world without
the sight of land. This analogy resembles my attitude towards the usage of game design
methods. By using and learning from methods, anecdotes, rules, guidelines, models and the
processes used by our game design predecessors, we can create the confidence to design
games with the freedom to explore game design as we choose.
What are game design methodologies? How are they applied to game design and
development? How do they benefit the game designer? My first introduction to game design
methodologies was the result of reading Bernd Kreimeier’s article Game Design Methods: A
survey 2003 for the Level and Game Design course taken during my second year study in
Game Design and Development at the HKU (Hogeschool voor de Kunsten Utrecht). The
concept of game design methods was intriguing to me at this time, especially because this
meant there was more to game design than design by trial and error. Further more this meant
that we could stop reinventing the wheel or trying to create half baked concepts about game
design and the game design process.
My first step to creating my own process started with my own game design document
template based on researching a variety of game design documents including the game
design document template created by Chris Taylor in use of the game Dungeon Siege.
[ihfsoft.com, 2006] The creation and research of my own game design document template
eventually led to my internship at Overloaded, a mobile game development studio, where I
completed my own game design document template as well as a game design document
template tailored for Overloaded’s mobile games. I was eventually employed at Overloaded
as their game architect. At Overloaded, the game development process lasts between two to
four months; because of the short development time, I have had the opportunity to streamline
my game design process repeatedly. Each development cycle has allowed me numerous
times adjust my processes and usage of methodologies.
I have also been involved in successful and unsuccessful projects during my study at
the HKU. These game development processes have become my sandbox for experiencing
applied ludology and the reason I support the usage of game design methods. The first full
fledge project that I was involved in was the development of a game for B.I.G. (Ban Illegal
Games & Software). I participated as the lead game designer and level designer. This project
was to broaden my understanding of level design methods, playtesting and balancing. The
experience of dealing with these processes was to cement my choice to further research
game design methods. This research was then applied to writing my first paper Current Game
Design Methodologies: Finding a new approach for my study at the HKU. It was through this
paper that I first began to realize that these rules, guidelines, models, methods and processes

i
An Illustration of Applied Ludology:
How are Game Design Methods applied to Game Development?

offered a game designer the most basic tools to create an approach to game designing thus
saving a young game designer (such as myself) learning game design from scratch.
In my last year of study at the HKU and through the EMMA two projects have defined
graduate study. The first project was the game development for a prototype hardware
developed by Philips. Our student team ‘Vonk’, created a methodology we used to solve
issues encountered with the cabal process during concept phase of the project. The tool
referred to in this thesis as the game design and development scope model; is a method
based on a context and content analysis model which was presented by Willem-Jan Renger
and Aukje Thomassen. This method proven its self successful enough I have now reused
again in this exegesis project.
The MMOG (Massive Multiplayer Online Game) Bounty Kings is the exegesis’s game
development that is coupled with this thesis to create my graduate exegesis. The game
design Bounty Kings has been developed under considerable attention to the usage of game
design methods. This thesis is meant to illustrate the application those game design methods
used in game design development.

Figure 1: Selling Methods

ii
An Illustration of Applied Ludology:
How are Game Design Methods applied to Game Development?

Contents

1 INTRODUCTION 1

2 GAME DESIGN METHODOLOGY 3

2.1 INTRODUCTION 3
2.2 WHAT ARE GAME DESIGN METHODS? 3
2.3 WHY USE GAME DESIGN METHODS? 4
2.4 ANECDOTES 5
2.5 LEXICON 6
2.6 PATTERNS 7
2.7 RULES & GUIDELINES 9
2.8 ABSTRACT TOOLS 10
2.9 DESIGN DOCUMENT AND TEMPLATES 11
2.10 VISIONARY, EVOLUTIONARY, CABAL AND ITERATIVE DESIGN PROCESSES 12
2.11 PROTOTYPING 17
2.12 TAXONOMIES 18
2.13 TWEAKING AND BALANCING 19
2.13.1 GAME THEORY 19
2.13.2 DESIGN WITH PRE-BALANCING 20
2.13.3 BALANCING PROCESS 22
2.13.4 PLAYTESTING 22
2.13.5 GAME BALANCE CHECKLIST 24

3 THE EXEGESIS PROJECT 26

3.1 INTRODUCTION 26
3.2 PROJECT SCOPE 26
3.3 GAME DEVELOPMENT PROCESSES 27
3.4 EXEGESIS GAME DEVELOPMENT PROCESS 31
3.5 EXEGESIS GAME DEVELOPMENT SCOPE 32
3.6 CONCLUSIONS 33
3.7 PROJECT PROCESS OVERVIEW 34

4 CONCEPT PHASE 35

4.1 INTRODUCTION 35
4.2 THE GAME DESIGN AND DEVELOPMENT SCOPE MODEL 36
4.2.1 EXEGESIS GAME DESIGN AND DEVELOPMENT SCOPE MODEL 38
4.3 CONCEPT DOCUMENT TEMPLATE 40
4.4 GAME TAXONOMY 42
4.5 GAME DESIGN PATTERNS 43
4.6 DESIGN FOR EXPERIENCE WITH MDA 43

iii
An Illustration of Applied Ludology:
How are Game Design Methods applied to Game Development?

Contents

5 GAME DESIGN PHASE 44

5.1 INTRODUCTION 45
5.2 USING DISCOURSE BY ANECDOTE 46
5.3 USING GAME LEXICON 46
5.4 USING A DESIGN DOCUMENT TEMPLATE 47
5.5 USING MDA 55
5.6 USING GAME DESIGN PATTERNS 57
5.7 USING THE 400 RULES 59
5.8 USING A PAPER PROTOTYPE 60
5.9 USING A SOFTWARE PROTOTYPE 61
5.10 USING THE ITERATIVE PROCESS 62

6 ALPHA DEVELOPMENT PHASE 63

6.1 INTRODUCTION 63
6.2 USING THE DESIGN DOCUMENT 64
6.3 USING THE ITERATIVE DESIGN 65
6.4 USING THE GAME BALANCING 65
6.5 USING THE GAME DESIGN AND DEVELOPMENT SCOPE MODEL 67

7 BETA DEVELOPMENT PHASE 68

7.1 INTRODUCTION 68
7.2 GAME BALANCING AND USING A BALANCING CHECKLIST 69
7.3 PLAYTESTING 70

8 CONCLUSION 72

9 TABLE OF FIGURES 74

10 INDEX 75

11 REFERENCES 78

11.1 BOOKS 78
11.2 DOCUMENTS & PAPERS 78
11.3 MULTI-MEDIA PRESENTATIONS 79
11.4 INTERNET ARTICLES 79
11.5 INTERNET WEBSITES 80
11.6 INTERVIEWS, SURVEYS & LECTURES 80
11.7 MOVIES 80

iv
An Illustration of Applied Ludology:
How are Game Design Methods applied to Game Development?

1 Introduction

Figure 2: The Ludology Tree

There is little in the way of practical history or treatment of game design methods until
the latter half of the twentieth century. [Rabin, 2005] Ludology is the result of needing to
define a specific space within which to discuss game theories and models. [van Pul, 2005]
Ludology is an academic attitude to games; in other words, a specific interest for knowledge
concerning games. Many definitions and models with a ludological attitude come from
professional game designers as well as game researchers who do experimental designs as
part of there method to explore the design space of games. Ludology for game developers is
called “Applied Ludology” which is especially geared toward practical applications of game
design in development. [Rabin, 2005] Game Design Methodology is a collection of models,
tools and methods that create a functional Applied Ludology.
This thesis is a part of an exegesis. This means that this thesis is coupled with an
exegesis game development project. The exegesis project creates the basis for the research
of this thesis. The goal of this exegesis is too explore, identify and illustrate game design
methodologies in practical use during game development. In other words, the exegesis
becomes an example of ‘Applied Ludology’. Ludology or the study of game design and game
development is still considered a new field, this can make game design methodologies seem
like a very vague subject. This thesis hopes to illuminate and finally illustrate the practical use
of game design methodologies during game development.

“The games industry and the academics are in two different worlds. They're getting closer, slowly, but it's going to
take a long, long time. “- Gonzalo Frasca

1
An Illustration of Applied Ludology:
How are Game Design Methods applied to Game Development?

Game design methods tend towards a controversial subject amongst game


designers. A large amount of this contention lies between game researchers and the game
industry. The common debates that revolve around game design methods concerns their
affect on creativity, the development process, practical application and origins of game design
methods. The first concern that most game designers have with game design methods are
their affect on the creative process. Adhering too closely to formal methods that determine
choice or sticking too rigidly to a planned design, is a concern for the game designer when
dealing with formal methods as this can suffocate creativity. [Falstein & Barwood, 2006] Yet,
another issue concerning game design methods is that they do not reflect the actual work
done by a game designer. This is because most game designers use these methods without
realizing it and that there are misunderstandings in the use of the methods. [Frasca, 2004]
This can also be the result of representing many methodologies as models which are usually
abstractions of game design circumstance. Another issue is the large gap between the game
industry and game researchers. This gap is only widened by the misunderstanding created by
game design methodologies. Interviews reveal that many game designers have a difficult time
separating game design from development. [Careless, 2004] Further more it is many may
see game design methodologies either as an affront to their knowledge or their design. Lastly
there is the “not invented here” syndrome, which seems to add to the gap between game
researchers and the game industry. [Rabin, 2005]
The thesis has been written to resemble the structure of a game development
process that is extrapolated from experience and built on processes that seem best suited to
demonstrate game design methodologies. This means that the reader can follow the
exegesis’s game design process step by step, as ideally implemented in game development
process. This also serves the purpose to demonstrate the reliability of the development
process used. In other words, the thesis has been sculpted to accommodate the topic of
game design methodologies. Due to the fact that many game designers currently barrow
methods from other fields of study and to keep the focus upon ‘Applied Ludology’ the game
design methods describe in the thesis are game design methods proposed by game
designers for game design. In many cases these game design methods were in the past
based on methods from other fields of study but have since matured to become game design
methods. Another aspect of this thesis is that it attempts to isolate the game design process.
This means that this paper is completely devoid of topics concerning programming methods,
methods concerning graphics and methods concerning project management. This does not
mean that my development process is only concerned with game design; rather… game
design is isolated here so that we can grasp a clearer understanding of what game design
methods accomplish. The subject of this thesis has been approached with the ludologic
attitude which embraces research into design, through design and for design. [Rabin, 2005]

2
An Illustration of Applied Ludology:
How are Game Design Methods applied to Game Development?

2 Game Design Methodology

The Pirate’s Code – “And the rules… are actually more like what
you would call guidelines.”- Capt. Barbossa
[Pirates of the Caribbean, 2004]
Figure 3: Captain Barbossa

2.1 Introduction

In software engineering and project management, a methodology is a codified set of


practices that may be repeatedly carried out to produce software. Software engineering
methods span many disciplines, including project management, analysis, specification,
design, coding, testing, and quality assurance. All of the methods guiding this field are
collations of all of these disciplines. [Wikipedia, 2006] Game design methodologies are
anecdotes, tools, methods, processes and models created to assist the game designer in the
analysis, process, problem solving, criticism and communication of game design. Simply put,
these are recommended practices based on research and practical experiences. The Game
design methodologies presented in this thesis have been selected based on their support
from game researchers and game designers for the application to game design. In this
section I will present several game design methods with a brief definition, their origins and
their main features.

2.2 What are Game Design Methods?

First, Game Design Methods must be applicable to game design. This means that the
method is focused on the system, rules and player experience of game design and is not
related to marketing, development, or management. Methods build a solid understanding of
some aspect of game design, even while leaving other aspects out. [Salen & Zimmerman,
2006] Secondly, a game design method should have utility; meaning that the methods should
be tools and be more than just a list of examples or a definition of a building block. In

3
An Illustration of Applied Ludology:
How are Game Design Methods applied to Game Development?

particular, it should address specific and concrete issues occurring during the design stage of
game development. Thirdly, game design methods should be abstract. This means that a
methodology can be applied to a large number of game design situations or instances.
Fourthly, a game design method should be formalized as any method requires some degree
of formal structure and organization. [Kreimeier, 2002]
What do game design methods consist?
- Rules
- Models
- Techniques
- Best Practice

What are the advantages of rules, models, and techniques?


- Well-defined
- Abstract (i.e. cross-genre)
- Day-to-day utility
- Well-understood application context
- Lenses, not value statements
[LeBlanc, 2000]

2.3 Why use Game Design Methods?

There are many issues when we discuss methods and rules. The topic can have many
negative connotations to the creative minded person. This revolves around the idea that
methods and rules restrict creativity. Rules in the strictest sense are exactly that, dangers to
the creative process. Methods adhered too strictly actually become rules that effect creativity.
[Falstein & Barwood, 2006] In the art of game design a certain amount of familiarity is
necessary with ‘best practices’ or similar such guidelines, while at the same time remaining
flexible to personal styles or approaches to a problem. Then creativity will not become stifled.
[Wikipedia, 2006]

“Lots of people get stuck on the idea of immutable RULES, get very dramatic about it — lighten up!”- Falstein &
Barwood

The meaning of game design methodology can not be stressed enough. Game
design methodology can be viewed as a set of guidelines or a philosophical approach meant
to help provide the game designer with tools for the application to game design. Even if the
game designer may consciously apply or unconsciously apply game design methods, it is in
the favor of the game designer to have a structured approach to his game design. [Fullerton,
Swain & Hoffman, 2004] Methodologies originate from the trial and error; in other words, an
accumulation of experience. Game design methodology comes from what a game designer
thinks to be best practice when dealing with a particular issue of game design. This does not
mean that this is going to become the best practice for every game designer. A valuable

4
An Illustration of Applied Ludology:
How are Game Design Methods applied to Game Development?

aspect of methodologies is that it can be passed on to inexperienced designers as ways to


deal with the complexity of game design with the experience of a veteran game designer.
At the Game Developer’s Conference in 2006 Noah Falstein and Hal Barwood gave
lecture about the purpose and progress on their project The 400 Rules. Even though the
discussion was to promote The 400 Rules, much of their arguments for The 400 Rules can be
applied to the arguments for game design methodolgy. In the section below ‘rules’ have been
replaced with ‘methods’ so that we may see the transparency of the argument.

Why Use Methods?


o All complex endeavors seem to spawn them
o Most professions embrace them
o In game design, the vast range of possibilities seems to demand them...
Four good reasons —
o help guide us through the huge range of choices
o help us avoid trouble
o help us enlist the wisdom of others
o help us conceptualize problems
[Falstein and Barwood 2006]

Methodologies in and of themselves are meaningless without clear expectations.


Expectations can include terminology, process, procedure, etc. It won't matter how a problem
is approached, if the expectation wasn't managed and/or met, the solution then becomes
worthless. Methodologies are as much a matter of best practice as they are personal style.
[Wikipedia, 2006]

2.4 Anecdotes

Discourse by anecdote in essence is the recognition that game design knowledge can
be shared by means of written or verbal monologues and dialogues. By sharing an
experience through anecdote; tools, methods, processes, guidelines and models can be used
as abstract references during the game design process. This is a method that was developed
to discuss game design with minimal of formal constraints. [Kremeier, 2003]
The recognition and elaboration of this method can be contributed to such works as
Chris Crawford’s: Art of Computer Game Design, Game Design Perspectives, Rules of Play:
Game Design Fundamentals and The Game Design Reader: A rules of play anthology. Game
design anecdotes can originate from game journalists, game inventors (game designers that
design board games or card games), sociologists and players. Anecdotal texts can range
from seminal, teachable, significant, relevant and diverse. The following is an example of how
an anecdotal approach could be formalized, based on the setup of The Game Design Reader:
A rules of play anthology:

5
An Illustration of Applied Ludology:
How are Game Design Methods applied to Game Development?

Contributors Anecdotal Text Game Design Subjects


Game Journalists Seminal: classic essay Player Experience
Game Designers (Computer) Teachable: educational Game Rules
Game Inventors (Traditional) Significant: focal upon games Game Dynamics
Players Relevant: theory vs. practice Games and Narratives
Sociologists Diverse: different points of view Game Design Process
Game Design Models
Game Economies

An example of this method can also be found in game developer magazines as post
mortems. Since postmortems tend to be a summary of experience during game development.
Postmortems supply the perfect models to understanding what went right and what went
wrong. Further examples consist of zines, blogs, journals, and books. [Salen & Zimmerman,
2006]

Features: Anecdotes
o Sharing Knowledge
o Intuitive Method
o Minimum Formality
o Transmits Using Various Mediums
o Learning from other’s mistakes
o Learning from other’s successes

2.5 Lexicon

Anecdotes, rules and patterns all require a vocabulary with definitions. This is the
method of creating a consistent terminology so that game designers have a vocabulary in
which to communicate about game design. The value of a standard vocabulary is two fold.
One it can be considered as away to share knowledge without confusion and resolve
misunderstandings regarding terminology in high level game design discussions. A consistent
vocabulary can also be considered a method at a more practical level, where game designers
structure the vocabulary in their game design documentation.
An authoritative game design thesaurus and dictionary has yet to be published and
accepted by ludology as a standard vocabulary. There have been two attempts to provide a
consistent vocabulary for ludology. One was started in the Gamasutra forum based on Doug
Church’s concept of FADT. The second is the “Game Design Lexicon” project which is
collaboration between multiple institutions and is hosted by IC² and headed by Patrick Burkat
from the University of Texas. The lexicon project is to deliver an HTML thesaurus and an XML

6
An Illustration of Applied Ludology:
How are Game Design Methods applied to Game Development?

compatible lexicon of a polyhierarchical vocabulary, distinguishing three user groups; video


game production, game designers and developers, and players. [Kremeier, 2003]

“When trying to make good games, “fun” only gets you so far.” -Marc LeBlanc

An example of using a lexicon system that is applied to a much smaller scale could
mean that the approach is used to create a consistent vocabulary throughout a game’s design
and development process. This approach could then be applied not only to the documentation
but discussions during a project. Instead of just saying, "That was fun," or "I don't know, that
wasn't much fun," a game design vocabulary would allow the discussion to refer to defined
game components and how those parts balance and fit together. A precise vocabulary would
improve our understanding of and facilitate game design. [Church, 1999]

Features: Lexicon
o Consistent Vocabulary
o Consistent Definitions
o Game Design Specific Vocabulary
o Improving Communication

2.6 Patterns

The pattern method attempts to recognize reoccurring mechanics and dynamics in an


abstract structure. At its core, a pattern is a template structure in which research knowledge is
entered. [Kremeier, 2003] Game design patterns are meant to support the development of
game concepts, problem-solving during development, analysis and comparisons of games.
[Bjork, 2003] The tool ‘Game Design Patterns’, in its simplicity is a collection of design
choices possible in games. [Bjork & Holopainen, 2005] The basis of a game design pattern is
FADT or Formal Abstract Design Tools, FADT is a method for creating a tool that can be
applied to game design. 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, 1999]

“Abstract tools are not bricks to build a game out of. You don't build a house out of tools; you build it with tools,
FADT (Game Design Patterns) is used in the same way. “– Doug Church

In 1999, Doug Church proposed a new method that he called "Formal Abstract Design
Tools" (FADT). Later ‘patterns’ based on the FADT proposal and combined with the
Alexandrian patterns method found in architecture were combined to make ‘Game Design

7
An Illustration of Applied Ludology:
How are Game Design Methods applied to Game Development?

Patterns’. Since then ‘Game Design Patterns’ have been promoted by ludologists such as
Bernd Kreimier, Staffan Bjork and Jussi Holopainen. Even though FADT evolved into game
design patterns, it should still be considered a valuable tool for the game designer in the
sense that it is an appropriate guideline to creating and formalizing your own set of design
tools based on your own experience.
The basic structure of a game design pattern based upon Alexandrian patterns is
defined by four properties. The properties are as follows; a name, that is mnemonic and
evocative, but with the attention to the possible connotations it could pose; a problem, a
description of an obstacle encountered; a solution, a general arrangement of entities and
mechanisms that can be used to solve the problem; a consequence, a description of costs
and benefits of a solution. [Kreimeier, 2002] Game Design Patterns have many usages, a
game designer can use them as a standard game design lexicon, game design analysis tool,
reference for identifying game mechanics and reference for a game design balance checklist.
Here is an example of a few game design patterns:
Paper-Rock-Scissors: Sets of three or more actions form cycles where every action has an advantage
over another action.

Symmetric Goals: Players have structurally different goals requiring different tactics and actions.

Asymmetric Goals: The players have goals with the same definition, for example, to be the first one to
reach a certain area or amount of points, solve a problem, find an item, or overcome
the opponent.

Power-Ups: Game elements that give time-limited advantages to the player that picks them up.

Perfect Information: The player has full and reliable access to current or past information about a game
component, or that total current or past game state is known to the player.

Features: FADT
o Guidelines for Creating a Game Design Tools

Features: Game Design Patterns


o Collection of Predefined Game Design Patterns
o Structured Approach to Creation
o Supports Development of Game Concepts
o Helps Problem-Solving During Development
o Game Mechanic Analysis
o Game Mechanic Comparisons
o Vocabulary
o Definitions

8
An Illustration of Applied Ludology:
How are Game Design Methods applied to Game Development?

2.7 Rules & Guidelines

Though the name of this method allows for 400 Rules it does not limit the number of
rules that could be conceived. These ‘Rules’ are intended be used as tools and applied as
guidelines. These rules have the benefit of helping game designers gain the insight they need
to resolve problems encounter during game design. The 400 Rules can also be applied by
examining a game design by comparing it to the 400 Rules as a checklist. Further more the
guidelines touch upon a wide range of game design issues; player psychology, serious
games, meta games, level design, games for girls, brainstorming, production, story, feedback,
basic design, localization, multiplayer, single player, mobile games and development.
[theinspiracy, 2006]

“Our aim is to discover and compile rules-of-thumb for game design.”- Noah Falstein & Hal Barwood

Hal Barwood, in his presentation at Game Developer Conference in 2001 proposed


representing game design experience as a series of rules. Introduced in Falstein's Better By
Design article the 400 Project was initiated by Noah Falstein and Hal Barwood, later the duo's
More of the 400 presentation at Game Developer Conference in 2001 further cemented the
existence of the 400 rules. [Kremeier, 2003] Many game designers have contributed to the
growth of the 400 Rules, but most of the existing rules have been written by Hal Barwood and
Noah Falstein. [theinspiracy, 2006]
A 400 Rule consists of a template system that dictates the creation of a rule. First a
rule consists of an imperative statement followed by explanation. This is followed by
categorizing the rule’s domain, meaning its focus.
Here are a few a few of rules from the 400 Rules:
Imperative Statement Explanation Domain
Fight Player Fatigue: Games are a challenge and playing takes effort — Basic,
actively work to keep the player involved, and make Variety,
sure the appeal of your game always exceeds its Flow
difficulty.

Maximize Expressive Get the most out of your (always limited) material -- Simplicity
Potential: either find ways to exploit an element of your game, or
cut it out

Maintain Level of Abstraction: Immersion is easily disturbed -- don't make the player Psych
re-calibrate his "suspension of disbelief" and lose touch
with your game

Make Subgames: Players want to participate in the course they take Basic
through your game -- so give them plenty of
opportunities to voluntarily take up ancillary challenges

[Barwood & Fastein, 2006]

9
An Illustration of Applied Ludology:
How are Game Design Methods applied to Game Development?

Features: The 400 Rules


o Collection of Guidelines
o Game Feature Analysis
o Game Feature Comparison
o Extensive Guideline Subjects

2.8 Abstract Tools

The MDA (Mechanics, Dynamics and Aesthetics) methodology is approach to


understanding games that bridges the gap between game design and game development,
game criticism and technical game research. MDA provides the structure to reinforce iterative
processes and allow the game designer the ability to decompose the study and design of a
broad class of game design and game artifacts. MDA looks at games as being composed of
rules, systems and fun which are respectively represented by Mechanics, Dynamics, and
Aesthetics. Mechanics, the particular components of the game, at the level of data
representation and algorithms; Dynamics, the run-time behavior of the mechanics acting on
player inputs and each others’ outputs over time; Aesthetics, the desirable emotional
responses evoked in the player, when interacting with the game system. [Hunicke, LeBlanc &
Zubek, 2004]
The MDA framework was first presented by Marc LeBlanc as Formal Design Tools in
1999. The MDA framework which stands for Mechanics, Dynamics, and Aesthetics, has now
been incorporated as part of the Game Design and Tuning Workshop at the Game
Developers Conference. MDA can find its origins at about the same time as FADT, but the
primary difference is that MDA is an abstract tool with few constraints. [LeBlanc, 1999] The
primary ludologists associated with MDA methodology are Robin Hunicke, Marc LeBlanc and
Robert Zubek.
To use this method one must first identify the fun (aesthetics) factor. Some of these
have been listed as sensation, Game as sense-pleasure; Fantasy, Game as make-believe;
Narrative, Game as drama; Challenge, Game as obstacle course; Fellowship, Game as social
framework; Discovery, Game as social framework; Discovery, Game as uncharted territory;
Expression, Game as self-discovery; Submission, Game as pastime. Once the fun
(aesthetics) factor that the designer is trying to achieve has been identified, we are asked
what are the systems (dynamics) in place and how do they best create the fun (aesthetics)?
Is it a better reward for taking a bigger risk to increase ‘challenge’? Or is it the goal that is best
achieved through cooperation to create a sense of ‘fellowship’? Once we have a concept of
the system we can then ask what rules (mechanics) need to be put in place to achieve this
system (dynamics)? In the end the game designer is able to achieve the fun (aesthetics) that
he/she set out to achieve. MDA provides the game designer with a tool during an iterative

10
An Illustration of Applied Ludology:
How are Game Design Methods applied to Game Development?

process too focus his/her design on achieving the fun (aesthetics) originally intend by the
design. In essence this method allows us to ‘Design for Experience’.

Figure 4: A visual reference to MDA.

Features: MDA
o Game System Analysis
o Game Mechanics Analysis
o Game Experience Analysis
o Supports Iterative Process
o Design for Experience

2.9 Design Document and Templates

The game design document is a way for the game designer to create a blue print for
the game. The game design document is meant to transmit the game design to the team but
typically it is more a notebook for the game designer’s reference. [Rollings and Morris, 2004]
The design document 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. [Kremeier, 2003] A game design document
usually contains flow charts, matrixes, mock-ups and relational diagrams to help facilitate the
communication of the game’s design. The game design document template thus becomes the
method for the creation of this document. A game design document template is an attempt to
create an outline that can be reused each time the game designer writes a game design
document. A typical sample of this outline template offers an archetypical design document
that can used as a form into which the designer fills in the details of a given design-in-
progress. There are many game design document methods recommended by various game
designers. The main benefit of this is to have reference to the information about the game that
needs to be communicated in every game design.
The design document arose from the need of communicating a design to a game
development team. When teams started to become large and games became more complex,
the document preserved the main elements of the game’s design. This was already a

11
An Illustration of Applied Ludology:
How are Game Design Methods applied to Game Development?

standard practice for the software industry and was carried over quite early to the game
industry. The planning provided by the game design document solved the problems
experienced by cowboy (solo) designers whom designed as they developed. [Rollings and
Morris, 2004]

“Seeing as it was a small, technology-based game, I didn't think it was necessary to have a design document.”-
Peter Stock

The postmortem of Armadillo Run which was an independent game development that decided
in retrospect that a game design document was something that could have added better
structure to the design concerning interface, level design and game play. In the end there was
a feeling directionless evolution rather than intelligently designed. [Stock, 2006] An example
of a game design document template may be found in many places but one of the most
accessible can be found at ihfsoft.com. Located here is a game design document template
created by Chris Taylor. This template was used to create the game design document for
Dungeon Siege. [ihfsoft.com, 2004] Other template documents can be found in books such as
Game Architecture and Design and Game Design Workshop.

Game Design Document Features


o Game Design Communication
o Flow Charts
o Relational Diagrams
o Matrixes
o Mock-ups

Game Design Template Document Features


o Archetypical Game Design Document
o Reference
o Consistent Information

2.10 Visionary, Evolutionary, Cabal and Iterative Design Processes

A design process is a method that organizes the creative process involved with game
design. This is meant to help create the best aesthetic result. In the case of game design
processes it also determines the authority to make design decisions and the role of the game
designer. The first type of game design process discussed here will be called the visionary
design process. This is will be referred to as the visionary design or the authortive design
process because it usually involved a visionary game designer. Formally this was the lead
programmer or the developer with most experience that would take up this position. When the

12
An Illustration of Applied Ludology:
How are Game Design Methods applied to Game Development?

game designer, the visionary, is the sole determinate of the game design process the game
designer also determines this game design method based on a conglomeration of
experiences. It can be expected that the visionary game designer remains in control of every
aspect of the game’s concept and design. [Wikipedia, 2006] The process of the visionary can
be credited with the creation of various methods and processes.

“… we’re of the opinion that the only worthwhile thing that was ever designed by a committee is the American
Constituition.”- Andrew Rollings & Dave Morris

Examples of game designers that represent and iconize this process are Shigeru Miyamoto,
Sid Meier, Will Wright and Peter Molyneux. This is not a group that exclusively acts visionary
game designers but the visionary game design process can also be seen in many cases
concerning independent game designers. [Michael, 2003]
In figure 5 we see an example of how visionary design process would interact with a
basic iterative game design and development process. As seen in figure 5 the only thing the
visionary game designer does not determine is tester’s experience playing the game.

Figure 5: Visionary design coupled with the Iterative development.

The next design method is that of the cabal design process. The primary mission of a
cabal is to complete the game design. Cabal meetings are semi- structured brainstorming
sessions dedicated to a specific area of the game design. These meetings generally involve
the expertise from a cross section of the development team, allowing ideas to be offered by
everyone. The idea is to gather ideas from a wide range of sources to allow for the most
optimal solutions to the game design’s problems. [Birdwell, 1999] The Valve cabal method
follows an iterative design method of generating, formalizing, testing and evaluation. It is
therefore notable that this method can be applied to the iterative development approach, only
the cabal process decides the authority to make game design decisions.

13
An Illustration of Applied Ludology:
How are Game Design Methods applied to Game Development?

The cabal design process is a result of Valve’s efforts to develop the critically
acclaimed game Half-Life. In 1997 the developer had reached a point when the realized the
game was not what they had hoped for and they needed a solution. The first solution was to
search for a game designer that could help them resolve their issues with the game design,
this turned into a fruitless endeavor. It was at this point that Valve combined cross sections of
the company to initiate the method known as design by cabal. [Birdwell, 1999]
In the figure 6 we see that the role of the visionary has now been taken over by the
cabal. The cabal is represented as being composed of a cross section of a development
team.

Figure 6: Cabal design coupled with the Iterative development.

The next game design process is aimed at creating the best aesthetic experience
possible by continuous evolution through iteration. Evolutionary Design is best described as
“Death of the ego”. This is because the game design will ultimately be decide through play
testing. Evolutionary design is a process of steps that allows the design to evolve. The first
steps need to focus on the game’s core activity. This is followed by the need to play through
the game, which allows for minor tweaks and changes. This is followed by a playtesting
session with the main activity of the designer observing the game and the players. Through
observation, identification of emergent gameplay and problems can be determined by the
designer. The designer can now adjust and tweak in an effort to create a better aesthetic
experience. [Cook, 2002]
In figure 7 the play testers have taken the evaluation of the game from the game
designer or cabal. This has two effects on the design process; one is the task of the game
designer to iterate the design to the liking of his play testers and two is the play testers
determine if the criteria for the best aesthetic experience and when it has been reached.

14
An Illustration of Applied Ludology:
How are Game Design Methods applied to Game Development?

Figure 7: Evolutionary design coupled with the iterative development.

While game designers are by no means meant to be dictators and, game design
should also not be decided according committees. The game designer could be considered
as ultimately being responsible for guarding the vision of the game instead. [Laramee, 1999]
The Iterative approach differs from evolutionary design because the aesthetic experience that
the game designer is responsible for remains in contact or in other words, “the ego remains”.
An Iterative design process simply means that a game’s design is tested and evaluated over
and over again throughout the development of the game until it meets the game designer’s
criteria. In most cases the game designer’s criteria is based upon a vision that has been
agreed upon by the development team. The iteration cycle consists of generating ideas,
which can originate from brainstorming sessions and research; formalizing ideas, meaning
writing them down in a documented form; testing ideas, meaning implementing them as
prototypes and play- testing; evaluating results; meaning the need to determine if the result
meet the criteria as functional part of the game. [Fullerton, Swain & Hoffman, 2004]
In figure 8 we now see that the primary difference of the game designer’s position in
iterative design and visionary design is that the game designer now becomes the “guardian”
of the game’s design. Ultimately the game design depends upon the agreed upon aesthetic
experience based on the proposed game design.

15
An Illustration of Applied Ludology:
How are Game Design Methods applied to Game Development?

Figure 8: Iterative design coupled with the iterative development.

Game design processes at the dawn of computer games were vague and mostly
dependent the personal discipline, this was the traditional game designer considered to be a
cowboy designer. Modern game designs are the result of this messy, content dependent
process a ‘cowboy’ designer intuitively followed when building a game. [Danc, 2004] Later
when teams worked on game development game designers were often the lead programmer,
this was the case in 1980s. Such was the case of Sid Meier, Chris Sawyer and Will Wright
whom would fit the profile of working with visionary design process. [Wikipedia, 2006] In 2002
Daniel Cook wrote an article about designing games by evolution. From the idea of
evolutionary design the beginnings of what would be later termed as iterative design process
would develop. In 2004 Rules of Play and Games Design Workshop both advocated iteration
design process. Since being advocated the iterative process, be it visionary, evolutionary or
cabal forms the basis for the design process.

Features: Visionary Design


o Singular Vision
o Game Design is Game Designer’s Domain

Features: Cabal Design


o Wide Range of Solutions
o Wide Range of Expertise

Features: Evolutionary Design


o Continuous play-testing during development
o Continuous iterations during development
o Optimal Aesthetic Experience

16
An Illustration of Applied Ludology:
How are Game Design Methods applied to Game Development?

Features: Iteration Design


o Continuous play-testing during development
o Continuous iterations during development
o Designed Aesthetic Experience

2.11 Prototyping

Prototyping lies at the heart at the heart of all good game design. The word prototyping
means to create a working version of the formal system that, while playable, includes only a
rough approximation of the artwork, sound and features. [Fullerton, Swain and Hoffman,
2004] There are two prototyping methods recommended, Physical Prototypes and Software
Prototypes. Physical prototypes or early rapid prototypes are similar in many ways to board
games or paper and pencil games. Physical prototypes allow for the game designer to
experience and familiarize him/her with the game’s mechanics and rules. Physical prototyping
is method that is not concerned with looks thus recycling tokens, recycling cards and using
whiteboards are common place. [Danc, 2006]

Using Paper Prototypes:


• Good for understanding existing games
• Use these techniques for games in progress
• Process is quick and cheap
• You don’t need programmers or artists
• Can’t replace actual gameplay testing
• Can give you a head start and keep you focused
• Can give you a vocabulary to use when discussing your game
• Can be used as a tool to educate programmers. Have them play, too!
[Stone, 2005]

The second prototyping method is that software prototyping. This method uses quick
roughly programmed prototypes using various program languages or even reusing level
editors. Again the goal of a software prototype is to get an impression of the game’s dynamics
and rules in action in an analogue version. [Fullerton, Swain and Hoffman, 2004]
A good example of what a prototype can achieve was given by Ken Birdwells
discussion about Valve’s design process. Here the team came to a point where they
accumulated the best parts of their game in to a single prototype level. Having seen the best
dynamics and mechanics they were able to determine the best parts of the game design
which determined the aesthetics. (Birdwell, 1999)

17
An Illustration of Applied Ludology:
How are Game Design Methods applied to Game Development?

Features: Paper Prototyping


o Quick Results
o Evaluation of Game Mechanics

Features: Software Prototyping


o Evaluation of Game Mechanics in Analogue
o Evaluation of Game’s Analogue Potentials

2.12 Taxonomies

Taxonomies give us a high level frame work of analysis and design. The first taxonomy
uses an orthogonal taxonomy system. This approach allows for greater flexibility than
hierarchal systems. [Craig A. Lindley, 2003] The second taxonomy system is a hierarchal
system with the ability to adapt and change due to its wiki foundation. This taxonomy system
also has the feature of delving into non-game design specifics. [Danc, 2006]
The taxonomy method based on the orthogonal system was presented by Craig
Lindley in a 2003 article for Gamasutra and developed within the Zero Game Studio of the
Interactive Institute in Sweden. This taxonomy was the result of many design discussions,
and resulted in a framework that saved time by resolving basic questions and confusions.
[Lindley, 2003] The hierarchal system proposed at The Game Innovation Database (GIDb)
based upon a wiki forum is supported by Carnegie Mellon an Entertainment Technology
Center which is attempting to create a living taxonomy system for games. [Gameinovation,
2006]

Figure 9: The 3 classification diagrams: Unified Plane, Unified Gambling Space & Unified Fiction/ Non-Fiction Space.

18
An Illustration of Applied Ludology:
How are Game Design Methods applied to Game Development?

Features: Taxonomy
o Game Concept Analysis
o Game Genre Analysis
o Game Feature Analysis
o Game Comparison Analysis

2.13 Tweaking and Balancing

Significant time and resources are invested in attempts to balance games so that
they're neither too hard nor too easy for players. [Carpenter, 2003] Game balancing is the
need to balance the game’s mechanics and dynamics to create the desired aesthetics.
Achieving game balance basically means that the game doesn’t degenerate down to a very
small number of real options. [Sirlin, 2001]

“Good game balance is, in many ways, the holy grail of game design.”- Adam Carpenter

With the advent of more complicated games and the search for new game play the
ability to balance a game has multiplied in importance. Most tweaks and game play balancing
are now results of a play testing sessions, but there are a few proven techniques that allow us
to begin the process of balancing before playtesting through the use of game design
methods. This is in an effort to lower the amount iterative cycles needed during development
to achieve a proper game balance. The methods here cover a broad spectrum of balancing
techniques, such as game theory, pre-balancing, playtesting, balancing processes and
balancing checklists.

“A lack of balance often stands in between great design and a great game”. - Tom Cadwell

2.13.1 Game Theory

The first balancing method we will look at is presented to us by the mathematic study
of Game Theory. Game Theory is a collection of models that help us understand player
decision according to a situation in mathematical terms. Perhaps one of the best known is
that of the Prisoner’s Dilemma or zero-sum presented to us by strategic games. Using Game
Theory allows insight into what the player could perceive as optimal strategy and allows the
game designer to predict the player’s choices based on the situation faced. [Osborne, 2004]
Game theory is also known as multi-person decision theory which allows us to measure
desire by numeric representation known as payoffs. The representation are created in models

19
An Illustration of Applied Ludology:
How are Game Design Methods applied to Game Development?

know as zero-sum, pure coordination and mixed-motives. Zero-sum represents a situation


where player outcomes are directly opposed, pure coordination describes a situation where
players try to achieve the best outcome for all players and mixed-motives describe player
payoffs that do not correspond to each other. Game Theory when applied at high level game
design can help tune choices and outcomes. At a low level these models can be useful with
the behaviors of game elements such as AI design. [Rabin, 2005]
In figure 10 we see the outcome in years which the prisoners would receive based
other their choice to cooperate with the police.

Figure 10: A zero-sum game.

2.13.2 Design with pre-balancing

Another way to achieve balance is to begin with pre-balancing a game with some
basic principles. One way of pre-balancing is to design the game with dynamic balancing.
This is balancing that adjusts dynamically according to the player’s skills or the player’s
progression. [Fullerton, Swain & Hoffman] Dynamic balancing is seen in many old arcade
games that became more difficult as the player progressed.
Another way to pre-balance more complicated game design is to use a game design
methods that aim to achieve pre-balance. These methods consist of a set of guidelines that
address designing the game with; elemental modularity or modular design, meaning each
game mechanic exists for specific purpose; consistency of design motivation or purity of
purpose, meaning adhering to the fundamental core mechanics; complexity control, keeping
the game’s system simple as possible; one change at a time, meaning changes to the game
are made one change at a time.

20
An Illustration of Applied Ludology:
How are Game Design Methods applied to Game Development?

Another approach can be termed as the Capcom principle to pre-balance. This


principle is to design the game so that balancing becomes a matter of variety versus balance.
Variety versus balance means that a game design has to offer a large amount of variety, this
variety makes up for minor imbalances. The strategies offered by the large amount of variety
can offer enough of an equilibrium that even the huge gaming audience is faced with a task
that may takes years to sort out. [Sirlin, 2001] The need for large amounts of variety can
make this strategy a bit unwieldy but still a valid as a design strategy.
Pre-balancing methods offer several tools as well in which the designer can use to
begin the balancing process. One such tool is the spread sheet, in this thesis the spreadsheet
is referred to as the matrix. The matrix offers an overview of corresponding variables.
Additional tools can applied through the means of the matrix such as the use of graphs and
charts. [Fullerton, Swain & Hoffman, 2004] One example is the use of risk analysis tools
usually found as economic models to determine the risk to the player for certain choices
available during the game. This allows the designer to run different scenarios with various
tweaks to the values. These include cumulative probability distribution graph which can
illustrate the percentage of chance that an outcome Y will occur at least X percent of the time
and the supply-and-demand graph, which can illustrate the success and failure curves.
[Carpenter, 2003] Another valuable tool is that of the relationship diagram that helps the game
designer determine relationships. The relationship diagram becomes specifically valuable
when the game designer is balancing the game dynamics which requires adjusting game
mechanics. The relationship diagrams taken to its extreme becomes similar to a formalized
UML diagrams.
The usage of balance math is another tool can achieve in some cases a consensus
of game element values. This equation plays with values associated with Game Impact,
Durability and Effectiveness. [Cadwell, 1999] Other ways of achieving pre-balance include the
usage of such principles as the Stone-Paper-Scissor game dynamic. The Stone-Paper-
Scissor is a typical game dynamic is very simple and effective way to prevent the creation of
limited game options or dominant game elements. [Rollings & Morris, 2004]
In figure 11 we see two diagrams. The first diagram demonstrates the traditional
relationship between paper, rocks and scissors. The second diagram demonstrates a slightly
more complex Paper-Rocks-Scissor relationship between four elements. The Paper-Rock-
Scissor relationship can be applied to even more game elements creating further complex
relationships.

21
An Illustration of Applied Ludology:
How are Game Design Methods applied to Game Development?

Figure 11: 3 way P-R-S and 4-way P-R-S.

2.13.3 Balancing Process

A game balancing process is method to help guide the game designer during the
phases when the game is being adjusted to create a balance that takes into consideration the
learning curve, player versus players and game elements. A game balancing process is
meant to give the game designer a perspective on the balancing issues as they occur during
iterations. [Fullerton, Swain & Hoffman, 2004] When the game reaches the first phase where
it becomes playable, the Game Designer begins with Marcocalibration. Macrocalibration
means that in first phase the adjusted values need only achieve a percentage of the Game
Designer’s criteria of the game’s aesthetic experience. As the iterative development cycle
progresses during development macrocalibration becomes micro-calibration. Microcalibration
means that the game designer has reached the phase when game balance is now focused
fine tuning the game balance. Lastly playtesting identifies balancing issues missed during the
micro and macrocalibrations. [Cadwell, 1999]

2.13.4 Playtesting

“Playtesting is the single most important activity a designer engages in, and ironically, it’s often the one designers
understand the least about.”- T. Fullerton, C. Swain & S. Hoffman

Playtesting has become the foremost important activity in the effort to create aesthetic
experience. Playtesting is the activity of using playtesters to determine the game’s aesthetic
experience. Playtesters are used because game designers and game development are
biased about the game’s aesthetic experience, which from experience this can both be a
negative and positive bias. Playtester’s provide the objective view that the game designer
requires to adjust and balance the game for the best possible aesthetic experience. Here are
examples as to why we need game testing to balance a game:

22
An Illustration of Applied Ludology:
How are Game Design Methods applied to Game Development?

1. Gamers will uncover any and all relevant equations and formulas.
2. Gamers will find bugs and "features" that the developers never knew about.
3. Gamers will use features in bizarre ways never envisioned by the developers or even the testers.
4. Gamers have far, far more time to play the game than the developers do. The developers are busy
making games, but hardcore gamers have seemingly infinite time.
5. The gaming public just has far more pairs of eyeballs than the developers and testers.
6. The developers and testers have skewed perceptions on balance since features change often
throughout development.
7. The developers and testers are often playing without all the options available in the final game, or at
least without the final tweaking in place.
8. Finally, the gamers have the motivation. If you discover a strategy in Starcraft or a deck in Magic the
Gathering that truly breaks the game wide open, you have lots of rewards waiting for you.
[Sirlin, 2001]
Playtesting is more than just letting playtester play your game and then hearing their
opinions. The game designer must be able to abstract the information that is relevant to the
aesthetic experience that is trying to be achieved. To do this certain tools have been devised
for the game designer. One of these tools that can be used in the testing phase is that of the
play matrix. The play matrix seen if figure 12 is a matrix used by the player, the player places
his game experience in this chart.

Figure 12: Playtest matrix.

This chart along with the following questions help determine a sort of taxonomy of the game
based on the player’s experience, this in turn allows the game designer to examine the
game’s design in comparison with the game’s original taxonomy. Here below is a list of
suggested questions that can be asked along with the playtesting matrix:
- Is the outcome a result of chance or skill?
- Is the outcome a result of mental skill or physical dexterity?
- What quadrant would the player move the game into if they could?
[Fullerton, Swain & Hoffman, 2004]

This analysis has a two fold purpose. One the game designer can see the preferred game
type of the tester and second if the tester is from specific target group then the game designer
can determine the direction in which the game design must be directed.

23
An Illustration of Applied Ludology:
How are Game Design Methods applied to Game Development?

Another activity of playtesting is asking the right questions that will help guide the
game designer in iterative design process. Game Designer activities in such a method
requires the need for the game designer to be present during playtesting to make in-game
observations, make in-game questions and lastly ask post-game questions. Questions can be
aimed at finding information about how the player experienced the game’s procedures, rules,
interface, controls, formal elements and dramatic elements. Lastly playtesting provides a few
guidelines to ease the process of playtesting. The first guideline is to ask the testers to think
out loud. This allows the game designer to have a verbal sense of what the player is thinking
while playtesting. Another important guideline is to avoid leading the testers. This will defeat
the purpose of observing the playtesters and possibly missing problems within the game.
[Fullerton, Swain & Hoffman, 2004]

2.13.5 Game Balance Checklist

A balance checklist is created to help remind and guide the game designer’s process of
reviewing balance issues between players, players and the system or to create an aesthetic
experience. [Bjork & Holopainen, 2005] The next method to add to game balancing is the
creation of a checklist that can be referenced to during game balancing phases. This checklist
can be identified coming from two sources. One is from Game Design and Architecture and
the other from Patterns in Game Design. Game Design and Architecture starts using the
checklist for macro-calibration. This macro-calibration checklist is composed of:
- Player vs. Player Balance: Issues concerning the symmetry between players in that compete against
each other.
- Player vs. Gameplay Balance: Issues concerning rewards and using the game in a manor to challenge
not frustrate the player.
- Gameplay vs. Gameplay Balance: Issues concerning concepts such as stone, paper and scissor
balancing.
[Rollings & Morris, 2004]

The checklist based upon Patterns in Game Design can be considered to be more micro-
calibration. Here is an example of concepts that could be on the checklist:
- Loopholes
- Balancing for skill
- Dead Ends
- Balancing Variables
- Balancing Dynamics
- Reinforcing Relationships
- Dominant Strategies
- Asymmetrical
- Handicaps
- Level of Difficulty
- Level of Complexity
- Team Balance
[Bjork & Holopainen, 2005]

24
An Illustration of Applied Ludology:
How are Game Design Methods applied to Game Development?

Features: Game Theory


o Tweaking Choices
o Models
o Understanding Player Choices
o AI (Artificial Intelligence) Design

Features: Pre-Balancing
o Modular Design
o Purity of Purpose
o Complexity Control
o Variety vs. Balance
o Balance Math
o Risk Analysis
o Matrix (spreadsheet)

Features: Balancing Process


o Macro-calibration
o Micro-calibration
o Compatibility with Iterative Process
o Compatibility with MDA

eatures: Playtesting
o Observation
o Play Matrix
o Survey
o Guidelines

Features: Game Balancing Checklist


o Concepts
o References
o Analysis

25
An Illustration of Applied Ludology:
How are Game Design Methods applied to Game Development?

3 The Exegesis Project

3.1 Introduction

This chapter will discuss the exegesis project and its development process. This game
development project and its process are meant to support this thesis as an illustration of how
a game designer can use game design methods in practical application. It is important that we
discuss the project setup since the project acts as a frame work in which game design and
game development exist together.
In this chapter we discuss the exegesis project’s scope, different project processes
related to game development and the exegesis project’s process. Why is it relevant to
discuss project processes? Even though this thesis is aims at the exploration of the isolated
design process, the project processes discussed in this chapter could be considered to have
little to do with game design methods. In this case the game development process becomes
the link to the successful illustration game design methods and their practical application
during game development. It also to demonstrate that the game development process used to
accommodate the use of game design methods varies little from common development
methods. What is also demonstrated is that game design methods do not replace a sound
development process.

3.2 Project Scope

The project scope will cover all the important principles concerning project
management such as scope, time, risk and cost. [Wikipedia, 2006] In this section we will
discuss the parameters of the Exegesis’s game development. Some of the parameters were
determined by HKU requirements for the exegesis. Other parameters have been set by the
game designer and development team in attempt to create the most situations that require the
need to fall back upon the usage of game design methods.
Perhaps one of the most pressing issues in game development is how much time is
allotted to the game’s development. More time can mean more content, more polish, more
testing and more time to analyze the game design. Time is crucial parameter that can affect
so many of the decisions in determining the scope of the game’s design. It is important at this
stage for the game designer to understand what is possible and what is not. In the case of the
exegesis project there was twenty two weeks allotted for the game design and development.
Next, is the issue of determining the game’s deliverable. What will be the promised
deliverable? Will it be a demo version, gold version, alpha version, beta version or prototype
version? In the case of the exegesis game development it was important to achieve a beta

26
An Illustration of Applied Ludology:
How are Game Design Methods applied to Game Development?

version. This was chosen to so that the thesis would have complimentary conclusions up to
the beta version for use in this thesis. Next the game would require a certain level of design
complexity to justify the need of game design methods and must boast at least two game
design mechanics. The dynamics of the game should also be of a unique nature to
demonstrate how methods are capable in guiding projects that are not based on cloned
gameplay. It was determined it was necessary to keep the technical and graphical part of the
development as simple as possible. The reason for this is that often technical and graphical
features leave us blinded to the game design process. This would allow for the more attention
to go to the game’s design. Isolation and focus of the game design during development was
intentionally done for the needs of the thesis. Another part of determining the project’s scope
concerned the team. It was determined that there were certain abilities necessary to fulfill the
needs of the exegesis. The number one ability of the team would be the capability to create a
functional software beta version of the game. As for determining the risk involved with this the
exegesis game development, it determined that there was the possibility of not achieving the
beta deliverable needed to support this thesis. In such as case it was determined that the
experience gained by the author as a professional game designer and based on past school
projects would be used to further support this paper. Lastly project scope budget was not
defined, since there was a lack of financial backing.

Exegesis Project Overview:


Project Scope Parameters

Time: 22 Weeks
Deliverable: Beta Version
Team: Ability to achieve beta technical
level
Budget: None
Genre: Complex enough to justify game
design methods

3.3 Game Development Processes

Now that we have described the scope of the project, we will proceed to analyze the
project method used for the game development. There has been in recent history of game
design and development many changes in development processes but this has become more
standard over the years. There are too many software and engineering project processes to
list here, processes listed here are project methods that are recommended from research into
game design and development. The following processes originate from game industry
literature and software project methods that have influenced the process used to illustrate the
thesis’s main question.

27
An Illustration of Applied Ludology:
How are Game Design Methods applied to Game Development?

The first development process we will discuss is the one prescribed by Game
Architecture and Design. This is an important source of information since this was perhaps
one of the first game design and development sources with information on industry
processes. Below in figure 13 this can be considered a standard industry process and is the
game development method described in Game Architecture and Design. This process is also
used as a possible alternative to RAD according to Break Into the Game Industry: How to get
a Job Making Video Games which will also be looked at later in this section. Also note worthy
is that the process is divided into phases which denotes an amount of modularity, which
focuses on the creation of a ‘software factory’. Game Architecture and Design functions
primarily on deadlines and milestones which help to cut a project up into little manageable
pieces that demonstrate progress. [Rollings & Moris, 2004]

“Milestones should be clear and concise.”- Andrew Rollings

Figure 13: The Game Architecture and Design

The next development process described here is the one proscribed by Introduction
to Game Development. We look at this process next since terminology is highly associative
with film production. In figure 14 we see that development is split into four phases that
resemble the film industry’s development methods. This is an interesting trend since this
means that the game production takes on characteristics associated with entertainment
industry. This process also features the acknowledgement of Alpha and Beta versions of a
game. We can also assume that there is some sort of playtesting at these two milestones.
[Rabin, 2005]

Figure 14: Introduction to Game Development

The next process we will discuss is proscribed by Break into the Game Industry: How
to get a Job Making Video Games seen in figure 15. This process is different than the
previous two in that it now creates an emphasis on three new phases. These phases all

28
An Illustration of Applied Ludology:
How are Game Design Methods applied to Game Development?

include emphasis on playtesting in an Alpha, Beta and Quality Assurance phases. What is
also very important about this process is that we have concrete definitions of Alpha and Beta
versions of the game. When a game reaches the point where all of its features are present,
even if all its content is not, then the game is considered a alpha version. When all the
content is ready, all the levels designed and all the art and audio created and the game is
complete. This would be considered the Beta version. [Adams, 2003] Other features of this
particular development method are the alternative use of RAD (Rapid Application
Development). RAD has three core elements: prototyping, iterative development and time
boxing. The first element, prototyping, is the construction of a feature-light application in a
short amount of time. The objective is to create a working application to help designer flesh
out requirements. The second element, Iterative development, is the creation of increasingly
feature rich versions of applications in short development cycles. Time boxing is the third
element, and supports iterative development by pushing off features to future versions in
order to complete iterative cycles as quickly as possible. [Wikipedia, 2006]

Figure 15: Break into the Game Industry

Game Design Workshop: Designing, Prototyping and Playtesting Games adds new
millstones to the phases into the process to insure more attention to a game’s final playability.
In figure 16 we see that there is an emphasis on millstones in the first part of this
development method. The new milestones added to the phases are prototyping and the
iterative design based on playtesting through out the entire development process of the
game. The iterative project process is not only a project method but also a game design
method. The core of the iterative process is the principle of cycling through generating ideas,
formalizing ideas, testing ideas, evaluating results, revising, evaluating and testing. This
occurs during the development process continues in a downward spiral until the last test and
evaluation. [Fullerton, Swain & Hoffman, 2004]

Figure 16: Game Design Workshop

29
An Illustration of Applied Ludology:
How are Game Design Methods applied to Game Development?

We now look at the next development method, which in many ways relates to the
exegesis’s development method used in our illustration. The Indie Game Development
Survival Guide seen in figure 17 starts with pointing out the importance of choosing a suitable
game concept. The core difference of this development method compared to those previously
discussed is the attention that is given to choosing the game concept. For the indie game
developer it is important that the game developed is unique and this is similar to what needs
to be achieved with the exegesis project. This attention to choosing a concept is a unique
feature in the project process as this will determine the end result as much as the final
product. This means that an independent developer will consider brainstorming and concept
design one of most important phases. Another interesting point in the process of an
independent developer is choice of setting up a remote project team. This is especially
interesting since previous processes do not take this possibility into consideration. [D.
Michael, 2003]

Figure 17: The Indie Game Development Survival Guide

Lastly I would like to add a process that I found very influential in consideration to the
management of the game development process. This method is that of the Kaizen. This is
also intriguing since there is very little to be found in terms of research on Japanese game
development methods, but we can imagine that Kaizen could be the core ideology behind the
success of Japanese game developers. The Kaizen method of continuous incremental
improvements is originally a Japanese management concept for gradual, continuous and
incremental, change and improvement. Kaizen is actually a way of life philosophy. It assumes
that every aspect of our life deserves to be constantly improved. Japanese companies
distinguish between: Innovation, a radical form of change, and Kaizen, a continuous form of
change. Kaizen means literally: change (kai) to become good (zen). The five elements of
Kaizen are:
1) Teamwork
2) Personal discipline
3) Improved morale
4) Quality circles
5) Suggestions for improvement
[12manage, 2006]

30
An Illustration of Applied Ludology:
How are Game Design Methods applied to Game Development?

3.4 Exegesis Game Development Process

This section describes the exegesis’s game development approach, which used a
hybrid process, barrowed from aspects of previously described game development
processes. While barrowing some points from the previously mentioned processes, there are
also a few points that have been acquired through the authors experience at school or as a
professional game designer. The game development process is also important because it
also influences the structure of this thesis. This is done on purpose to create a clear link
between the game development and the game design.
The first experience that helped shape the game development process for the
exegesis was the experience of creating the game development process for Overloaded. The
company had come to a point that their overall approach to making games was unclear to
everyone. It was decided that needed and then created. a document that described their
process. The most notable features of this process are the descriptions that describe
relationships, determining points of evaluation based on playtesting, more emphasis on
brainstorming and the milestone that ends a phase. In figure 18 the Overloaded game
development process is shown. [Overloaded, 2004]

Figure 18: Overloaded Project Method

Another experience that influenced the creation of the process used in the exegesis was
recent development of a game for a experimental hardware system developed by Phillips.
This experience addressed the problems that independent developers seem to face. How do
you choose a concept? And how do you choose a concept that will fulfill the wishes of the
team, client or project? With the influence of one of our professors the Vonk team from the
HKU’s MA created a concept-scope model system. In this thesis this will be referred to as a
game design and development scope model. This scope model was used as a tool create an
objective view on proposed concepts. This was followed by a system of culling concept that
did not fit into what we as a team wish to accomplish. I have adopted this process and
consider it to be an essential milestone of the development process.
In the creation of the game development process certain aspects for using this project
as an illustration of game design methods were taken into consideration. This game
development process was created from a game designer’s point of view thus making this
process ultra sensitive to the needs of the game’s design which ultimately means the player’s
overall experience. The main features considered in the creation of this process:

31
An Illustration of Applied Ludology:
How are Game Design Methods applied to Game Development?

- Game Design Iteration for the Fun Factor


- Pre Game Balancing
- Objective Concept and Design Analysis
- Design Evaluation
- A Finalized Product
- Development Remains Efficient

What I consider to be essential differences in my game development process seen in figure


19 is when compared to that of other game development processes there is more emphasis
upon creating a paper prototype, tech prototypes, and the usage of the game design and
development scope model.

Figure 19: An overview of the exegesis project process.

3.5 Exegesis Game Development Scope

In a previous section we discussed the defining elements that would determine the
scope of the exegesis game development project. In this section there is a quick overview of
the results. Using the game development process described in section 3.4, which was the
result of research and experience, will form the structure for the illustration for the game
design methods. For the sake of simplicity it will be referred to as the Dev66 game
development process. The Dev66 team consists one fulltime member and five parttime
members; one game artist, two programmers, one game designer and one writer. Lastly the
concept chosen falls into the genre category of a MMO (Massive Multi-player Online) TBS
(Turn Based Strategy) game with RPG (Role Playing Game) elements.

32
An Illustration of Applied Ludology:
How are Game Design Methods applied to Game Development?

Dev66 Scope Overview:


Project Issue Parameters
Time: 22 Weeks
Deliverable: Beta Version
Team: 1 Full-time Member
5 Part-time Members
Budget: €1,000.00 Euro
Genre: MMO/TBS/RPG

3.6 Conclusions

The process which has been chosen to be used in this exegesis project is the result of
combining research and experience. The main feature of this game development process is
its focus on the game design process. This should allow for ample illustration of the practical
application of game design methods and emphasis on project completion. It is also important
to demonstrate that the use of game design methods is not only a way to help with the quality
of a game’s design, but also demonstrates their application does nothing disturb the
development process. If the methods and process should prove to be cumbersome to the
point of slowing a project down, then to some extent a part of illustration has failed. I hope to
demonstrate that with the Dev66 game development process allows the evaluation and
implementation of game design and development equally. This process could also be
considered a project template for the game design students and independent developers who
wish to evaluate their designs while remaining synergetic during development.

33
An Illustration of Applied Ludology:
How are Game Design Methods applied to Game Development?

3.7 Project Process Overview

Technical Document

Technical Prototype
Concept Document
Iterative Process

Paper Prototype

Storyboarding

Brainstorming
Game Design

Techniques
Document
Research
Scope
Model
Pre Production

Exegesis Project Process


x x x x x x x
The Indie Game
Development Survival x x x
Guide
Overloaded Project
x x x x x
Method
Game Design Workshop x x x x x x x
Breaking into the Game
x x x x
Industry
Game Design and
x x x x
Architecture
Introduction to Game
x x x
Development
Iterative Process

Game Balancing
Iterative Testing
Alpha Version

Other Testing
Beta Version

Architecture
Hard & Soft

Playtesting
Debugging
Release
Gold

Production

Exegesis Project Process


x x x x x x
The Indie Game
Development Survival x x x x x
Guide
Overloaded Project
x x x x x x
Method
Game Design Workshop x x x
Breaking into the Game
x x x x
Industry
Game Design and
x x x x x x
Architecture
Introduction to Game
x x x x
Development

34
An Illustration of Applied Ludology:
How are Game Design Methods applied to Game Development?

4 Concept Phase

Figure 20: A visual reference to the concept phase.

4.1 Introduction

The exegesis project started with the prerequisite that required it to be linked to the
exegesis thesis other than this prerequisite, the game design and development was allowed
to head in any direction the development team wished. This freedom creates the question,
where do we begin? The concept phase is the phase dedicated to the creation of the game
concept. This can be the trickiest part of game development especially for student and
independent game designers faced with the same freedom to choose their concepts and start
their game design and development from scratch. [Michael, 2003] In the game industry the
concept phase becomes more about formalizing the basis for the game’s design, as concept
creation is more likely to be based logical or obvious decisions based on past business
experiences. [Rabin, 2005] Based on practical experiences from working in groups with fellow
game designers has taught that the concept phase can consume large amounts of time. This
occurs due to the fact game design students tend to adopt a cabal game design process in
favor of appointing a single game designer for obvious reasons. Independent game designers
can also suffer from the democratic nature of the cabal process. The concept phase used in
the exegesis project is an attempt to streamline the concept phase based on previous
experience and game design methodologies.

35
An Illustration of Applied Ludology:
How are Game Design Methods applied to Game Development?

In the exegesis process used, a variation of the content and context analysis model is
used. [Thomassen & Renger, 2005] The use of this new model becomes a scope model. In
this thesis it is referred to the game design and development scope model. This model is the
core to the exegesis project’s concept phase. The concept phase consists of a series of steps
that when used correctly can be used both with a cabal process and an iterative process. The
first step to the concept phase is the creation of a design scope model. The purpose of the
model is setup guidelines that can be used to filter concept proposals. This step is then
followed by the need to generate game concepts. Creating concepts can be accomplished in
numerous ways. Typically brainstorming techniques, mind trees and other such methods are
used. These ideas are then formalized onto paper as a paragraph or two attempting to
describe the game as a high level concept with just enough information to demonstrate the
basic idea of the game. Research is also done during this step to make sure that the concepts
are viable. The result of these two steps should be numerous game concepts to choose from.
These concepts are then evaluated in the following step by filtering them through the scope
model. Once the game design development scope model is applied to a concept, it can be
determined how optimal the game concept is compared to the expectations of the current
game design and development scope model. The final step in this phase is the need to write
a formalized concept document that attempts to define the game even more. It is during the
game design concept document such game design tools such as taxonomy, 400 rules and
game patterns can be used to analyze the game’s concept and help define features,
gameplay, genre and structure.

4.2 The Game Design and Development Scope Model

The concept phase is full of challenges. These challenges are even more complex if you
are required to create a concept from scratch. The concept phase described here attempts to
organize this process to offer the best result by offering the use of the game design and
development scope model. First let us identify the challenges that face us when attempting to
create and choose a concept:
- Time: There is always a time constraint to choosing the best concept.
- Best Concept: We always set out to try to have the best game concept.
- Unanimously: Working in a cabal process requires unanimous agreement from its members.
- Prerequisites: Working for a client can mean that there are prerequisites that must be considered into
game’s concept.
- Design Size: Throughout a game’s development features are dropped as it is realized that the game was
designed too big.
- Over Emphasis: This is when a concept over emphasizes technology, graphics, story or game play.

36
An Illustration of Applied Ludology:
How are Game Design Methods applied to Game Development?

These challenges are met with usage of the game design and development scope model
during the concept phase’s process. Below is a list of the challenges and how they interact
with the game design and development scope model:
- Time: Because the game design and development scope model contains the core expectations of the
game’s design and development the time it takes to determine if a concept is viable decreases. In
essence a concept either fits the game design and development scope model or doesn’t.
- Best Concept: Because of the game design and development scope model, only concepts that fit the
scope model will be accepted.
- Creativity: Because the game design and development scope model is there to help determine the best
concept. The group can focus on making up as many different concepts as possible instead trying to
concentrate on the creation of one best concept that must be deliberated.
- Iterative: Because the nature of the model it can be reiterated as expectations change. The game
concept culling with the game design and development scope model allow concepts that have failed to
pass the game design and development scope model’s culling process to be reevaluated with the scope
model to determine if the iteration to the concept better fits the game design and development scope
model.
- Prerequisites: Easily added to the scope model and removed from the game design and development
scope model.
- Design Size: The game design and development scope model can also include this as a factor which
limits the number of features a game can include.
- Over Emphasis: Because the game’s expectations are determined by the game design and
development scope model, over emphasis can be avoided through referring to the scope model through
out the game’s development.

A game design and development scope model is created to guide game design scope
and development scope. Beginning development with a game design and development scope
model allows the designer or the team to put there expectations of the game into a sort
guideline that can be later referred to for objective analysis. In the case of working with
student groups and independent development groups this model can be used as a tool to
filter concepts. A game design and development scope model consists of two levels; these
are the design level and development level. Each level is made up of scope factors that
describe the expectations of the design and development of the game concept. The design
scope factors determine the expectations of the mechanics, dynamics and aesthetics of the
game design. The development scope factors determine the external factors that the affect
the game’s design. Also included in the game design and development scope model are
scope factors that describe the expectations of the parties concerned in the game
development. These two levels put together act as a refined content and context analysis
model. [Thomassen & Renger, 2005] The Game Design and Development Scope Model
differ from a research project content and analysis model in that the game design and
development become the primary focus.
Making a scope model is a process of collecting the expectations of the parties involved
and reflecting those concerns in the game’s game design and development scope model.
Concerns can range from programming compatibility, to the type of graphics implemented, to
the need for the mechanics, to representing a specific simulated situation, to describing a
particular need of the game’s target group.

37
An Illustration of Applied Ludology:
How are Game Design Methods applied to Game Development?

4.2.1 Exegesis Game Design and Development Scope Model

Figure 21: The Game Design and Development Scope Model used for the exegesis.

Design Scope:
-Meaningful Choices: This is the theory: That if we give the player an option to choose then that option should be a
meaningful choice.
-Humor: This is the content of the game. This was chosen because there is an overall lack of humor in the games
found today.
-Characters over Technology: This is the theory: That if we replace technology names, upgrades and options with
characters, then the player will feel more attached to the game and game events.
-Mechanically Induced Player Interaction: This is the theory: That a game mechanic can force players to interact to
achieve the goal of the game.
-Max. 3 types of Game Play: This is a constraint to keep us from adding too many extra features.
Development Scope:
-MMOG (Massive Multiplayer Online Game): This is the chosen technical form of the game. It has been chosen for
its uniqueness and relation to the thesis subject.
-Careful Planning: Extra consideration for participant’s time will need to be kept in mind.
-Use Game Editor: A game editor needs to be in place that will allow the game designer to adjust and tweak the
game.
-Max. 10,000 players: This is the constraint of the server that is available.

In the exegesis’s game design and development scope model seen in figure 21 we
see two circles. The inner circle is the content or design of the game and the outer circle is
context or the development of the game. The context layer contains issues that concern the
shaping of the development of the game. For example a MMOG genre was chosen as a
scope factor, this was done to insure that game design concepts would fulfill the need to
demonstrate the use of game design methods during development of complex dynamics. This
also meant that any concepts that was not a MMOG was less likely to be considered for the
final concept that was to be developed. The content layer contains scope factors that
influence the game’s design. For example the idea of ‘Characters over Technology’ scope
factor. In many games the player upgrades his equipment or abilities with technology as the
semantic representation. ‘Characters over Technology’ is the concept of replacing the

38
An Illustration of Applied Ludology:
How are Game Design Methods applied to Game Development?

semantic representation from technology to characters with the same abilities. Scope factors
can be the most difficult aspect of the design concept model to determine since these are
primarily subjective, unless a scope factor needs to conform to some prerequisite.
Scope factors for the exegesis project were determined by various resources. For
example factors for concerning design level can be based on things like ‘Meaningful Choices’
which refers to a quote from Sid Meier and humor which refers to the game’s content. Scope
factors for the development level can be determined by hardware limitations or software
limitations. Scope factors can be derived from many sources but a good place to start is by
looking through various game design methodologies such as the 400 Rules, game design
patterns and taxonomy lists. These can all become sources to creating clear scope factors.
Once the game design and development scope model is assembled and the main
factors are known, it is time to apply it to the game concept proposals. The model now acts a
filter that decides if a concept fits the project development’s expectations. This act of culling
concepts allows a development team to swiftly discard concepts that do not fit the scope
factors of the scope model. While this process is still a process of subjective argumentation
as to why a game concept proposal fits the model. The model it’s self maintains an objective
view that allows argumentations a firm base to arise. For example in figure 22 we have team
member A and team member B that present two different game concept proposals. We will
now use the game design and development scope model to cull these concepts. After
analyzing concept A we find it lacking three factors from the concept model awhile concept B
is missing only one. At this point we can consider that concept B fits our design expectations
better than concept A. Now let us say we have a concept C presented and concept D which
both apparently fit all the requirements of the game design and development scope model. At
this point it is time to decide how strongly these concepts fulfill these factors. This can be
done by voting to demonstrate how strong a game concept’s factors appear. Another way to
determine the best game concept is to prioritize the importance of each scope factor and then
determine by rating the game concept proposal by how well it follows the prioritized scope
factors.

Figure 22: The culling process.

39
An Illustration of Applied Ludology:
How are Game Design Methods applied to Game Development?

In the exegesis project there was 4 concept proposals presented during the concept phase.
In figure 23 we see that some of the concepts lacked certain scope factors. In the end we
chose the concept that we thought fulfilled all the factors.

Figure 23: Exegesis concept proposals culled during the concept phase.

4.3 Concept Document Template

The concept document or treatment document is all about sharing the core idea or
concept of the game. This should be done in a two to five page document. Concept
documents carry quick precise information concerning the game and its intended game
design. The concept document is also the point were the concept can be analyzed and
formalized on paper. [Rollings & Morris, 2004] In this section I will discuss the important
elements of the concept document template used in the exegesis are described.

Introduction:
The concept document introduction should be a short paragraph about the game, its genre,
player type, technical form, references and theme. Anyone that reads this should be able to
grasp what the basic idea of the game. [Ryan, 1999] Another purpose for the introduction can
be the reason to demonstrate the understanding of certain prerequisites for the design, such
as scope factor considerations or trade mark history. Here is a short list of subjects to address
in the introduction:
- Genre
- Player Type
- Game Play
- Technical Form
- History
- Reference
- Theme
- Design Intentions (original or cloned)
[Hrehovcsik, 2004i]

40
An Illustration of Applied Ludology:
How are Game Design Methods applied to Game Development?

Game Analysis:
The game concept analysis is a process to understand the game concept and demonstrate
the ability to identify core features of the game. This process of analysis allows the designer
to create an abstraction of the game for an overview of the game. This analysis also becomes
a simple list that identifies the major characteristics of the concept. Below is an example of an
analysis of features based on exegesis game design concept:

Game Analysis
Genre: MMOG/ Strategy/RPG/Management
Game Elements: Resource Management/ Cooperation/ Strategy/ Collection/ Exploration
Game Content: Humor
Style: Cartoon
Theme: Pirates
Player Immersion: Social/ Strategy/ Emotional
Game Sequence: Simulative
Player: +100 Players
Reference: Film: Pirate’s of the Caribbean/ Master & Commander/ One Piece/ The Goonies/ Ice
Pirates/ Sponge Bob Square Pants/ Cutthroat Island/ Farscape/
Books: One Piece/ Robinson Caruso/ Treasure Island/ Kidnapped
Games: Sid Meier’s Pirates/ Pirates of the Caribbean/ Monkey Island
Experience: Cozumel Museum/ Black Beard/ Lafitte
Game Technical
Technical From: 2D
View: Top Down
Platform: Java Script, PHP, Internet Browser
Device: PC
[Mastrigt, 2002]

Gameplay:
This section of the concept document should describe the gameplay. It is helpful at this point
to have gone though game design patterns to help determine some of the game features that
the concept supports. Below is an outline that can demonstrate some of the information in a
gameplay description, while keeping in mind this outline will fluctuate according to the game
design.
- Opening the game application
- Game Options
- Story Synopsis
- Modes
- Game Elements
- Game Levels
- Player’s Controls
- Winning
- Losing
- End
- Why is it fun?

41
An Illustration of Applied Ludology:
How are Game Design Methods applied to Game Development?

Game Atmosphere:
The concept document’s atmosphere is where it is best to have a mood-board or a clear
description of the game’s style. Mock-ups and mock-ups describing gameplay are extremely
useful here. A list of valuable elements is included here:
- Atmosphere Mood-Board
- Character/ Units Sketch & Description
- A Level(Locations) Sketch & Description
- Audio Description

4.4 Game Taxonomy

At this stage we can now use the game taxonomy method. This is a high level frame
work in which to describe the game’s genre, if used properly this can give insight to the core
aesthetic aspect of the game. As a game designer it is valuable to understand the constraints
of the aesthetic concept. For example in Figure 25 we see that the exegesis game tend
towards simulation and game aesthetics, it would then be a critical choice to add a strict
narrative to the game as this would shift the position towards the narrative. While this may or
may not affect the aesthetics of the game, it will make its aesthetics different from the original.
Taxonomy is especially valuable if the concept does not originate from the game designer but
from another source. The high level frame work gives the designer the advantage to
understand the intended direction of the game design. Most of all, game taxonomy is far more
reliable way to understand the game’s genre. [Lindley, 2003] In figure 24 an example of the
game concept chosen for the exegesis is broken down into its genre based on the taxonomy
tool.

Figure 24: Game Classification in the unification plane.

42
An Illustration of Applied Ludology:
How are Game Design Methods applied to Game Development?

Game Taxonomy
Classification: Game/ Simulation
Chance Factor: Medium
World Classification: Fiction
Representation: Virtual

4.5 Game Design Patterns

Lastly the concept document will need to identify the key features of the game concept.
This is an ideal point to analyze your game with game design patterns. Using game design
patterns will reveal the core features that have been used in previous designs. Using game
design patterns is also the point that you hope to point out the unique features that have not
been identified in game design patterns before. Here below is an analysis based on the
features found in Patterns in Game Design that can be associated with the exegesis game
concept:

Social Features Game Features


-Dynamic Alliances -Avatars
-Social Statuses -Asynchronous Game
-Multiplayer

Game Play Game World


-King of the Hill -Obstacles
-Budgeted Action Points -Safe Havens
-Ownership -Never Ending Stories
-Combat
-Damage
-Player Killing
-Exploration
-Rewards
-Asymmetric Information
-New Abilities

4.6 Design for Experience with MDA

‘Design for Experience’ is an essential attitude for the game design process used in
this exegesis. In an interpretation of MDA we focus on the kind of aesthetic experience that is
being created for the player. In the exegesis game design the game experience is ‘Valued
Ownership’ that the player develops with the characters that he collects throughout the game.
This experience is then a direct link to the ‘Characters over Technology’ scope factor in the
game design and development concept model. By analyzing the concept with MDA we are
able to identify the aesthetics of the game. To achieve the aesthetics requires the proper
mechanics that will form the dynamic system the will create the aesthetic experience. In the
concept phase MDA allows the game designer to choose the dynamics and mechanics of the
game that will produce the aesthetic experience for the player.

43
An Illustration of Applied Ludology:
How are Game Design Methods applied to Game Development?

5 Game Design Phase

Figure 25: A visual reference to the design phase.

44
An Illustration of Applied Ludology:
How are Game Design Methods applied to Game Development?

5.1 Introduction

The game design phase requires the use of the most game design methods to create a
cohesive and transparent game design from the game concept. The game design phase
becomes the time allotted to creating a document that will guide the development. It is at this
point that the game designer becomes the advocate for the player and must demonstrate a
solid process for developing a concept into a playable and satisfying game. [Fullerton, Swain
& Hoffman, 2004] The exegesis design phase takes several successful game design methods
and combines them. This is an attempt to make the most optimal approach by taking the
strengths from each, to create a solid process that a good game design and development
requires from the start.

“There is no one “Right” way to game design, but there are many successful approaches.”- Steve Rabin

All efforts in this phase should attempt to minimize the need for changes in the game’s
design in the following development phases. This process also supports the game designer
by allowing significant time to analyze and iterate the game design before initiating
development. The design phase used in the exegesis project is a hybrid in the use of
documentation and prototyping. This process uses many different game design methods for
analysis and structure. The first and primary step of this phase is the need for a game design
document. The game design document at this point should be considered a formalized note
book that is created in such a way that it is easy to update and change as iterations occur.
The next step in this phase is the need to analyze the game design written in the game
design document. This can at first be just reading through the game design document looking
for game design and documentation errors. This often leads to the discovery of overlooked
game design issues. The next step is to run the game design through several analytical
processes with game design methods such as MDA, game design patterns and the 400 rules.
Using these as tools to analyze the game design helps us understand our game design better
and allows us to predetermine possible flaws in the game design. At the end of the analysis
step an evaluation of the game design is made. Based on the evaluation the game design can
be iterated according to newly generated ideas or attempt to fix flaws in the game design
discovered by analysis process. Once the design iterations are completed the game design
can be reevaluated in comparison with the game design and development scope model to
determine if the game design still meets the game its criteria. The next step in the design
phase is to get an impression of the working game design. This is accomplished with a paper
prototype and a software prototype. The paper prototype is used to get a feel for the game’s
dynamics and an understanding of relationships created with the game’s mechanics. The
software prototype is used to get a first look at the game’s featured mechanics and the
aesthetic feel for these features. The iterative process is then applied to the prototypes to
make the aesthetic experience as apparent as possible. Iterations to the game’s design are

45
An Illustration of Applied Ludology:
How are Game Design Methods applied to Game Development?

then documented in the game design document. The iterations continue until the time allotted
to the phase runs out or the game designer feels the game design meets the set criteria. The
last step is to finalize the game design document and compare it to the game design and
development scope model to insure the design continues to fulfill its criteria. The final result of
this phase is to have compiled a clear and concise vision of the game. This vision will be
based on the final game design document, the paper prototype, and the software prototype.

5.2 Using Discourse by Anecdote

This is the hardest method to describe the usage of anecdotes in practical game
design. This is all the knowledge accumulated through reading, interviews, shared
experiences and conversations. Sometimes these anecdotes are testimonies of those that
failed to use a method as sometimes described in postmortems. [Stock, 2006] Sometimes it is
a reminder to insure that the choices given to the player are truly a meaningful choices as
described by Sid Meier. [Rouse III, 2005] Sometimes it is the advice that any content created
should always be seen by the player. [Roberts, 2005] Or it could be the attempts to
consciously use a new verb to create new gameplay. [Crawford, 2005] Using the method of
discourse by anecdote is the method of understanding where certain procedures in one’s
game design originate. It is important for a game designer to understand and know how to
use this abstract information to the benefit of one’s game design. While designing a game
these become quick reference used to make game design decisions. This also gives the
game designer the power to make his own conclusions on game design based on the
anecdotes.

5.3 Using Game Lexicon

While this method’s large goal is meant unify ludology with one vocabulary, this system
should not be ignored by a game designer. What should be emphasized here is the need of a
common language within the process of development. Since the primary purpose is to
communicate the game design to the development team it is important to use a common
vocabulary with consistent terminology. This may seem like common sense but terminology
can vary from development team to development team. For example what some people may
call ‘frictions’ others may call ‘obstacles’ or even ‘puzzles’. [Roberts, 2006] This method is
also a guideline to a structured vocabulary for game designers and can be used when
referring to game elements, rules, objects, properties and actions with consistency throughout
the game design’s documentation. Experience dictates that confusion can cost valuable time
and effort during development. Based on my own surveys the Patterns in Games Design can

46
An Illustration of Applied Ludology:
How are Game Design Methods applied to Game Development?

be considered an excellent source of a defined vocabulary. [Bjork & Holopainen, 2005] In the
exegesis project this method is most visible in use throughout the game design document.
Even with this system in place lexicon issues do briefly appear. Sometimes using the wrong
terminology based on how you perceive a game element can confuse your team. This issued
appeared when a section of our game that was an overview map was called the ‘map’. The
terminology that was better to describe this would have been ‘mini-map’. While this did not
cause any real issues during development we can perceive the consequences if the game
development was on a larger scale.

5.4 Using A Design Document Template

The game design document is the primary source for the communicating the game
design to the development team. The document is perhaps better considered as a note book,
in which the game designer can refer to when asked a particular question about the game’s
design. This document does not necessary have to be a word document or paper document,
the document can even be created online and dynamically. [Kremier, 2003] Regardless of the
game design document’s form, the document must be concise information about the game
design. This can be achieved by having created a thorough game design document template
to help outline the information that typically needs elaboration.

Figure 26: A visual reference of the game design document template.

The game design document template used for the exegesis was created through a
process of research and finally the end result of my internship at Overloaded Pocket Media.

47
An Illustration of Applied Ludology:
How are Game Design Methods applied to Game Development?

The template structure was created with philosophy that the game designer is an advocate for
the player. [Fullerton, Swain & Hoffman, 2004] This focus is also combined with the attitude of
‘Design for Experience’ based upon the MDA approach. A visual representation gives an
example of the game design document template is shown figure 26. The game design
document template that helped guide the creation of the game design document is used for
the exegesis begins by defining the three main game elements. The first element to be
considered is the player element. The player element contains information about the player’s
interaction, rewards, properties, HUD (heads up display) information state, UI (user’s
interface), control, definitions, camera and view. Next the player typically is faced with a
challenge; this challenge is considered the antagonistic element. The antagonistic element
contains information about the antagonist’s properties, information, definitions, AI (Artificial
Intelligence) and behaviors. Thirdly there is typically a space occupied by the game.
Sometimes the space presents its own behaviors, properties and characteristics that can
challenge or influence both antagonistic elements and player elements. This third element is
the global element and a section that defines the properties and boundaries that shape the
game’s playing field or space. Once these element have been determined, the next
component of the game design document template is to explore and structure relationships
between the player, antagonistic and global elements. This is done via the creation of the
architectural flow chart, relationship diagrams, matrices, level design, world design and mock-
ups. This structural information takes the elements and defines them within the game
structure. The next section of the game design document is the atmospheric section that
focuses on the visual, audio and narrative aesthetics. In many cases this section is only
conceptual information for the development team to start from as audio and visual element of
a game is very difficult to document. In the following sections I will describe the core elements
of the template used in the exegesis project. This list is also an example of how the template
document is used as a checklist of standard information that should be described by the
game designer when creating the game design document. If the template is used correctly
then the game designer can focus more on the creative side of the design rather than the
documentation side.

The Game Design Document:


This topic serves to remind the game designer of the need to keep information modular. For
example the game architecture section is a section that focuses on the game related to the
menu screen structure.

Design Version:
This is used not only to keep track of game document versions but also to keep track of
game design iterations and when used properly helps the document become more like a
notebook.

48
An Illustration of Applied Ludology:
How are Game Design Methods applied to Game Development?

Game Design and Development Design Scope Model:


This sets up the guidelines for the game design and development as described before in
earlier part of this thesis, but as a part of the documentation it acts as a reference.

Game Description:
This section is a brief written description of the game, its gameplay and features. This is here
to give the reader a brief overview of the game. A template outline is useful when writing this
section so that again the game designer can focus on the creative writing rather than trying to
remember information that should be in every game design description. Game Design
Description Outline:
- Describe the Menu System
- Describe the Story Synopsis
- Describe the player’s actions
- Describe the player’s rewards
- Describe game challenges
- Describe game world or levels
- Describe how the player wins or loses
- Describe why this is fun

Game Matrix:
Used to have an overview of properties and also used to pre-balance units, enemies and
other game elements. A useful pre-balancing trick is to create a system where properties are
determined by buying them; this is often seen in RPG (Roll Playing Games) such as
Battletech or Advanced Dungeons & Dragons. [MechwarriorII, 1991] This was useful in the
exegesis project while pre-balancing the ships and their property variables. In figure 27 an
example is shown of the matrix used to determine the cost, chance, type, variable and affects
actions have in exegesis game.

Figure 27: An example of a matrix.

49
An Illustration of Applied Ludology:
How are Game Design Methods applied to Game Development?

Relationship Diagram:
Not to be confused with UML, this diagram is used to show interactions within the game
system not the software. This is a useful tool for the game designer to determine if elements
have a significant purpose in the games dynamics. This is easy to determine with a relational
diagram as most games are cycle oriented, if an element is outside this ‘loop’ then it is
probably a loose end that can either be scraped from the game design or rules need to be
change to incorporate it properly. In figure 28 an example of a relational diagram from the
exegesis game design document is shown.

Figure 28: The relationship diagram used for the exegesis game.

Player Element:
This section is one of the prime focuses of the game design document. This section lists the
elements that are directly related to the player, including the player’s reward mechanics.

Player Definition:
This section is a quick definition of what the player is able to do and unable to do in the game.
This section also describes the player as an avatar. For example figure 29 shows a ship, one
of the many possible avatars that could represent the player in the game.
Player Definition:
- What can the player do?
- What information about the game is available
to the player?
- How does the player begin the game?
- How can the player win?
- How does the player lose? Figure 29: A player’s avatar from the exegesis project.

50
An Illustration of Applied Ludology:
How are Game Design Methods applied to Game Development?

Player Properties:
The player’s properties determine what the properties a player will need or use during a
game. For example a ship can take damage from other players so the ship will need hit points
or a health property. Below is a sample list of player properties from the exegesis game:
Ship Properties
- Type: This is the name of the type of ship. Types have preset properties.
- Description: A place to read more info about this object.
- Icon: This will be associated with an action in the action menu.
- Ship Overview: This is a detailed view of the ship from side.
- Name: The player can give and change the name of the ship.
- Gold Cost: This is the cost in gold to buy a new ship.
- Defense: This is a value that affects an Action’s Chance to Hit. A ship with a high defense value can
avoid more Actions.
- Hit Points: When this value reaches 0 the ship is considered sunk. These can be reduced by other
players or by Sea Events.
- Speed: This value influences the cost in Action pts .to move the ship on the Game Map.
- Action: This is the action or actions that this ship type can give you.
- View: This is the range in Hexagons around the ship on the Game Map that allows the player to see
other players.
- Attack Range: This is the area in Hexagons around the ship on the Game Map that allows the player to
use attack actions.

Player Rewards:
This simply describes how rewards can benefit the player’s properties. For example, if a
player collects a pick-up, there is a temporary increase in the player’s properties. Below is an
example of a reward description from the exegesis game:
Bounty
Ship: A larger ship increases your bounty.
Gold: The more gold you have the higher your bounty.
Experience: The higher the Experience Level the more bounty you gain.
Character: Each character adds X amount of bounty to your total bounty score.

UI (User Interface):
The UI or GUI (Graphical User Interface) depending on the game is where the consideration
for the player’s interaction with the software and hardware takes place.

HUD (Heads up Display):


The HUD section is all about information state representation. Information comes in many
varieties in a game. This is something that must always be considered in the game’s design,
since not all game design provide absolute game state information.

Player View:
This section describes what the player will see visually and elements that the player can
interact with as in the case of GUI (Graphical User Interface). In figure 30 we see the main
game map this mock-up for visual reference for the exegesis game.

51
An Illustration of Applied Ludology:
How are Game Design Methods applied to Game Development?

Figure 30: The GUI from the Bounty Kings.

Antagonistic Elements:
This is where a list of antagonistic (enemies, obstacles & opponent) elements should be listed
with graphics, written descriptions and definitions. From experience not all games involve
clear antagonistic elements. A good example is in the exegesis game, where the primary
antagonistic elements are other players. If figure 31 we see the graphic of an antagonistic
element from the exegesis project.

Antagonistic Definitions:
The exegesis project antagonistic elements were mostly obstacles that caused damage to the
player as he passed through a water hex. This becomes essential information that needs to
be defined to create the antagonistic mechanic.

52
An Illustration of Applied Ludology:
How are Game Design Methods applied to Game Development?

Defining an antagonist:
- What can the antagonist do?
- What information about the game is available
to the antagonist?
- How does the antagonist react to the player?
- How does the player optimally over come the
antagonist?
Figure 31: An example of an antagonist from exegesis game.

Antagonistic Properties:
Depending on the game, the antagonistic properties can be similar to the player’s properties.
The biggest difference are the properties needed for the AI (Artificial Intelligence). Below is a
sample of antagonistic properties from the exegesis project:

Sea Event
- Ship Hit Points: The ship loses hit points.
- Lower View: This lowers the range of view by the player while in this hexagon.
- Ship Change Name: The name of the player’s ship is changed to default name.
- Ship Change Flag: The flag of the player’s ship is changed to default flag.
- Disable Character: A character constant action is disabled.

Artificial Intelligence (AI):


This is the section that contains visual mock-ups and written descriptions of the antagonistic
element behaviors. These should be labeled in such a way that they can be used in level
design with out having to describe them again. This is a basic list used as reference in
creating AI action:

- Normal State: What is the object doing if it has not come in contact with the player?
- Detection State: What does it take for this object to detect the player?
- Reaction State: What does the object do as an action after passing the reaction state?
- End State: What happens to the object after player has reacted correctly or incorrectly to object?Global
Game Elements:
In this section it is important to describe the boundaries, neutral objects, camera views and
scale of the world. Neutral game world objects can be things like a static background, objects
that do not interact with the player or antagonistic elements.

Level Design:
Level design in essence should be similar to a small game design documents. In the game
design document short descriptions of the game’s design is enough. Level design should take
place in a separate document. In the project thesis the only level design described is that in
the game’s tutorial.

53
An Illustration of Applied Ludology:
How are Game Design Methods applied to Game Development?

Game Architecture Overview:


In this section the entire game structure is mapped out as a flow chart. This shows the
different screens and how these sections relate to each other in the game. This is also where
the functionality of the menu system is described. Figure 32 is an example of the architecture
created for the exegesis game design document.

Figure 32: An example of the exegesis game’s architecture.

Back Story:
The back story is all the information on which comprises the narrative element of the game.
The information here may or may not be an actual part of the game copy. This is a crucial part
of the creative development of the game since the back story can be a source of depth during
the development of the game.

Concept Art::
This section comprises of sketches and mood-boards. This section is a place that inspiration
can arise but experience says the development team members concerned for the game’s
style will deicide the style devoid of the game design document. In figure 33 the mood-board
used to get a feel for the exegesis game’s style.

54
An Illustration of Applied Ludology:
How are Game Design Methods applied to Game Development?

Figure 33: Mood board created to give artist an idea of the game’s style.

Audio & Sound F/X:


This is an important area and should be carefully reviewed by the game designer. This is
where important feedback relationships with the sounds are noted. This is also where game
ambient and Sound F/X are also listed and described.

5.5 Using MDA

“You are undoubtedly the worst pirate I have heard of.”- Norington
“Ah, but you have heard of me.”- Jack Sparrow [Pirates of the Caribbean, 2004]

The primary use of MDA in the exegesis was to provide the attitude of ‘Designing for
Experience’ or finding the proper way to express the aesthetics by way of the dynamics and
mechanics. MDA provides a unique tool in which to analyze the game as if using a Lens, in
which we can view each component of the MDA framework separately, but also knowing that
they are linked together causally. [LeBlanc, 2004] The first step when using MDA is to
understand the aesthetic experience is the player’s focal point of the game. The exegesis
project’s game aesthetics would be best described as:
- Competition aimed at gaining fame and recognition.
- Fantasy about sailing and pirates.
- Exploration where knowledge of the game world is a distinct advantage.
- Combat that allows the player to customize his strategy.
- Cooperation in order to gain temporary advantages.
- Allowing players expression by choosing their own flag, name, etc.

55
An Illustration of Applied Ludology:
How are Game Design Methods applied to Game Development?

Once we have defined the aesthetics of the game we will now look at the dynamics of the
game. When we set up the dynamics in a flow chart we can see that there are two cycles
occurring. We see in figure 34 that shows how the game’s mechanics interact to create the
dynamics.

Figure 34: Exegesis’s game dynamics flow chart.

In the figure 35 and figure 36 we break down the dynamics into the Mechanics that make up
the dynamics. Figure 35 explains the combat mechanics and figure 36 demonstrates the
mission mechanics used in the exegesis game. An analysis of the game mechanics allows
the identification of the essential parts of the game design. For example, in the two mechanics
shown in figure 35 and figure 36 as a player completes theses cycles the difficult level is
adjusted to accommodate the player’s level of play. This mechanic is in place to specifically
avoid a permanent and dominating player.

Figure 35: The combat game mechanic.


Figure 36: The Mission game mechanic.

56
An Illustration of Applied Ludology:
How are Game Design Methods applied to Game Development?

Figure 37 shows MDA analysis of the exegesis game design in one diagram. This diagram
shows the combat game mechanic in its position within the game dynamics and the aesthetic
value this mechanic induces.

Figure 37: A visual of Bounty Kings analyzed with MDA.

5.6 Using Game Design Patterns

Game design patterns are used during design phase in two ways. The first use is to
use game design patterns as a game design analysis tool, so that we can learn more about
the mechanics that are involved. By understanding the mechanics implemented in the game
and understanding the pattern that they are associated with we can determine how best these
mechanics can be used and what pitfalls are associated with these mechanics.
For example, one pattern that can be associated with the exegesis game is ‘Player
Killing’ meaning that players can knock each other out of the game by combat. This mechanic
is meant to create higher anxiety in the game. A possible pitfall of ‘Player Killing’ is that the
player may not wish to play again, especially if the player feels like he must start the game
over. The game mechanic used in the exegesis allows the player to recover instead of forcing
a ‘Killed Player’ the game over again from the beginning. The second use is to support the
game designer’s lexicon method applied to the game design document. Below is a new
analysis of the exegesis’s game design by using the game design patterns. This analysis is
based on the fully implemented game design formalized in the game design document and
the outcome of iterations based on prototype testing. [Bjork & Holopainen, 2005]

57
An Illustration of Applied Ludology:
How are Game Design Methods applied to Game Development?

Bounty Kings: Game Design Patterns


Social Features Game Features
Dynamic Alliances Alternative Reality
Betrayal Avatars
Cooperation Cameras
Player Defined Goals Buttons
Shared Rewards Communication Channels
Social Dilemmas Downtime
Social Statuses Alarms
Social Organizations Asynchronous Games
Game World
Gameplay Features Irreversible Actions
Score Multiplayer Games
King of the Hill Spawn Points
Status Indicators Survive
The Show Must Go On
Combat Varied Game play
Combat
Contact Missions
Combos Exploration
Damage Damage
Individual Penalties Goal Points
Player Killing Game World Navigation
Preventing Goals Individual Rewards
Interferable Goals
Game World Race
Deadly Traps Rescue
Obstacles Rewards
Outstanding Features
Randomness Harbor
Arithmetic Rewards for Investments
Management Committed Goals
Budgeted Action Points Collecting
Limited Set of Actions Collection
Movement Limitations Competition
Ownership Converters
Delivery
Characters Features Producers
Cards Safe Havens
Character Development
Characters Perceived Design Pitfalls
Asymmetric Abilities Analysis Paralysis
Asymmetric Resource Distribution Camping
Improved Abilities Diminishing Returns
New Abilities Perceived Chance to Succeed
Skills Perceivable Margins
Predictable Consequences
Game Information System Right Level of Complexity
Fog of War Right Level of Difficulty
Freedom of Choice Smooth Learning Curves
Limited Foresight
Asymmetric Information Storyline Features
Clues
Intended Game Features Narrative Structures
Anticipation Never Ending Stories
Emotional Immersion Storytelling
Identification
Immersion
Tension

58
An Illustration of Applied Ludology:
How are Game Design Methods applied to Game Development?

As the game design becomes more mature more patterns can be identified. Another
application of game design patterns is for the game designer to use the patterns as guide
away from patterns to find unique game elements. It is impossible to break loose of patterns if
we are unable to identify them in the first place. Also included in this list of patterns based on
the exegesis game is a list of Perceived Design Pitfalls associated with the patterns that have
been defined. These pitfall patterns will serve as a guideline or checklist while playtesting.

5.7 Using the 400 rules

The 400 rules serve as the ultimate set of guidelines setup by veteran game designers.
This method is used is used twice during the design phase. The first time it is used is when
the first game design is formalized and then examined with the 400 Rules like a checklist to
determine what rules can be applied to the game. The 400 Rules is used again as a checklist
in the design phase to analyze the testing of the prototypes. On the following page is a list of
rules that can be applied to the exegesis’s project:

Rule Name Rule Name


1 Fight Player Fatigue 64 Make the Hunter Become the Hunted
Provide Clear Short-Term Goals Emphasize Acquisition, Cater to Greed
6 66
Let the Player Turn the Game Off Provide Outward and Visible Signs of
7 (note meant for single player games but this 67 Accomplishment
is my point of the MMO)
Maintain Suspension of Disbelief Make Failures Spectacular, Varied, and Cool
10 68
11 Emphasize Exploration and Discovery 69 Provide a Reaction to Every Player Action
Turn Constants into Variables If You See It, You Should Hear It
13 73
Differentiate Interactivity from Non- Set Up Expectations About How Game Works
14 75
Interactivity Then Reinforce Them
Balance Units Starting with the Middle of the Leave Player Wanting More
18 77
Pack
Make the Game Fun for the Player, not the Ruthlessly Minimize Clicks
19 78
Designer or Computer
Don’t Penalize the Player Play the Game Every Day
24 80
Be Consistent in Feedback to the Player Imply More Depth Than is There
28 81
Implement the Hardest Part of the Game Let Players' Actions Leave Lasting Effects
29 85
First
Provide a Consistent Single Vision for the Differentiate Between Game Design and
30 86
Game Experience Design
Use Common Sense When Applying Rules Make the Player Feel Special and Powerful
31 87
Ask "What does the user do?" Respect Each Game Element Equally
32 90
Begin Each Project with a One-Page Trim the Fat
33 92
Specification of the Gameplay
Design to the Medium's Strengths Instead of Use Interest Curve to Identify Dead Spots
37 93
Struggling with its Limitations

59
An Illustration of Applied Ludology:
How are Game Design Methods applied to Game Development?

Every Person and Idea has Equal Worth Write Player Narrative to Identify Problems
41 94
Critique Ideas, Not People Make Consequences of Actions Predictable
42 96
Challenge Assumptions Avoid Dominant Strategies that Trivialize Player
44 97
Choice
Alternate Discussion Between Theme Design Concentric Spaces
45 98
(Story) and Game Mechanics
Game Play Comes First Provide a Framework for Social Interaction
47 99
Simple as Possible Give Player a Way to Measure Progress and
50 100
Clear Indication of How to Become Better
Make the Interface "Desperately Simple" Create Emergent Complexity
51 102
Make Rewards Proportional to the Difficulty Make Common Actions Easiest to Perform
54 103
of the Task Required to Earn Them
Make the Game Appear Fair to the Player Turn Your Limitations into Strengths
55 104
60 Provide Multiple Solutions to Challenges 105 Provide Both Safe and Dangerous Areas
106 Have Fun in the First Minute
Incorporate Tutorial into Gameplay
110
111 Show Character Through Action

5.8 Using a paper prototype

The paper prototype made for the exegesis is a representation of the games dynamics
the player could experience in the game. The paper prototype allows the game designer the
first real evaluation of the game design. From the paper prototype we can learn about the
ease, of which the tester grasps the game mechanics, this is valuable when a game
mechanics or its dynamics are experimental. Determining if players grasp the dynamics of the
game is not entirely the same as the learning curve, this issue is linked with player’s pattern
recognitions. [Koster, 2005]
The paper prototype is used in the exegesis to have a preview of how players interact
with the game mechanics and dynamics. The original exegesis game mechanic for player’s
experience properties was created in such a way that it made it difficult for the players to
understand the mechanics. Playtesters admitted that it wasn’t difficult to understand once it
was explained but they had never seen the experience property represented in this way
before. This resulted in an iteration of this mechanic that ended up treating the experience
property as a resource and thus conforming to the player’s need to recognize the game
mechanic easily. The paper prototype also excels in the ability to allow the designer to begin
pre-balancing game object variables. This is especially useful if the game includes an
economic system or store. The prototype will allow the game designer a better estimation
when adjusting the values of the variables. This also holds true for certain units and their most
prominent properties. For example the paper prototype under went three iterations each time
values were adjusted to reward players for participating in combat after the first playtesting

60
An Illustration of Applied Ludology:
How are Game Design Methods applied to Game Development?

resulted in people only concerned with the missions a secondary mechanic. Iterations also
determined that speed was valued by the players above other ship attributes, meaning that
ships that had a lower speed needed higher compensation in other attributes.

Figure 38: The paper prototype used for the exegesis.

There are number of lessons to be learned about using a paper prototype for gameplay
testing purposes. The first lesson is that a paper prototype is not a game, this is because
what the paper prototype is trying to explore the game’s mechanics and a abstract of the
game’s dynamics. There should be some feel for the game’s aesthetic experience, but this
will most likely be hindered by the bulky nature of the paper prototype. The game after all is
meant for a computer which is a master at calculation. A human playtester is only capable of
so much, which brings up the next issue. A paper prototype needs to be designed in such a
way that it explores the core aspects of the game while cutting away parts that would make it
impossible to playtest as a paper prototype. In conclusion, a paper prototype is not a board
game to be played but requires to be worked through. Testers should be made aware that
they are not ‘playing’ a board game prior to playtesting a paper prototype.

5.9 Using a software prototype

Software prototyping is essential part of game design and development. In the


exegesis project software prototyping plays two crucial roles. The first role was that proving
the technology and skills for the development were sufficient enough to implement the game’s
design. This technique can save the development team a lot of effort if there is a realization
that the game design is beyond the technical level of the development team. An example of
learning about technology from the prototype during the exegesis was that our development
team’s ability to create quick versions of the game was difficult since each time a version was

61
An Illustration of Applied Ludology:
How are Game Design Methods applied to Game Development?

put online, it cost enormous amounts of time. The second role of software prototyping is to
have demonstration of the aesthetic experience of the game design, which becomes a point
for evaluation to base iteration to the game design. In figure 39 we see Henkieland the
prototype game project that served as the exegesis’s software prototype.

Figure 39: A screenshot of the map from Henkieland.

5.10 Using the iterative process

It is important reminder that the iteration process is an attempt to make fewer and
fewer changes to the game design during game development and this is also true in the game
design phase. When the first draft of the game design document is finished, the point is
reached when an analysis of the game design using analysis tools such as game design
patterns and the 400 Rules. This first analysis of the game design should result in the first
series of iterations to the game design during the design phase. The next iteration comes
after a paper prototype is made and worked through. Based on the playtest of the paper
prototype and software prototype, new iterations can be made to the game design document.
During the exegesis project the largest iteration occurred after the paper prototype
playtest when playtesters played more with the game’s secondary game mechanic and
avoided the primary game mechanic. Iterations changed two factors, first the secondary game
mechanic became more prominent as a means to attract players in the beginning and the
second iteration rewarded players for using the primary game mechanic. The paper Prototype
playtesting also determined the need for a tutorial at the beginning the game to give players
their first goals. Iterations as a result of software prototyping came in the form of deciding the
usage of audio but also iterated the UI (user interface).

62
An Illustration of Applied Ludology:
How are Game Design Methods applied to Game Development?

6 Alpha Development Phase

Figure 40: A visual reference to the alpha development process.

6.1 Introduction

The alpha phase is the preliminary phase of implementing the game’s mechanics
together into a software version of the game or an alpha version. This phase allows the game
designer the first preview of the game mechanics functioning together to demonstrate the
game dynamics. As the development of a game progresses, there is less and less of chance
for major changes to the game design, the alpha phase gives us the flexibility for further
iterations during the development process. Based on the game design document and analysis
that defined the game mechanics during the design phase, development begins to implement
the game mechanics needed to create an alpha version. The result of the alpha development
should be an alpha version that shows the featured game mechanics. This alpha version is

63
An Illustration of Applied Ludology:
How are Game Design Methods applied to Game Development?

then playtested, testing should cover the functionality of game mechanics, interaction with
game mechanics and lastly if the mechanics interact correctly to create the game’s intended
dynamics. During this alpha phase the game designer must solve issues by critiquing the
alpha version and playtesting of the alpha version correctly. A useful strategy to back up this
process is using a checklist to analyze the alpha version. The process of looking at the alpha
version should wind down once the game has been evaluated a few times. Ideally this
process ends when the game designer has fully evaluated the alpha version and the alpha
version’s game mechanics meets the game design’s criteria. The final results of this phase
should be a very large ‘to do list’.
This phase also refines game design, allowing the game designer to see the game in
a functioning state. At this point it is important that key game mechanics are not missing as
this can lead to a poor evaluation of the game’s design and cause decisions to prematurely
alter the design based on incomplete game dynamics. This is why it is important to have a
strict definition of a game’s alpha version. Imagine a game like Monopoly, now remove the
money from the game dynamics. As you can well imagine this would alter our perspective of
game dynamics and would be dangerous to alter game mechanics when the game dynamics
are not present. As development goes it can be quite messy and sometimes we are not
offered our perfect alpha version. This is when previous analysis of our game again becomes
useful as it is now possible to identify missing game mechanics that should be present in the
dynamics. This allows the designer a certain amount of objectivity when critiquing the game
dynamics. This can prevent the immediate condemnation of the game dynamics. The game’s
design should at least be allowed to become a skeleton of its design before iterations are
commenced.

6.2 Using the Design Document

During iterations after the evaluation of the alpha version, the game design document
is updated to reflect the changes in the game design. This can seem tedious but since the
game design is now starting its transition into a game, the game design document now
becomes a reference document that keeps track of the changes. This becomes a record of
changes to the game design during iteration cycle or cycles that occurred during the alpha
phase. It becomes important at this stage that the design document has been written so that it
can be updated easily and remain orderly after the update. How well a game design
document is written will become apparent at each iteration step. The key to efficient
documentation for the exegesis game development was usage of the game design document
template which helped to setup the document correctly from the start with a modular
organization that can be easily changed and updated.
An example of use of a game design document during this phase is when a
development team member has a question about the game’s design. As the game designer, it
can be tempting to answer questions about the game’s design from memory, but this is when

64
An Illustration of Applied Ludology:
How are Game Design Methods applied to Game Development?

a game designer needs to find the discipline to refer to the documentation. A good analogy
would be when you go to play a new board game with friends. The friend that owns the board
game explains the rules to the game, later when playing there comes a point when there was
one rule that wasn’t mentioned or worse misinterpreted. The evidence of good design
documentation during the game development for the exegesis is reflected in the smooth
development of the game.

6.3 Using the Iterative Design

Before we start the process of iterative design in this phase there should be an alpha
version of the game with the core game mechanics. With the core game mechanics in place,
the game’s dynamics should be apparent. With the previous conditions met the iteration
process of evaluation, generation and iteration can commence. This process can last more
than one cycle and unless expectations are met then the process should continue until the
game’s dynamics fit expectations. This of course is not a process that can be allowed to
continue forever, so it is important to have this cycle spiral down with fewer and fewer
iterations.

6.4 Using the Game Balancing

The alpha phase is the beginning of macrobalancing process. The object of


macrobalancing is to get the game dynamics closer to the final game dynamics and aesthetic
experience. The process of game balancing is accomplished hand in hand with the iterative
design process. In the alpha version, determining imbalances are usually easy to find. At this
stage we can also apply game theory to beginning the balancing process. If we have given
the player choices we need to determine if any of these choices present an out right
advantage. In figure 41 two charts represent player decision making processes. In the first
part of figure 41 the advantage outcome of deciding upon combat or missions is compared. In
the second part of figure 41 we see the advantages of forming alliances.

65
An Illustration of Applied Ludology:
How are Game Design Methods applied to Game Development?

Figure 41: Reward vs. risk charts based on game theory.

The chart indicates the advantage for new players to form alliances while experienced players
the advantage is to stay alone. Game theory helps the game designer to determine dominate
strategies from the playtesting. Balancing at this stage also determines if the challenges are
too difficult, this will be demonstrated by playtesters becoming frustrated. Frustration is
guaranteed to occur when the player’s interaction is not correctly implemented. In this phase
the amount of macrobalancing needed will be directly related how well the pre-balancing was
implemented. In figure 42 a paper-rocks-scissors situation in bounty kings is demonstrated.

Figure 42: A situation of paper-rock-scissor in bounty kings.

66
An Illustration of Applied Ludology:
How are Game Design Methods applied to Game Development?

6.5 Using the Game Design and Development Scope Model

The Game Design and Development model becomes a useful tool in this phase as it
indicates how well the game design and the development achieved the scope factors.
Depending on the scope factors, the game designer may decide that certain factors no longer
apply and therefore should be scraped. This however depends on how important the scope
factor is to the end product’s goal. In the exegesis project the game design and development
scope model had no urgent scope factor except the need to demonstrate game design
methods. Some of the factors were ignored in the design process to accommodate new ideas
and a better system. This is seen by the current number of current features, where originally 3
features were determined by the original scope model.

67
An Illustration of Applied Ludology:
How are Game Design Methods applied to Game Development?

7 Beta Development Phase

Figure 43: A visual reference to the beta development phase.

7.1 Introduction

If we look at our last two phases; the design phase and the alpha phase, we can use
MDA as analogy to compare these phases. In the Design Phase we are mostly concerned
with the setup of game rules or mechanics. This is then followed by the alpha phase which is
mostly concerned with the system or dynamics created with the mechanics. In the beta phase
everything in development must come together for the aesthetics. While this thesis is primarily
focused on the game design process isolated from the development process, it is important
that in game design and development everything must come together in the beta phase. This
is because the beta phase requires all content to be in place.

68
An Illustration of Applied Ludology:
How are Game Design Methods applied to Game Development?

As beta development begins, game design iterations from the alpha phase will begin
to be implemented. The aim of the beta development is a beta version of the game. The
definition used for the beta version in this exegesis development project is that all content
(graphics, audio, programming, etc.) must be in place. Game design at this stage becomes
very limited as the ability to change game mechanics and dynamics have become finalized.
The primary focus, as described before now brings everything together for the player’s
aesthetic experience. A core part of the beta development is playtesting. Iterations should be
based primarily upon this activity. Once iterations have met the criteria of the game designer
as well as the playtesters, this will lead to the final development and release. The final result
of this development phase should be a version ready for release. Depending on the type of
game there could be a maintenance phase that continues for a time after release. For
example the exegesis project is a MMOG this could mean years of maintenance and game
tweaking as the game grows. The exegesis project was also designed in such away that
content can be continuously added to allow for that growth, but the beta version is the extent
of game design process covered in this thesis.

7.2 Game Balancing and Using a Balancing Checklist

Balancing the exegesis game design at this point was supported by pre-balancing
during the paper prototype stage. The testing did during this period had already helped to
identify balancing problems. Microbalacing becomes the main focus of this phase as
balancing issues become difficult to determine and small adjustments can fix or disturb the
game’s balance. In figure 44 the same ships are shown but with pre-balanced values adjusted
to counter the other’s advantage. It will be these values that will require further tuning as
playtest results indicate minor imbalances.

Figure 44: An example pre-balanced units.

As a final run down of the beta stage this list made for balancing issues was created. This list
can is also be used during the alpha phase but in the beta phase this becomes the checklist
that needs re-checking to be sure these issues have been resolved. Here is the list used in
the project exegesis:

69
An Illustration of Applied Ludology:
How are Game Design Methods applied to Game Development?

Player vs. Player:


- Symmetry
o Balancing achieved by creating algorithms that protect beginning players from advanced.
o Balancing achieved by allowing beginners to form alliances that help beginners advance faster
o Balance by creating safe havens for beginners.
o The amount of variety in the game should make it difficult for players to find absolute
advantages
o Editing tools will allow easy in-game balancing
- Player vs. Gameplay
o Reward is available depending on the risk the player is willing to take.
o Attempt at making the user interaction with game smoother.
o The game does have more than few obstacles meant to cause damage to the player as he
moves about so far balancing suggests it is acceptable.
- Game Play vs. Game Play
o The prototyping phase helped iron out the major unbalances in attributes and variables.
Microcalibration is still needed for perfect balancing.
o No loopholes found yet.
o There is still a concern of a dead end, this can occur if the player runs out of money. We have
placed rules that allow the player to make money by spending action points. This requires
more monitoring.
o Experience point relationship changed to reflect experience level.
o No dominant strategy found yet.
o A tutorial beginning of the game has been included to help the learning curve.
o Usefulness of the alliance is inconclusive, and more testing is required.

7.3 Playtesting

At the time of writing this thesis the exegesis’s beta testing phase had not commenced. The
information illustrated here is based experience and practices used at Overloaded. The two
main methods used for gametesting in this phase are the playertest matrix and a
questionnaire. The circle in figure 45 indicates the reaction of the playertester to the game
after a playtesting session. It can be determined by the location of the circle that while the
game has an amount of mental calculation but it feels like chance plays a role in the game.
The information represented here in the playtest matrix, allows the game designer to cross
reference this information with a previous analysis of the game design. This will determine if
the results of playtest matrix fits the aesthetic experience that the game designer is trying to
achieve. Playtest results in the beta phase will eventually determine the need for an iteration
to occur. Due to the fact that the exegesis game is a MMOG, is likely to need several
iterations to find the proper balance and achieve its aesthetic experience.

70
An Illustration of Applied Ludology:
How are Game Design Methods applied to Game Development?

Figure 45: This is the playtest matrix used to describe the exegesis’s game.

The interview process is another part of playtesting that can be conducted verbally or with a
questionnaire. The exegesis playtesting processes made use of an online questionnaire,
since the amount of playertesters that could potentially participate in the beta testing would be
too many to conduct interviews verbally. The questionnaire is arranged so that it covers the
main topics; Gameplay, Menu Interaction, Controls, Audio, Look and Feel. In figure 46 an
example of an online questionnaire form is shown. The advantages of using this kind of form,
is that it gives the game designer the ability to have an overview of the acquired testing data.
Using the questionnaire and the playtest matrix, allows the game designer the best tools
during the beta phase to achieve the aesthetic experience that was created during the design
process.

Figure 46: Screenshot from questionnaire used for Stella’s Flying School.

71
An Illustration of Applied Ludology:
How are Game Design Methods applied to Game Development?

8 Conclusion

Using game design methodologies over a twenty two week period has resulted in a new
and valuable experience. Understanding the application of game design methodologies and
then attempting to illustrate their practical application has been an intensive period of
reflection of my own game design process. The result of using game design methods during
the exegesis project has only strengthened my resolve to further refine my own design
processes. Surprisingly I found that the use of some game design methods have proven
themselves much more useful than what I had originally anticipated.
Ludology is considered an attitude to the approach of game studies. This attitude is
carried on into applied ludology by studying game design through game development.
Methodologies that support the study of game design should be considered invaluable to any
game designer, especially for the aspirant game designer. Game design methodologies
represent a series of tools in which game designers can choose from and then use to build up
a game design process. In saying that a game designer should apply these as tools does not
require that the game designer be consciously and reflectively aware that he is using a
‘methodology’. Game design like any creative pursuit is based on creativity and no amount of
methodology will replace the creative element. Methodologies do provide tools created to help
us with this creative process.
Game design methodologies can also be viewed as representing the core of what game
designers know about game designing. The methodologies created for game design are the
result of practical experience, refining previous methods or result of in-depth research. Game
design methodologies represent more than a decade of knowledge and for the aspirant game
designer this is a gold mine of knowledge and it should be impossible to ignore the advantage
of learning these methods.
‘Applied Ludology’ is the key word, when discussing game design methodologies. Game
design is only valuable as long is it remains a part of development. This means that game
design methodologies and theory will always have the challenge of remaining a part of the
practical and applicable process of game design and development. This means that game
design methodologies must become and remain firmly within the attitude of ludology as a
study that; researches into design, through design, for design. [Rabin, 2005]
Many of the game design methods covered in this thesis are a result of the past four to
five year, before this time there was very few authorities concerned with applied ludology.
Also, many of game design methodologies also used unconsciously and without the
association to actual name and terminology. It was also apparent from interviews collected;
that many game designers are also heavily influenced by methods derived from software
development and other multi-media. Lastly, interviews have indicated that it was difficult for
my intended sources to separate the game design process from the game development
process, which was needed to support my thesis.

72
An Illustration of Applied Ludology:
How are Game Design Methods applied to Game Development?

As more knowledge is accumulated about game design we can expect methodologies to


evolve. I believe at some level we should always remain aware of this evolution and promote
the knowledge gathered for the overall advancement of ludology. It will be through this
process that ludology will have the chance to become a mature field of study.

73
An Illustration of Applied Ludology:
How are Game Design Methods applied to Game Development?

9 Table of Figures

FIGURE 1: SELLING METHODS II


FIGURE 2: THE LUDOLOGY TREE 1
FIGURE 3: CAPTAIN BARBOSSA 3
FIGURE 4: A VISUAL REFERENCE TO MDA. 11
FIGURE 5: VISIONARY DESIGN COUPLED WITH THE ITERATIVE DEVELOPMENT. 13
FIGURE 6: CABAL DESIGN COUPLED WITH THE ITERATIVE DEVELOPMENT. 14
FIGURE 7: EVOLUTIONARY DESIGN COUPLED WITH THE ITERATIVE DEVELOPMENT. 15
FIGURE 8: ITERATIVE DESIGN COUPLED WITH THE ITERATIVE DEVELOPMENT. 16
FIGURE 9: THE 3 CLASSIFICATION DIAGRAMS: UNIFIED PLANE, UNIFIED GAMBLING SPACE & UNIFIED
FICTION/ NON-FICTION SPACE. 18
FIGURE 10: A ZERO-SUM GAME. 20
FIGURE 11: 3 WAY P-R-S AND 4-WAY P-R-S. 22
FIGURE 12: PLAYTEST MATRIX. 23
FIGURE 13: THE GAME ARCHITECTURE AND DESIGN 28
FIGURE 14: INTRODUCTION TO GAME DEVELOPMENT 28
FIGURE 15: BREAK INTO THE GAME INDUSTRY 29
FIGURE 16: GAME DESIGN WORKSHOP 29
FIGURE 17: THE INDIE GAME DEVELOPMENT SURVIVAL GUIDE 30
FIGURE 18: OVERLOADED PROJECT METHOD 31
FIGURE 19: AN OVERVIEW OF THE EXEGESIS PROJECT PROCESS. 32
FIGURE 20: A VISUAL REFERENCE TO THE CONCEPT PHASE. 35
FIGURE 21: THE GAME DESIGN AND DEVELOPMENT SCOPE MODEL USED FOR THE EXEGESIS. 38
FIGURE 22: THE CULLING PROCESS. 39
FIGURE 23: EXEGESIS CONCEPT PROPOSALS CULLED DURING THE CONCEPT PHASE. 40
FIGURE 24: GAME CLASSIFICATION IN THE UNIFICATION PLANE. 42
FIGURE 25: A VISUAL REFERENCE TO THE DESIGN PHASE. 44
FIGURE 26: A VISUAL REFERENCE OF THE GAME DESIGN DOCUMENT TEMPLATE. 47
FIGURE 27: AN EXAMPLE OF A MATRIX. 49
FIGURE 28: THE RELATIONSHIP DIAGRAM USED FOR THE EXEGESIS GAME. 50
FIGURE 29: A PLAYER’S AVATAR FROM THE EXEGESIS PROJECT. 50
FIGURE 30: THE GUI FROM THE BOUNTY KINGS. 52
FIGURE 31: AN EXAMPLE OF AN ANTAGONIST FROM EXEGESIS GAME. 53
FIGURE 32: AN EXAMPLE OF THE EXEGESIS GAME’S ARCHITECTURE. 54
FIGURE 33: MOOD BOARD CREATED TO GIVE ARTIST AN IDEA OF THE GAME’S STYLE. 55
FIGURE 34: EXEGESIS’S GAME DYNAMICS FLOW CHART. 56
FIGURE 35: THE COMBAT GAME MECHANIC. 56
FIGURE 36: THE MISSION GAME MECHANIC. 56
FIGURE 37: A VISUAL OF BOUNTY KINGS ANALYZED WITH MDA. 57
FIGURE 38: THE PAPER PROTOTYPE USED FOR THE EXEGESIS. 61
FIGURE 39: A SCREENSHOT OF THE MAP FROM HENKIELAND. 62
FIGURE 40: A VISUAL REFERENCE TO THE ALPHA DEVELOPMENT PROCESS. 63
FIGURE 41: REWARD VS. RISK CHARTS BASED ON GAME THEORY. 66
FIGURE 42: A SITUATION OF PAPER-ROCK-SCISSOR IN BOUNTY KINGS. 66
FIGURE 43: A VISUAL REFERENCE TO THE BETA DEVELOPMENT PHASE. 68
FIGURE 44: AN EXAMPLE PRE-BALANCED UNITS. 69
FIGURE 45: THIS IS THE PLAYTEST MATRIX USED TO DESCRIBE THE EXEGESIS’S GAME. 71
FIGURE 46: SCREENSHOT FROM QUESTIONNAIRE USED FOR STELLA’S FLYING SCHOOL. 71

74
An Illustration of Applied Ludology:
How are Game Design Methods applied to Game Development?

10 Index

A
Adam Carpenter.....................................................................................................................19
Advanced Dungeons & Dragons ............................................................................................49
AI 20, 25, 48, 53
Andrew Rollings ...............................................................................................................13, 28
antagonistic................................................................................................................48, 52, 53
Armadillo Run ..................................................................................................................12, 79

B
Battletech...............................................................................................................................49
Bernd Kreimier .........................................................................................................................8
Bounty Kings.......................................................................................................... ii, 52, 57, 58
Break into the Game Industry ..........................................................................................28, 29

C
cabal .......................................................................................................... ii, 13, 14, 16, 35, 36
Capcom .................................................................................................................................21
Chris Crawford .........................................................................................................................5
Chris Taylor ........................................................................................................................ i, 12
content and context analysis model .................................................................................36, 37
cowboy.............................................................................................................................12, 16
Craig Lindley ..........................................................................................................................18
Current Game Design Methodologies .......................................................................................i

D
Daniel Cook ...........................................................................................................................16
Dave Morris ...........................................................................................................................13
Dev66 ..............................................................................................................................32, 33
Doug Church........................................................................................................................6, 7

F
FADT .........................................................................................................................6, 7, 8, 10

G
Gamasutra ...................................................................................................................6, 18, 79
Game Architecture and Design ..................................................................................12, 28, 78
Game Design Perspectives......................................................................................................5
Game Design Workshop ...................................................................................... 12, 29, 34, 78
Game Matrix ..........................................................................................................................49
GIDb ......................................................................................................................................18
Gonzalo Frasca..................................................................................................................1, 79
GUI (Graphical User Interface)...............................................................................................51

H
Hal Barwood ........................................................................................................................5, 9
Half-Life. ................................................................................................................................14
Henkieland .............................................................................................................................62
HKU ...............................................................................................................i, ii, 26, 31, 78, 79

I
Introduction to Game Development............................................................................28, 34, 78

75
An Illustration of Applied Ludology:
How are Game Design Methods applied to Game Development?

J
Japanese ...............................................................................................................................30
Jussi Holopainen......................................................................................................................8

K
Kaizen....................................................................................................................................30

L
ludologist................................................................................................................................10
Ludology ........................................................................................................................1, 2, 72

M
macrobalancing................................................................................................................65, 66
Marc LeBlanc .....................................................................................................................7, 10
MDA................................................................................. 10, 11, 25, 43, 45, 48, 55, 57, 68, 79
Microcalibration................................................................................................................22, 70
MMOG ................................................................................................................... ii, 38, 41, 69
Monopoly ...............................................................................................................................64

N
Noah Falstein.......................................................................................................................5, 9

O
Overloaded ....................................................................................................... i, 31, 34, 47, 78

P
paper-rocks-scissors ..............................................................................................................66
Patrick Burkat...........................................................................................................................6
Patterns in Games Design .....................................................................................................46
Peter Molyneux ......................................................................................................................13
Peter Stock ............................................................................................................................12
Phillips ...................................................................................................................................31
Pirates of the Caribbean............................................................................................3, 41, 55
Player Killing ..............................................................................................................43, 57, 58
Prisoner’s Dilemma ................................................................................................................19

R
RAD .................................................................................................................................28, 29
Robert Zubek .........................................................................................................................10
Robin Hunicke........................................................................................................................10
Rules of Play................................................................................................................5, 16, 78

S
Shigeru Miyamoto ..................................................................................................................13
Sid Meier........................................................................................................ 13, 16, 39, 41, 46
Staffan Bjork ............................................................................................................................8
Steve Rabin ...........................................................................................................................45

T
the 400 Rules......................................................................................................... 9, 39, 59, 62
The Game Design Reader .................................................................................................5, 78
The Game Innovation Database ............................................................................................18
The Indie Game Development Survival Guide ...........................................................30, 34, 78
Tom Cadwell ..........................................................................................................................19

76
An Illustration of Applied Ludology:
How are Game Design Methods applied to Game Development?

U
UI (user interface) ..................................................................................................................62

V
Valve..........................................................................................................................13, 14, 17
Vonk................................................................................................................................... ii, 31

W
Will Wright........................................................................................................................13, 16

Z
Zero Game Studio..................................................................................................................18
zero-sum..........................................................................................................................19, 20

77
An Illustration of Applied Ludology:
How are Game Design Methods applied to Game Development?

11 References

11.1 Books

Rabin, S., Introduction to Game Development, Charles River Media, 2005

Salen, K. & Zimmerman E., Rules of Play, The MIT press, 2004

Salen, K. & Zimmerman E., The Game Design Reader: A rules of Play Anthology, The MIT
press, 2006

Fullerton, T., Swain, C. & Hoffman, S., Game Design Workshop: Designing, Prototyping and
Playtesting Games, CMP Books, 2004

Bjork, S. & Holopainen, J., Patterns in Game Design, Charles River Media, 2005

Rollings, A. & Morris, D., Game Architecture and Design: A New Edition, New Riders
Publishing, 2004

Michael, D., The Indie Game Development Survival Guide, Charles River Media, 2003

Osborne, M.J., An Introduction to Game Theory, Oxford University Press, 2004

Adams, E., Break into the Game Industr: How to get a job making video games, McGraw
Hill/Osborne, 2003

Rouse III, R., Game Design Theory and Practice- Second Edition, Wordware Publishing,
2005

Koster, R., A Theory of Fun: For Game Design, Paraglyph Press, 2005

Mechwarrior II: The Battletech Role Playing Game- Second Edition, FASA, 1991

11.2 Documents & Papers

van Pul, S., Defining a Method for Applying Narrativity in Game Design, HKU-KMTGDD3,
2005

Hrehovcsik, M., Overloaded Project Method, Overloaded Pocket Media, 2004

Mastrigt, J., Game Design and Development Reader: Theorie van Spel en Spelen, HKU,
2002

(i) Hrehovcsik, M., Overloaded Game Design Document Template, Overloaded Pocket Media,
2004

Barwood, H. & Falstein, N., The 400 Project Rule List, GDC06 032306, 2006

78
An Illustration of Applied Ludology:
How are Game Design Methods applied to Game Development?

11.3 Multi-Media Presentations

Barwood, H. & Falstein, N., Rules Worth Breaking, GDC, 2006

LeBlanc, M., Formal Design Tools: Emergent Complexity, Emergent Narrative, GDC, 2000

LeBlanc, M., The Last Mile of Game Design, GDC, 2004

LeBlanc, M., Intuition and Intellect: Deconstructing the Design of Oasis, GDC, 2005

LeBlanc, M., Formal Design Tools: Feedback Systems and the Dramatic Structure of
Competition, GDC, 1999

Hunicke, R., LeBlanc, M., & Zubek, R., MDA: A Formal Approach to Game Design and Game
Research, 2004

Frasca, G., Practical Game Theories: Academics Fragging Developers, GDC, 2004

Stone, S., Paper Simulations of Digital Games, GDC, 2005

Renger WJ. & Thomassen A., Mapping the Journey: Context and Content Analysis, HKU,
2005

11.4 Internet Articles

Carless, S., Gonzalo Frasca Discusses Academia and Political Gaming, Gamasutra, 2004

Kreimeier, B., Game Design Methods: A 2003 Survey, Gamasutra, 2003

Kreimeier, B., The Case for Game Design Patterns, Gamasutra, 2002

Church, D., Formal Abstract Design Tools, Gamasutra, 1999

Bjork, S., The Game Design Patterns Project, Gamedesignpatterns, 2003

Stock, P., Indie Postmortem: Armadillo Run, Gamasutra, 2006

Birdwell, K., The Cabal: Valves’ Design Process for Creating Half-life, Gamasutra, 1999

Larmees, F.D., The Game Design Process, Gamedev, 1999

Danc, Design Testing: The use of addiction metrics to force rapid evolution of innovative
game designs, Lostgarden, 2005

Lindley, C., Game Taxonomies: A High Level Framework for Game Analysis and Design,
Gamasutra, 2003

Carpenter, A., Applying Risk Analysis to Play-Balance RPGs, Gamasutra, 2003

Cook, D., Evolutionary Design: A Practical Process for Creating Great Designs, Lostgarden,
2002

Cadewell, T., Techniques for Achieving Game Balance, Gamasutra, 1999

Sirlin, D., Game Balance: Part 1, Sirlin, 2001

79
An Illustration of Applied Ludology:
How are Game Design Methods applied to Game Development?

Ryan, T., Documentation Milestones and the Development Schedule, Gamesutra, 1999

11.5 Internet Websites

www.wikipedia.org
www.gamasutra.com
www.algorithmancy.8kindsoffun.com
www.ihfsoft.com
www.gamedev.net
www.gamedesignpatterns.org
www.lostgarden.com
www.theinspiracy.com
www.gameinovation.org
www.sirlin.net
www.12manage.com

11.6 Interviews, Surveys & Lectures

van Dinter, H., Game Design Methods Interview, Game Designer: Woedend, Internet, 2005

Roberts, B., Game Design Methods Interview, Game Designer: Guerilla, Amsterdam, 2005

Crawford, C., Games Symposium, Game Designer, Maastricht, 2005

11.7 Movies

Pirates of the Caribbean: Curse of the Black Pearl, Disney, 2004

80

You might also like