For the sake of providing a concrete example let's consider 360 submission. I first think of the cost of certification as the time between shipping the game and being "done" with the game. The time I don't get to spend finishing the game. The polish time I don't get to have. The time I need to set aside for getting the team ready to...wait.
I suspect many people don't realize that from the developer's perspective, the game has to be done long before you send it off to manufacturing. It has to be done several weeks before that, in fact, so that (in this example) Microsoft can verify it's bug-free, compliant with technical requirements, etc.
This period of time requires you to have a significant number of people available for the inevitable top-priority bugs that MS comes back with. They may be rare crash bugs that you can't reproduce on your own (but of course the QA guys at MS can repro it enough to fail your submission). They may be multiplayer bugs that you never see on your internal network. They may be ninja controller pulls or crazy PC system specs problems or UI localization or... point being, the bugs that come back during submission or rarely simple to fix but are obviously the highest imaginable priority. I mean, if you don't fix these the game won't ship. So you've got to have folks on hand to fix this stuff during the submission process, even though everyone's pretty much sitting back with a "we did it, it's over" feeling.
When those bugs come back from your 1st submission, you have to have people on hand that can fix them, correctly and quickly. Those people aren't taking time off to recharge before the next project, they aren't doing pre-production, they're just...not doing work. And you have to budget for two submissions, so that's twice as much not doing work. Now, since you budget for two submissions you can assume you're going to fail your first sub (which is a very reasonably plan...MS can be pretty demanding) and therefore you keep fixing bugs and polishing the game. Then, when the Fail comes back from MS you take care of the bugs they found and your second submission is actually a better version of the game.
This actually bit us in the keister on Xmen2, though, where we had at least one bad bug that wouldn't prevent the game from being certified but we did want to fix before the game went to consumers. So we sent Sony the first submission thinking "we'll be able to take the next few days to fix this issue, then the first submission will fail and we'll include this fix in our second submission." Unbelievably, our first submission passed. We couldn't believe it. We wound up petitioning Sony to allow a second submission that included the fix for Bug X. Let me tell you one way to get Sony's hackles up...actually pass their submission process and then ask to resubmit anyway. Well, you, the consumer, did get a better version of the game out of it, at least.
So, yeah. That's the cost of certification to me. A number of talented people sitting around not making the game better. Maybe a good question for the future would be, "Is the cost of certification worth what you get out of it?"
Sunday, August 22, 2010
Sunday, August 15, 2010
What production methods should you use developing your game?
I'll work to come up with a more broad question next time. Dunno if I can top this one, though. :}
Allow me to preface these thoughts with the fact that my background is almost exclusively in AAA development. The smallest team I've worked with was about 25 people on the first Soldier of Fortune.
I know Agile methods are now such a hot topic that they've almost become mainstream, but I can't say even something like Scrum is required for successful development. I will say that my own limited experience implementing Agile methods has met with success, but it's still case-by-case as to whether that would solve more problems than it would fix. When I look at something like what Haunted Temple Studio is doing with Skulls of the Shogun I find it unlikely even a framework as almost universally applicable as Scrum would be more help than hindrance. I mean, they're four guys. And they're talking just a few months of development.
Is the importance of using a named method directly proportional to the size of the team, then? Well, going full on Wild West, code-what-you-feel with 200 developers seems unarguably questionable to me so maybe your team should be using something at that point, even if it's *gasp* waterfall. If you're working on the eleventeenth sequel to a particular sport game, though, maybe you can just do whatever you want. I haven't worked on more than a few sequels in my time, nor have I worked with a 200-person team so I can't comment authoritatively on that one.
That raises a point, though...does the familiarity of the project really determine how you do what you do? Or to put it in a more intriguing light, does the unfamiliarity drive your choice of methodology? If your team has primarily done shooters and now you're on a top-down action RPG, should that point you toward a more structured approach to your project? When we did exactly that at Raven we probably should've picked some sort of production methodology, I can tell you that. Instead, we drifted around a fair amount and took quite a while to create X-men Legends.
It may well come down to a case-by-case basis. The best general advice I could give is to ask the question of your project lead and/or studio management, "If someone brand new to the team came into your office and asked How does your team make a game, how would you answer them?" If you don't have an answer, or if it takes several tries over the span of several minutes, try to get someone in charge to sit down with you and do some research. Doing something new doesn't mean experimental or risky, but you should be implementing something with a wee bit more formality.
Allow me to preface these thoughts with the fact that my background is almost exclusively in AAA development. The smallest team I've worked with was about 25 people on the first Soldier of Fortune.
I know Agile methods are now such a hot topic that they've almost become mainstream, but I can't say even something like Scrum is required for successful development. I will say that my own limited experience implementing Agile methods has met with success, but it's still case-by-case as to whether that would solve more problems than it would fix. When I look at something like what Haunted Temple Studio is doing with Skulls of the Shogun I find it unlikely even a framework as almost universally applicable as Scrum would be more help than hindrance. I mean, they're four guys. And they're talking just a few months of development.
Is the importance of using a named method directly proportional to the size of the team, then? Well, going full on Wild West, code-what-you-feel with 200 developers seems unarguably questionable to me so maybe your team should be using something at that point, even if it's *gasp* waterfall. If you're working on the eleventeenth sequel to a particular sport game, though, maybe you can just do whatever you want. I haven't worked on more than a few sequels in my time, nor have I worked with a 200-person team so I can't comment authoritatively on that one.
That raises a point, though...does the familiarity of the project really determine how you do what you do? Or to put it in a more intriguing light, does the unfamiliarity drive your choice of methodology? If your team has primarily done shooters and now you're on a top-down action RPG, should that point you toward a more structured approach to your project? When we did exactly that at Raven we probably should've picked some sort of production methodology, I can tell you that. Instead, we drifted around a fair amount and took quite a while to create X-men Legends.
It may well come down to a case-by-case basis. The best general advice I could give is to ask the question of your project lead and/or studio management, "If someone brand new to the team came into your office and asked How does your team make a game, how would you answer them?" If you don't have an answer, or if it takes several tries over the span of several minutes, try to get someone in charge to sit down with you and do some research. Doing something new doesn't mean experimental or risky, but you should be implementing something with a wee bit more formality.
Sunday, August 8, 2010
Subscribe to:
Posts (Atom)