Game Unified Process (GUP)
by Kevin Flood

Game development post mortems all sound the same: The game was late. It had too many bugs. Functionality was not what was originally intended. Getting the game out the door took too many development hours and the development team was under too much pressure. Even when the game was launched, management was not pleased.

What is missing from all these evaluations is the resolve to overhaul the game development process. Why? Perhaps there's something about the macho aspect of game development, the love of bragging about difficulties overcome and pain endured. I'll reserve comment, not being a sociologist or a psychologist. As an executive and manager I know that these problems have a cost, measurable in misused resources, problems in the game, features that have little value, or slipped target dates. All of these have business implications. Isn't it time we tried to address these issues?

Before I take a crack at this, a confession: my background is software engineering, not content development. If you are a producer, artist, or audio engineer you may be tempted to stop here. This would be a mistake because the content developers are the ones that have a big influence over how the entire game development process operates.

A Recent Project

To illustrate how I think the game development process usually works, I'll cite a project I recently managed. It was large, involving the development of games (casino games) and a complementary platform to support high-volume Internet game play.

Client-side technologies included Flash, animation, audio components, and logic to support game play. On the server side, we used BEA's J2EE-compliant WebLogic platform, Enterprise JavaBeans (EJBs), servlets, Java coding, and an Informix database. Web development combined HTML, Javascript, and JSPs.

The team included artists, producers, Flash developers, programmers, architects, database developers, product managers, project leads, etc., working in three main groups. Responsibility for the games' look and feel as well as the supporting client-side logic belonged to the content group. Server-side logic was the responsibility of the system platform group. A third group handled Web development; they floated between the content and system platform organizations.

There was an overriding development process, but its role was more project management, tracking where we were on the project, who was working on what piece, and what had to be delivered when to achieve our objectives. Each group had the latitude to define the actual process of getting the work done, on time, with the features that they signed up for and at the quality level that was expected of a production or golden master product.

The content group and the system platform group used different development approaches, affording me the opportunity to see how each organization defined and executed a development process. It allowed me to assess the pros and cons of each and to determine which methodology resulted in a better outcome. (I'm leaving out the Web development group. It was small and was subject to the development strategies of either the content group or the systems group.)

The groups did not sit down and explicitly say what the overriding development process would be. Instead each group used the methods with which they were most familiar. Despite some differences, essentially they followed a similar process. I call it the game waterfall process (GWP).

Waterfall Development Basics

The waterfall development process is the one commonly used in game development. It has distinct phases that need to be completed in a certain order. Once a phase has been complete there is no turning back and it is on to the next phase.

Waterfall processes occur at various levels of complexity. The following are the larger categories found in game development, described in a common sequence of execution.

Conception

The business analysts, product managers, and senior development personnel get together and discuss what the game should be. Among other issues, they may discuss the following:

Audience
Platform
Development time frame
Some of the features of the game
Some of the high-level technical and artistic challenges

The group may (or may not) produce a document describing all of the expectations for the game and some of the detail about how a group might approach development. In some cases a series of discussions results in a go or no-go decision.

Game specification

If the team gets the go ahead to proceed, a document is crafted by the product manager and/or producer that describes what the user experience will be in the game. This involves play characteristics, platform decisions, and potential artistic mockups of the game. It is a description of the game from the end user's perspective. This document is circulated to high-level art directors, game designers, and architects.

Art bible/story bible

I have compressed the art and story bible into one phase. They are different but they are executed at about the same time in the process and are linked because the producers and artists need to work together to create these documents.

The art bible contains what the name implies. It defines the overriding art style that will be used, the tools to develop this art, and mock-ups to validate that approach. The story bible describes how the game will flow. It discusses the overriding objective of the game and how that objective will be expressed in various scenarios.

Technical specifications

In this document the engineers detail the architecture of the game. It could be expressed in unified modeling language (UML) or with system diagrams. If development is to be object oriented, high-level objects and their interactions are defined. Core fundamental tools are defined and a platform for the game is recommended. The interactions between art assets and programming code are defined. Security and access methods might be part of the game technical specification.

Construction

The decision is made to go ahead; architecture and concept documents are completed; the platforms have been established; the full team is hired; and the development environment is up and running. Then people begin to construct the game. The producers, managers, and project leads form the organizational glue within their respective disciplines and across organizational lines. The artists and developers begin to develop the game using all of the documents that have been previously developed.

QA system test

Upon completion, pieces of the game go to the quality assurance (QA) organization, which takes all of the previously mentioned documents and tests the game against these documents. Any problems that are found are logged and reported back to the development teams. The development team responds by fixing the problems, redesigning certain key modules, or adding additional functionality.

Play testing

Once the QA organization has an opportunity to give feedback to the development teams and the game is up in some working order, play testing begins. In this exercise, producers organize group sessions to demonstrate the play characteristics of the game. These sessions are usually attended by product and marketing managers as well as members of the development staff. The goal is to validate or critique the play characteristics of the game at that point in time. These sessions may occur a number of times during the testing cycle. Each play test session involves feedback that must be addressed by developers. The feedback can require cosmetic or fundamental changes to the game.

Alpha testing

When producers, product managers, and developers agree that the game is ready for a wider audience, the producer will release the product to a select group of evaluators that provide feedback on the game. This feedback can result in required changes to the game. Some of these changes could be substantial. The assumption is that the changes will not be drastic in nature.

Beta testing

In this phase the game is released to a much wider audience with little knowledge of the game. People play the game and provide feedback on problems that occur, features they like or dislike, and the overall game experience. For console games it is difficult to get a comprehensive beta test because the game is usually kept inside the company that is making it. On the Web the first release of a game is frequently considered the beta test. Sometimes this is called release 1.0 and is quickly followed by a subsequent more robust release.

Golden master or final release

With all the feedback received and changes made, the game is released to the general public.

Defects in the GWP

So what is wrong with the waterfall process? It has been used for years. It results in feedback along the way and everyone can be made aware of when each phase is complete. This way the development group and all people involved in the process are aware of the progress against the target date.

If you look closely at this linear process you see that each phase exposes the game to different classes of observers. The test team does not see the product until after the developers determine it is time for them to see it. In some cases the product managers will not see the game until the developers schedule a play test. If play tests are not scheduled early in the cycle, product managers may not see the game until late in the cycle. Alpha evaluators may not see the game until very late in the cycle.

The reality is that as each of these groups sees the game they may request drastic changes. This has a cascading effect, introducing problems into the game and sending the game back into phases that were expected to be complete, and possibly forcing the development team into emergency mode very late in the development cycle. The actual process may become very chaotic because the sequence of the waterfall development process has been broken. Development activity that should have occurred early in the cycle is actually occurring late in the cycle. Also, many unplanned minicycles may be occurring at the same time. These issues are common themes in game development post mortems.

This is precisely what occurred in our project, and watching it, from a management perspective, was very unnerving. I was responsible for the delivery of this project. The company's future depended on finishing this game platform and games on time. I set about to understand what alternative development process would be better.

These Are Not New Problems

Software engineers will recognize our experiences, because they've been plagued with them for quite some time. The response has been new techniques, such as agile modeling, rational unified process (RUP), extreme programming (XP), and other hybrid processes to address the waterfall process's pitfalls. There are differences between the new approaches, but they all have a common theme. They all recognize that the software development process is iterative, not linear. Issues are identified and problems arise all through the development cycle and need to be addressed.

These techniques also seek to get more disciplines involved early in the development cycle, including QA personnel, product managers, business managers, developers, and others. The goal is to get as much interaction, dialogue, and goal setting done early in the cycle as possible. It also establishes formal communications between all vested parties. These communication mechanisms help as the product moves through the iterative process. All of the parties stay involved in all phases of development.

Rational unified process

For RUP, documentation (that is, artifacts) and use cases in particular play a key role in keeping the development process on track and well communicated to all participants. Use cases are collaboratively developed user expectations for the product, visually and verbally representing how an end user will interact with it. (In some cases, the user is another application or machine.)

The user case forum and its resulting artifacts help to force interdisciplinary communication as well as the documentation of that communication. RUP continues from the initial use cases to more detailed artifacts that reveal the technical specification for the product. RUP acknowledges that at each phase of development facts may be revealed that cause a return to an earlier phase. In fact, RUP encourages this iterative recycling as opposed to discouraging it. The use of RUP lets a project stay on track, despite the existence of many minicycles, by forcing all groups to collaborate. Everyone is aware of the state of development and can make adjustments. Documentation plays a key role because it gets continually recycled to reflect the actual state of the project. This combined with the emphasis on multidisciplinary collaboration creates a communication feedback loop that lets decision makers make the right calls to keep the project on track.

The discipline required to follow and document the iterative phases ironically contributes to less iteration in the development process. Recognizing the collaborative nature of development and the religious demand for documentation together decrease the need for changes.

The RUP process is not endlessly iterative; it doesn't allow gross changes to design and specifications to the bitter end. It does assume that this process in itself will result in fewer and fewer changes to design and specification as the project proceeds towards the release date.

XP and agile modeling

The XP and agile approaches are philosophically similar to RUP, but with some key differences. XP is not documentation-centric in the traditional sense. It is geared toward short cycle development and projects that are engineered in relatively small development groups. XP is very interactive-centric and proposes that through the process of peer programming and intense small group interaction, the program and product itself become the documentation. A key differentiator for XP is its emphasis on testing early in the development cycle. It proposes that test cases, test harnesses, and test examples should be created before the application code is developed. This discipline forces the development team to think about the end result of the development before development begins. I believe this discipline, by forcing agreement on what the product is supposed to do before development begins, achieves the same results as use cases.

XP is perhaps more iterative aware than RUP because it does not explicitly establish phases such as use cases, design documentation, or test cases. XP is a scrum type development cycle that facilitates rapid development by discarding formal documentation phases; it substitutes, from the start of development, unit tests for documentation. The project moves along the cycle and continues to add unit tests as the product becomes more sophisticated. With each build, these unit tests are executed to make sure that the product is working according to the understanding of what the product should be doing. XP development is meant to be fast. Six months appears to be the average term of the development cycle. It also assumes a very close working relationship for all of the parties involved in the success of the product. If any group is not well represented throughout the cycle the development could suffer.

Agile modeling, RUP, and XP are the subjects of many books, articles and Web sites. My point is not to provide a full description of these processes, but to make a case for them as useful alternatives for game development, which, I believe, is closely related to pure software engineering.

An argument against using RUP, XP, or agile modeling as alternatives to the current GWP might be that game development has a creative component that software engineering does not. Game developers will argue that artists feel constrained by "process" and cannot fully realize their potential in a highly structured environment.

My response is that iterative development processes are inherently less constrained than the waterfall process. They recognize that during the process of development new ideas will arise that need to be incorporated in the product. In a game, the creative feedback loop is a classic example of the need for frequent collaboration and iteration. (A slightly more parochial argument is that software engineering is also a creative process, it just lacks the visual expression of that creativity. Why should game development be any different?)

Changing Our Ways

After the experience we had with our first phase of development the development groups proposed alternatives to the GWP, my game development group decided to try an agile iterative process. The content group and the software engineering group each researched the various processes and adopted various elements of these philosophies. I called our new process the Game Unified Process or GUP.

Each development group was given the latitude to adopt any of the interactive processes. Software engineering took a very RUP-like approach, creating use cases and following as best they could the dogma of RUP. The content group took more of an XP approach by working in small teams focusing on single games.

These changes significantly improved our predictability and output, but we were still not where I wanted the teams to be. The core problem was the entrenched nature of the GWP. Both development groups understood the new agile processes, but had a very hard time adjusting to them. Frequently, they would regress to the waterfall process.

The content group had an especially difficult problem with incorporating iterative minicycles and frequent cross-functional game play testing into the project. The software engineering group fell back on the waterfall process when the deadlines came closer and closer. They stopped collaborating cross functionally and resorted to pure development without the frequent input of QA and product management. Ironically, this had the effect of jeopardizing product quality and the overall deliverables.

In retrospect, the adaptation of an agile iterative development process significantly helped improve our overall deliverable. However, old habits die hard, leading to the incomplete implementation of the new development process in our project.

I was convinced that these processes could be adapted to game development and would produce significant improvement. In our case a partial implementation of agile processes showed promise over the traditional results from the waterfall approach. The content group did take a less structured approach to iterative development. However, the recognition of the natural tendency of game development to be iterative was an eye opener for the content developers.

We learned that, despite the faults in the traditional game process, development groups have a very difficult time making the transition to an organized iterative process. We also learned that content groups and software engineering groups could use the same agile processes with positive results.

We concluded that the establishment of a Game Unified Process that combines the short cycle focus of XP with the longer cycle focus of RUP is the way to go for a multidimensional development group. We also recognized that getting everyone to fully understand and adopt the process is not easy. Educating everyone across organizational lines about the process is critical to the success of GUP.

From a management perspective, implementing GUP was worth the challenges. GUP changed the attitude of many developers and galvanized the entire organization. People involved in the managerial functions play a key role in the successful implementation of GUP. Managers need to make sure everyone involved in the development process understands GUP and is bought into the concept. If GUP is executed properly, product quality improves, upper management gets better visibility into the process, a documentation trail is created that others can refer to, and change can become a recognized and valuable aspect of the development process.

Discuss this article in the forums

Date this article was posted to GameDev.net: 5/14/2003
(Note that this date does not necessarily correspond to the date the article was written)

See Also:
Formal Methods
Game Engineering