A Metric for Scoping Games?
Well, it's Saturday, and I'm stuck at the office today on about my sixtieth hour this week trying to make a so-called RAD (Rapid Application Development) tool do stuff that was never intended by the team that designed the thing. Whether that's their limitation, or my own, I don't know. But I needed a short break and I wanted to talk game development stuff, so here I am.

I was re-reading an article by Phil Carlisle a few days ago (in response to a thread on the GarageGames forums). Something really struck me. While the numbers thrown around by Phil and Dan MacDonald (in the comments) aren't necessarily definitive, they are a pretty solid rule of thumb if you know what you are doing and aren't at the fast-moving point in the learning curve. That means for every week you spend prototyping, you'll spend two additional weeks getting it "feature complete" - and then two months polishing it and getting it ready to release. So you can pretty much estimate your dev time by the amount of time it takes to prototype the game - or, working backwards, you can define the scope of the game by taking your total dev time, dividing it by twelve, and then scoping your prototype to fit within that time.

Of course, there are variables. At SingleTrac we spent about three months getting prototypes done for our first games that had only a 1 year development horizon. So that's only a 1:4 ratio. A lot of those three months were spent characterizing the machine, staffing up the dev teams, and getting over the early-learning-curve stuff. We had probably twice the team size during development as we did during prototyping and early-engine-creation... so that would bring the ratio from 1:4 to about 1:8. Not quite 1:12, but halfway there. The learning-curve stages could account for some of it. And, arguably, the compression showed - SingleTrac never had a reputation for having extremely polished-looking games.

Void War took about 1/6th of the time to prototype instead of 1/12th... but I also ramped up the amount of time I spent on the project significantly during the latter third of development (from about 10 hours a week to 30+). So if you consider the last six months to be worth three times the value of the first twelve, you get a total development time of 30 "10 hours-per-week months." 3 of those spent prototyping... That's a 1:10 ratio instead of 1:12, but still dang close. HOWEVER - I also got some additional help developing content and programming the launcher during the latter half of development. Bingo. Unscientific guesstimation could bring that ratio to about 1:12. So Dan's numbers hold up.

So I think we have something approaching a true, honest-to-goodness metric for scoping games. Something hard to think about - especially for ME, working on my current projects. While I'm breaking a few rules with this game design, deliberately persuing some methods of achieving larger scope along one axis by reducing scope along another... it doesn't make me immune. Does this apply to triple-A retail games as well? Maybe, though if anything I'd say the escalation of production qualities means an even smaller ratio.

And moving on to something different, with pictures:

I think my "prototype" barn turned out pretty well, as a learner project. I don't know if the 1:12 ratio applies here (I hope not, or I'll be spending about 12 weeks on every one-room-sized interior in my game, and I'll be screwed!). It's not professional quality, and the final version will have to have things like a ladder, doors on the stalls, and lots of clutter - like hay bails and maybe piles of fly-attracting dung (phew!) And I need to figure out how to get rid of the "sneaky ninja lightmap-leaks" that show off certain edges between polygons. But for creating a simple environment for testing out gameplay, I think it'll work just fine.

Labels: Game Design

- posted by The Rampant Coyote @ 2:18 PM (Permalink)