Game review site Giant Bomb has a great article about Mass Effect 2’s development process.  The article is written by one of the review staff, who doesn’t have development experience, but went to a GDC talk on Bioware’s development process to see if he could glean any information on one of the most anticipated titles in development.  I can’t blame him, I played Mass Effect at least 3 times from start to finish and unlocked every XBox 360 achievement in the game.  Still, as great as the game was, it still had some performance issues.

For the first game, teams went off from the design meetings and implemented their parts separately (level design, art, story, game control, etc), then integrated the pieces into the whole.  That was the plan at least:

That didn't always happen. If the level was actually playable at the end of this process--and sometimes it wasn't--it often ran into problems like a significant drop in performance (and the company wasn't proud of the frame rate drops in the original game). The team tried to address these issues where they popped up, but since doing so required reworking "entire swaths of content," time and resource constraints meant the designers often had to live with the deficiencies.

In extreme cases, large pieces of content were removed completely. Caleston, a story-related "outland" planet with refineries and industrial cartels that was intended to be a part of the game's core story arc, was deleted from the game outright. We will never get that planet back, people. Shed a tear.

Sound familiar?  In the world of business application development this same problem exists.  Teams struggle with integration issues and spend large amounts of time rewriting existing code instead of adding new features.  In the worst cases, planned features are cut to meet budgets and deadlines. (To get a since of what it much have been like to cut Caleston consider the planet was mentioned in a TV ad prior to game release.)

In Mass Effect 2, BioWare is using a linear, phased approach to level design that builds the levels step by step, starting with only the most important parts. This method has a couple of primary requirements: from the very outset, always keep your levels playable, and always keep them at target performance. The designers should only do the minimum of necessary work to answer the important questions about each level, most of which amount to "Can you still see how this will be fun when it's finished?"

It sounds like Bioware has welcomed the Church of Agile.  They have shortened iterations, and made sure each iteration results in a running (though not complete) application.  They established a definition of quality (the game must run at 30 frames per second), and measure the quality each iteration instead of a final round of performance tuning.  Finally, at the end of each iteration they have a point for feedback to enter into the development process, keeping themselves on target.

Game development differs from business application development in many ways.    Performance truly is king and a game dev may write code considered bad form to a business dev.  Games have a fixed life cycle; once released there is no new development.  This is the opposite of the business apps that are constantly updated and once updates to the application stop it probably means people have stopped using the app.  While business apps only need to target a handful of (mostly similar) platforms, games target a wide range of highly specialized platforms.

Differences aside however, it is comforting to see that the same Agile methodology, culture, and process can work for both.