April 24, 2009 4:00 PM | Simon Carless
[What went right and wrong in making Volition's hit 2008 title Saints Row 2? The April 2009 issue of sister publication Game Developer magazine explains, straight from the horse's mouth, and here's some choice extracts for GSW readers.]
The latest issue of Gamasutra sister publication Game Developer magazine includes a postmortem of THQ and Volition's over-the-top, open-world crime romp Saints Row 2, written by producer Greg Donovan.
The following excerpts from the piece explain how the Saints Row 2 team coped with feature creep and game instability, ultimately delivering a well-received multiplatform product.
Says Saints Row 2 producer Greg Donovan: "When everything was said and done, the game was localized into 14 languages across 15 separate SKUs. From a purely quantitative perspective, development was a logistical challenge and it would not have been completed without collaboration across many departments and studios."
Carving Out a Unique Identity
Released in Q4 2008, publisher THQ pit Saints Row 2 against a slew of other high-profile video games during the holidays. Donovan was aware that creating an action game that stood out from the crowd of holiday releases was crucial. In this excerpt, the game's producer writes:
"From the start, the team’s fundamental goal was to create an original open-world gameplay experience that would further distinguish Saints Row from other non-linear games, and carve out a distinct identity in the genre.
We needed to build upon the success of the predecessor and create a game that would ultimately establish Saints Row as a viable and global franchise on next generation hardware.
We also needed to create a game that could succeed in a more competitive window than the original Saints Row, without alienating the established fan base or deviating too much from the core mechanics players had come to expect—customization, sandbox gameplay, and combat.
We aimed to achieve this by iterating gameplay that worked in Saints Row, and cutting those mechanics and features that did not work. Three years of analysis, collaboration, discussion and hard work followed and concluded with a game that we feel was ultimately able to accomplish these goals."
Mitigating Feature Creep
Donovan was also cognizant of feature creep, implementing a system that would carefully monitor the addition of new features. Through what he calls "Change Management," Donovan made sure that key decision makers were kept in the loop:
"Near the end of pre-production, the team implemented a scope-control process called “Change Management.” Feature creep is common in game development, and it becomes an issue when elements are added without the knowledge or approval of key decision makers. Our process was designed to mitigate this.
Any new feature requests that came to light after our feature complete deadline had to be submitted to the leads group for review with a detailed spec that included an initial pass at task breakdowns, work estimates and dependencies.
This process helped ensure all appropriate parties had thought the request through and submitted the request with details already in place. The leads met regularly to review the requests and determine what could and could not be added to the game. We were overly zealous in our approvals, but we were able to schedule scope additions quickly because of this upfront planning.
Past projects proved that all too often additional features were implemented in a vacuum, without the awareness of all affected team members, or without adequate planning and forethought. Change Management was a valuable process designed to make additional scope requests more transparent."
Wrestling with Instability
During development, Saints Row 2, Volition's first simultaneous release across Xbox 360 and PlayStation 3, experienced serious build stability issues. Donovan stated the team eventually worked through the problems and reaching an appropriate level of polish, but at certain points he called the issues "disconcerting":
"Build stability was a real problem. It wasn’t until late in the development cycle that anyone could play the game for more than a couple of hours without crashing. This was extremely frustrating and at times quite disconcerting.
Top-level, our instability was caused by failing to take systems and features to completion, an issue that had its roots in the litany of usual suspects—unforeseen dependencies, late design changes, new team members working in an unfamiliar code base, and of course a pre-production commitment to an assumed competitive scope that wasn’t adequately reflected in the schedule.
In hindsight, we failed to “develop deep” and didn’t take adequate time to think about system scalability. Instead we developed wide and made the mistake of hastily marking systems or features as “done” when in reality more work was needed to take them to full completion.
When production officially started, the schedule showed we needed to get things done at a brisk pace. This meant fast-paced work, and this mentality created a cycle that effectively exacerbated the core issue and resulted in further instability.
Programmers rushed to fix bugs that came late in development (which commonly resulted in more bugs; when you have hundreds of check-ins going into a mainline branch on a daily basis, you’re going to see things break), and design and art expectedly fell behind on polish and iteration.
Therefore, Q/A wasn’t able to progress through test plans efficiently, and we couldn’t conduct extended playtests until late in development."
The full postmortem for Saints Row 2 explores "What Went Right" and "What Went Wrong" during the course of the game's development, and is now available in the April 2009 issue of Game Developer magazine.
The issue also includes the 8th Annual Game Developer Salary Survey, always a popular and useful feature; a divergent perspective from Rod Green of Intel's Project Offset on the crucial area of art pipelines; BioWare Austin's Damion Schubert on the nature of the design space; LucasArts' Jesse Harlin on dynamic scores, and much more.
Worldwide paper-based subscriptions to Game Developer magazine are currently available at the official magazine website, and the Game Developer Digital version of the issue is also now available, with the site offering six months' and a year's subscriptions, alongside access to back issues and PDF downloads of all issues, all for a reduced price. There is now also an opportunity to buy the digital version of April 2009's edition as a single issue.