Clinton Keith shows how designers can embrace the benefit of emergent design. No designer has a crystal ball about any mechanic. Instead, they need to ensure that their vision is communicated and open to all potential ideas.



When I first started working on games professionally in the early nineties, the role of designer was being instituted throughout the industry. Following the mold of prominent designers such as Shigeru Miyamoto and Sid Meier, designers were seen as directors of the game, or at least the people who came up with many of the ideas. The role required communication with the team on a daily basis but not much written documentation.

As technical complexity, team size, and project durations grew, the role of the designer became more delineated. Some projects had teams of designers who specialized in writing stories, scripting, tuning characters, or creating audio. Hierarchies emerged to include lead, senior, associate, or assistant designers, among others.

The overhead of communication with large teams and the cost of longer development efforts led to a demand for certainty from the stakeholders. Large detailed design documents attempted to create that certainty, but at best they only deferred its reckoning.

This chapter examines how agile can help reverse this trend.

Viewpoint "Designers are the chief proponents for the player. This has not changed in 20 years of game development. Though titles and roles have changed, designers look out for gameplay and quality of the product from a player's perspective. "When teams were small—with ten or less people—this could be done easily; it was a series of conversations while textures were created and code was written. The design was natural and organic as it emerged from the team. 'Horse swaps' could easily occur. For example, trading a very difficult-to-build mechanic for an easy one that still achieved the same gameplay vision was relatively simple. "However, in the past ten years, teams have begun to balloon, first to the 30- to 50-person teams of the nineties and then finally to the occasional several-hundred-person monstrosities of the 2000s. A single designer could not have all the conversations that needed to happen (even several designers have problems). As a result, documentation began to surface that outlined the product as a whole, from the very high level to the very granular. Although this paints the initial vision of the title, it does away with one of the most important facets of any type of product development: the dialogue. "Scrum addresses this. Five- to ten-person cross-discipline Scrum teams usually include a designer. Each of these designers is entrusted by the lead designer to understand the key vision elements and speak to the team." —Rory McGuire, game designer

The Problems

What are some of the problems that face developers on large projects? The two most common problems are the creation of large documents at the start of a project and the rush at the end of the project to cobble something together to ship.

Designs Do Not Create Knowledge

Originally when designers were asked to write design documents, they rebelled. Writing a design document seemed like an exercise to placate a publisher or commit the designers to decisions they weren't ready to make. Over time this attitude toward documentation has changed. Writing design documents has become the focus for many designers. It's felt that this is the easiest way to communicate vision to both the stakeholders and a large project team.

Designers need to create a vision, but design documents can go too far beyond this and speculate instead. Once, on a fantasy shooter game I worked on, the designers not only defined all the weapons in the design document but how many clips the player could hold and how many bullets each clip contained! This level of detail didn't help the team. In fact, for a while, it led them in the wrong direction.

The Game Emerges at the End

At the end of a typical game project, when all the features are being integrated, optimized, and debugged, life becomes complicated for the designer. This is the first time they experience a potentially shippable version of the game. At this point it typically bears little resemblance to what was defined in the design document, but it's too late to dwell on that. Marketing and QA staffs are ramping up, and disc production and marketing campaigns are scheduled.

The true performance of the technology begins to emerge, and it's usually less than what was planned for during production. This requires that budgets be slashed. For example, waves of enemy characters become trickles, detailed textures are decimated, and props are thinned out.

Because of deadlines, key features that are "at 90%" are cut regardless of their value. As a result, the game that emerges at beta is a shadow of what was speculated in the design document. However, it's time to polish what remains for shipping.