What Went Wrong? Learning From Past Postmortems
April 22, 2009 Page 5 of 5
9. Poor tool implementation.
Building tools for your game is horrifyingly difficult, and the problem becomes larger when the use of these tools is not obvious, or when they become too big for their britches. This is the cousin of the lack of technical documentation problem, and no less common.
Resistance: Fall of Man (Insomniac, Marcus Smith) "The flipside to homegrown tools and technology is that our tools changed quickly and our ability to properly train people on all the changes proved impossible. Building assets while simultaneously building the tools needed to create them is akin to trying to build a house on quicksand.
"Artists would literally open their tools one day and discover new interface buttons and have no idea what they were or how to use them. Many assets needed to be rebuilt, re-lighted and/or re-animated because of changes to our builder tools.
"Adding to the confusion, only a small number of programmers had the knowledge required to debug the problems, and these people were overwhelmed with requests for help. If it weren't for their inhuman effort and long hours hunched over their keyboards, we would have never hit the launch date."
Insomniac had a related problem, wherein the company couldn't maintain stable builds without a great deal of effort. Making your tools accessible is absolutely essential.
Uncharted: Drake's Fortune (Naughty Dog, Richard Lemarchand) "We realized that we'd bitten off too much with our tools approach -- we'd tried to be too clever, coming up with convoluted approaches that were intended to solve every last problem that anyone had ever had with each kind of tool. To make it worse, we'd gotten distracted by our lofty aspirations, and had left it very late to implement a build pipeline that let people actually run and play levels.
"The moral that we took away was that even though it's good to aim high with your tools, you should choose your battles, and shouldn't try to solve every last tools issue that your team faces. In some cases, simple work-arounds are better and free up more time to work on the game itself."
The goals were noble, as these problems were originated in a desire to share technology. The lesson remains the same -- reign in scope until the project's goals are completely clear.
Well here it is, the inevitable crunch discussion. Everyone knows it's a problem, but it keeps on keeping on. Crunch is usually a side effect of most of the other problems on this list, and then exacerbates those problems in turn. Some studios go well out of their way to avoid it -- others can't seem to help themselves, for reasons of ambition, money, or any number of things. It's never good.
Drawn to Life (5th Cell, Joseph Tringali) "Consistent overtime is not fun, nor is it something that should be assumed when developing a game. We ended up working late weekdays and Saturdays for the entire second half of the project.
"Our studio had the perfect storm of factors that contribute to crunch -- lack of experience on the platform, an ambitious game, and a schedule that was too short. Combined with so little pre-production, we were playing catch up from day one, taking far too many shortcuts to implement the required game features."
Playing catch up from day one is the key phrase here, and proper schedule and project management is the solution. Easier said than done!
Stubbs the Zombie (Wideload Games, Alexander Seropian) "(In spite of using contractors), we crunched for a solid three months, which isn't too bad relative to past experiences, but is way worse than zero.
"Because we let some major components slip into post-production and were four months behind schedule, and we let ourselves get behind on contractor approvals, we ended up with more than post-production tasks during our post-production phase."
This example should be a reminder to us all that contractors don't necessarily eliminate crunch. A healthy post-production timeframe is very useful, but shouldn't be used as a cushion when other phases fall behind.
What went wrong?
In the end, a lot of the same problems will keep cropping up in development. People fall into their old working habits and let best practices slide.
The jury remains out on methodologies like Scrum, but certainly a very conscious management of projects can help identify problems before they become critical. Let's keep sharing those best practices, and dare I suggest they be shared in Game Developer magazine? Do drop us a line!
Page 5 of 5