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 2 INTRODUCTION GAME DESIGN METHODOLOGY 1 3 3 3 4 5 6 7 9 10 11 12 17 18 19 19 20 22 22 24 26 26 26 27 31 32 33 34 35 35 36 38 40 42 43 43

2.1 INTRODUCTION 2.2 WHAT ARE GAME DESIGN METHODS? 2.3 WHY USE GAME DESIGN METHODS? 2.4 ANECDOTES 2.5 LEXICON 2.6 PATTERNS 2.7 RULES & GUIDELINES 2.8 ABSTRACT TOOLS 2.9 DESIGN DOCUMENT AND TEMPLATES 2.10 VISIONARY, EVOLUTIONARY, CABAL AND ITERATIVE DESIGN PROCESSES 2.11 PROTOTYPING 2.12 TAXONOMIES 2.13 TWEAKING AND BALANCING 2.13.1 GAME THEORY 2.13.2 DESIGN WITH PRE-BALANCING 2.13.3 BALANCING PROCESS 2.13.4 PLAYTESTING 2.13.5 GAME BALANCE CHECKLIST 3 3.1 3.2 3.3 3.4 3.5 3.6 3.7 4 THE EXEGESIS PROJECT INTRODUCTION PROJECT SCOPE GAME DEVELOPMENT PROCESSES EXEGESIS GAME DEVELOPMENT PROCESS EXEGESIS GAME DEVELOPMENT SCOPE CONCLUSIONS PROJECT PROCESS OVERVIEW CONCEPT PHASE INTRODUCTION THE GAME DESIGN AND DEVELOPMENT SCOPE MODEL EXEGESIS GAME DESIGN AND DEVELOPMENT SCOPE MODEL CONCEPT DOCUMENT TEMPLATE GAME TAXONOMY GAME DESIGN PATTERNS DESIGN FOR EXPERIENCE WITH MDA

4.1 4.2 4.2.1 4.3 4.4 4.5 4.6

iii

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

Contents
5 GAME DESIGN PHASE INTRODUCTION USING DISCOURSE BY ANECDOTE USING GAME LEXICON USING A DESIGN DOCUMENT TEMPLATE USING MDA USING GAME DESIGN PATTERNS USING THE 400 RULES USING A PAPER PROTOTYPE USING A SOFTWARE PROTOTYPE USING THE ITERATIVE PROCESS 44 45 46 46 47 55 57 59 60 61 62 63 63 64 65 65 67 68 68 69 70 72 74 75 78 78 78 79 79 80 80 80

5.1 5.2 5.3 5.4 5.5 5.6 5.7 5.8 5.9 5.10 6 6.1 6.2 6.3 6.4 6.5 7 7.1 7.2 7.3 8 9 10 11 11.1 11.2 11.3 11.4 11.5 11.6 11.7

ALPHA DEVELOPMENT PHASE INTRODUCTION USING THE DESIGN DOCUMENT USING THE ITERATIVE DESIGN USING THE GAME BALANCING USING THE GAME DESIGN AND DEVELOPMENT SCOPE MODEL BETA DEVELOPMENT PHASE INTRODUCTION GAME BALANCING AND USING A BALANCING CHECKLIST PLAYTESTING CONCLUSION TABLE OF FIGURES INDEX REFERENCES BOOKS DOCUMENTS & PAPERS MULTI-MEDIA PRESENTATIONS INTERNET ARTICLES INTERNET WEBSITES INTERVIEWS, SURVEYS & LECTURES MOVIES

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

Figure 3: Captain Barbossa

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

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 Game Journalists Game Designers (Computer) Game Inventors (Traditional) Players Sociologists

Anecdotal Text Seminal: classic essay Teachable: educational Significant: focal upon games Relevant: theory vs. practice Diverse: different points of view

Game Design Subjects Player Experience Game Rules Game Dynamics Games and Narratives 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 o o o o o Sharing Knowledge Intuitive Method Minimum Formality Transmits Using Various Mediums Learning from other’s mistakes

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 o o o Consistent Vocabulary Consistent Definitions Game Design Specific Vocabulary 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: Symmetric Goals: Asymmetric Goals: Sets of three or more actions form cycles where every action has an advantage over another action. Players have structurally different goals requiring different tactics and actions. 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. Game elements that give time-limited advantages to the player that picks them up. 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.

Power-Ups: Perfect Information:

Features: FADT o Guidelines for Creating a Game Design Tools

Features: Game Design Patterns o o o o o o o o Collection of Predefined Game Design Patterns Structured Approach to Creation Supports Development of Game Concepts Helps Problem-Solving During Development Game Mechanic Analysis Game Mechanic Comparisons Vocabulary 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 Fight Player Fatigue: Explanation Games are a challenge and playing takes effort — actively work to keep the player involved, and make sure the appeal of your game always exceeds its difficulty. Get the most out of your (always limited) material -either find ways to exploit an element of your game, or cut it out Immersion is easily disturbed -- don't make the player re-calibrate his "suspension of disbelief" and lose touch with your game Players want to participate in the course they take through your game -- so give them plenty of opportunities to voluntarily take up ancillary challenges Domain Basic, Variety, Flow

Maximize Expressive Potential:

Simplicity

Maintain Level of Abstraction:

Psych

Make Subgames:

Basic

[Barwood & Fastein, 2006]

9

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

Features: The 400 Rules o o o o Collection of Guidelines Game Feature Analysis Game Feature Comparison 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 o o o o Game System Analysis Game Mechanics Analysis Game Experience Analysis Supports Iterative Process 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-inprogress. 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 o o o o Game Design Communication Flow Charts Relational Diagrams Matrixes Mock-ups

Game Design Template Document Features o o o Archetypical Game Design Document Reference 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 o Singular Vision Game Design is Game Designer’s Domain

Features: Cabal Design o o Wide Range of Solutions Wide Range of Expertise

Features: Evolutionary Design o o o Continuous play-testing during development Continuous iterations during development Optimal Aesthetic Experience

16

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

Features: Iteration Design o o o Continuous play-testing during development Continuous iterations during development 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 o Quick Results Evaluation of Game Mechanics

Features: Software Prototyping o o Evaluation of Game Mechanics in Analogue 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 o o o Game Concept Analysis Game Genre Analysis Game Feature Analysis 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-PaperScissor 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-RockScissor 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?

Gamers will uncover any and all relevant equations and formulas. Gamers will find bugs and "features" that the developers never knew about. Gamers will use features in bizarre ways never envisioned by the developers or even the testers. 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.

1. 2. 3. 4.

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 microcalibration. 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 o o o Tweaking Choices Models Understanding Player Choices AI (Artificial Intelligence) Design

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

Features: Balancing Process o o o o Macro-calibration Micro-calibration Compatibility with Iterative Process Compatibility with MDA

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

Features: Game Balancing Checklist o o o Concepts References 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 Time: Deliverable: Team: Budget: Genre: 22 Weeks Beta Version Ability to achieve beta technical level None Complex enough to justify game design methods Parameters

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 Time: Deliverable: Team: Budget: Genre: 22 Weeks Beta Version 1 Full-time Member 5 Part-time Members €1,000.00 Euro MMO/TBS/RPG Parameters

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

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

x

x x x x

x

x

x x

x

x x x

x x x

x x x x x

x x x x x x x x x x x

x

Iterative Process

Game Balancing

Iterative Testing

Alpha Version

Other Testing

Beta Version

Architecture

Hard & Soft

Production
Exegesis Project Process

x x x x x

x x x

x x x x

x x x x

x x x x x x x x x x x x

x

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

x

x

x

x

x

34

Playtesting

Debugging

Release

Gold

Techniques

Document

Research

Scope

Model

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: Game Elements: Game Content: Style: Theme: Player Immersion: Game Sequence: Player: Reference: MMOG/ Strategy/RPG/Management Resource Management/ Cooperation/ Strategy/ Collection/ Exploration Humor Cartoon Pirates Social/ Strategy/ Emotional Simulative +100 Players 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 2D Top Down Java Script, PHP, Internet Browser PC

Game Technical Technical From: View: Platform: Device: [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: Chance Factor: World Classification: Representation:

Game/ Simulation Medium Fiction 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 -Dynamic Alliances -Social Statuses Game Play -King of the Hill -Budgeted Action Points -Ownership -Combat -Damage -Player Killing -Exploration -Rewards -Asymmetric Information -New Abilities Game Features -Avatars -Asynchronous Game -Multiplayer Game World -Obstacles -Safe Havens -Never Ending Stories

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

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

59

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

41 42 44 45 47 50 51 54 55 60

Every Person and Idea has Equal Worth Critique Ideas, Not People Challenge Assumptions Alternate Discussion Between Theme (Story) and Game Mechanics Game Play Comes First Simple as Possible Make the Interface "Desperately Simple" Make Rewards Proportional to the Difficulty of the Task Required to Earn Them Make the Game Appear Fair to the Player Provide Multiple Solutions to Challenges

94 96 97 98 99 100 102 103 104 105 106 110 111

Write Player Narrative to Identify Problems Make Consequences of Actions Predictable Avoid Dominant Strategies that Trivialize Player Choice Design Concentric Spaces Provide a Framework for Social Interaction Give Player a Way to Measure Progress and Clear Indication of How to Become Better Create Emergent Complexity Make Common Actions Easiest to Perform Turn Your Limitations into Strengths Provide Both Safe and Dangerous Areas Have Fun in the First Minute Incorporate Tutorial into Gameplay 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

Sign up to vote on this title
UsefulNot useful