     |
 |
 |
 | | | | |
 |
|||
 |
||||||
          |
 |
 |
||||
|
Manager In A Strange Land: I've worked on a bunch of role-playing and action-adventure titles. I've started noticing a pattern, which is this: games that aren't done yet don't look done. This always takes me by surprise. Maybe it's because, at E3, for a brief moment, the game (well, the portion of the game you feel comfortable showing) looks done. Then, a couple weeks later, people go in and start making things better, which -- for the interim -- makes everything look worse. You also start paying attention to the levels, missions, dungeons, and what-have-you that never looked done. They're filled with placeholder textures, placeholder characters, stubbed-out gameplay, placeholder visual effects, and placeholder sound effects. You begin to wonder: will we ever finish this thing? As the teams I've worked on have gotten larger, this problem has worsened. When I was hired to finish a casino game all by my lonesome (a game where almost all the art had already been done, and I just had to put it together), I finished it one part at a time. First I did the blackjack, then the roulette, and so on. So the game showed steady, visible progress. If they had hired five programmers instead, to do one mini-game each, although they might have finished the project in one fifth the time (ignoring Brooks' law for a second), the project wouldn't have shown satisfactory progress until the very end, when all the components were completed simultaneously. Everything coming together at the last minute is actually a sign of a well-leveled schedule. Your game has twelve levels? The fastest route to completion is to hire twelve level designers. Not the most efficient, mind you, but the fastest. However, you won't have a sense of your progress until they're almost done. A lot of project management books for software developers spout feel-good platitudes like: "always keep your product in a zero-defect state", "have 'ship-it'milestones", "do a 'spiral' where you finish one iteration of your software", "evaluate-refine-repeat", blah, blah, blah. Most rules of managing software development apply to game development. But some do not. I think managing game development projects in more like building construction than software development. Imagine if construction management books said things like, "You should always keep your building in a zero-defect, shippable state." Obviously, building construction crews don't work this way. Construction projects look like disaster areas up until the last minute. Then they blow the sawdust away, take away the scaffolding, and -- ta-dah! -- a house. (Greg John, senior producer on Spider-Man 2, points out that construction analogies are dangerous because in the construction industry, there's a well-defined blueprint and the work itself isn't terribly creative. All I'm saying is that in this case -- unfinished buildings don't look finished and neither do unfinished games -- there's a parallel. Ed Del Castillo, CEO of Liquid Entertainment, has an interesting story that may indicate the opposite, however. Ed hired a guy to do his pool, and the contractor advised against creating a blueprint, saying it would be a lot of extra work and money, and Ed would probably want to make changes to the pool once he saw the actual work anyway. The guy suggested that 't they "just get at it." Maybe construction is more like software development than we thought.) I think of the period of the time where the game looks horrible as being the "Dead Zone". It starts shortly after your earliest demo and goes up to when you're several weeks from content complete. Others call this phase "Full Production." This means you'll be in the Dead Zone eight months before you ship. Of course, your publisher is going to freak out when it has been six months since your E3 demo and the only levels you have complete are the ones you showed in your E3 demo, and everything else is in varying stages of completion. Even though your publisher has probably never seen a title the size and complexity of yours do any better than yours has, they have some utopian idea in their head of what a well-run project should look like, and you fall short of the mark. They have no way of telling, just by looking at the product, how close you are to being done. Which is important. There has to be some way to tell whether the project's going to ship on time when you're making your commitment to retail. According to Mike McShaffry in Game Coding Complete, eight months is when your publisher makes their commitment to retail. They need to know if your game is going to be a Stonekeep (tragically late) or a No One Lives Forever (ship-date nailed). And they won't be able to tell just by looking at the product. With external development, you can use the milestone schedule. If you're on target, and your milestones are defect-free, you're a big winner. If you're off target, and you've cut enough to still hit, you're still a winner. But what if you're like us: an internal developer? You may not even have a milestone document. But you do have some method of tracking your schedule (you do have some way of tracking your schedule, right?), and that's what you -- and upper management -- have to rely on. If you're on target, great. If you're not, cut early and often. During this time, you're going to have to regularly remind upper management to look at the schedule instead of the game. Another thing we can do about the Dead Zone is try to keep it as short as possible, by trying to finish the game as early as possible and leaving lots of padding in the schedule for alpha. Like I said in my previous article, this pad should be proportional to the size of the project. (Untested theory: for a really long project -- say, three years -- you could plan to be done with production more than eight months before you ship. That way you'll be able to make your commitment to retail with absolute confidence, and have a ton of time left over for balance and polish.) The Dead Zone is my least favorite time in game development.
It has neither the raw creativity of the design/planning/proof-of-concept
stage, nor the straightforward push of the testing and bug-fixing
endgame. If anyone out there has worked on an original title where
there was no Dead Zone -- where the game showed steady, visible,
bug-free progress as new levels and new missions and new features
were brought to a shippable state, one after the other -- please
write me and let me know how you did it.
|
|||||||||||||||||||||||||||||||||||||||||||||||
The
Dead Zone
Features
|
|
|