GDC 2012, Day 3
The Last 10: Going From Good To Awesome
Benson Russel of Naughty Dog talked about how they polish their games. As he said this, everyone in the room thought to themselves "Blizzard...Blizzard..." But actually this was about Uncharted 3, and not Starcraft.
Benson explained that polish is not something you just hope happens, that it has to be scheduled and planned for. He showed a diagram of a normal company's production schedule. It has some pre-production, a very long production phase, then alpha, beta, and ship. Then he showed Naughty Dog's version of this, with the same total length because the point is the relative lenghts of each phase. They have a much shorter production phase and a longer alpha phase and beta phase. There is even an additional "hands off" phase after beta and before ship.
The shorter production phase ensures that any core mechanics are figured out even sooner than they sometimes are at other companies. He also said this kind of scheduling requires a "hard alpha," like you can't half-ass it. The alpha really does need to have everything there in a rough form and the entire game playable from beginning to end. Once it's all stitched together enough to play it all through, and everything in place (at least roughly), alpha becomes the polish phase and for them lasted 4 months on uncharted 3. He said they would like it to last a bit longer next time. I think beta also lasted 4 months, but I'm not sure on that. The "hands off" phase is actually after the polishing is done. At this point, it's only the QA department and programmers playing it, and the only purpose is to find major showstopping bugs. On Uncharted 3, during this period they actually did find a very difficult to detect loading bug that would have caused the game to crash on 25% of the Playstation 3s out there.
To show us what "polish" means, he showed several example videos of Uncharted 3. He had videos showing a bug, and then showing the same scene when the bug was fixed. It was often small stuff, but that's his point, really. That you can't let a bunch of small bugs drag down the overall feeling of the game, it all adds up. He had to play most of these bug videos twice so we could even *see* what the bug was. In one, the main character is in a tunnel and sees rushing water coming, turns from it, and runs. As he turns, there is an animation glitch (over in a fraction of a second) before he runs. In another example, the scene starts with a stationary camera, then the camera moves in to show the action. The bug is that during the part where it's stationary, there is accidentally one frame (yeah, one frame) where the camera moves forward. In another example, an NPC throws an enemy to the ground, but the enemy is then right under his feet, which doesn't really look right or make any sense. The corrected version has the enemy fly a couple feet to the side, so he's not directly under the guy who threw him. Another example showed that one scene where the main character falls into a new environment has the background ambient lighting set to a wrong value during part of the fall. And yet another example showed a scene where for just one frame, the screen was pure white for no reason.
So yeah, they fix all this stuff during alpha and beta. And they even have a person on the team, not the QA team but like the real team, whose job it is to look for these polish issues. They have a fairly high ranking person do this because it's not just about spotting the issues (though apparently he is great at that), it's about making a judgment call about how to fix or what to fix. There is often the issue that fixing something might be really easy or really hard (is it worth it?) and the other issue that fixing something might be low risk or high risk (is it worth the possibility that the fix could fuck up other parts of the game?).
Benson also explained that as alpha and beta go on, it is (intentionally) harder and harder to get changes approved. At first, it's like a free-for-all. Everyone fix everything they can, go! They monitor bug counts and everyone does their best to keep their bug counts down to at most X bugs, set by their project managers. By looking at these bug counts, they can see if any particular team member is overwhelmed, and maybe needs help fixing stuff, and if another team member doesn't have many to work on. Also, seeing the rate of fixes helps them estimate if they are on track to ship on time or not.
So at some point in all that, they institute a rule that from then on, they have to be more careful about making lots of changes because ship date is getting closer. So you have to get the approval of one of three executives (including my friend, game director Justin Richmond, haha go Justin) to change something. A bit later on, you need two approvals. After that, you need all three of them to approve any change. This is just good sense, if you've ever been on a software project before. They are reducing their risk screwing things up at the last minute this way.
BURN THIS MOTHERFATHER! Game Dev Parents Rant
In the annual rant session hosted by Eric Zimmerman, developer's break out of their prepared scripts to tell us passionately what's bothering them. I think this is an important part of the conference overall, because we get under the surface about what's really going on. Except...we totally didn't this time and it mostly sucked. I am more upset about three things before breakfast than half these people were about whatever they are supposedly "ranting" about.
Graeme Devine started us off just fine, at about 80% or so on the rant-scale. He is sad that