Game Development going Agile

image 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.


Posted 03-28-2009 5:49 PM by Michael C. Neel
Filed under: ,

[Advertisement]

Comments

Ryan Roberts wrote re: Game Development going Agile
on 03-30-2009 5:58 AM

>once released there is no new development

This isn't really true in the PC game market, at least not if you are Blizzard. They still ship patches for Starcraft, which is over a decade old now. Console games were until recently different, but many are now patched post release nowadays too.

Targetprocess list Bioware as a customer.

Michael C. Neel wrote re: Game Development going Agile
on 03-30-2009 11:53 AM

True the bits are altered but a patch for bug fixes is not really new development in the since of going from Office 9 to Office 10, in which developers continue to work on the 9 codebase and shape it into version 10.  Even games lucky enough to have a sequel like Mass Effect won't start from ME1's code base and attempt to upgrade it to ME2.

Most games offer content updates in the form of Expansion Packs and DLC, and some games like StarCraft are lucky enough to see players in the game a decade later - but I don't think Blizzard is using the SC1 codebase as the jumping off point for SC2.  And my point is to contrast that with the business app world where it would be heresy to suggest a ground up rewrite of an app between each release.

About The CodeBetter.Com Blog Network
CodeBetter.Com FAQ

Our Mission

Advertisers should contact Brendan

Subscribe
Google Reader or Homepage

del.icio.us CodeBetter.com Latest Items
Add to My Yahoo!
Subscribe with Bloglines
Subscribe in NewsGator Online
Subscribe with myFeedster
Add to My AOL
Furl CodeBetter.com Latest Items
Subscribe in Rojo

Member Projects
DimeCasts.Net - Derik Whittaker

Friends of Devlicio.us
Red-Gate Tools For SQL and .NET

NDepend

SlickEdit
 
SmartInspect .NET Logging
NGEDIT: ViEmu and Codekana
LiteAccounting.Com
DevExpress
Fixx
NHibernate Profiler
Unfuddle
Balsamiq Mockups
Scrumy
JetBrains - ReSharper
Umbraco
NServiceBus
RavenDb
Web Sequence Diagrams
Ducksboard<-- NEW Friend!

 



Site Copyright © 2007 CodeBetter.Com
Content Copyright Individual Bloggers

 

Community Server (Commercial Edition)