Asbjoern Thesis

Game design and development - asbjoern@asbjoern.
com
1.
Introduction ........................................................................................................ 4
1.1. 1.2. 1.3. 1.4. 1.5. THE FOCUS OF THIS THESIS .................................................................................................. 6 EMPIRICAL STUDY ................................................................................................................ 7 THEORETICAL FIELD ............................................................................................................ 8 ESTABLISHING A FRAMEWORK FOR GAME DEVELOPMENT ............................................... 10 SUMMARY .......................................................................................................................... 11
2.
Game Developer Postmortems ...................................................................... 13

2.1. 2.2. 2.3. THE GD POSTMORTEMS AS EMPIRICAL MATERIAL ........................................................... 14 METHOD FOR DATA COLLECTION AND IDENTIFYING THEMES IN POSTMORTEMS ........... 15 DESIGN............................................................................................................................... 17 Design document...................................................................................................... 17 Vision and high-level design .................................................................................... 18 Collaborative design ................................................................................................. 20 Level design and feature management...................................................................... 22
2.3.1. 2.3.2. 2.3.3. 2.3.4. 2.4. 2.5. 2.6. 2.7.
PROTOTYPING .................................................................................................................... 26 PLAYTESTING ..................................................................................................................... 28 PLANNING ......................................................................................................................... 31 SUMMARY .......................................................................................................................... 33
3.
Project management in a drifting environment .......................................... 35

3.1. 3.2. 3.3. 3.4. 3.5. 3.6. ENVIRONMENTAL DRIFT.................................................................................................... 36 EMERGENT ORGANIZATIONS ............................................................................................ 38 MANAGING SOFTWARE PROJECTS IN A DRIFTING ENVIRONMENT .................................. 45 AGILE SOFTWARE DEVELOPMENT .................................................................................... 47 MINIMIZING THE COST OF CHANGE .................................................................................. 50 SUMMARY .......................................................................................................................... 54
4.
Establishing a game development framework ............................................ 56

4.1. 4.2. GAME DESIGN AS ITERATIONS ........................................................................................... 56 PREPRODUCTION ............................................................................................................... 58 Publishable Demo and Macro Design ...................................................................... 58 A Front Loaded Development Model for game production ...................................... 64
4.2.1. 4.2.2. 4.3. 4.4.
DESIGN RULES AS A MANAGEMENT TOOL ........................................................................ 64 COLLABORATIVE DESIGN .................................................................................................. 67 The Pre-Cabal Process .............................................................................................. 67 The Cabal Process..................................................................................................... 68
4.4.1. 4.4.2.
Game design and development - asbjoern@asbjoern.com
4.4.3. 4.5. 4.6. 4.7.
Collaborative Design Summary ............................................................................... 69
PLAYTESTING ..................................................................................................................... 70 PLANNING ......................................................................................................................... 72 SUMMARY .......................................................................................................................... 77
5.
A game development framework proposed................................................ 79

5.1. 5.2. PREPRODUCTION ............................................................................................................... 80 PRODUCTION ..................................................................................................................... 82
6.
Concluding remarks ........................................................................................ 85

6.1. 6.2. 6.3. 6.4. 6.5. PROJECT MANAGEMENT, AGILE PRACTICES AND GAME DEVELOPMENT COMBINED ....... 86 THE PREPRODUCTION PHASE ........................................................................................... 87 THE ASSET PRODUCTION PHASE ...................................................................................... 87 FUTURE WORK ................................................................................................................... 88 FINAL REMARKS................................................................................................................. 89
7.
Literature........................................................................................................... 90
7.1. 7.2. POSTMORTEMS REFERRED TO IN THE ANALYSIS................................................................ 92 POSTMORTEM OVERVIEW .................................................................................................. 93
8.
Appendix........................................................................................................... 97
8.1. SOFTWARE DEVELOPMENT MODELS .................................................................................. 97 Waterfall model ........................................................................................................ 97 Modified Waterfalls .................................................................................................. 97 Code and Fix............................................................................................................. 97 Spiral Model ............................................................................................................. 98 Evolutionary Prototyping ........................................................................................ 98 Staged Delivery ........................................................................................................ 98 Evolutionary Delivery.............................................................................................. 98 Design-to-Schedule .................................................................................................. 99 Design-to-Tools ........................................................................................................ 99 8.1.1. 8.1.2. 8.1.3. 8.1.4. 8.1.5. 8.1.6. 8.1.7. 8.1.8. 8.1.9. 8.2. 8.3.
BALDURS GATE II DESIGN RULES ..................................................................................... 99 RPG COMMANDMENTS DESIGN RULES USED IN TH DUES EX PRODUCTION (SPECTOR 101 TRUEX ET AL. 2000 TABLE 1 ............................................................................................ 102
1999) 8.4.
1. Introduction
This thesis aims to propose a new model for game development. I will improve the methods used in contemporary game development by combining literature on project management and agile software development practices with game development methods. The thesis is divided into three main sections, 1) an empirically founded analysis, 2) a theoretical discussion and 3) the establishment of a methodological framework to game development. These are briefly explained below. 1. The empirical discussion is based on a study of game development projects described in Game Developer (GD), also known as GD Postmortems. 2. The theoretical discussion is based on contemporary literature within the field of project management/economic theory, traditional plan driven software development and agile software development methodologies. 3. The third section combines the theoretical discussion and the analysis with concrete game design and software development methods. This structure will help shed light on both the practice field and the theoretical field. The analysis of the GD postmortems serves to identify the most prevalent problems within the practice field of game development. The theoretical discussion of software development methodologies and project management helps map the surrounding environment. The ambition is to bridge the knowledge gained from the GD postmortems and contemporary project management theory in order to set the scene for the establishment of a framework for game development. It is my hope that the reader of the thesis will be inspired by my view on game development, either as a development staff member wishing to gain 4
insight in methodological aspects of the game development process or as a manager desiring to reduce project risk.
Asbjrn M. Sndergaard Copenhagen, Denmark 2006
1.1. The focus of this thesis

Right now, thousands of people are working on numerous game development projects. Aside for all the projects being over budget, delivering late only a small percentage of the games will provide a positive Return on Investment (ROI). In a recent market forecast, Screen Digest predicts that as few as 80 console titles a year will have a positive ROI (Gibson et al. 2005). One of the authors of Gibson et al. (2005), Marc de Gentile-Williams, comments:
"At 30 years of age, the games industry still suffers from an endemic lack of professional management compared to less mature industries such as the mobile telephony and the internet industries. The high number of bankruptcies - despite favourable market conditions - is testament to this fact. Games companies must complement their formidable creative and technological achievements with strong business planning and analysis in order to reap the benefits of the next phase of console market growth" 1
One of the big questions when discussing video game productions from a management perspective is why so many productions fail to provide a positive ROI. Part of the explanation should be found in an extremely hit-driven market. The gaming market distinguishes itself from other leisure markets such as film production by being extremely hit driven. The top ten video games provide 85% of the entire industry revenue. This leaves a void market between success and failure. Either the game provides a huge ROI or no return at all. One of the problems within the video game market is the minimum production costs. Like it is the case with animated movies, production costs are not easily downscaled. Games have to meet the market demands for improved graphics, physics etc. to be considered a high-end product. Development costs in the next generation consoles are set to rise from $3 -$6 million per title to $6-$10 million, with some cases surpassing $20 million (Gibson et al. 2005). This leaves projects that fail to reach top ten sales charts with a poor change on generating a positive ROI.
http://www.screendigest.com/reports/05_games_s_pub/FHAN6J6PR9/pressRelease%20.pdf
1
While it is worth discussing whether this is healthy for the industry or not, it is not debatable that publishers and developers need to adjust to this situation. One of the problems faced is that it is difficult for publishers to predict future development in the market. In response to this, numerous titles are launched in the hope that a small percentage of the titles will become blockbusters covering the losses of the rest. The problem with this strategy is that it is difficult to control and predict which titles are going to be successful. Therefore both publishers and developers are extremely exposed to risk, since none of their titles are guaranteed success. In this sense, there are two sides to the problem: Schedule slippage and budget overruns and an extremely hit driven market. Since it is difficult to change the market, and consequently the criteria of market success, publishers and developers have to evolve their business and production methods. In short, the problem can be reduced to two issues, developers have to find ways to reduce the risk of schedule slippage and budget overruns, and publishers have to find ways to adjust to the surrounding market more efficiently. In order to refine this problem I will give a brief introduction to the empirical and theoretical findings in the thesis. Following the scope of the problem can be reduced.
1.2. Empirical study

Before going into a discussion of how to reduce schedule slippage and budget overruns, the problem as such will have to be examined thoroughly in order for us to get a better understanding of it. In this thesis an analysis of the GD postmortems serve to identify the biggest problems to schedule slippage and budget overruns. In the GD postmortem analysis, four problems that are causing budget overruns and slipped schedules will be identified. Firstly, problems arise because of the lack of design documentation and vague vision statements 7
before the projects go into full production. Secondly, poor communication of the vision causes communication breakdown and asset reworks. Thirdly, difficulties arise in estimating tasks and validating progress. Fourthly, lack of continuous testing makes it difficult to track project progression. The identification of these four problems helps narrow the scope of the theoretical field, since the theoretical discussion must consider the prevalent problems in contemporary development practices.
1.3. Theoretical field

In the next part of the thesis I will introduce the postmortem analysis into a broader market perspective. The aim is to establish a better understanding of the market surrounding the game development process and ultimately to highlight ways to adjust to the surrounding market and enable publishers to reduce project risks. Not all problems inherent in the game industry are unique to game development. Some of the problems with game development are also problems in the rest of the market. The current market, which is based on a global economy changes rapidly. Rapid changes in the market are driven by rapid changes in demands. In order to cope with these changes products and organizations have to adapt to the market (Bettis and Hitt 1995, Nonaka and Takeuchi 1995, Kreiner 1995, Truex et al. 1999). Consequently, when managing a business project these fluctuations in the market have to be considered. According to Lessard and Miller (2001), a successful strategy to managing this process is to focus on making project decisions reversible. The future value of a decision will not be known in the present, since the market might shift, thus making the product obsolete before it reaches the market. Therefore, the value of a decision made at present will be higher if it can be reversed in the future. In this sense, the present value of a decision is dependent on the cost to alter it in the future. The relationship between fluctuations in the market and product 8
development is important to understand before going further into the discussion of game development and software development in general. The rapid change in the market makes it difficult to foresee future market demands. The longer the project period, the more likely it will be that the project will be affected by the turbulent market. This poses a dilemma to all project stakeholders: How can the project be planned and contracts made if no deterministic forecast of the future can be made? Effective project investors should be cautious when making irreversible commitments, but they must also recognize that they must make such commitments eventually. As project investors commit to a project, they lose degrees of freedom, increase their exposure to potential losses, and lock their claims on eventual rewards. To support this process project risks must be identified early in the project. The management goal should be to uncover the boundaries of the project and remove uncertainty. Uncovering the project boundaries also means investing upfront to uncover project uncertainty. From a project management perspective the response to the drifting market environment is to front load the project risks. Front loading project risks is done by attacking the most risky and uncertain elements in a project first. In this sense, focus in the early stages of the project is on making decisions reversible in order to uncover project risks. Within the software development field some methods have already been successfully applied to front load project risks. A new branch of software methodologies called agile software development methods are based on this understanding of the market. Agile practices focus is on adapting to the market (Beck 1999a, 1999b, 2001, 2003, Beck and Boehm 2003, Fowler 1999, 2000a and 2000b, Beck and Fowler 2001, Fowler and Foemmel, Beedle and Schwaber 2002, Fowler and Taber 2001 2 ). One of the reasons why agile methods are able to
The primary inspiration from agile methodologies in this thesis is based on extreme programming (XP) with Martin Fowler and Martin Beck as the dominant contributors and Scrum with Ken Schwaber and Mark Beedle as the main contributors.
adapt to the market is because they focus on small incremental milestones adding functionality to a working release. The speedy updates of the working software enables project owners to make continuous adjustments in the development schedule based on development in the surrounding market. Agile methods have proven successful in traditional software projects dependent on rapid changes in the market. The game development industry shares these characteristics, e.g. when a genre defining game comes out the entire market is affected. However the game development process distinguishes itself from traditional software development in three important phases: preproduction, design and asset production. In the preproduction or requirement specification phase not only technical but also creative risk is present in game development. The design phase is not only concerned with program architecture but also gameplay, design of graphics, sound and so forth. In traditional software projects the main concern in the asset production phase is code production, in game development additional assets such as graphics, sound etc. have to be produced. In consequence we will need to refine the front loaded development model to incorporate the risks faced in a game development project. The reduction of these risks will enable developers to more efficiently plan and manage projects, ultimately reducing the risk of slipped schedule or budget overruns. While small continuous updates of a game will not enable the publisher to release the full game sooner to the public, the incremental milestones would enable publishers to steer the project thorough fluctuations in the market.
1.4. Establishing a framework for game development

After discussing how project managers should understand the surrounding environment and identifying the most prevalent problems to slipped schedules and budget overruns, we can now establish a front loaded development model 10
for game development. The important thing is to establish a development framework that can actively address the issues uncovered in the postmortem analysis and incorporate a front loaded project model needed to adapt to a drifting market. Cerny and Johns (2002) preproduction model helps address the first problem in the postmortems analysis in that it prevents the team from entering into full production before a demo of publishable quality is produced along with a Macro Design. Most of the problems related to lack of design documentation and vague vision statements can be avoided by following Cerny and Johns (2002) guidelines. Furthermore Cerny and Johns (2002)
preproduction model helps front load project risk by creating a demo of publishable quality. The next problem from the postmortem analysis was that poor communication of the vision causes communication breakdown and asset reworks. A solution to this problem is the use of Design Rules to communicate the vision to the team. The last two problems identified in the postmortem analysis are closely related. The problems are; difficulties with accurately estimating tasks, validating project progress combined with lack of continuous testing, making it difficult to track project progression. The solution to these problems is a model of Valve Softwares Cabal Process and Beedle and Schwabers (2002) Scrum model combined.
1.5. Summary
After this brief introduction, we can now narrow the scope of the thesis. Firstly, the main difference between game development and traditional software development can be limited to three phases of the production cycle: the preproduction, the design, and the asset production phases. Secondly, we have limited the theoretical field by establishing an understanding of 11
contemporary project management theory and agile software development methods. We have shown that it will be beneficial to combine these with game development methods in order to address the challenge faced by the game industry. Lastly, the GD postmortem analysis serves as an empirical source. The insight in contemporary development practices enables us to explain why developers run over budget and slip their schedules. This knowledge will be used to refine the theoretical understanding. After limiting the scope we can refine the initial problem proposed:
How do we combine agile practices with game development methods and project management theory in order to improve the understanding of the preproduction phase, the design phase and the asset production phase? Furthermore, how can we utilize this knowledge to find solutions to prevalent problems identified in GD postmortems?
Throughout this thesis I will seek to answer this question, and in doing so I will propose a new model for game development.
12
2. Game Developer Postmortems

Game Developer (GD) is one of the most renowned magazines in the game development community. It is a non-academic journal on game development targeted towards game developers. Each month GD features a game development project postmortem. A GD postmortem is an article discussing what went right and what went wrong in a given video game development project. All postmortem articles follow the same basic structure; a short introduction to the game, five things that went right and five things that went wrong. Over the years these postmortems have been one of the most important resources to first hand experiences on game development. It is important to note that almost all the projects discussed in the GD postmortems have resulted in hugely successful games 3 . Compared to the market in general the games reviewed in the GD postmortems must be considered blockbuster titles. In this sense the GD postmortems reviews features some of the most successful developers, working on some of the most successful games. Using this argumentation it would seem likely that repeatedly appearing problems encountered in the GD postmortems are likely to be general problems within the industry as a whole. The projects described in the GD postmortems are far from flawless. The room for improvement is immense. The important thing with GD postmortems is that since the postmortems feature the industries most successful developers, the problems they describe are likely to by genuine problems throughout the industry. While examining the past six years of Game Developers postmortems and several of the postmortems available at Gamasutra.com (approx. 85), it is clear that themes evolve over the years. Issues tend to move from the what went wrong columns to the what went right columns. An example of this is the
Examples could be Diablo II, Age of Empires, The Sims 2, Ratchet & Clank, Black & White just to mention a few.
13
discussions of feature creep and scheduling problems, which seems to be less of a problem to developers now than it was six years ago. Hence, the postmortems and development methods are slowly but steady maturing, and when observed on a six year timeframe these improvements are significant.
2.1. The GD Postmortems as empirical material

The postmortems are in their nature of being project postmortems context specific. This is extremely valuable since the insight into the specific project helps put the issues discussed in perspective. But, being context specific also limits the general usefulness unless the knowledge is carefully analyzed and incorporated into a specific development model. The aim of the postmortem analysis is to collect the knowledge from the last six years of postmortems and incorporate them into such a framework. Throughout the analysis I will identify pitfalls in current development practices. The goal of the postmortem analysis is to identify the most prevalent problems within contemporary development practices. However, before going into further detail with the analysis a number of reservations regarding the validity of the knowledge gained from the post mortems need to be addressed. I have five main reservations. 1. Different authors of each postmortem. In result, the issues discussed vary from problems related to being a startup company to postmortems solely dedicated to music and sound effects. It is difficult to know what information was left out. 2. No validation of the authors skill level. 3. No fact validation. Everything stated in the postmortems must be assumed to be truthfully. This can however not be checked. 4. Authors level of self-criticism. Although some of the examples from the postmortems indicate that the authors also deal with the parts of the process that went wrong the most. This can not be validated 14
since we do not have any other first hand knowledge of the production process. 5. Different platforms and genres. Since the postmortems deal with anything from PC, Console games to GameBoy Advance games. Far from all the postmortems are relevant in the context of this thesis.
2.2. Method
for
data
collection
and
identifying
themes
in
postmortems
This section will shortly describe how I have structured the data collected from the GD postmortems. At the first reading of the postmortems I collected notes on issues that I believed could have a general interest. For example considerations regarding successful/unsuccessful design practices, but not specific design implementations. General considerations regarding tool development but not how a specific script language worked well. Gradually, themes emerged as problems/situations reappeared. Each time a problem was identified the meaning was condensated into note form, using the meaning condensation method described by Kvale (1996:192). After this first rreading, I had condensated the postmortems into approximately 50 pages of notes. Based on these notes I identified the themes that I believed covered the processes most critical in producing a successful game. These themes are of course heavily interrelated and the importance of each theme may wary depending on which type of production that is in question. For instance the success of an adventure game will be more dependent on story, than a real time strategy (RTS) game. Subsequently, the success of a RTS game will be more dependent on gameplay balancing tests than the adventure game. This is not to say that story is not important to a RTS game, but the importance of a given game element such as a story may vary depending on the game genre.
15
The focus in the theme selection process was to identify the common themes that should be considered in order to minimize project risks. During this review the following themes emerged: 1. Design Theme: Methods for developing and guiding the projects creative vision, be it technical gameplay mechanics or graphical representation. Ultimately all creative decisions. In the analysis the design issues are divided into: Design document, Vision and high-level design, Collaborative design and level design and feature management. 2. Prototyping i.e. processes for testing ideas and technology in a working model in order to test various aspects of the design. 3. Playtesting i.e. testing procedures, different methods for playtesting, how these methods are incorporated into the development process. 4. Planning i.e. pitfalls when scheduling, estimating project scope and risks. After restructuring all the condensated notes into these themes, the actual analysis could begin. During this analysis all condensated sentences were rechecked with the original sources before being incorporated into the final analysis. In this way inconsistencies between meaning condensated notes and actual source could be recognized and corrected. The consistency in the empirical data was established according to carefully considerated principles, thus it must be stressed that the selection process and subsequently the analysis are my subjective interpretations. Hence, my postmortem analysis is a qualitative study; the intent is not to collect verifiable statistics. The themes listed above were the ones I found the most relevant to the development process. After restructuring the notes into these themes approximately twenty-five pages of meaning condensated notes were discarded, because they did not meet these final selection criteria. In this way the themes were used to limit the scope of the study. The rest of this chapter is the result of this process.
16
2.3. Design
Game design is not surprisingly the single most debated theme in the postmortems, since the design is what ultimately sells the game. Hence creating a successful design is critical to every development projects. Although great ideas seldom are generated purely from standardized methodological procedures, there are a number of actions that can be taken in order to improve the probability of creating an innovative and unique user experience. Methods can be applied in order to spark inspiration when creating the initial vision. Methods can help communicate the vision to the team in order to ensure the implementation is as smooth as possible. Techniques can be applied in order to ensure that the team buy-in to the projects vision. 2.3.1. Design document A noticeable thing, when studying the discussions on the use of design documents, is how a number of projects seem to skip design documentation. At the Diablo II project they never had a design document, just a rough plan. It is however unclear how much of a design document this plan covered (Shaefer 2000). The problem with this approach is that when design fails to be formally documented, it is hard to identify clear guidelines for code and assets production. This can result in costly asset reworks and may pose problems to making proper estimates (Upton 1999). Similar to this problem is the problem of not having a design document before entering full production. At the Spiderman production, an inadequate initial design resulted in rudderless process where documentation for AI, visual references and so forth was made late in the process (Fristrom 2002). The Project Gotham Racing 2 team worked with an incomplete design document resulting in continuous updates even after feature freeze (Pickford et al 2004). Likewise initial lack of design documentation at the Kohan production caused the design document to never really be used and consequently never updated (Chaneleh and Papp 17
2001). In parallel to this people at the Big Mutha Trucker production did not read the design document because the information they needed was not there or not easily found (Jobling 2003). Another issue when documenting design is the level of detail. It is essential that the design issues are indisputable before the actual implementation begins. This proved to be important in the production of Fall Out Tactics, where the lack of detail in the design documentation before the actual implementation started resulted in ad hoc design decisions made outside the design team (Oakden 2001). The lesson learned is: Do not design every thing in advance but make sure the essential design is made before the actual implementation begins. Alike the lack of documentation on paper at the Operation Flashpoint production meant that tasks could only be preformed by the person who knew the task (Spanel and Spanel 2002). From a production management perspective it is imminent that a formalized work process model for documenting game design is crucial if major asset reworks are to be avoided. The two most prevailing problems with design documents are: incomplete design documentation before going into full production and the lack of a formalized work process model for documenting game design. If these two issues are not addressed early in the process the risk of major asset reworks is high. 2.3.2. Vision and high-level design Closely related to the discussion of the initial design documentation, is the discussion of the vision for the project. In general, a clear vision before entering full production is noted in a number of postmortems as a key factor of success 4 . When everybody on the team is on the same page creatively and agrees on core features, the team will be able to fill gaps in the design later on. The Rainbow
See Reinhart 2000, Hubbard 2001, Pickford et al. 2004, Morgan 2004, Upton 1999, and Blossom et al. 1999
4
18
Six production team succeeded because of this, even though no design document was ever written (Upton 1999). But, as mentioned earlier a lot of assets had to be reworked because of the lack of documentation. Even though it seems obvious that a project needs a vision in order to have a sense of direction, this is something you will have to work with. A team does not automatically share a vision. At the Tropico production the team all thought that they shared a common vision, but ultimately they found they did not. As people felt that their ideas were cut or did not understand why certain decisions were made they lost buy-in 5 . As a result the game lost, due to lack of creative nerve (Smith 2001). A project losing buy-in from the team members is probably the single biggest source to creative starvation. If the team stops feeling passionate about the game the chances of producing great gameplay are drastically reduced. Another important factor is the communication of this vision to both the team and the publisher. At The Suffering production, the design vision changed during the production. The changes to the design vision were not communicated to the entire team resulting in a diffuse vision (Rouse III 2004). Similarly, the complex and abstract game universe in Tron 2.0 made it difficult to communicate the vision to the entire team because it was difficult to comprehend the game universe (Rooke 2003). Communicating the design vision is closely related to documenting it in a design document. Since the first step in the communication process is to document the vision. Again the formalized procedures seem to be absent in the cases where the design vision failed to be communicated properly. The most significant problem that will arise, if a clear vision is not established early in the project, is misunderstandings across the team. Team misconception of the vision can be destructive to the process because this can lead to failure in motivating the team. Furthermore, the lack of
In this context buy-in refers to team members accepting the project vision as a personal goal for self-realization.
19
formalized procedures for communicating the vision is likely to lead to miscommunication that will result in costly asset reworks later in the process. 2.3.3. Collaborative design As mentioned above, a key element in implementing a design successfully is to have the team invested in the product. Involving the team in the design process can be crucial in establishing a common vision and motivating the team. Many postmortems stress the value of team members giving feedback on design decisions. In the extreme, productions like Diablo II state that: As a team, we dont have to wonder what our audience wants, because we are our audience. (Shaefer 2000) At the Diablo II production everybody was encouraged to give inputs on all aspects of the game. This open development process is, according to Schaefer (2000), one of the main reasons to the success of Blizzards games. At System Shock 2 everybody participated in the design process. It was a stated goal when hiring that everybody should be able to get games if they were to be considered for a position, even though it was not a game design position (Chey 1999). Besides contributing to creating a better product, this approach also generates an important spin-off. It establishes a collective ownership of the game design. To the contrary, if the team fails to establish a collective ownership of the design, the team members are less likely to invest themselves in the product, as it was the case in the Tron 2.0 production (Rooke 2003). In this manner collective ownership can be crucial because the feeling of influence in the design process can be a huge motivating factor for everybody involved in the process. To validate this claim following postmortems mentioned collective design practices, team feedback etc. as a contributor to success: Age of Empires, Age of Mythology, Dungeon Siege, Jurassic Park: Operation Genesis, Ratchet & Clank, Ratchet & Clank: Up Your Arsenal, Prince of 20
Persia: Sands of Time, Homeworld 2, Aggressive Inline, Vampire: Masquerade Redemption, System Shock 2 and Draken: Order of the Flame. Important to this discussion, as noted by Price (2003), is that input from the team does not necessarily imply design by consensus. This is very important to emphasize since collecting tacit knowledge does not necessarily imply empowerment 6 in the sense that key design decisions are dispersed across the team. But collecting feedback from the team can be essential to discovering new gameplay elements (Carlton et al. 2003). Feedback from the team members being important in refining gameplay is an ongoing theme in several of the postmortems. Morichere-Matte et al. (2003) uses the analogy of balancing between democracy and dictatorship in the question of team involvement. On one side the teams different preferences are an important source for gameplay design input (Morichere-Matte et al. 2003). On the other hand collaborative design can be difficult to manage, especially with larger development teams. The Homeworld 2 team encountered problems because too many people were signing off on script decisions and story meetings dragged out because of the number of people involved. Furthermore, the collaborative design practice took responsibility away from the people making the actual implementations. Level designers needed to consult numerous people even when making small changes to their missions. In the end this diminished peoples investment in their work (Morichere-Matte et al. 2003). It is important to note that this case illustrate how collaborative design does not necessarily imply empowerment. The entire team ends up being the authority. This constitutes a situation where everybody has the responsibility and therefore no one has it. Not placing the design decisions closer to the actual implementation, since the people
When used in this context, empowerment refers to processes for giving subordinates (or workers generally) greater discretion and resources: distributing control in order to better serve the interests of the employing organization.
21
implementing the design do not have the freedom to make the decisions on the fly but have to consult with the entire team. At the Age of Mythology production everyone had a voice but creating the design as one large team simply worked too slowly to be efficient (Fischer and Street 2003). The solution to this was to place the design responsibility for individual parts of the whole with smaller groups. These design groups called Pet Feature Teams were responsible for gathering design feedback from the entire team. These design Teams developed the detailed design, like for instance making Civilization bonus lists. Ultimately the Pet Feature Teams were responsible of defining the design and made the final design decisions. This opens another important discussion in relation to collaborate design, collaborating between areas of competence. The Pet Feature Teams consisted of four to five people with half of them being designers, half being programmers (Fischer and Street 2003). This puts focus on another important part of collaborative design ensuring collaboration between areas of competence across the team. As an example to illustrate how important close collaboration across the team can be to the final product, the lead AI programmer and the lead animator on Prince of Persia: Sands of Time worked together from the beginning of the project (Mallat 2004). The result is one of the most successful features in the entire game. To sum up the discussion of collaborative design, it is a problem if feedback from the entire team is not collected since this is crucial in refining the design. Furthermore, if collaborative design practices are neglected cooperation across the team will be more difficult. 2.3.4. Level design and feature management Feature management and the level design process are closely related. The reason for this is that feature management and level design are both processes that are in development throughout the entire production cycle and both have 22
considerable impact on the gameplay. Unlike the vision/high-level design, level design is not finalized to the same extent before the actual implementation. Where the high-level design evolves during the production, the level design is developed throughout the production process. In this sense the level creation process is about implementing the high-level design on a daily basis. Similar feature management is focused on prioritizing and subsequently implementing the high-level design. As with the development of high-level design, input from across the team is valuable in refining the gameplay during development. At the Ratchet & Clank production the experience gained was that with more people involved at the beginning of a level creation process, it was easier to estimate and adjust the resources spend on the level with the overall project plan (Price 2003). Whereas the level designers at Psychonauts worked independently, and
consequently the level designers produced levels that the lead designers had to throw out since the designs were not coherent with the vision (Esmurdoc 2005). A theme covered in many postmortems is problems related to level reworks caused by changes in the high-level design. Some teams, like Blizzards Diablo II team, are fortunate enough to have flexible ship dates/budgets. This enables the team to constantly evaluate gameplay and features since changes in highlevel design can be made if necessary (Shaefer 2000). However most teams can not afford major feature or asset reworks. At the Psychonauts production the design continued to grow during production. This resulted in a vague vision and uncertainties in the design document. The outcome was that reworks were necessary in order to make the levels coherent with the high-level design (Esmurdoc 2005). At the Homeworld 2 production programmers started working on features before they were fully documented, this resulted in reworks (Morichere-Matte et al. 2003). Similarly, the Fall Out Tactics production had problems because the implementation of multiple levels were started before the core in the gameplay was identified (Oakden 2001). At the 23
Thief: The Dark Project production the game design was hurried without a proper understanding of the technology aspects. With insufficient specifications of code systems and mission designs the Thief: The Dark Project team ended up producing content essentially wrong for the game (Leonard 1999). At the Jak & Daxter: The Precursor Legacy gameplay code had second priority to technology development. This caused the designers to create levels and creatures that could not be tested until later in the process (White 2002). Even though it did not become crucial in this case, it exposed the project to unnecessary risk that could have proven fatal to the project completion. At the Ratchet & Clank a much more conservative risk assessment model was used. 2 of 20 intended levels were cut even before the production was started (Price 2003). This is however, very difficult to make general assessments as to how much to cut since it is difficult to say how realistic the initial estimates were. But it is certainly relevant to mention since many projects experience feature creep because of overly ambitious designers. This was the case at the Knights of the Old Republic II production. The team realized too late that they were too ambitious in terms of content creation (Saunders 2005). At Fall Out Tactics time was also spent making a large game with lots of assets, (Oakden 2001). Both games ended up missing time for polish and playtesting. The conclusion to this problem is, according to Hubbard (2001) that it is better to release a humble working game with a lot of detail than an ambitious game that fall short. The limited focus will help enhance the things that give extra value to the core gameplay (Morichere-Matte et al. 2003). A strong focus on feature management control at the Medal of Honor: Allied Assault production enabled the team to cut features early and keep focus (Millinger 2002). The key to this success was to allocate development resources according to importance to gameplay.
If vehicles appear in only one tenth of your game, then dont allocate more than that share of a designers or programmers time to make a robust vehicle dynamics system. Two mediocre features will never equal one good feature. (Millinger 2002)
24
The discussion of feature creep is closely related to the feature management discussion. Since it is the failure to cut features early enough that creates the problem. There can however be multiple reasons why features are not cut early enough. One of them is a floating high-level 7 design. At the Psychonauts production the team did not solidify the design and technology prior to going into full production. Hence, the team failed to gain a deeper understanding of the game (Esmurdoc 2005). This made it difficult to identify risks and prioritize the global feature design. If a better understanding of the high-level design had been established earlier the team had been able to prioritize the feature set and subsequently cut content earlier. The lack of a feature set and high-level design at the production of Asherons Call caused features to be cut without considering the effect on playability. Later these features had to be added back into the game to support gameplay (Ragaini 2000). The lesson learned was that identification of feature priorities and dependencies have to be made early in order to estimate and schedule tasks. An important issue that needs mentioning with reference to this discussion is complexity inherent in AAA 8 game development. Hastings (2005) agues that even though the Ratchet & Clank: Up Your Arsenals team had been able to predict the entire scope of the design in the beginning of the project they could never have foreseen the complexity of the implementation. However a problem that can be addressed proactively is establishing a formal review process for design implementations. At the Homeworld 2 production features were checked of as finished even though they suffered from usability or gameplay issues. When entering the final stages of the project the team realized that these issues had to be addressed. If some kind of formal
7 8
High-level design refers to the games unique feature list While there is no official definition of a AAA title or triple-A. When used in the context of this thesis it refers to game productions targeted at towards top 10 bestselling lists in North America, Europe and Japan.
25
review process had been implemented these issues could have been addressed earlier, ultimately enabling the team to adjust to the problem sooner. In summary we can point at two main problems that should be addressed in the feature management strategy. Firstly, not having a clear high-level vision will make it difficult to plan and manage feature implementation. Secondly, it is a problem if no formalized testing procedures and assets signoffs are formulated since it makes it difficult to track project progression.
2.4. Prototyping
Based on the postmortems prototyping 9 can roughly be divided into two process areas: gameplay and feature prototyping, and technology prototyping. Besides these prototypes (which are usually heavily interrelated one way or another), a third prototyping process I have chosen to call asset pipeline prototyping will be addressed. A common theme in the postmortems is that changes in gameplay and features and so forth cut late in the process will cause a lot of assets to be lost. This was the case at the first Spiderman title (Fristrom 2004). Similar the Draken 2 production suffered because cuts were not made early enough (Rouse III 2002). As Mallat (2004) argues, being able to cut features early is critical in a successful risk management strategy. In the Never Winter Nights production the team made the mistake to go too quickly into full production. Instead of analyzing what they thought were full-featured prototypes thoroughly they went directly into full production. As a result, time was spent late in the development cycle resolving problems with key game systems (Greig et al. 2002). Besides the risk related to the gameplay itself, the complexities of the technological aspects of the development process are also often uncertain. At
In this context prototyping is the process of quickly putting together a working model (a prototype) in order to test various aspects of the design, illustrate ideas or features and gather early user feedback.
9
26
the Vampire: The Masquerade Redemption production the team did not prototype on the technology platform which they had to build the final game on. The reason being that it was faster to do the game on a known platform. This posed problems later in development when unforeseen implementation problems arose (Huebner 2000). The lesson learned was that the game has to be prototyped on the target platform before going into full production, if a proper risk assessment has to be made. Technology was also a critical path for the gameplay in No One Lives Forever. Key technical features such as terrain systems, animation systems and vehicles were not researched properly before making final commitments. Hence these features were finished later than initially expected. The end result was that gameplay could not be tested until late in development (Hubbard 2001). This is a critical situation since other feature dependencies might not be discovered until late in the development process. Another critical path that can be addressed proactively through prototyping is the teams dependencies on tools 10 . The lack of proper tools can cause problems later in the development cycle. Hao (2003) agues, it should be taken into consideration how widely used an engine feature is throughout the entire development cycle when prototyping it. In the Splinter Cellproduction it was not recognized during the prototyping phase how important the lighting and shadow effects would be to the gameplay. The lack of this engine feature made it difficult for the team to control the quality of the final product exposing it to unnecessary risk (Hao 2003). Closely related to the discussion of the tool prototyping is the establishing a well functioning asset pipeline. The lack of a formal review process at the Kohan production caused lost production time later in the process due to miscommunication and lack of project progression overview (Chaneleh and Papp 2001). One of the major problems faced here was that no checklist was
10
Tools refer to software applications used to produce the actual game.
27
available to verify different steps in the process. A problem with regards to the asset pipeline and prototyping gameplay in general is that in most cases the development teams do not have the tools they need early in the process. Amongst others, this was the case at the Jak & Daxter production (White 2002). At the Asherons Call production a problem faced was that the core technology i.e. server communication had never been proven (Ragaini 2000). Neither the team, nor the publisher, had any idea of the project scope. This resulted in missed deadlines and changing feature priorities. The biggest mistake the Asherons Call team made was probably to enter full production before committing to solving the technological issues. To summarize, the prototyping discussion, if technology, gameplay and the asset pipeline is not prototyped properly during the early stages of the project, management will not be able to establish a coherent risk assessment.
2.5. Playtesting
Play testing is ultimately about securing the quality of the game. In this section I will try to summarize the test procedures that different teams have found successful for securing quality. Roughly, gameplay tests can be divided into three categories: tests of gameplay mechanics (core gameplay), test of specific gameplay features, and level/mission/quest testing. Omnipresent in all these forms of testing is the usability aspect. At the Deus EX production the team used colleagues and select friends to gather feedback. In this manner the team gathered well-reasoned opinions from players who understood the vision of the game (Spector 2000). The benefit of this kind of testing is similar to bringing subject matter experts into the production. The knowledge and understanding of the development process makes the feedback valuable in refining the core concept. Having the team play the game on a regular basis and gather feedback can also be a valuable to the fine-tuning gameplay. At the Age of Mythology 28
production all team members played the game at least once a week (Fisher and Street 2003). Similarly, all team members gave play balance feedback at the Project Gotham Racing 2 production (Pickford et al. 2004). Especially, teams developing RTS games stress this test form. Since one of the core elements in RTS games is play balancing (Train and Reynolds 2003, Fischer and Street 2003, Molyneux 2001, Pritchard 2000, Pritchard 1998). It is however difficult to test if a feature is actually working as expected when feedback is based solely on the team. Furthermore, people tend to develop and play by certain strategies and therefore might be reluctant to discover new ways of playing the game. To address this issue, focus test can be applied both with regards to specific features and usability. At the The Suffering production the team used focus group tests. Players were watched while playing and discussing the game with each other (Rouse III 2004). The feedback was used to improve the gameplay. This process is similar to Maxis Kleenex testing.
The key to fresh feedback is using each tester only once: just like Kleenex. Since so much of our game hinges on players immediately understanding the gameplay and interface, and that the rewards hit with good lacing, we elicited feedback and acted upon it regularly throughout the development process. The most important part of Kleenex testing is finding people who can play a game with someone looking over their shoulders and while voicing the thoughts that go through their heads. (Boyle et al. 2005)
Kleenex testers refer to people that never seen the game before and only tests it just once. Two virgin players are asked to play the game at one computer. This encourages them to discuss what they are doing while they are playing. Designers get input by listening to their conversation and observing gameplay. An important part of the Kleenex testing process is that the games usability can be thoroughly tested throughout the development process (Boyle et al. 2005). When listening to the players conversations, the designer can investigate if the players understand what they are meant to do, i.e. the usability, and if the game is fun to play. Ultimately, an important factor in any game is if it is possible to learn the gameplay and have fun at the same time. A similar kind of usability 29
testing was performed by the Diablo II team. Shaefer (2000) refers to this practice as mom-tests. The test is could Mom figure this out without reading the manual. Ultimately, this kind of usability testing enables the team to polish the gameplay experience and ease the players experience. A central aspect of having a successful test process is to establish testing as an integral part of the development routine as early as possible. At the Fall Out Tactics production focus group testing was made too late for changes to be implemented (Oakden 2001). The importance of testing early in the development cycle is stressed in a number of postmortems. Having play tests in the prototype phase can help put focus on communicating the gameplay to the player, as it was the case with early play testing of the proof of concept demo in the Spiderman II production. From the beginning of the production the team worked with a tutorial level in their proof of concept demo in order to test the learning curve of the gameplay (Fristrom 2004). Another way to gather user feedback is from a community like it was the case with Soldier of Fortune. Feedback from demos was used to improve gameplay. It is however questionable if this strategy can be applied in general (Johnson and Biessman 2000). One last issue in regard to playtesting is to evaluate if the game meets quality demands. FreQuency is an example of what happens if you do not test this. The graphical standard and demands to mainstream music where simply not met, so the title performed poorly even though critically acclaimed (Lopiccolo and Rigopulos 2003). Besides testing the core gameplay, gameplay tests of each level should also be incorporated into the development schedule. The aim for this type of test is to minimize the amount of future reworks. At the Rainbow Six production the modellers playtested the level geometry before actual implementation and texturing (Upton 1999). At the Draken 2 production features were not tested immediately after implementation (Rouse III 2002). This is why the design team thought they were finished according to guidelines in the design document, 30
when in fact they needed tweaking and rework. The morale is: do not trust anything before it has been play tested. Proper procedures for signing of assets and features are needed so that errors can be found as early in the process as possible; the cost of defects also applies to features and assets. The problem is that if testing is not integrated into the process workflow it is impossible to use testing to evaluate the product continuously. If this is not addressed, the team can easily end up in situation were features/levels are not playtested before they are signed off in the end causing reworks and inconsistency in the product.
2.6. Planning
Missed deadlines and unrealistic project schedules have been recurring problems in the game development industry. Even though the problems, judging from the frequency they appear in the postmortems, are decreasing in magnitude, they remain significant. In this section, my intent is to discuss the reason why these schedule slips happens. Two vital factors in this discussion are estimation of scope, and risk management. In many ways these two categories are inseparable since the scope will not be known until a risk analysis has been performed. The worst case scenario is neither publisher nor developer having any idea of the projects scope, as it was the case in the Asherons Call production (Ragaini 2000). The lack of knowledge of the projects scope made project milestones unrealistic and unattainable. These vaguely defined milestones made it difficult for the team to track project progression. Instead of making a full reassessment of the initial plan, the development team tried continuously to catch-up with the schedule, desperate to make up for lost time. In the end, this resulted in feature cuts. Unfortunately these cuts were not initially made with regard to playability, and the features had to be added to the game later resulting in additional resources lost.
31
An important thing in order to measure project progression is the ability to test a milestone. If the milestone is clear, then it will be indisputable whatever it is completed or not. One way of obtaining this is to focus on visual in-game implementations. Spector (2000) notes; Its a truism that milestones should be testable, showing visible progress, whenever possible. The key to succeed in this kind of scheduling is to resist the temptation to do what looks prettiest, but to focus on the most risky tasks first (Spector 2000). As the less risky tasks are attacked last, the knowledge of the entire project scope slowly becomes clearer. One aspect of milestone planning is to be able to comprehend the scope of the milestone. Well defined attainable milestone helped focus in the Fall Out Tactics production (Oakden 2001). Nevertheless the project was late. Maybe it was partly due to the fact that no re-estimation was done after substantial add-ons to the design. If this milestone becomes too extensive the uncertainty in scope estimations increase. The tradeoff is that if the milestone cycle is too short,s too many resources will be needed to evaluate them, thus compromising project progress. The Jak & Daxter: The Precursor Legacy team had great success with schedules only detailed for near future and shipped on time (White 2002). At the Star Wars Star Fighter production the team worked with milestone iterations varying from four to eight weeks. Each milestone was required to demonstrate progression in either gameplay or visuals, similar to the focus in the Deus EX production (Corry 2001). All assignments were as concrete as possible in the sense that they related to the gaming experience. Corry (2001) writes,
() we had very few milestone tasks that looked like complete the Foobar class; instead we would have a milestone task that might read Explosion smoke trails, and the assigned programmer would know that completing the Foobar class was an implied requirement. By keeping our attention focused on a discrete and relatively small body of work, we were able to avoid the cumulative errors that invariably creep into longer schedules, while still allowing for demonstrable progress.
32
This planning of each milestone was based on estimates made by the people responsible for the implementation themselves (Corry 2001). In this way, programmers were solely responsible of estimation of their own tasks. At the Spiderman team they worked with a similar model based on Spolskys (2000) scheduling method (Fristrom 2002). Due to this method, no significant delays in scheduled milestones occurred. Since estimates were far more accurate and reliable. Collaborate estimating tasks and feature priorities in the tool development process at the Asherons Call 2 production helped establish an our job mentality instead of a more individualistic my job thinking. Each month, a team representing each functional area (art, design, engineering and game systems) prioritized the list of tasks and reshuffled the schedule if necessary. This eased communication and made feedback loops fast and effective (Frost 2003). To sum up, the finding is, in this section, two main problems in relation to planning procedures have been addressed. Firstly, milestones that cannot be tested, make it difficult to follow project progression. Secondly, large tasks make it difficult to estimate the scope of the tasks causing poor estimates and milestone slippage.
2.7. Summary
In this chapter I have identified a series of pitfalls in contemporary game development practices. The problems can the summarized in four categories. Firstly, problems arise because the lack of design documentation and vague vision statements before going into full production. If technology, gameplay and the asset pipeline is not tested properly during the preproduction, management will not be able to establish a coherent risk assessment. This will expose the project to risk. The result of not having identified risks in preproduction is unforeseen schedule slips later in the process. 33
Secondly, poor communication of the vision causes communication breakdown and asset reworks. If collaborative design practices are neglected cooperation across the team will not be utilized to its full potential. Team misconception of the vision can turn out destructive to the process because this can lead to failure in motivating the team. The team will loose buy-in if they do not understand the vision. Numerous postmortems stress the importance of team feedback on design decisions. The challenge is to manage this communication flow. Furthermore, the teams misconception of the vision can lead to asset reworks later in the production process. Thirdly, it is difficult to estimate tasks and validate progress. Large tasks make it difficult to estimate the scope of the tasks causing poor estimates and milestone slippage. It becomes risk prone to estimate tasks because of the lack of knowledge of what the task exactly is. Furthermore, not having a clear highlevel vision will make it difficult to plan and manage feature implementation. Fourthly, lack of continuous testing makes it difficult to track project progression. Milestones that cannot be tested make it difficult for management to track project progression. If testing is not integrated into the process workflow, it is impossible to use testing to evaluate the product continuously. Without continuously evaluation through testing the team can easily end up in situations were features/levels are not playtested before they are signed off, in the end causing reworks and inconsistency in the product.
34
3. Project management in a drifting environment

In this chapter I will establish an understanding of the business environment surrounding game development projects in general. The reason why this is important to realize, before moving further into the discussion of game development methods, is that it helps put the postmortem analysis into a broader context. The problems inherent to contemporary game development practices are not unique to this area. Hence, the solutions to cope with the present market situation can be found outside the realm of game production. The business environment has during the past decades undergone rapid change (Bettis and Hitt 1995). In general the business environment has changed towards a global economy, and since the 80s fast-paced product development and flexibility have become more and more essential (Nonaka and Takeuchi 1995). These changes have however never been a major concern to the game development industry since, like many other high tech industries, it has been born into this new world order. Nevertheless, this new competitive landscape is as important to understand to game developers as to any other business. One of the most significant challenges in this economic environment is to adapt to changes from outside of the company. Organizations are in a constant state of seeking stability as well as trying to adapt to the ever changing business environment (Truex et al. 1999:117). Therefore, game developers, like any other businesses, have to find new ways to manage the uncertainty that the rapidly shifting economy exposes them to. Before we can manage to respond to this growing uncertainty, we will need to have an understanding of how the uncertainty evolves. A way of explaining this uncertainty is through environmental drift.
35
3.1. Environmental drift

The concept of environmental drift refers to a situation where the expected course of the project is altered by unforeseen events outside the project organization. In the case of environment drift it must be assumed that the project has been planned professionally that all contractual obligations are based on all information available, and that the expertise has been used to specify means and activities (Kreiner 1995:338). In a situation like this, environmental drift becomes a major challenge to management because the environment specified in the beginning of the project might not be true any more. In traditional plan driven software development methodologies, the best practice would be to collect more information in order to fully comprehend and plan the implementation process. The problem is, however, not to gather more information but how to determine which data will be relevant in the future. If the project is exposed to further drifts in the environment, plans and information may become obsolete once again. Even though management might be aware of this drifting environment the consequences are ambiguous and can therefore only be known in retrospect (Kreiner 1995:340). Examples of a drifting environment, familiar to game development could be new standards in technical requirements (rendering standards, modeling language, hardware etc.) or a game that redefines your genre comes out making your gameplay obsolete (GTA3, StarCraft). Claiming that all game developers are equally exposed to market drift would not be true. Established developers with successful franchises will tend to be less exposed, e.g. Blizzard Entertainment, Rockstar Games, DICE, and Valve Software etc 11 . Still, even a renowned developer such a Valve Software would have been under considerable pressure had Half-Life 2 been a complete flop.
Noteworthy is how publishers tend to acquire these developers, presumably in order to lowering the overall company risk exposure.
11
36
In this sense franchises can be a way of creating a buffer between the surrounding drift in the environment and the organization. Lessard and Miller refer to the process of managing this uncertain future as planning for the journey rather than planning the journey (2001:203). The dilemma in this regard is how to plan in an environment where it is impossible to make deterministic forecasts. According to Lessard and Miller, the key to the solution is to find project sponsors 12 that recognize that projects are not to make all decisions once and for all, (2001:204) but a continuously dynamic process. A way to deal with the uncertainty in the project is according to Lessard and Miller (2001), to work with a front-end investment period. The goal is to foster multiple perspectives and reveal uncertainty. In the front-end period the sponsors prime objective is to allocate project risks. Lessard and Miller
(2001:206) argue that the project sponsors must avoid making irreversible commitments during the front-end period, until they have gained enough knowledge to make reasoned choices. Eventually the project sponsor must commit to the project thereby increasing their risk exposure and locking their claim on eventual returns on the investment. In this sense the front-end of the process can be viewed as an iterative process helping the involved parties to identify risk and calculate project risk exposure. The dilemmas identified by Lessard and Miller (2001) can be summarized in the Table 1.
12
In the context of game development the project sponsor would most likely be a publisher
37
Project Dilemmas The forecasting dilemma Strategic interdependency Irreversible, indivisible exposure Dormant innovations Underinvestment projects The dilemma of time External effects in worthy
Strategic principle Planning for the journey rather than planning the journey Embracing interdependency and shared governance Avoid locking in too early or too late Unlocking latent solutions through trust-based relationships Tailoring public-private partnerships to internalize benefits Stretching the front end and squeezing the back end Seeking win-win situations to accommodate stakeholders interests
Table 1 Project Dilemmas and strategic principles in evolving high-stakes games (Source: Lessard and Miller 2001:203)
Since the project stakeholders will only know if the decision they make in the present is beneficial for the project in the future, less irreversibility will grow larger project risks. On the contrary, reversible decisions will put less risk on the project. A tight spot faced in the earliest project stages is that less information will be available than towards the end of the project, whilst some of the most important decisions have to be made early in the project timeline. Often the complexity of a project has to be reduced in the early stages of the project in order to narrow the project scope. This process will unavoidably demand irreversible decision making.
3.2. Emergent organizations

As a response to the constant drift in the business environment, organizations have to adapt accordingly. The form of the organizations is no longer fixed, but continuously emerges from the adaptation of outside demands. Truex et al. (1999:117) labels this type of organization as an emergent organization since the current state of the organization will always 38
be bound to the history and context of the present. In this sense, the organizational emergence can be described as a theory of social organization that is not necessarily supported by a stable structure. Game development companies are almost all is this category of organization since they are dependent on a very limited number of projects that has to constantly adapt to flux in the market. Most developers would simply go out of business if no publisher funding for the next project was secured relatively quickly after the completion of a project. Compared to traditional project management methodologies removing the stable organization redefines the initial goal in the development process, since the goal is no longer planning but adapting. Again, Lessard and Millers (2001) journey metaphor describes this shift in focus. The problem for many game developers is, however the lack of project management methodologies to control this constant adaptation the company is exposed to. Instead of acknowledging the changed business condition game developers try to implement static management methodologies that software engineering has more or less successfully used in the past (Irish 2005:32). Furthermore, as mentioned before, game development distinguishes itself from traditional software engineering in areas such as asset production and game design. General software management methodologies often fall short when applied to such practices since their main focus is to manage the code production. Software products developed in the 60s, 70s and 80s 13 had longer life times than we see today allowing development cycles to focus on stable systems with a low-maintenance cost. In the present business environment software projects have to adapt to ever changing conditions since the need for systems maintenance is not certain. Low maintenance costs become of less value and hence the system will most likely be obsolete within a short period of time. The development is illustrated in Figure 1 and Figure 2:
13
E.g. the IBM OS/360 discussed in Brooks (1975)
39
Figure 1 Lifespan Curve Static Organization (Source: Truex et al. 1999:119)
Figure 2 Lifespan Curve Emergent Organization (Source: Truex et al. 1999:119)
As the figures suggest, traditional software projects have high analysis and design cost. This reduces the long term cost, since the cost of maintenance is reduced. On the contrary, emergent organizations focus on short term costs 40
since the need for future maintenance is of lesser value. It is important to note that while plan driven project management might be obsolete in response to the present business environment, it has had considerable benefits in the past decades. Figure 3 and 4 shows the shift in historic focus on maintenance and requirements.
Figure 3 Historical lifecycle change cost (Source: Highsmith 2000)
41
Figure 4 Contemporary lifecycle change cost (Source: Highsmith 2000)
42
To relate this to game development, a static organization would invest heavily in engine and toolset before going into the actual development. On an AAA-title such an investment would have to be big enough to at least produce content 2 generations of consoles using the exact same toolset. This scenario is presented in Figure 5 and Figure 6.
Figure 5 Console game production in static organization
43
Figure 6 Console game production lifecycle in emergent organization
In Figure 5 the game developer has to use the toolset to produce games for at least two generations of consoles in order to capitalize on the extra upfront investment. In consequence, the toolset might be less flexible and most likely outdated before it would be of any value to the actual game production. In Figure 6 the development of the first game begins sooner. But although the toolset that is available in the beginning of the project might not be as rich in feature as the one produced in Figure 5. Consequently, the project will be less vulnerable to changes in rendering technology, hardware specifications and other changes, which the company cannot predict anyway. At the completion of the first project, the emergent project organization would be able to adapt to market demands a lot smoother than the static project organization. The above figures depict the difference of emergent and static organizations over a considerable time scale. As discussed earlier, another important factor in the drifting environment is how risk is addressed in the specific project. As implied, one way of reducing project risk is by enabling decision reversibility.
44
An approach to achieve this is minimising the cost of change and subsequently reducing the cost altering previous decisions.
3.3. Managing Software Projects in a drifting environment

Software projects in general, are highly complex and therefore the reduction of the project complexity by a requirement and planning phase has been focal point in traditional literature on software development. It has been a widespread belief that formalisation of practices by adherence of logical approaches was an appropriate step towards a solution of the problems inherent in software development (Fitzgerald 1996:9). With this goal in mind a lot of software development methodologies has been created over the years. McConnell (1996:133-162) identifies a number of software development methodologies which most real-life projects employ a blend of: Pure waterfall, Code-and-fix, Spiral, Modified Waterfalls, Evolutionary Prototyping, Staged Delivery, Evolutionary Delivery, Design-to-Schedule and Design-to-Tools 14 . With the exception of code-and-fix, all these software development methodologies are based on physical engineering practices and claim to be predictive . In addition, people are comprehended as an abstract resource. Consequently, the drifting environment surrounding the projects has been ignored. As a result, irrational practitioners have been seen as the main reason for project failure and formalized methodologies as the solution (Boehm 1986, Yourdon 1991, Ward 1992, Chapin 1981, Ramamoorthy et al. 1986, Dijkstra 1972, Zolnowski and Ting 1982, Jenkins et al. 1984, Plat et al. 1991, Palvia and Nosek 1993) 15 . This supposition has also led to the general assumption that software development methodologies are used by practitioners, thus there has been little
See appendix for further description of these models. I will not go further into the discussion of research traditions within academia, for an overview of this discussion see Hirschheim et al. 1991 and Olaisen 1991
14 15
45
research to confirm this (Wynekoop and Russo 1995:65, Wynekoop and Russo 1997:53). A survey on the actual use of traditional software methodologies conducted by Chatzoglou and Macaulay (1996) shows evidence that half of the software projects examined use a software development methodology. Further, Wynekoop and Russo (1997) has classified over a hundred (123) research papers on the use and evaluation of software development methodologies. Although most studies indicate that respondents believe that software development methods are valuable there is less consensus about when to use these. There is neither agreement on software development methodologies being useful in todays business environment, nor evidence that they have ever been so. This general assumption seems also to be dominating among game developers, and maybe even more importantly, publishers. While it is probably true that poor management is responsible for these many project failures, it is less certain that the solution to these problems is to adopt traditional software management methodologies. The problem with the traditional conception of software project management methodologies is best portrayed by Fowler (2000b) in his comparison of resources used on design and planning in engineering project vs. software projects. In traditional engineering projects approximately 15% of all resources are used on planning, and to a large extent the construction plan can be evaluated by mathematical testing. On the contrary, software development uses approximately 85% of the total resources on designing and planning, and only 15% on actual construction (McConnell 1996). Even though tools such as UML enable the practitioner to design systems on an abstract level, the systems are too complex to be fully comprehended before actual implementation is reached. Besides this point, further uncertainty is added by environmental drift caused by the rapid changes in technology and market, whereas traditional engineering practices are less exposed to rapid changes in terms of materials, 46
and hardware amongst other things. In software project management theory light weight or agile methodologies has emerged as a response to the drifting environment.
3.4. Agile Software Development

The background for the emergence of agile software developments methods is the gap between plan driven software development approach to producing software and rapid changing market. Fowler (2000b) distinguishes between adaptive and predictive methods arguing that it is a utopia to give detailed predictions as to how a system design works in practice, before the actual design is implemented. Similarly, Beedle and Schwaber (2002) identifies traditional methods as defined processes in opposition to what they call empirical based methods, i.e. agile methodologies. Under the new conditions imposed by the rapid changing environment agile methods have shown to be highly effective software development methods (Maurer and Mantek 2002, Khan and Balbo 2005). The term agile methodology is often used to describe the software development methodologies that focus on incremental, cooperative,
straightforward and adaptive development (Abrahamsson et al. 2002:17). Although the different agile methodologies differ, they all share certain underlying principles in a common approach to: People/co-workers, documentation, customer relations, and adaptability. As stated in the agile manifesto the agile methodologies values:
Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan www.AgileManifesto.org
47
Furthermore, agile methodologies share the same fundamental assumption as Lessard and Millers (2001) front loaded approach to project management.
Figure 7 Evolutionary map of agile methods (Source: Abrahamsson et al. 2003).
Figure 7 shows the different methodological frameworks within the agile field. The dotted lines indicate that the authors have contributed to the agile manifesto. As the figure shows, agile methodologies are a dispersed field and the different methodologies cover different aspects of the development process. In their study of agile methodologies Abrahamsson et al. (2002, 2003) differentiates the different agile traditions according to relevancy for the different steps in the development process; project inception, requirement specification, design , code, unit test, integration tests, system tests, acceptance tests and system in use. In addition, each methodology is evaluated on the ability to 1) support project management 2) give concrete guidelines and 3)
48
offers descriptions of the process. A brief overview of their finding is depicted in figure 8 below.
Figure 8 Comparing life-cycle, project management and concrete guidance support (Source: Abrahamsson et al. 2003).
Figure 8 evaluates if current writings on each methodology cover the issues of process, project management, and concrete guidance. In this thesis I have chosen to focus primarily on XP and Scrum. The reason for this is that Scrum and XP methodologies are complimentary on several levels. As illustrated in the figure 8, Scrum gives general guidelines on how to manage projects on a larger scale, while XP is focused on giving advice on concrete development routines. In addition, the focus in this thesis is primarily on the requirement specifications phase, the design phase, and the code production phase, which is well documented when combining Scrum and XP writings. These three phases are slightly different in game development projects compared to normal software projects. This is due to the graphical assets and game design have to be 49
produced in addition to code base. In relation to game development the requirement specification can be compared to the feature list, the design to the code design plus art direction, gameplay systems, music etc. and the code production phase also include the production of all assets in the game 16 . The rest of the production phases depicted above do not differ significantly from those of normal software development projects. Hence I will not go into detailed discussions on how to use unit tests, integration tests, systems test, acceptance tests, and systems tests. It should however be noted that all these steps are important to any software development project, including game development projects. Lastly, a strong argument for choosing to focus on XP and Scrum is that the methodologies are widely used (with success) within the developer community. I will return to the discussion of how to apply XP and Scrum to a project in the next chapter, following the discussion of concrete methods to front loading risks in game design practices.
3.5. Minimizing the cost of change

In traditional plan driven software projects the cost of change increases exponentially along the development timeline. The reason for this, is that it is costly to alter and communicate alterations of the overall plan once the project enters the production phase. Each stage of the development cycle is rigid because each stage of the development cycle is an independent entity, not easily adjusted to other stages in the development cycle. Lastly, systems and consequently requirements are planned for a long life cycle of maintenance not changing consumer demands. The extreme case of this development methodology would of course be the Waterfall model 17 . Examples of plan driven development strategies that are tying to compensate for the lack
16 17
For an in detail description of the game asset pipeline see Carter (2004) See appendix for further description of the waterfall model
50
flexibility in the Waterfall model by introducing a less rigid process view, are the Modified Waterfall, Staged Delivery, Evolutionary Prototyping and the Spiral model (McConnell 1996). Even though some of these models might be more flexible than others, they are all grounded in a rationalistic/positivistic approach to planning. In other words, this view of the process implies that method is comprehended as a static structure. As a result, they all fail to recognize the surrounding drifting environment making them vulnerable to risk exposure. The relationship between the cost of change and traditional plan driven project management can be illustrated as showed in Figure 7.
Figure 9 Cost of change in plan driven software projects
The basic assumption in the exponential cost of change curve, is that the cost of a change made in the early phase of a project will be significantly smaller than the cost of a change made later in the process. This means, as long as the project runs, the cost of change will increase exponentially. While Figure 7 shows the overall accumulation of the project decisions, and the cost of 51
changing them, a cost of change curve for each individual decision also becomes more a more costly to reverse over time. In this sense, each decision has its own cost of change timeline. An example of a decision on this level of analysis could be error corrections. Beck (1999:99) refers to this as the Defect Cost Increase. One of the values stressed by agile practitioners is the possibility for customers to see the system as it grows. In this way, mistakes in requirements can be spotted early in the process before the cost of fixing escalates. According to McConnell (1998:31), corrections to errors made in the requirement specification in a traditional plan-driven development project tend to cost 50-200 times as much to correct later in the projects as it does close to the point where the error originated. This is why code and fix /evolutionary design 18 as we know it, eventually will turn into a nightmare where the lack of design, will result in a program breeding new bugs as old ones are killed. One of the fundamental assumptions in agile software development is that it is possible to flatten the cost of change curve enough to make evolutionary design work (Fowler 2000a). The easy way out of this problem seems pretty obvious; get it right the first time. It certainly would be ideal if we could apply a methodology that would ensure us that this was doable. Unfortunately, as discussed in the previous, it is not feasible to comprehend the development process in such a deterministic way. At best this will only capture the intended development processes not the actual process to come. Since the environment surrounding the project is in constant drift, the exact value of decisions made at present, may only be apparent in the future. The result is a trade off; higher maintenance cost in exchange for lower cost of change later in the projects lifecycle. The cost of
Evolutionary design in this context means that the design of the systems grows as the systems is implemented.
18
52
change associated with a project based in an emergent organization can be depicted as shown in Figure 8.
Figure 10 Cost of change and cost of system maintenance in emergent project organization
The cost of change and the constant pressure to external risk indicates that the relationship between upstream and downstream planning has shifted 19 . The following arguments for and against upstream design has to be found in the change of cost curve. In regards to traditional plan driven software project management it is important to recognize that it is not a matter of planning or not, rather it is a question how much to plan before you start coding (Fowler 2000a). To summarize the arguments; risk exposure can be minimized by supporting processes with focus on reversibility of decisions since it is keeping the cost of change low, hence maximizing the projects adaptability to unforeseen market drifts. However, this does not mean that design should be omitted in the upstream process but only suggests that the balance between up-front design
19
For a brief introduction to up-& downstream planning see McConnell (1998)
53
and continual design and analysis has shifted. Project management should focus on building software without a predefined sequence, and not base itself upon a rational control structure. The main argument for adopting this view is the possibility of actively addressing the projects risk exposure.
3.6. Summary
The problems faced by game development projects are not entirely different from the ones faced in other business situations. The market surrounding game development projects are drifting, like it is the case for any other business. By using Kreiners (1995) understanding of the environment surrounding the organization as a drifting environment we can explain why a plan driven approach is risk prone. Since the market is drifting, the future market can not be predicted. Hence, plan driven methodologies with focus on long term planning are likely to fail due to market drifts. As argued by Truex et al. (1999), a way to cope with the drifts in the market is to adapt. By becoming an emergent organization, with focus on change and adaptation to fluctuations in the market, organizations can reduce the risks inherent in plan driven methodologies. Lessard and Millers (2001) journey metaphor describes this shift in the market. The current market situation demands project managers to plan for the journey, rather than planning the journey. An important part of this plan for the journey is to focus on decision reversibility, especially in the early stages of a project. By lowering the cost of changing a decision, the present value of the decision will increase. The reason for this is that the present value of a decision can only be known in the future. Consequently, the ability to change or adjust the decision in the future will enable management to utilize drifts in the surrounding market. A strategy based on this understanding of the market is to front load project risks. By focusing on reversible decisions early in the project management can identify risks before making final commitments to the project. 54
Within the field of software development, a methodological approach to this can be found in the agile development community. The focus in agile software development methodologies is to respond to change, instead of following a plan. Again, the key in the frontloaded project model is to adapt to the market.
55
4. Establishing a game development framework

In the postmortem analysis, four reasons to schedule slippage and budget overruns were identified. Previous chapters discussion of the current market situation highlighted how the market affects the possibility to plan a project. Within the software development community, agile methodologies have emerged as a solution to cope with this new market situation. In this chapter, focus will be given game development methods and combining these with the knowledge gained within the agile community. The aim of this is to create a model that addresses the problems identified in the postmortem analysis.
4.1. Game design as iterations

Everybody working with any form of design, whether it is programming, industrial design or game design, know that the initial idea seldom remains unchanged throughout the production process. The reason for this is mainly that the complexity of the initial idea makes it difficult to comprehend the full scope of the idea. The first step on the way to reducing the complexity of the idea is to systemize the concept. In a game project, you would typically write down key features in a design document. The process of writing down key features extends the initial idea from pure thought and makes it possible for a team to negotiate the actual meaning of the key features. It should be noted that writing things down is just one of many possibilities of communicating the initial idea. Concept art, a UML diagram, a piece of code; anything that helps narrow the scope of the idea will help. The important thing is that the
complexity is reduced. The reduction of this complexity enables the designer or team to rethink/test the product and thereby narrow the scope even further. In this way the iterative process helps refine the product. As the project progresses, the scope of the product/game narrows down. In order to reduce the complexity design, decisions have to be made and as the scope narrows, so does the possibility of alternate paths, that is, once you have started building 56
Game design and development - asbjoern@asbjoern.com technology to produce a First Person Shooter game, it will be very costly to change the concept to a Real Time Strategy game. On smaller game development projects where core gameplay quickly can be mocked up and tested, the iteration process can be utilized better. Zimmerman (2003) 20 has described what he calls the Iterative Design Process. The method involves early continuous mockups and playtesting sessions. This process repeats itself in iterations until the game is good enough to be released. Since this methodology is focussed on web and board games, the initial scope of the concept is already reduced considerably compared to video game productions. The Iterative Design Process is not easily scaled to larger game productions because the cost of rework would be substantial if the whole game was to be reworked after every iteration. The small scope makes it possible to iterate continuously throughout the process without endangering major rework of assets and code. A common way to illustrate the iterative process is through a spiral, each iteration taking the project one step closer to the final product. This is achieved by continuously limiting project scope. In this way, the spiral model reflects the underlying concept that iterations address the same sequence of steps in a continuing refinement of the product (Boehm 1985). In larger scale productions, iterations have to be controlled, since they would otherwise cause a lot of work to be thrown out. In other words, ideas are cheap on paper but once you have constructed a level of the game, changing the storyline and making the level obsolete will be much more expensive. One of the main reasons for this is the significant extra load of communication and coordination that a larger team demands. Furthermore, it would be very difficult to set up a well-functioning content pipeline if the asset demands kept changing. But does this mean that iterations are bad? No it does not. It means that they will have to be controlled in order for the change they impose to be manageable. The challenge in doing so is to ensure that the creativity and
Similar to Zimmermans Iterative Design Process although less formally described are the productions methods of Pop Cap Games Inc., basically: iterate until the game is fun summarizes this way of producing games.
20
57
Game design and development - asbjoern@asbjoern.com quality in the project is maintained. In short, take the benefits from the Iterative Design Process and scale them to video game production. The following section deals with this.
4.2. Preproduction
As discussed earlier, a way of reducing the complexity of an idea is to document it. An extensive way of documentation is prototyping. In all its simplicity, prototyping combine the most representative attributes of an idea into a working model in order to test various aspects of the design to illustrate ideas or features. Since prototyping is a relatively complex form of documentation, other forms of documentations will most likely have been produced in order to narrow the scope enough to actually build the prototype. One of the main reasons for producing a prototype is to test the idea as close to the intended vision a possible. Secondly, prototypes can be extremely valuable when pitching a game to a publisher. Prototypes are part of the preproduction phase, the phase where the scope and potential of the project is still vague and therefore this stage of the production phase is exposed to a high degree of risk. As argued earlier by Lessard and Miller (2001), a way of attacking this risk is to front load it, uncovering as much of the unknown as possible before making the final commitment. In computer games production, the major concerns/risks are associated with consumers preferences for gameplay at the time the game hits the shelves, and the technology necessary to produce the game. Cerny and John (2002) have developed a front loaded development model which, through an extensive preproduction and prototyping phase, seeks to eliminate project risks. Their methodology is concerned with structuring the preproduction phase where the team develops a Publishable Demo and the Macro Design. 4.2.1. Publishable Demo and Macro Design Cerny and John (2002) and Cerny (2002) argue that the goal of the preproduction is not producing assets but building a game design. In this way, the process focuses on growing the design similar to the Iterative Design 58
Game design and development - asbjoern@asbjoern.com Process. The main difference is that where the scalability of the Iterative Design Process is very limited, Cerny and John (2002) give guidelines on how to keep the benefits of the iterative design process while working on larger projects. Cerny and Johns development methodology is derived from four key elements: 1) a clear distinction between preproduction and production, 2) making a demo of publishable quality before going into full production, 3) macro and Micro Design and 4) gameplay testing. The driving force is to create a methodology that ensures the necessary creativity for producing high quality games and as well as actively attacking the risks involved with not having clear schedules form the first day of development. In this way, Cerny and John (2002) break with the dominating paradigm that creativity can be controlled. One of the tools to actively address these risks is to have an extensive preproduction phase. The first step is to create the preproduction team. The preproduction team should not be larger than 4-8 people. They will determine everything that is important in the game and will most likely be the leads during production. As discussed earlier, the smaller the team the cheaper the iterations, simply because each iteration affects fewer people. This is a key ingredient in controlling the risk since more experimentation can be done, thereby enhancing the quality of the product with the least amount of risk exposure. In this preproduction phase, the team does not work according to a specific plan. In this way, the process is very similar to the Iterative Design Process. Instead of milestones during preproduction there is simply a limit on how long the preproduction can continue. This is the one big deadline. One of the reasons for this is that the product is still not clearly defined yet. When a product is still so vaguely outlined, it is virtually impossible to track progress, so there is no
59
Game design and development - asbjoern@asbjoern.com point is having milestones. Instead of having clear milestones, management can follow the progress of the team through iteration reviews 21 . In the preproduction process, the team take their ideas and build simple prototypes. The end goal of the prototyping process is to produce a demo. To ease the terminology I will distinguish between a proof of concept (POC) and a demo of publishable quality. Using this terminology, the first step in the prototyping process is to establish a proof of concept. A proof of concept distinguishes itself from a prototype by still having uncovered risks such as technological issues, missing gameplay features etc.
A proof-of-concept (POC) is a videogame demo that exists only to prove a concept; it can have placeholder art, it can be missing animations and sounds, but as long as it shows enough promise to justify making a better POC, its a success. A prototype, on the other hand, is a videogame demo, most of which will probably go into the final game with minor changes. (Fristrom 2004)
Prototyping can help make the necessary risk assessments early in the process since the scope of a feature can be understood better once it has been prototyped. In this sense, prototyping early in development can help map interdependencies and risks related to core gameplay or features. The goal of the prototype, according to Cerny and John (2002), is to become indistinguishable from game levels relatively quickly. This entails bringing everything in the game together; artwork, game mechanics and technology. During this phase, focus should be directed towards: Primary schemes for player interaction, e.g. controls, camera, interface, character The games look/visual concept The key technology
It is important to be aware that the prototyping process is not about producing assets, it is about developing a game design. The reason why this
21 Iteration reviews means that management gives feedback in a semi-formal setting, well aware that it is not a final design that is presented before them but a mere test of possible gameplay features etc.
60
Game design and development - asbjoern@asbjoern.com should be stressed is, according to Cerny and John (2002), the general misconception that working productively means not throwing away good work. It is unavoidable to test all your ideas without producing assets. When the ideas from time to time turn out to be less brilliant, the assets will have to be cut along with the idea. While this is true, it should obviously always be a goal to use as much as possible of the assets produced. The important thing in relation to this discussion is that the prototyping phase focuses on throwing things away before the asset pipeline is set up. This indirectly means that it affects as small an amount of people as possible. Again minimizing the projects risk exposure. Cerny and Johns own rough estimates show that about 20% of what would be the final game will typically be thrown out during preproduction. Again, it should be stressed that while this seems as a huge part of game just going down the drain, this process is necessary in order to narrow the scope of the production. In order to get a game design worth building, you have to take changes. One of the fundamentals of game development is that it is a creative industry and as a result, artistic risk has to be taken in order to make a successful product. At some point in development, you will have to trust your gut feeling. You might as well risk your guts at the lowest possible risk since the risk is only going to increase throughout the project lifecycle. The key is to attack the risks as early in the process as possible, allowing the team to test the ideas before too much work has been lost. Ultimately, the money spent during preproduction will be returned as money saved later. Based on my analysis of the postmortems in Game Developer, a rough estimate suggests that approx. 80% of all mistakes during production are direct results of things done or not done during preproduction. This does by no means imply that mistakes will not happen during production even after a thorough preproduction. But the risk associated with the mistakes will be far less frequent and significant. The goal of the preproduction process is to reduce uncertainty and thereby ultimately project risk. Project risk is reduced by mapping interdependencies and testing 61
Game design and development - asbjoern@asbjoern.com gameplay and core features. In this respect, preproduction should be continued as long as it helps reduce risk that would otherwise have remained unaddressed. The preproduction phase ends with the delivering of 1) a Publishable Demo and 2) the Macro Design. The Publishable Demo As noted previously, a Publishable Demo or a first playable is a demo of the game in publishable quality. Publishable quality is achieved when the targeted audience is impressed by your gameplay and technology to a degree where they would compare the game to a commercial title. The best way to evaluate whether the demo is of publishable quality is to playtest the demo on the target group. Cerny and John (2002) refer to these playtests as Sniff-tests. The demo has to show exactly what the game is about, and it should be known exactly how the game should be built. In order ensure that this is achievable, at least two levels should have been built. It is important that the two or more levels represent the variety of the gameplay. Cerny and John (2002) provide this checklist to evaluate if the demo is of publishable quality: Player behavior fully defined Basic technology done Enemy/obstacle behavior fully defined Art direction in place All local features included, with global features included as required A touch of variety Scope of game defined
Besides the Publishable Demo, the Macro Design has to be completed by the end of the preproduction.
62
Game design and development - asbjoern@asbjoern.com The Macro Design Cerny and John (2002) distinguish between two game design levels: the Macro Design and the Micro Design. Micro Design is the design that the designers make on a day to day basis during production. Elements of the Micro Design includes level design, in-detail enemy descriptions, mini games etc. The important thing is that the Micro Design should never compromise the Macro Design. The Macro Design is the fruit of the preproduction phase. During the preproduction the team works on defining the core gameplay and the overall structure of the game. Before going into the production phase a five page Macro Design document should be produced. As noted above, the most important features should be implemented in the demo, and the gameplay should communicate itself. The Macro Design documents main function is to bring the vision from the demo into a form that can be used to develop a schedule and thereby assist in the planning of the production phase. You could say that the Macro Design sets the scope of the iterations when developing the Micro Design. The five page Macro Design should include: The character move set Any exotic mechanics planned Description of level structure, size and count Level contents Overall structure (linear, hub etc.) The macro chart22
The idea with this way of proposing a game design is that the whole game should be able to be distilled into a five page document. But this document should be allowed to refer to other in-depth descriptions of for instance storyline. In this way, these five pages only describe core gameplay and flow of the game.
The macro chart is a one page chart that shows all the game dependencies and distribution of various mechanics and gameplay elements throughout the game.
22
63
Game design and development - asbjoern@asbjoern.com 4.2.2. A Front Loaded Development Model for game production As discussed in the previous chapter, Lessard and Miller (2001) argue for a front loaded project model in order to cope with the surrounding environment. An important aspect of a front loaded development model is to front load project risk. This is exactly what Cerny and Johns (2002) preproduction model is aiming at. By focussing on building a publishable quality demo, the team has to both attack the technological risks and the creative risks. The technological risks are resolved since the technology has to be made in order for the demo to function, and the creative risk is resolved by building a gameplay that appeals to the consumer. This front loaded development model (FLDM 23 ) addresses the first prevalent problem in the postmortem analysis, which is that lack of proper prototyping of technology, design, and asset pipeline made it difficult for management to establish a coherent risk assessment. The lack of proper risk assessments caused schedule slips and asset reworks later in the process. By applying the FLDM, this problem can be addressed. While the FLDM might be hard to sell to a publisher, especially if you are a new developer, front loading project risks is not something that is limited to the game industry. In this sense, Cerny and Johns (2002) model can be backed up by economic and project management theory; hence, the benefits of front loading project risk are not unique to video game development.
4.3. Design Rules as a management tool

As noted in the postmortems analysis, a prevailing problem in many productions is establishing a formalized model for communicating the vision. The problem with not having a formalized model to communicate the vision is that misconceptions of the vision are likely to cause asset reworks later in the process, exposing the project to risk. A powerful way of communicating a project vision is through the use of Design Rules.
23
FLDM in the context of this thesis refers to Cerny and Johns (2002) preproduction model.
64
Game design and development - asbjoern@asbjoern.com Design Rules are production dogmas that help establish basic guidelines for the creative process. In this sense, the Design Rules are formulated standards for creating user content. At a number of productions, these clear standards or guidelines have been stressed as valuable assets in maintaining discipline in the content creation process and in communicating the projects design vision. In Star Wars: Droid Works, the vision was distilled into one sentence that was easy to understand and communicate to the team: Give players the opportunity to build any kind of Star Wars droid and see it animate (Blossom and Michand 1999). At the EA Sports Nights production, the design team formulated two basic Design Rules: 1) Increase control for gamers over boxers fists and 2) Change simple button-press punching found in all other boxing games (Tsunoda 2004). Similar to this, the half-Life Team had some basic Design Rules:
Experiential Density The amount of things that happen to and are done by the player per unit of time and area of map. Player Acknowledgement [T]he game world must acknowledge players every time they perform an action. For example, if they shoot their gun, the world needs to acknowledge it with something more permanent than just a sound there should be some visual evidence that theyve just fired their gun. Player failure [T]he players should always blame themselves for failure. (Birdwell 1999)
The important notion is that these simple Design Rules define the core gameplay, they are easy to communicate across the team, and they are easy to validate. In this way, the design team enable themselves to communicate and enforce a clear vision throughout the production. Formulating Design Rules also force the team to consider what the game will do/not do compared to other games. An example of this could be Warren Spectors design
65
Game design and development - asbjoern@asbjoern.com Commandments (Spector 1999) 24 . These commandments were guiding principles during the production of Deus EX. The commandments helped the production team to maintain a clear high-level vision throughout the production process. The Baldurs Gate II team also worked actively with Design Rules. The team formulated a number of Design Rules divided into a number of categories: Basic Design Rules, Story Design Rules, Environmental Design Rules, Game System Design Rules, and Writing Guideline Rules 25 . These rules, accompanied by a prioritized feature set, were invaluable in helping to manage the project (Zeschuk and Muzyka 2001). The strength of Design Rules is that they can be used to establish clear guidelines on how to interpret the feature set. In this way, the feature set becomes less abstract, and it becomes easier to understand how to implement a feature. The Baldurs Gate II Design Rules are relatively detailed and an excellent example of establishing detailed guidelines for content creation. As mentioned in the postmortem analysis, asset reworks late in the process are often directly or indirectly caused by unclear guidelines. By establishing detailed Design Rules, it becomes easier to communicate the vision to the team. From a management perspective, it is important that the Design Rules can be documented and in a sense formalized. Evaluating concrete implementations becomes easier since the Design Rules can be used as guidelines. Thus, Design Rules can be used to establish a formal reviewing and validation process. This is valuable, especially from a management perspective, since a formalized review process facilitates tracking project progress. Another important issue in the discussion of how to maintain a strong vision throughout the production process is securing buy-in from team members. Team misconception of the vision can be destructive to the process because it can lead to failure in motivating the team. By formulating clear Design Rules, everyone is able to understand. Management can help prevent misconceptions
24 25
See appendix for in detail Design Rules used at the Dues Ex production See appendix for in detail Design Rules used at the Baldurs Gate II production
66
Game design and development - asbjoern@asbjoern.com and communication failures. In this sense, Design Rules can be an important management tool in any creative production. In the productions referred to above, Design Rules have proved to be successful in providing two basic things: Firstly, Design Rules can be a key in establishing and maintaining a distilled vision. This makes it easier to communicate the vision across the team. Secondly, Design Rules can be valuable when establishing formal practices for validating assets.
4.4. Collaborative design

As discussed earlier, collaborative design practices are an important creative source to the innovation of gameplay. If collaborative design practices are neglected, cooperation across the team will not be utilized to its full potential. A company that has actively met this challenge is Valve Software, the creators of Half-Life 1 and 2, and the Source Engine. Since their games have been extremely successful both commercially and among critics, they seem to be an excellent base for the further discussion of empowerment processes in game design. 4.4.1. The Pre-Cabal Process Unlike the FLDM, the Cabal process focuses on the processes used under the production phase. In this sense, the Cabal process focuses on what Cerny and John (2002) refer to as the Micro Design process. The FLDM is concerned with establishing a framework to guide the preproduction phase; the Cabal Process main concern is the actual development cycle. It is important not to confuse the difference in focus. One of the basic assumptions in the Cabal Process is that a demo similar to the one suggested in the FLDM is produced before the Cabal Process begins.
We set up a small group of people to take every silly idea, every cool trick, everything interesting that existed in any kind of working state somewhere in the game and put them into a single prototype level. When the level started to get fun, they added more variations of the fun things. If an idea wasnt fun, they cut it. () When they were done, we all played it. It was great. It was Die Hard meets Evil Dead. It was the vision. It was going to be our game. It was huge and scary and going to take a lot of
67

work, but after seeing it we werent going to be satisfied with anything less. All that we needed to do was to create about 100 more levels that were just as fun. No problem. (Birdwell 1999)
In this light, the Cabal Process should be considered as the day-to-day implementation of the Micro Design, based on the Macro Design. The Cabal Process is a methodology to controlling the day to day design. After completing the prototype or Publishable Demo, as Cerny and John (2002) argue, the next step in the pre-cabal process is to analyse what makes the demo fun. At the Half-Life production, this analysis resulted in some basic theories or Design Rules for Experimental Density, Player Acknowledgement and Player Failure as cited earlier. These theories are very similar to Design Rules, in the sense that they define what should always be present in the game. These design theories served as validation criteria for every design decision made during the Cabal Process. As discussed earlier, Design Rules can be effective when communicating the vision across the team. In this case, the design theories combined with the demo help maintain the vision throughout the development process. The Cabal Group was given the responsibility of executing the vision from the demo and the design theories. The initial goal of the Cabal was to create a complete design document detailing level designs, enemy interactions, special effects, plot devices and design standards. It is important in relation to the design document that the team does no t commit to a specific implementation. In this sense, you could claim that the design document is merely a written down brainstorm to what Cerny and John (2002) calls micro-design. 4.4.2. The Cabal Process After the establishment of a clear vision through the construction of the demo and the formulation of design theories, the Cabal Process is initiated. At Valve, the original idea of creating a design Cabal came after interviewing numerous promising applicants for the lead design position. None of the applicants had enough of all the qualities the Half-Life team wanted in an overall godlike game designer. The problem was that it was impossible for a 68
Game design and development - asbjoern@asbjoern.com single person to have the in-depth knowledge of all the areas that the Half-Life team demanded. It was impossible to find the ideal lead designer. Instead, the team created their ideal, by combining the strengths of a cross section of the team, putting them together in a group called the Cabal (Birdwell 1999). This Cabal group has the lead designer authority and makes design decisions during the implementation period. The Cabal group should represent all the major groups in the development team, which was very similar to the competences represented in the team making the initial Publishable Demo. At the Half-Life production, the Cabal consisted of three software engineers, a level designer, a writer, and an animator. An interesting notion when compared to industry standard is that the Cabal only consisted of people with responsibility for actually shipping components of the game. In this sense, there were no dedicated designers. This way, everybody involved in the design process would have responsibility or at least have the ability of actually doing the work that the design specified (Birdwell 1999). After a while, people should be rotated through the Cabal group. This rotation scheme is important both in relation to keeping a productive pace preventing creative burnout and in empowering the team to ensure that creative resources are not lost. To ensure continuity, a few people from the last group should be included, and the Cabal should always represent a cross section of the company (Birdwell 1999). 4.4.3. Collaborative Design Summary One of the most valuable elements in the Cabal Process is that it ensures that everyone becomes invested in the design. Besides preventing the team from a creative burnout, the rotation cycle in the Cabal also ensures that people are not just working in one limited area of the game. This process ensures that more than one level designer works at all levels. Consequently, everybody will be able to make changes to levels if this is needed later in development without
69
Game design and development - asbjoern@asbjoern.com being dependent on a specific designer 26 . In this way, collective ownership of the assets ensures that the number of critical paths is reduced from single individuals to the team, thereby reducing the risk exposure significantly. Furthermore, the collective ownership of assets helps tacit knowledge to spread across the team 27 . The Cabal Process moves the critical path to a sub-team instead of an individual.
4.5. Playtesting
As noted in the postmortems analysis, it can be a problem if playtests are not integrated into the production process. Production teams that failed to establish formal procedures for playtesting had difficulties tracking project progression. The reason was that features that had been signed off were implemented, but they did not provide the expected user experience when they were tested towards the end of the production cycle. In the end, these features have to be corrected, which will cause unexpected reworks in assets and game mechanics. As mentioned in the discussion of software methodologies, the sooner you address a defect the cheaper it will be to fix it (McConnell 1998:29-36). This general rule also applies to non-code features. The longer your feedback loop is, the longer it will take until the error can be corrected, and in the end the more costly it will be to correct the error. In order to address this issue, the production team will have to establish formal procedures for signing off assets and features. Otherwise, the team can easily end up in a situation where features/levels are not playtested before they are signed off, in the end causing reworks and inconsistency in the product. In the Cabal Process, continuous playtesting is incorporated into the production cycle. These playtest sessions are used to evaluate the gameplay mechanics before they are signed off.
Valve call these corrections Action Items. Action Items are made based upon gameplay testing 27 In XP the equivalent to this would be pair programming
26
70
Game design and development - asbjoern@asbjoern.com Playtests can be easily isolated to individual game levels 28 . From a management point of view, it makes sense to set the scope of each playtest to individual game levels. Thus, a level can be iterated independently from the rest of the content pipeline. In the Cabal Process, each playtest session is attended by a member of the Cabal and one of the people working with the specific part of the game. For example, if the goal of the test session is to test the AI, the AI programmer should be present and so forth. After each test, the results are evaluated, and this is done by making a list of issues that need to be fixed called Action Items. These Action Items are reported back to the Cabal, which is responsible for prioritising and resolving the Action Items. After the Action Items have been addressed, a new iteration begins; the process is repeated until all the issues are resolved and the level can move to the next step in the process (Jacobson and Speyer 2005). In the Cabal Process, this validation process is separated into two steps. First step is to create a mock-up of the level with primitives. This step in the pipeline is referred to as the Agent Orange stage, since the level only consists of grey and orange primitives. The Agent Orange mock-up phase is repeated until the core gameplay of the level is validated through the playtests. The validation criteria are the same in all steps in the process: the design theories/Design Rules must never be compromised, and the game must never be boring to the tester. The Agent Orange iterations of each level ensure that a minimum of assets has to be discarded when changes are made to the level. After passing the first step, the level is ready for the next step in the process. In the next step, the level is handed over to the visual artist and the implementation of the graphical assets begins. After the art implementation, the level is playtested again and is validated according to the same criteria as the last step in the process. In this step of the process, it is important to ensure that gameplay has not been broken by the graphical assets. As the level of
28
Some playtests, such as interface tests and tests of core mechanics, might not be restricted to single levels; while these tests are valuable, they are not useful to evaluate specific assets.
71
Game design and development - asbjoern@asbjoern.com abstraction is reduced by implementing real models and textures, new unexpected problems may arise and consequently break the gameplay. The level is iterated through playtests until the validation criteria are met. To summarize the playtesting procedure in the Cabal Process, it can be noted that while the exact goal of the individual playtest may vary as for A.I., level geometry etc. A key element integrated into the Cabal Process, is that formalized procedures keep testing close to the actual implementation. This helps keeping track of project progression since the progression of each level can be tracked continuously. Furthermore, the cost of iterations/corrections is reduced because of the quick feedback loops.
4.6. Planning
In the postmortems analysis, two prevalent problems regarding planning were found. Firstly, milestones that can not be tested make it difficult to follow project progression. Secondly, large tasks make it difficult to estimate the scope of the tasks causing poor estimates and milestone slippage. As discussed in the previous chapter, agile software development offers concrete guidance on how to structure development routines based on a fluctuating market. Essential in obtaining this is the small incremental
iterations. At the end of each iteration new or improved functionality should be added to a working release. This basic rule assures that the teams focus is targeted towards working software, one of the key premises in agile development routines. In short, the small incremental milestones providing a working release will enable the team to track project progress because the release can be tested. Further the small incremental milestones force the team to create small tasks, which eases the estimation problem. Evidently, the next question is how this is handled in XP and Scrum. In XP, the plan for each iteration is based upon the costumers decision for which features 29 are the most valuable at the given time. A feature or User Story
29
In XP terminology, features are often referred to as a user story.
72
Game design and development - asbjoern@asbjoern.com is a chunk of functionality that adds value to the costumer. Dividing a project into User Stories enables the developer to deliver the system in smaller pieces. In traditional software development projects this is often valuable to the costumer since the system can be taken into use early with reduced functionality, though still adding value to the business immediately. When it comes to video game development, the costumer/developer relationship is slightly different since the customer does not equal the end user. The customer is in most cases a publisher, while the end user is the gamer buying the game. Due to this business model, it does not make sense to release a console game in smaller pieces. Nevertheless, short iterations with improved functionality enable the publisher to track the progress of the project closely. Lessard and Millers (2001) journey metaphor was used to describe the strategic respond to the forecasting dilemma. Since we do not now exactly what the future brings, we had better plan for the journey rather than plan the journey. Beck (1999a) and Beck and Fowler (2001) uses the driving metaphor to describe this situation in relation to XP.
We use driving as a metaphor for developing software. Driving is not about pointing the car in one direction and holding to it; driving is about making lost of little course corrections. (Beck and Fowler 2001:11)
Delivering new working functionality at the end of each milestone enables these continuous course corrections. It is important that a User Story never is larger than that each developer can build a few of them each iteration. The reason for this is that it gives the team the ability to steer the project by shifting stories between iterations (Beck and Fowler 2001:47). Applied on the video game publisher/developer relation, the milestones can help the publisher to steer the project and make corrections based on developments in technology and competing games. In Scrum, each iteration, called a Sprint, is controlled by the Sprint Backlog, in this sense, the Sprint Backlog is similar in function to User Stories assigned to
73
Game design and development - asbjoern@asbjoern.com an iteration in XP. The Scrum process can be explained as shown in Figure 11 below.
Figure 11 Scrum 30 Day Iteration (Source: www.controlchaos.com)
The Sprint/iteration begins with the team agreeing with the customer (in our case the publisher) on a prioritized list of features that the team will implement in the Sprint. The feature list assigned to the Sprint is called the Sprint Backlog. The individual Sprint Backlogs are based on the Product Backlog. The Product Backlog is a complete prioritization of all features desired in the final product. The Sprint Backlog consists of the features assigned to a given Sprint/iteration. The Sprint Backlog is created each month in corporation between the team and the product owner (publisher). The team estimates first priority features in the Product Backlog. Based on these estimates, the team and the project owner (publisher) agree on which features should be assigned to the Sprint Backlog. If the team advances quicker through the Sprint Backlog than estimated, they add 74
Game design and development - asbjoern@asbjoern.com new features from the Project Backlog to the Sprint Backlog. If the team advances slower than initially estimated, they complete the features from the Sprint Backlog in prioritized order, leaving the lowest priority features to next Sprint. At the end of each sprint, new functionality should be added to a working release. The product owner now evaluates the new functionality. Consequently, the project owner evaluates the priorities in the Product Backlog and creates a Sprint Backlog for the Next Sprint based on this. As the team and the project owner become more familiar, the estimates will tend to become more and more accurate. This Scrum process gives the project owner the ability to steer the project and make small corrections continuously. During the Sprint the team has daily Scrum meetings 30 . At these meetings, everybody tells the rest of the team what they have worked on since the last meeting, whether they have encountered any problems since last meeting and what they will work on before the next meeting. The Scrum meetings are a simple but effective management tool to actively spread knowledge across the team. Nonaka et al. (2000) labels four processes that transform tacit to explicit knowledge and vice versa. This understanding of the knowledge creation process can be used to describe the processes utilized in both Scrum and XP.
The Scrum process can be scaled to bigger project were the project managers/Scrum Master have regular meetings with other Scrum Masters. The Scrum of Scrums.
30
75
Figure 12 Simplified SECI Model (Socialisation, Externalisation, Combination, Internalisation) (Simplified version of Nonaka et al. 2000 SECI Model)
At the daily meetings, tacit knowledge is spread from individual to individual through socialization. Knowledge is externalized when corrections are made to the Sprint Backlog by articulating the tacit knowledge into explicit concepts. This process also works the other way around, enabling team members to internalize explicit knowledge from the Sprint Backlog into tacit knowledge that can be utilized during the work process. As more explicit knowledge is produced, the Sprint Backlog can be refined by combining explicit knowledge with explicit knowledge. While the theoretical terms (Socialization, Externalization, Internalization and Combination) for these processes are less useful in the daily management, the understanding of the knowledge creation practice is valuable. A simple 15-minutes daily meeting can help boost the speed of the knowledge creation loops, which is illustrated with a spiral in
76
Game design and development - asbjoern@asbjoern.com Figure 12. In this way, the daily meetings ensures a rapid flow of knowledge across the team. To sum up, in both XP and Scrum focus is on small incremental milestones. The most concrete framework is Scrums 30 day iterations called Sprints. After each sprint, the overall progression of the project can be evaluated. Secondly, both XP and Scrum avoid large tasks by limiting the scope of the individual features/User Stories in the Sprint Backlog. The focus on small tasks makes estimations more accurate, which reduces the risk for schedule slippage.
4.7. Summary
In this chapter, I have identified solutions to the problems found in the postmortem analysis. The solutions presented take both take into account the concrete problems found in the postmortem analysis and the current market condition. Firstly, the response to the problems that arise because of the lack of design documentation and vague vision statements before going into full production can be found in the FLDM. Cerny and Johns (2002) FLDM focuses on identifying risk during preproduction by making a Publishable Demo and a Macro Design before going into full production. Secondly, a problem identified in the postmortem analysis was that poor communication of the vision caused communication breakdown and asset reworks. In response to this, it was suggested that Design Rules are established during the preproduction phase. Design Rules make it easier to communicate the vision across the team. Furthermore, Design Rules enable the team to establish formal practices for validating assets. Thirdly, as pointed out in the postmortem analysis, it is difficult to estimate tasks and validate progress. The solution to this is to adopt some of the practices used in XP and Scrum. The most important one is small iterations and incremental milestones. When working with shorter iterations, the publisher is able to track the project progress and steer the project in the desired direction, which makes it more likely that it will be a market success. 77
Game design and development - asbjoern@asbjoern.com The last problem identified in the postmortem analysis is that lack of continuous testing makes it difficult to track project progression. The knowledge we can adopt from XP and Scrum is that the closer the test is to the actual implementation, the more efficient the work process. This is utilized in the Cabal Process where playtests are performed each time new assets are added to a level. Having the Design Rules as a validation tool in this process enables management to communicate clear playtest guidelines.
78
5. A game development framework proposed

In this chapter, I will combine the findings from the previous chapters into a model suggesting how to successfully structure a game development project. The findings in this thesis are primarily based on the GDM postmortems and various theoretical writings. In this sense, this model - as I am presenting it has not been used to develop an AAA title, and it would be reasonable to claim that the model suggested in this chapter is unlikely to provide enough detail to stand alone. The model is not detailed in the sense that I provide concrete guidance on how to go about daily development routines. The aim for this model is to summarize some of the issues that I believe are important to consider when producing AAA titles. In this thesis, I have chosen not to go into detail with issues such as coding practices in general. The reason for this is in part the limitations in the scope of this thesis, but maybe more importantly that coding practices are well documented in contemporary software development literature. In this thesis I have focussed on the three steps in the game development process I believe distinguish game development projects from traditional software development projects: Game design, requirement
phase/preproduction and playtesting of assets. The model I propose in this chapter is therefore limited to address these issues alone and cannot stand alone as the method that solves all problems inherent in game development. The model I am proposing is divided in two: a preproduction phase and the full production phase. The main difference between the two phases is the size of the team. The team in the preproduction phase is smaller and therefore easier to control. As discussed with reference to Zimmermans (2003) Iterative Design Process, smaller teams make the iteration costs smaller, and the ability to rapidly evolve the game and improve product quality makes it an advantage to have a small team during the preproduction phase. In the production phase, the 79
focus shifts from developing the game design and technology to actually producing the game. In this phase, the scope of an AAA title makes it necessary to increase the team size significantly. The increased team size poses new challenges to the management; as I will suggest, the solution to meeting this challenge is to establish a formalized assets production model. The model I am proposing is based on four main contributions: 1) Cerny and Johns (2002) front loaded development model, 2) my own notion of Design Rules inspired form Spector (1999), Jacobson and Spreyer (2005), Birdwell (1999), Tsunoda (2004) and Greig et al. (2002), 3) Valve Softwares playtesting routines, and lastly 4) Scrums planning processes. From Cerny and John (2002) I use the terminology of Macro Design and Publishable Demo. Design Rules are introduced to establish formal review criteria for asset/level evaluations. By introducing the concept of Design Rules and combining this concept with the concepts of Macro Design and Publishable Demo, I refine Cerny and Johns (2002) preproduction model. By refining Cerny and Johns (2002) model, the risk of miscommunication and asset reworks when entering full production is reduced. Inspired by Valves playtesting routines I used the Action Item terminology. From Beedle and Schwaber (2002) I use the Scrum Sprint Model. By applying the terminology from Scrum, Action Items, Macro Design and Design Rules I propose a 30 Day iteration model for computer games development. This model is aimed towards the full production phase.
5.1. Preproduction
As discussed earlier, the key to a successful preproduction is to identify project risks. Cerny and Johns (2002) Front Loaded Development Model helps us to understand where focus should be directed during the preproduction phase. A prevalent problem in contemporary game development practices is that the 80
projects have the biggest risk exposure in the phase of the production process, which is the most expensive phase. One of the big problems is that individual developers can not fund the preproduction alone. Publisher funding is needed. This poses a dilemma where many developers tend to shorten the preproduction period and go into full production before the game is ready for it. The aim of the FLDM is to avoid this situation by identifying and addressing risks during the preproduction phase. In the preproduction phase, the team is small and iterations are therefore cheap compared to later in the development cycle. The asset pipe line is not yet set up and therefore relatively few assets must be discarded when the game concept changes. By constructing a demo of publishable quality, the team will uncover unidentified risks, both risks associated with technology and creative risks such as gameplay. By performing Sniff-tests the commercial potential of a title can be evaluated before entering the production phase. Even though commercial success can never be guaranteed, this approach will expose the project to relatively smaller risks. In Cerny and Johns (2002) FLDM, however, an important factor is neglected. The importance of clear guidelines to evaluate the assets as they are developed during the full production is not incorporated into their FLDM. Design Rules has proved to be a successful management tool in a number of productions. I therefore suggest that the Design Rules are incorporated into the preproduction phase in order to establish clear guidelines on how to evaluate assets later in the production process. The exact formulation and structure of the Design Rules may vary from production to production; the important thing is that the Design Rules are clear enough to be used as an evaluation tool later in the production process. We can hereby refine Cerny and Johns (2002) front loaded development model by adding Design Rules as just as important as the Macro Design and the Publishable Demo.
81
Macro Design Publishable Demo
Design Rules
Figure 13 Issues that should be addressed before entering full production
5.2. Production
As mentioned earlier, the two main concerns in this thesis besides the preproduction phase are how to structure the asset evaluation and design phases, respectively. When entering the full production phase, the first part of the design process has been addressed, resulting in the Macro Design. During the production phase, the main design concern is the day-to-day
implementation of the Micro Design based on the Macro Design. This process is closely related to the playtesting processes since it is the playtests which, with the Design Rules as evaluation criteria, are used to determine whether the design is implemented well enough. The prevalent idea in this line of thought is that the closer to the actual implementation we can place the test, the cheaper the iterations and the better the product quality. This mindset is imported from agile practices such as XP where unit testing, automated build processes etc. enable the programmer to gain rapid feedback and make quick corrections. The problem in relation to playtesting is that it can not be automated in the same way as for instance unit testing. Furthermore, playtesting has a normative 82
evaluation criterion whereas unit testing can be objective in the sense that it tests for exactly the same every time they are run. The solution to this can be displayed as suggested in Figure 14.
Figure 14 Game development process
The above figure is inspired by the Scrum model. But whereas Scrum only addresses code production, this model address the rest of the asset pipeline as well. After the preproduction phase, a Macro Design is used as a product backlog to control the development process. Similar to Scrum, the team works with 30day iterations, and perform daily stand-up meetings. Each iteration is controlled by a 30 Day Iteration Backlog based on the monthly prioritizations of the Macro Design. The main difference from the Scrum process is that playtesting cycles are integrated into the process every week. These playtesting sessions are used to evaluate the assets/levels before they can be signed off. At each playtest, the knowledge gained is formalized by making an Action Item list. These Action Items are then incorporated into the Iteration Backlog. When 83
all Action Items on an asset/level have been addressed, the assets can be playtested again. If no further Action Items are identified, the asset/level can be signed off and added to the working release. At the end of each 30 Day Iteration, the team evaluates the working release in co-operation with the publisher, and a new 30 Day Iteration Backlog which is based on the working release and the Macro Design is agreed upon., At these evaluations, the publisher can make corrections to the game based on the development in the market. If a competing game with a new genre defining feature has been released, it might be crucial to the market potential of the game to incorporate such a feature into the final release. In this situation, the publisher has the ability to make corrections to the Macro Design (Product Backlog), in order to meet market demands. It is of course obvious that these changes are corrections, not major changes. But in a two-year development timeframe, which is not uncommon when producing AAA titles, these small course corrections will have significant impact on the final product. In the end, these small correction to the Macro Design will remove risk from the project because of a higher probability of market success.
84
6. Concluding remarks
To summarize this thesis the following can be concluded. By refining Cerny and Johns (2002) preproduction model with the addition of Design Rules it is secured that technical risks, creative risks and evaluation criteria for the asset pipeline is established before going into full production. By combining Valve Softwares playtesting routine with the Scrum development framework, the review process can be formalized making asset signoff less error prone. This enables management to track project progression. Furthermore, by focusing on 30 Day Iterations the project owner/publisher is able to steer the project through monthly reviews. This enables the publisher to better adapt to drift in the market, and enhances the chances of the game performing well in the marketplace at release. The insight gained from combining agile development, project management theory and the postmortems analysis enabled the proposition of a new development framework. Furthermore, the findings enable us to conclude on the problem we initially intended to clarify.
How do we combine agile practices with game development methods and project management theory in order to improve the understanding of the preproduction phase, the design phase and the asset production phase? Furthermore, how can we utilize this knowledge to find solutions to prevalent problems identified in GD postmortems?
Design is a prevailing aspect of both the preproduction and the asset production phase or full production. In this sense, the design phase is omnipresent throughout the entire production and should be addressed as part of the preproduction phase and part of the asset production phase. Hence, the conclusion is divided in three; theoretical conclusions, the preproduction phase and the full production phase.
85
6.1. Project management, agile practices and game development combined

From a project management perspective, the most important
acknowledgement was made based on Lessard and Miller (2001). Two basic premises in project management were identified; firstly, the need to frontload project risk and secondly, the benefits of reversible decision making. To refine this, Kreiners (1995) understanding of the drifting environment was introduced. Environmental drift refers to a situation where the expected course of the project is altered by unforeseen events outside the project organization. In order to respond to this situation the project organization has to adapt. Instead of having a fixed static structure, the project organization becomes what Truex et al. (1999) labels an emergent organization. The emergent organization is unlike the static organization in a constant state of reshaping itself in order to adapt to the drift in the surrounding environment. Game development companies fit perfectly into this emergent organization form, since their organizational form in the present is bound to current games in development. An interesting coupling can be made between agile developments focus on reducing the cost of change and the emergent organizations similar focus on reducing the cost or organizational change. Furthermore, agile development is, like Lessard and Miller (2001), focussed on reversible decision making. The discussion of cost of change and the discussion of reversible decision making are closely related. The rationale is that by motivating reversible decision making, management will be able to keep the cost of change low, thereby ensuring the ability to adapt to a drifting market. Within the field of game development methods, Cerny and Johns (2002) preproduction model also focuses on front loading project risks. By constructing a Publishable Demo and a Macro Design, both technical and creative risks are front loaded. It is important to stress that even though the use of Cerny and Johns (2002) preproduction models is completely different from 86
that of Lessard and Miller (2001), Kreiner (1995) and Truex et al. (1999), the underlying principle in their arguments is the same. In this sense, the arguments presented by all authors are mutually inclusive and therefore can be used to advocate the use of either methodology.
6.2. The Preproduction Phase

The knowledge gained from contemporary project management literature and agile practices can be used as an argument for the use of Cerny and Johns (2002) preproduction model. However, Cerny and Johns (2002) preproduction model does not address all the problems in relation to preproduction which we have identified in the postmortem analysis. A prevalent problem identified in the postmortem analysis is the lack of formalized procedures for
communicating the project vision to the team. Furthermore, teams that failed to establish formal review practices for assets before entering full production encountered problems with asset reworks later in the development cycle. In order to address this problem, a third element was added to the preproduction phase; Design Rules. Design Rules are simple rules for evaluating assets through playtests. By adding formalized Design Rules as a demand before entering full production, it is secured that the evaluation criterion for the playtests later in the development cycle is established. In this way, a preproduction model addressing both the most prevalent problems in contemporary game development practices and contemporary literature was constructed.
6.3. The Asset Production Phase

After establishing a preproduction model, the asset production phase or full production phase was addressed. During the asset production phase, the main design concern is the day-to-day Micro design decisions, based on the Macro Design made during the preproduction phase. The initial project vision must be omnipresent in all assets produced in order to maintain a cohesive whole 87
throughout the production. Furthermore, the management must be able to steer the project through the drifting environment. The Scrum model presented by Beedle and Schwaber (2002) enables management to steer the project through the drifting environment by making adjustments to the Project Backlog every thirty days. However, the Scrum model is based on traditional software production where the main concern is evaluation of code. In game development projects, not only code but also assets such as levels, sound, graphics and the like have to be evaluated. Therefore, the Scrum framework has to be modified in order to account for this difference. A prevalent idea in agile development practices is that unit test, automated build processes etc. enable the programmer to gain rapid feedback and make quick corrections. However, in order to evaluate assets such as levels playtests have to be performed. Hence, a formal playtesting procedure must be integrated into the framework. This is achieved by integrating Valve Softwares playtesting routine and using Design Rules as an evaluation criterion into the Scrum framework.
6.4. Future work

The conclusion to this thesis should be seen in the context of the methods I have used. The use of the postmortems as an empirical source is biased. As mentioned in sections 2.1 and 2.2, this poses some limitations to the applicability of the empirical material used in the thesis. However, I would never have been able to gain insight in such a high number of game productions if I had chosen to collect the data in person. In this sense, the quality of the empirical data prevents me from making inclusive conclusions; rather my conclusion must be narrowed to represent an assumption. The framework I have presented cannot be validated though empirical testing. However, based on my theoretical and empirical studies it cannot be excluded either. In this sense, I believe that the conclusions in this thesis help further the 88
understanding of the subjects discussed, hopefully providing inspiration for practitioners in the evaluation of contemporary practice. The next step in this process is to actually apply this framework to a development project in order to validate its usefulness. Furthermore, this thesis has been limited to the preproduction, the design and the asset production phases. The framework proposed is mainly focussed on these three phases. However, a complete development framework will have to address in detail descriptions of the actual day to day practices. Everything from version control to error handling should be described in order to create a complete framework. This has already been done to a large extent in contemporary literature on software development. It is nevertheless important that these methods acknowledge the drifting market before incorporating them into the front loaded development model. If this is not the case, the model I have proposed will become obtrusive.
6.5. Final remarks

This thesis has shown that there is a way for game developers to reduce both the risk of schedule slippage and budget overruns, by planning for the journey rather than plan the journey. I have proposed a game development model that actively meets this challenge, by front loading both creative and technical risk. Just as important the development model I have proposed improve the publishers ability to succeed steering the project trough currents in the gaming market. The key to succeed in steering the project is small continual course corrections obtained by focussing on small incremental milestones. This enables the publisher to continually make small adjustments following the drifts in the market.
89
7. Literature
Abrahamsson, P., O. Salo, J. Ronkainen, and J. Warsta 2002 Agile software development methods: Review and Analysis. Espoo, Finland: Technical Research Centre of Finland, VTT Publications 478, http://www.inf.vtt.fi/pdf/publications/2002/P478.pdf Abrahamsson, P., J. Warsta, M.T. Siponen and J. Ronkaimn 2003 New Directions on Agile Methods: A Comparative Analysis, Published in the Proceedings of the International Conference on Software Engineering, May 3-5, 2003, Portland, Oregon, USA. Beck, K. 1999a Extreme programming Explained Embrace Change Beck, K. 1999b Embrace Change with Extreme Programming, IEEE Computer Beck, K. 2001 Test Driven Development By Example, Addison Wesley, ISBN: 0-321-14653-0 Beck, K. 2003 Scale-Free Extreme Programming, http://groups.yahoo.com/group/scalefreexp/ Beck, K. and B. Boehm 2003 Agility through Discipline: A Debate, IEEE Computer Beck, M. and M. Fowler 2001 Planning Extreme Programming Beedle, M. and K. Schwaber 2002 Agile Software Development with Scrum, Prentice Hall, ISBN: 0-13-067634-9 Bettis, R.A. and M.A. Hitt 1995 The new competitive landscape, Strategic Management Journal 16, 7-14 Birdwell, K. 1999 The Cabal: Valves Design Process For Creating Half-Life, Game Developer December 1999 Boehm, B. 1985 A Spiral Model of Software Development and Enhancement in IEEE Computer Vol.21 Issue.5 Cerny, M. 2002 The Method: A Model for Game Design, Web lecture, http://www.gamasutra.com/features/slides/cerny/index.htm Cerny, M. and M. John 2002 Game Development: Myth vs. Method, Game Developer June 2002 Chatzoglou, P.D. and L.A. Macaulay 1996 Requirements capture and IS methodologies, Information Systems Journal, 6, 209-225 Chapin, N. 1981 Flowcharts, Auerbach , New Jersey Crispin, L. and T. House 2001 Testing in the Fast Lane: Automating Acceptence Testing in an Extreme Programming Environment http://www.xpuniverse.com/2001/pdfs/Testing06.pdf Crispin, L., T. House, C. Wade 2002 The Need for Speed: Automating Acceptance Testing in an eXtreme Programming Environment in http://www.upgrade-cepis.org Vol. III, No. 2, April 2002 p. 11-18 Dijkstra, E. 1972 The humble programmer, In: E. Yourdon 1979 Classics In Software Engineering Yourdon Press, New York Fitzgerald, B. (1996), Formalized systems development methodologies: a critical perspective', Information Systems Journal, Vol. 6, pp. 3-23. Fowler, M. 1999, Refactoring: Improving the Design of Existing Code, Addison-Wesley, ISBN: 0-201-48567-2 Fowler, M. 2000a Is Design Dead? http://martinfowler.com/articles/designDead.html Fowler, M. 2000b New Methodology http://www.martinfowler.com/articles/newMethodology.html Fowler, M. and M. Foemmel Continuous Integration http://www.martinfowler.com/articles/continuousIntegration.html Fowler, M. and C. Taber 2001 Planning and Running an XP Iteration http://www.martinfowler.com/articles/planningXpIteration.html
90
Gibson, N., B. Keen, M. de Gentile-Williams and N. Parker 2005 " Games Software Publishing: Strategies for market success, http://www.screendigest.com/reports/05_games_s_pub/readmore/view.html Highsmith, J. 2000 Extreme Programming Agile Projects Management Advisory Service White Paper, Cutter Consortiums Business Application Delivery Newsletter, December 2000 Hirschheim, R., H.K. Klein and H.E. Nissen 1991 A Pluralist Perspective of the Information Systems Research Arena, In: Information Systems Research; Contemporary Approaches and Emergent Traditions 1-21, North-Holland, ISBN: 0 444 89029 7 Irish, D. 2005 Game Producers Handbook Thomson Course Technology, ISBN: 1-59200-617-5 Jacobi, C. and B. Rumpe 2001 Hierarchical XP Improving XP for large scale projects an analogy to reorganization processes, http://www.sse.cs.tubs.de/~rumpe/publications/papers/JR01/JR01.pdf Jacobson, B. and D. Spreyer 2005 Scaling The Cabal: Valves Process For Creating Half-Life 2, Game Developer November 2005 Jenkins, A., J. Nuamann and J. Wetherbe 1884 Emperical investigations of systems development practices and results, Informations and Management, 7, 73-82 Khan and Balbo 2005 Agile versus Heavyweight Web Development: an Australian Survey http://ausweb.scu.edu.au/aw05/papers/edited/khan/paper.htm Kreiner, K. 1995 n Search of relevance: Project Management in Drifting Environments, Scandinavian Journal of Management 11 (4) , p. 335-346. Kvale, S. 1996 InterViews : An Introduction to Qualitative Research Interviewing, SAGE Publications, ISBN: 0-8039-5819-6 Lessard, D.R. and R. Miller 2001 The Strategic Management of Large Engineering Projects: Shaping Institutions Risks, and Governance, Massachusetts Institute of Technology, ISBN: 0-262-12236-7 Maurer and Mantek (2002) On the Productivity of Agile Practices: An Industial Case Study McConnell, S. 1996 Rapid Development, Microsoft Press, ISBN 1-55615-900-5 1 McConnell, S. 1996 Software Project Survival Guide, Microsoft Press, ISBN 1-57231-621-7 Nonaka, I., R. Toyama and N. Konno 2000 SECI, Ba and Leadership: a Unified Model of Dynamic Knowledge Creation, Long Range Planning 33 (2000) 5-34 Nonaka, I. and H. Takeuchi 1995 The Knowledge Creating Company, Oxford University Press. ISBN: 0-19-509269-4 Olaisen, J. 1991 Pluralism or Positivistic Trivialism: Important Trends in Contemporary Philosophy of Science, In: Information Systems Research; Contemporary Approaches and Emergent Traditions 235-267, North-Holland, ISBN: 0 444 89029 7 Palvia, P. and J. Nosek 1993 A field examination of systems lifecycle techniques and methodologies, information and Management, 25, 73-84 Plat, N., J. Katwijk andK. Pronk 1991 A case for structured analysis/formal design In: S. Prehn and W. Toetenel (eds.) VDM 91 Formal Development Methods, Vol. 1, Springer-Verlag Berlin Ramamoorthy, C., V. Garg and Prakash 1986 Programming in the large IEEE Transactions on Software Engineering, SE 12, 769-783 Royce, W.W. 1970 "Managing the Development of Large Software Systems", Proceedings from IEEE Computer Conference in WESCON, available at http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf Spector, W. 1999 Remodeling RPGs for the New Millennium in GD, Feb. 1999 (can also be found at http://www.gamasutra.com/features/game_design/19990115/remodeling_01.htm Spolsky, J. 2000 Painless Software Schedules at http://www.joelonsoftware.com/articles/fog0000000245.html
91
Truex, D., R. Baskerville and H. Klein 1999 Growing Systems in Emergent Organizations in Communications of the ACM, Vol. 42 No. 8 Truex, D., R. Baskerville and J. Travis 2000 Amethodical systems development: The deferred meaning of systems development methods, Accounting, Management and Information Technology 10: 53-79 Ward. P- 1991 The evolution of structured analysis: Part 1 the early years. American Programmer. 4. 11 4-16 Wynekoop, J.L. and N.L. Russo 1995, Systems development methodologies: unanswered questions', Journal of Information Technology, Vol. 10, pp. 65-73. Wynekoop, J.L. and N.L. Russo 1997, Studying systems development methodologies: an examination of research methods', Information Systems Journal, Vol. 7 No. 1, pp. 47-65. Yourdon, E. 1991 Sayonara, onc again, structured stuff American Programmer, 4, 8, 31-38 Zimmerman, E. 2003 Play as Research: The Iterative Design Process In Design Research: Methods and Perspectives ed. Laurel, B. Zolnowski, J. and P. Ting 1988 An insiders survey of software development, Journal of Systems and Software, 8, 331-336
7.1. Postmortems referred to in the analysis

Boyle et al. 2005, The Sims 2 Postmortem GD January 2005 Carlton et al. 2003, Jurassic Park: Operation Genesis Postmortem gamasutra.com Marts 2003 Chaneleh and Papp 2001, Kohan Postmortem GD August 2001 Chey 1999, System Shock 2 Postmortem GD November 1999 Corry 2001, Star Wars Starfighter Postmortem GD July 2001 Esmurdoc 2005, Pshychonauts Postmortem GD August 2005 Fischer and Street 2003, Age of Mythology Postmortem GD February 2003 Fristrom 2002, Spiderman Postmortem GD August 2002 Fristrom 2004, Spiderman II Postmortem GD September 2004 Frost 2003, Asherons's Call 2 Postmortem GD September 2003 Greig et al. 2002, Never Winther Nights Postmortem GD November 2002 Hao 2003, Tom Clancys Splinter Cell Port from Xbox to PS2 Postmortemgamasutra.com July 2003 Hastings 2005, Ratchet & Clank: Up Your arsenals Postmortem GD February 2005 Hubbard 2001, No One Lives Forever Postmortem gamasutra.com June 2001 Huebner 2000, Vampire: The Masquerade - Redemption Postmortem GD July 2000 Jobling 2003, Big Mutha Truckers Postmortem gamasutra.com December 2003 Leonard 1999, Thief: The Dark Project Postmortem GD July 1999 Lopiccolo and Rigopulos 2003, Amplitude Postmortem GD August 2003 Mallat 2004, Prince of Persia: Sands of Time Postmortem GD April 2004 Millinger 2002, Medal og Honor: Allied Assault Postmortem GD June 2002 Molyneux 2001, Black & White Postmortem GD June 2001 Morichere-Matte et al. 2003, Homeworld 2 Postmortem GD November 2003 Oakden 2001, Fall Out Tactics Postmortem GD april 2001 Pickford et al. 2004, Project Gotham Racing 2 Postmortem GD Marts 2004 Price 2003, Ratchet & Clank Postmortem GD June 2003 Pritchard 1998, Age If Empires Postmortem GD marts 1998 Pritchard 2000, Age If Empires II: The Age of Kings Postmortem GD January 2000 Ragaini 2000, Asherons's Call Postmortem GD April 2000 Rooke 2003, Tron 2.0 Postmortem GD October 2003 Rouse III 2002, Draken: The Ancients' Gates Postmortem GD July 2002 Rouse III 2004, The suffering Postmortem GD May 2004
92
Saunders 2005, Knights of the Old Republic II Postmortem GD April 2005 Shaefer 2000, Diablo II Postmortem GD October 2000 Smith 2001, Tropico Postmortem GD September 2001 Spanel and Spanel 2002, Operation Flashpoint Postmortem GD January 2002 Spector 2000, Dues EX Postmortem GD November 2000 Train and Reynolds 2003, Rise of Nations Postmortem GD July 2003 Upton 1999, Rainbow Six Postmortem GD May 1999 White 2002, Jak & Daxter: The Precursor Legacy Postmortem GD April 2002
7.2. Postmortem overview

The postmortems marked with grey have been disregarded in my analysis because they were either not concerned with AAA productions or only concerned with very limited parts of the process e.g. sound production etc.
Game Developer Issue December 2005 October 2005 September 2005 August 2005 May 2005 April 2005 Marts 2005 February 2005 Game Pac Man Resident Evil 4 Final Fantasy VII Pshychonauts Alien Hominid Knights of the Old Republic II Silent Hill 4 Ratchet & Clank: Up Your arsenals Author Turo Iwatani Yoshiaki Hirabayashi Kosai Ito Caroline Esmurdoc Tom Filp and John Baez Kevin Saunders Akihiro Imamura and Akira Yamaoka Brian Hastings Lucy Bradshaw Matt Brown, Tim LeTouneau and Paul Boyle Keita Takahashi Adel Chaneleh Ellen Eichler James Fristrom Mark Long Kudo Tsunoda Richard Rouse III Developer Namco Capcom Square Co. Ltd. Double Fine Productions The Behemoth Obsidian Entertainment Konami Insomniac Games
January 2005 December 2004 November 2004 October 2004 September 2004 August 2004 July 2004 May 2004 April 2004
The Sims 2 Katamary Damacy Kohan II and Axis and Allies Momentum Spiderman II Shadow Ops: Red Mercury Fight Night 2004 The suffering Prince of Persia: Sands of Time
Maxis Namco TimeGate Studios Blue Ridge Treyarch Zombie Studios EA Chicago Surreal Ubisoft Montreal
Marts 2004 February 2004 January 2004
Yannis Mallat Garrentt Young, Mario Project Gotham Racing Rodriguez and Chris 2 Pickford Weapons Over Normandy Morgan W. JAK II Daniel Arey
Bizarre Creations Totally Games Naughty Dog
93
December 2003
Knights of the Old Republic
November 2003 October 2003 September 2003 August 2003 July 2003 June 2003 May 2003 April 2003 Marts 2003 February 2003 January 2003 December 2002
Homeworld 2 Tron 2.0 Asherons's Call 2 Amplitude Rise of Nations Ratchet & Clank Sly Cooper Battle Engine Aquila Gothic II Age of Mythology No One Lives Forever II And Presto It's Gone!
Casey Hudson, Ray Muzyka, James Ohlen, Greg Zeschuk Geoffrey Thomas, Stephane Morichere-Matte and Joshua Mosqueira Frank Rooke Paul Frost Greg Lopiccolo and Alex Rigopulos Tim Train and Brian Reynolds Ted Price Chris Zimmerman Ben Carter Kai Rosenkranz Ian Fischer and Greg Street Greg Hubbard Michael Saladino Scott Creig, Ray Muzyka, James Ohlen, Trent Oster and Greg Zeschuk Randy Condon Bartosz Kijanka James Fristrom Richard Rouse III Mike Millinger Jonathan Chey Stephen White
BioWare
Relic Entertainment Monolith Tunebine Games Harmonix Big Huge Games Insomniac Games Sucker Punch Lost Toys Piranha Bytes Ensemble Studios Monolith Studio Post Mortem
November 2002 October 2002 September 2002 august 2002 July 2002 June 2002 May 2002 April 2002
Marts 2002 February 2002 January 2002 December 2001 November 2001 October 2001 September 2001 August 2001 July 2001 June 2001
Never Winther Nights Aggressive Inline Dungeon Siege Spiderman Draken: The Ancients' Gates Medal og Honor: Allied Assault Freedon Force Jak & Daxter: The Precursor Legacy Star Wars Rogue Leader: Rogue Squadron II Dark Age of Camelot Operation Flashpoint Cel Damage Rayman Advance Myst III: Exile Tropico Kohan Star Wars Starfighter Black & White
BioWare Z-Axis Gas Powered Games Treyarch Surreal Software 2015 Irrational Games Naughty Dog
Thomas Engel Matt Firor Marek Spanel and Ondrej Spanel Kevin Barett, John Harley and Rich Hilmer Chris Charla Greg Uhler Brent Smith Adel Chaneleh and Denis Papp Chris Corry Peter Molyneux
Factor 5 Mythic Entertainment Bohemia Interactive Pseudo Interactive Digital Eclipse Presto Studios Poptop Software TimeGate Studios Lucas Arts Lionhead Studios
94
May 2001 April 2001 Marts 2001 February 2001
ChickenRun American MacGee's Alice Baldurs Gate II Bachyard Soccer MLS Edition
Dave Manuel and Dave Flynn Jim Molinet James, Dr. Greg Zeschuk abd Dr. Ray Muzyka Eric Gross and Ryan Touchon Brian Pelletier, Michael Gummelt and James Monroe
Blitz Games Rogue Entertainment BioWare Humongous Entertainment
January 2001 December 2000 November 2000 October 2000 September 2000 August 2000
July 2000 June 2000 May 2000
Star Trek Voyager Elite Force Heavy Metal: K.A.K.K. 2 Scott Alden Dues EX Waren Spector Diablo II Erich Shaefer Rick Johnson and Eric Biessman Soldier of Fortune Colony Wars: Red Sun Jullian Gold Vampire: The Masquerade Redemption Robert Huebner Gabriel Knight 3 Scott Bilas Unreal Tournament Brandon Reinhart
Raven Software Ritual Entertainment Ion Storm Blizzard North Raven Software Psygnosis
April 2000 Marts 2000 February 2000 January 2000 December 1999 November 1999
Matt Pritchard Clancy Imislund Janathan Chey Jason Lieghton and Craig Derrick October 1999 Decent 3 September 1999 Centipede 3D Richard Rouse III Jon Blossom and Colette August 1999 Star Wars DroidWorks Michand July 1999 Thief: The Dark Project Tom Leonard June 1999 Trespasser Richard Wyckoff May 1999 Rainbow Six Brian Upton Marts 1998 Age If Empires Matt Pritchard Gamasutra.com Postmortems Publish date December 2003 Game Big Mutha Truckers Author Paul Jobling Hiplito Iroel Prez and September 2003 Legacy Online Marco Cultrera
Asherons's Call Draken: Order of the Flame Command & Conquer: Tiberian Sun Age If Empires II: The Age of Kings Heavy Gear II System Shock 2
Toby Ragaini Stuart Denman Rade Stojsavljevic
Nihilistic Software Sierra Studios Epic Games Turbine Entertainment Software Surreal Westwood Studios Ensemble Studios Activision Irrational Games Outrage Leaping Lizard Lucas Learning Looking Glass DreamWorks Red Storm Ensemble Studios Developer Eutechnyx Oceanus Communications
95
Tom Clancys Splinter July 2003 Cell Wu Dong Hao Kevin Chan, Steven Spagnolo, Shane Stevens, Jurassic Park: Marts 2003 June 2001 April 2001 Operation Genesis No One Lives Forever Fall Out Tactics Nick Haggerm Dan Chau and Geoff Carlton Craig Hubbard Tony Oakden Blue Tongue Software Monolith Micro Forte Ubisoft China
96
8. Appendix
8.1. Software development models
8.1.1. Waterfall model In Royce's (1970) original waterfall model, the following phases are followed perfectly in order: 1. Software Concept 2. Requirements analysis 3. Architectural Design 4. Detailed Design 5. Coding and Debugging 6. System testing To follow the waterfall model, one proceeds from one phase to the next in a purely sequential manner. Thus the waterfall model maintains that one should move to a phase only when its proceeding phase is completed and perfected. Phases of development in the waterfall model are thus discrete, and there is no jumping back and forth or overlap between them (McConnell 1996:137). 8.1.2. Modified Waterfalls The modified waterfall model also referred to as the sashimi model, some of the weaknesses found in the waterfall model is overcome by having the stages in the process overlap each other (McConnell 1996:144). 8.1.3. Code and Fix Code and fix development is not so much a deliberate strategy as an artifact of schedule pressure on software developers. Without much in the way of a design, programmers immediately begin producing code. At some point,
97
testing begins (often late in the development cycle), and the inevitable bugs must then be fixed before the product can be shipped (McConnell 1996:140). 8.1.4. Spiral Model The spiral model is a software development process combining elements of both design and prototyping-in-stages, in an effort to combine advantages of top-down and bottom-up concepts (McConnell 1996:142). The spiral model was defined by Boehm (1985). This model was not the first model to discuss iterative development, but it was the first model to explain why the iteration matters. Each phase starts with a design goal and ends with the client (who may be internal) reviewing the progress thus far. Analysis and engineering efforts are applied at each phase of the project, with an eye toward the end goal of the project. 8.1.5. Evolutionary Prototyping Evolutionary prototyping is a saoftware development model in which you develop a system concept as you move through the project. You star by designing and implementing the most prominent part of the program and thereafter adding and refining the prototype until you are done. In the end the prototyped evolves into the software you release (McConnell 1996:147). 8.1.6. Staged Delivery Staged delivery avoids the waterfall models problem of no part of the system being done until all of it is done. Once you have finished the design, the system is developed and delivered in stages (McConnel 1996:148). 8.1.7. Evolutionary Delivery In evolutionary design each production cycle is iterated until you run out of money, you complete a number iterations planned or the customer is satisfied (McConnell 1996:151). 98
8.1.8. Design-to-Schedule The design-schedule approach is similar to stages delivery. The major difference is that the design-to-schedule model has one drop-dead delivery date (McConnell 1996:150). 8.1.9. Design-to-Tools Design-to-Tools production concept is based on providing exceltional production speed, the tradeoffs is that you have less control over the functionality than you do in the other lifecycle models (McConnel 1996:153).
8.2. Baldurs Gate II Design Rules

Basic Design Rules: The player must always feel as if it is his actions that are making him succeed. He should feel that it is through his smart decisions and actions that he has solved a puzzle or battle. The player must feel as if he is having an effect on the environment. His actions are making a very visible difference with how things are running in the game world. His actions have consequences. When designing, a good and evil path must be considered. Several plots should be marked as changing according to the players alignment.
Story Design Rules: The story should always make the player the focus. The player is integral to the plot, and all events should revolve around him. It is important that the player be kept informed about the progress of the villain. This can be done through cutscenes during chapter transitions, or through integrating him into the main plot from time to time. It is important that there be a twist in the story (or even more than one). This is where a revelation is made to the player that makes him reevaluate whats going on with the story. All of the twists should involve the main player. Twists that the player figures out on his own are also better. It is good to keep the ending of the story open-ended, especially if a sequel or expansion packs are being planned.
99
Environment Design Rules: The game world should be divided into chapters. Each chapter should be of equal size and exploration potential. Each of these chapters should have a rather obvious goal, but one that the player can achieve in any fashion that he wants. Certain areas should be marked as core areas. These areas are usually towns or similar places that the player will be returning to often. Core areas should change as the environment changes. As the player performs actions in other areas, there should be changes to reflect this in the core areas. The player must always feel that he is exploring interesting areas. This means that areas always need to have a unique feel to the art. It is not a good idea to have the player moving between areas often. This becomes annoying. Plots should be kept within the confines of a single area. Its good to show things to the player that he cannot use or places that he cannot go. Later on, these objects or places will become enabled.
Game Systems Design Rules: A well-thought-out reward system must be created. The player should be rewarded often during the course of the game. These rewards can come in the form of XP, items, story rewards, new spells, new monsters, new art, romances, and so on. It is important that the player be able to personalize his character. This means that he should feel that the character he is playing is his own. It is important that the world reflect the ways in which the player has personalized his character.
Writing Guidelines Rules: No modern-day profanity. Each of the dialogue nodes (dialogue pieces) spoken by a nonplayer character (NPC) should be limited to two lines. Only in very rare circumstances are more than two used. All character responses should be one line when they appear in the game. There should be no reason for them to be longer than this. Try not to use accents in dialogue. For certain characters (Elminster, sailor types) it is all right, but for the most part it should be avoided.
100
When using player choices, try to keep the visible number to about three. Two or four are all right, but only when really necessary. When an NPC talks directly to the main player, this should be noted for scripting purposes. Other dialogue should be included for when someone other than the main player talks to this character. Random dialogue should be avoided, or at least used sparingly. Commoners should have only a few random dialogue lines, but there should be several different commoners to talk with.
8.3. RPG Commandments Design Rules used in th Dues EX production (Spector 1999)
Each player's path through the story must be unique. This -doesn't mean a branching-tree structure with winning and losing paths but, rather, that players will have the freedom to decide how they'll overcome game obstacles. A world simulation must be deep enough so that each game problem is open to a variety of solution strategies, from the most thoughtful and low-key to the most obvious and violent. And the solution you choose to any given problem must have clear consequences, both immediate (killing a guard sets off an alarm, attracting more guards) and long-term (killing a guard may result in "wanted" posters being posted, causing civilians to fear you and be less cooperative). Players must always have clear goals. Though free to stray from the storyline at will, players must know what they're supposed to be doing, minute to minute and, if appropriate, mission to mission. The fun of the game is in overcoming obstacles and solving problems; the fun is in how you solve a problem, not in guessing what problem you're supposed to solve. The level of interactivity must be high, with NPCs about whom you really care and with a densely populated, object-rich world that looks and behaves like the real world (or, at least, a believable, internally consistent world of your own creation). A big, empty world is boring. Players must be free to explore a cool and instantly understandable world. The central character must grow and change in ways that matter to players in an obvious and personal way. During the course of play, you'll become more powerful, acquire more items, and develop new skills, of course. However, you'll also make unique friends and enemies, accomplish tasks and missions differently, overhear different conversations, and see different events unfold. By game's end, each player must control an alter ego that is distinct from that of all other players.
101
The game must be about something more than killing things, solving puzzles, and maxing out a character's statistics. Remember all those hours you spent in school analyzing the underlying meaning of novels, poems, and movies? Guess what: RPGs lend themselves to the same kind of analysis. Games can and must have an impact on players. That impact may be the simple adrenaline rush of DIABLO, fleeting and soon forgotten (nothing wrong with that), or it may be the never-to-be-forgotten (and, in some cases, life-changing) experience of becoming the Avatar in ULTIMA IV. If all you're doing is throwing wave after wave of monsters at players so that they can kill lots of stuff so that they can increase some arbitrary statistics so that they can feel powerful, you're doing yourself, your players and your medium a disservice.
8.4. Truex et al. 2000 Table 1
102

Asbjoern Thesis

Загружено:

Сведения о документе

Исходное описание:

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Asbjoern Thesis

Загружено:

Авторское право:

Доступные форматы

Game design and development - asbjoern@asbjoern.

Game Developer Postmortems ...................................................................... 13

2.3.1. 2.3.2. 2.3.3. 2.3.4. 2.4. 2.5. 2.6. 2.7.

Project management in a drifting environment .......................................... 35

Establishing a game development framework ............................................ 56

4.2.1. 4.2.2. 4.3. 4.4.

Game design and development - asbjoern@asbjoern.com

4.4.3. 4.5. 4.6. 4.7.

Collaborative Design Summary ............................................................................... 69

A game development framework proposed................................................ 79

Concluding remarks ........................................................................................ 85

Game design and development - asbjoern@asbjoern.com

Game design and development - asbjoern@asbjoern.com

Asbjrn M. Sndergaard Copenhagen, Denmark 2006

Game design and development - asbjoern@asbjoern.com

1.1. The focus of this thesis

Game design and development - asbjoern@asbjoern.com

1.2. Empirical study

Game design and development - asbjoern@asbjoern.com

1.3. Theoretical field

Game design and development - asbjoern@asbjoern.com

Game design and development - asbjoern@asbjoern.com

1.4. Establishing a framework for game development

Game design and development - asbjoern@asbjoern.com

Game design and development - asbjoern@asbjoern.com

Game design and development - asbjoern@asbjoern.com

2. Game Developer Postmortems

Game design and development - asbjoern@asbjoern.com

2.1. The GD Postmortems as empirical material

Game design and development - asbjoern@asbjoern.com

Game design and development - asbjoern@asbjoern.com

Game design and development - asbjoern@asbjoern.com

Game design and development - asbjoern@asbjoern.com

Game design and development - asbjoern@asbjoern.com

Game design and development - asbjoern@asbjoern.com

Game design and development - asbjoern@asbjoern.com

Game design and development - asbjoern@asbjoern.com

Game design and development - asbjoern@asbjoern.com

Game design and development - asbjoern@asbjoern.com

Game design and development - asbjoern@asbjoern.com

Game design and development - asbjoern@asbjoern.com

Game design and development - asbjoern@asbjoern.com

Tools refer to software applications used to produce the actual game.

Game design and development - asbjoern@asbjoern.com

Game design and development - asbjoern@asbjoern.com

Game design and development - asbjoern@asbjoern.com

Game design and development - asbjoern@asbjoern.com

Game design and development - asbjoern@asbjoern.com

Game design and development - asbjoern@asbjoern.com

Game design and development - asbjoern@asbjoern.com

Game design and development - asbjoern@asbjoern.com

3. Project management in a drifting environment

Game design and development - asbjoern@asbjoern.com

3.1. Environmental drift

Game design and development - asbjoern@asbjoern.com

Game design and development - asbjoern@asbjoern.com

3.2. Emergent organizations

Game design and development - asbjoern@asbjoern.com

E.g. the IBM OS/360 discussed in Brooks (1975)

Game design and development - asbjoern@asbjoern.com

Figure 1 Lifespan Curve Static Organization (Source: Truex et al. 1999:119)

Figure 2 Lifespan Curve Emergent Organization (Source: Truex et al. 1999:119)

Game design and development - asbjoern@asbjoern.com