Agile Game Development with Scrum: Design
This chapter is from the book
This chapter is from the book
This chapter is from the book
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.
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.