Paper Burns: Game Design With Agile Methodologies

A fear of next generation development can be seen everywhere; it’s at the water cooler, it’s in magazines, it’s talked about at the Game Developers Conference and in Game Developer Magazine.  With increased hardware capacity allowing for ever more expansive and immersive games, everything is growing: Team sizes, asset requirements, person hour investment, and of-course required capital from investors to support it all. Audiences are also expecting more. They want more mechanics with greater functional and technical depth, denser polygon art, higher resolution textures, more complex AI, more testing and quality assurance, and the list goes on.

This fear of the next generation is not confined to the industry. The press has caught, and with them the consumer. Game site FiringSquad.com said, “Game publishers and developers industry-wide are complaining of ballooning development costs, mostly due to art teams that have to grow exponentially to create all the content that’s possible.” [Press01] A vast majority of the problems facing the industry are deep seated in the very production methodology that is employed. Teams of approximately 100 people are still using methodologies developed for a time when ten people were considered a bloated team. There are alternatives.

Traditional game development uses a production methodology that spends a lot of front-end time, defining intended functionality, often with implementation of important elements such as mechanics and levels waiting around until the mad scramble at the end. The traditional methodology, often called Waterfall, isn’t dissimilar to an assembly line, with the beginning of the line starting the process of piecing together the product while the end of the line waits to add polish.  The wait is what creates the problem. Designers and publishers are never able to get a real feel for the game, for example whether their initial assessment of mechanics was right, or the implementation of features doesn’t end up to original specifications. Factors like these are what degrade product quality..

One alternative addresses exactly these problems with traditional game development methodology. It is, a product R&D process and team management style aptly referred to as Agile Methodology.  Agile puts the emphasis on producing demonstrable iterations of a game almost immediately into production, creating prioritized vertical slices that iterate on the most critical elements and features. The method also puts great emphasis on the organization of teams and the relationships therein, as well as the cycles in which teams must plan and carry out their project objectives. The challenges faced by game development teams can be numerous and as varied as the divide between the discipline, such as art, engineering and design, that need to work together. The road to the end of game projects is also long; short games are in development for one to two years, bigger titles are running the gamut from a three years, and in exceptional cases up to five or more.

This paper will cover how the Agile method and a specific methodology, Scrum, can directly address these challenges, and perhaps are especially suitable for the complexity game developers, and explicitly designers, face with next-gen console development.

Methodologies

WATERFALL
Most game design or game development books contain very little about methodology. They assume the vast majority of developers use the exact same approach, a method often referred to as Waterfall. In the Waterfall approach work moves sequentially in one direction, such as from a project requirements or design phase to production and implementation. There is very little iteration in the early phases, leaving little opportunity for evaluation. What’s more, much like running water, once the sequence is in progress the process is not easily reversed.

In Waterfall game development, a game designer or group of game designers will first create the game design document, where they lay out many of the features and mechanics. The design document is then broken up into smaller chunks which producers use to extract required functionality and assets. The requirements for these assets and functionality elements span the spectrum of teams involved in the project.

Thus begins the sequence of the Waterfall method, as the requirements “flow down” to animation, programming, level art, character art, QA, FX, etc.  This continues as once an individual or team is done with a piece of a feature, they then hand it to another. A character, for example, would begin with the design document and get handed to a producer or a project director. From there, it would be broken out into its components: The mesh and texture of the character, the animation, the effects the character plays when hit, attacking or idling and finally the AI technology which powers the character. Each department focuses on its component, then work to implement it until its bears some semblance of completion.

It's then moved back to the designer for tuning, handed off to QA for testing, to the level designers to populate in levels, then bounced back to various departments for bug fixes. While this character is being worked on, other individuals and teams are working on their pieces of specific mechanics. In the same day, a single developer may work on pieces of several different mechanics. The nature of the methodology is a percolation, where the game’s many mechanics are brought from the ground up over time.

AGILE
In the late 1990s, a number of new software development methodologies began surfacing, derived from teams ranging from web applet development to systems powering NASA flights. Each methodology possessed its own do’s and don’ts, its own mantras and blasphemies, yet despite their variances, a majority of them had several fundamental things in common.

In 2001, several of the those who had helped spawned the half dozen or so methodologies in use organized a summit in Utah. The result was a central ideology, and a manifesto to go along with it:

Implementation over documentation, ongoing customer collaboration and the ability to problem solve and change course with agility. The central tenets to Agile Methodology were short, but they had large implications, and they were applicable to any complex product development system.

SCRUM
As use of Agile development grew, a number of different methodologies surfaced. Some were derived from Agile, others were systems that had been in use but never fully defined or applied to software development. One such method was Scrum, an approach to product R&D which had its roots in Japanese car and consumer electronics manufacture. By definition, scrum refers to a maneuver in rugby where everyone on the team is involved in an action to move the ball.

As a methodology, the same approach is applied to product development in spirit, where project teams are reorganized into small teams that work closely together on specific components of a project. Iterative development is stressed, with the project divided into components that are “shippable” pieces that can be demonstrated, tested and evaluated for functionality.

One of the principal tenets in Scrum is that everyone on the team is involved in the process. Scrum breaks down production into short work cycles called Sprints. At the beginning of each Sprint, the entire project team meets to create objectives and self-organize into small Scrum teams. The Scrum teams are interdisciplinary, with artists working alongside designers working alongside programmers. Though the goal of each team is determined by project managers, producers and publishers at the planning meetings, the teams ultimately decide the path they will use to achieve their goals for the Sprint. Once into the Sprint, the teams are completely self-managed in their daily planning and execution of tasks.

As recited often by those familiar with Scrum, projects become delayed one day at a time. For this reason, a critical component of Scrum is daily meetings among individual Scrum teams throughout the Sprint. The meetings can be as brief as 5-10 minutes, and are designed to ensure that objectives are on track, any impediments to progress are recognized, and daily accomplishments are seen by everyone involved. [Agile02]  The process creates a sense of ownership among every member of the team, and its transparency is designed to create accountability among team members that ultimately boosts productivity.

With the team self organizing, regular reviews keep the team on target and give everyone a full diagnostic of the product in the purest form possible; how it looks and performs. At the completion of every Sprint, the teams conduct reviews that demonstrate their accomplishments, and allow their product owners or “customers,” such as studio managers and publishers, to evaluate progress. The customers can then determine what the priorities are for the next Sprint.

The goal for these teams when reviewing with their customers is to demonstrate a “vertical slice” of the game, as in a piece of a game such as a single level hub or a completely playable mechanic or a tuned feature. While not all mechanics can be delivered in a single iteration, the individual pieces of them become the vertical slices that teams focus on. For example, an AI character is very difficult to deliver in a single Sprint. Yet a single behavior of that AI character can be fully programmed, animated, have sound attached to it, be deployed in a level, etc., resulting ultimately in something that can be tested.

With these two elements in mind, a customer can look at a product and see exactly what’s been achieved, where it’s going, how fast production is progressing, etc.. A customer does not need to guess or have faith, they can see a direct diagnostic, and often by picking up a controller rather than looking at spreadsheets or wireframes. Scrum also gives customers flexibility from iteration to iteration, just as it does product teams.

Customers have room to redirect project goals between Sprints if what’s been created and evaluated is not living up to expectations. And because of the iterative process of Scrum and the short work cycles of Sprints, redirecting a project rarely results in large volumes of wasted work.

Waterfall vs. Scrum

Waterfall development creates a problem for game designers in that no object can be considered complete until all of the dependencies on that object have also been built and moved into the process. For example, a designer may build a level centering around AI which exists solely in documentation. Using the design document as reference, the designer makes a best guess, has it evaluated by seniors, and hands off the level to an artist to begin building the meshes. The designer and his managers know that no one has actually got to experience the character enough to design a level around it, but in order to keep production flowing the designer and level artist will have to assume the AI will work as promised.. But while the work continues, the questions remain.

What if the programmer for the character determines that getting the AI mechanic to work as documented isn't attainable? What if the AI works, but animation can’t get the mechanic to look right? What if the designer responsible for the character realizes that the functionality isn't fun? Answers in the negative to these questions mean lost functionality, lost person-hours, some portion of the development budget wasted, even a psychological outcome such as loss of faith in the project. Whatever the drawback to the development process, it is best summed up in its most likely outcome: Degraded product quality.

Another substantial problem with Waterfall occurs when departments outpace each other, resulting in a "hurry up and wait" situation.  Everyone is going as fast as they can when their piece of the Waterfall is in their lap, then waiting for the next piece when their portion is complete. Imagine an assembly line where the belts moved at variable speeds, sometimes completely stopped, other times moving at a comfortable pace and occasionally blazing. A chronically irregular pace during production has downsides for producers, financial officers and just about everyone involved. For designers it affects their job at a fundamental level. Inconsistent progress can substantially affect the functionality and quality of essentially any features that require different elements to come together.  

For instance, consider a horror mechanic in a game, such as a moment when the player is surprised by a vicious boss encounter. A mechanic such as this relies on nuances for its success, and for a design team to test, evaluate and, as is nearly always needed, reiterate, they need finished art, sound and scripting. It certainly can’t be tested in a black box.

Waterfall will always put designers at a disadvantage, simply because while the breadth of a game is established at the project outset, the depth that makes up the game’s most important dynamics such as camera, tuned control, A.I., etc., "percolate" slowly and begin to take final shape only near the end of the project. In Graphic02 we can see a demonstration of this for a sample project, where mechanics have been handed off to various departments who are working on individual pieces, with the intention of delivering the finished product several months down the line.

The scenario is quite typical of a project at eight months. The team has moved out of pre-production and has laid the ground work for all the mechanics and assets outlined in the design document. The fundamental problem occurs in the assumption that all of these mechanics will be delivered and delivered well.

Another way to depict the progression of a Waterfall project is as a curve representing a product’s finished functionality over time, as depicted in Graphic03. Here, the right side of the timeline on the project is the delivery date -submission to a first party, handing over a master to the publisher, etc. It is immovable, the veritable brick wall. As development progresses, the game’s mechanics begin to take final form and function as promised during the critical final phases of the project.

What if as the team nears that brick wall, critical components do not function as promised? The inevitabilities are death marching, or cutting features late in the project along with the all the assets and content dependent on those features. The ultimate result is wasted resources, assets and person-hours, and quite likely, degraded product quality.

The most fundamental difference between Scrum and Waterfall is the level of communication Scrum establishes through daily collaboration towards goals approaching in a span of weeks instead of years. In the Waterfall example, our designer was building a level centering around A.I. using documentation and assumptions on how the character might be delivered. Applying Scrum to the same example, the designer works hand-in-hand with members of the team. For instance, the designer declares the goal: “I need AI to behave in a way that lets me easily iterate on its navigation.” The next step is working directly with programmers.

Together, the designers and programmers investigate options, coming to a consensus on what is the best technology to implement to get the desired behavior. Should the programmers run into impediments, the designer is imbedded in the process and able to have direct input on any alternative solution. The approach is not confined to how designers work with programmers. The same pipeline applies to, for instance, a designer iterating on how a character moves with animators, or how a level is laid out with environment artists. The end result is going to be better solutions, with Scrum ensuring that those who need to be part of the process have input.

Scrum presumes that the people creating and implementing the work are going the most knowledgeable on how to get to a goal and where the landmines are on the way there. Who would know more about the animations needed for a character to move than the animator? Who would know more about how the A.I. moves to a position than a programmer?

By simply declaring the spirit and end goal of the design it opens a dialogue between designers and the individuals implementing the feature or level, which in turn lets all parties involved figure out the best method to achieve the goal. Designers aren’t programmers or artists so presuming we know the best path in all methods of technology and art is foolish.  What we can do is determine a short goal and work with the team over a couple of weeks, then review the product and determine if it’s up to snuff. An emphasis on rapid iterations in small pieces benefits the end product and designers immensely.

Through rapid iteration designers are able to watch whole complete mechanics come online in very short order. This lets designers immediately see the status of a mechanic and where the game is heading. For lead designers and project directors, this let’s them get a status check every few weeks on exactly the destination of the project and have a month to month diagnostic on a team’s progress and whether or not they should meet their end goals.

Because a team is delivering entire vertical slices features can be cut without immediate repercussions to previously made content. No dependent features have moved into development which means that scope can be reduced with a clear conscience and without wasted work.

For level designers this also means that their levels can be built around mechanics that are proven and fun in and of themselves. While a designer can return to a level or area at a later time to layer in new functionality as it comes online, the game can ship without them doing so. Moreover if the level is fun with the things the designer has, imagine how it’ll play when the designer get the things he doesn’t have.

It may seem scary to focus on individual mechanics instead of getting everything to bare bones functionally and then letting it percolate. Yet, note that the fundamental mechanics required to ship the game and build levels are the first out of the door, as determined by the product owner. Additional features which add spice to the game but are not critical can be layered in. Building the most important things first instead of receiving them at the very end means that content creators (such as designers) can directly build levels around a specific functionality.

Moreover, attaining functionality central mechanics early means there are no dependencies on mechanics that may need to be cut; scope can always be cut or expanded to suit the customer’s needs. Additionally, product owners and designers can determine what features are working best and then “hammer down” on them, including more content that uses the functionality to showcase it better in the game. [Agile03]
 
Rapid iterations also minimize an increasing trend in the industry: Risk aversion.
With bloated schedules, more investment and factors such as untried technology and hardware, publishers and investors face far more complications with a mentality of “Let’s try it!” to one of “I don’t know about that.” As costs rise for investors moving into the next generation, this is a perfectly reasonable and expected response.

Using Scrum, product owners and publishers can follow risky goals for a several iterations. If unproven features or game concepts don’t pan out, the team can easily re-evaluate and redirect. If those features are a hit out of the park, the team and the product owner can decide to concentrate on those aspects of the game, and even take the game in a completely new direction.

Also, as development time increases, the product can face a changing market. What may have been a fresh idea can rapidly become stale as competing titles beat your project to market. Scrum let’s publishers and designers separate their title from the competition with very little risk involved. If product features need to be changed, or in a worst case scenario a game has to be completely cancelled, the publisher loses two weeks to two months instead of two quarters to two years.

Conclusion

Within Agile methodologies such as Scrum, game designers gain a tremendous number of benefits. Individuals such as project directors and lead designers can see whole complete pieces at regular intervals, and instead of measuring progress by abstracts they can measure it by putting their thumbs on a controller. For level designers, they are able to build levels that focus around existing mechanics. Using Scrum, those mechanics are online and taken to their fullest extent so the levels the designers do create are part of a complete whole, with a better view of how the mechanic is going to look on disk.

One feature of Scrum that benefits everyone in game development, not just designers, is a minimization of “crunches” and “death marches.” Publishers and project leads are able to get diagnostics on the team’s performance every iteration, meaning they can safely predict how a team will perform. Within a methodology like Waterfall where features percolate, any aspect of the game that isn’t up to snuff has to be “crunched on” to ensure the game is shipped.

Most importantly, using Agile methodologies and Scrum puts designers at the table with the individuals implementing features and technology used to power the game. Conversations are initiated, questions are asked, dialogue and cross department problem solving occurs organically. Assumptions that lead to wasted time and effort are checked at the door, and a collaboration can be reached that gets the best game out in the most efficient way possible.

Footnotes

[Press01]Recent article on Firingsquad.com by Jakub Wojnarowicz regarding Nintendo in the next generation. http://firingsquad.com/features/nintendo_revolution/default.asp

[Agile01] A full definition of the guidelines and principals that were defined by the Agile Manifesto founders can be found at Agilemanifesto.org

[Agile02]Noel Llopis, lead R&D architect at High Moon recently wrote a feature for Game Developer on a “Day in the life.” In that article he describes how a Scrum team meeting is organized and how individuals deal with tasks. It can be found on his blog at:  http://www.gamesfromwithin.com/articles/0602/000104.html

[Agile03]Additional information on Agile development for games, particularly via Scrum, can be found at http://www.Agilegamedevelopment.com/ the personal blog of High Moon’s Chief Technical Officer; Clinton Keith.

Additional Reading on SCRUM and Agile Methodologies

Agile Software Development with SCRUM by Ken Schwaber and Mike Beedle
Agile Project Management with SCRUM by Ken Schwaber
Managing Agile Projects by Sanjiv Augustine
Agile Project Management by Jim Highsmith

Bio:
Rory McGuire is a Senior Game Designer at High Moon Studios where he has worked for 3 years, most recently on Darkwatch. Prior to that he worked as a game journalist. High Moon Studios is located in Carlsbad California and recently received an IT Week award for being amongst the top 50 technology innovators in 2005 for their use of Agile methodologies in game development.