[That's right, I'm resurrecting my old "Manager In A Strange Land" column, here in the blog! We'll see how it goes...I've only really got ideas for two more articles.]
"Scope" is a fancy project manager word for "Size." I don't know why I use it. I guess to look fancy.
You've heard that expression: "Cheap, fast, or good: pick two." (Or, as the guys from Id put it at the last DICE: "Cheap, fast, or good: pick *one*.")
Well, there's a variable missing from that equation. What we really should be saying, is: "Cheap, fast, good, or big: pick three."
Or, better still: "Cheap, fast, good, or big: prioritize them and find a balance you're happy with."
Most of us don't have any wiggle room on time or budget: those parameters were established when our project started, and if we run out of either it's time for drastic measures. (Actually, we do have wiggle room on Schizoid right now, but that's a pretty rare situation!)
Which means we have to choose between good and big. The problem is it's hard to tell good from big: to differentiate between quality and scope. It's easy to say, "This game will be worse if we take this feature away." And if you look at the games that get in the nineties on gamerankings, you'll find that most of them are good AND big. So the temptation to say, "It all has to be there," is very strong.
"It all has to be there," is something some designers and directors like to say that causes producers and programmers to have rabid fits. It doesn't all have to be there - and if you try to get it all in there, quality is going to suffer.
Just ask guys from *Infinity Ward* or *Ready At Dawn* how they make their games so good and still ship on time. Their answer is, "Cut early, cut often." Not that *Call of Duty* or *Daxter* were small games - it was just that given a choice between having more stuff and having better stuff, they chose better stuff.
Here are some good, small games:
Diablo (small compared to other RPG's of the time, like the Ultimas)
Guitar Hero (small compared to your typical console game of today)
Here are large, bad games...according to MetaCritic, anyway:
True Crime 2
And here are some good, big games - but I believe these all slipped:
Zelda: Ocarina of Time
World of Warcraft
So - how do you tell? How do you tell when you're doing something that's going to improve quality, or if you're just making the game bigger at the expense of quality? Unfortunately, I don't know how to define it. But I can list examples of both:
More player verbs
Removing texture seams
Less robotic animation
Shorter load times
Less grinding or bottom-feeding
More responsive controls (less latency?)
More intuitive controls (less complexity, confusion)
Better framerate (less frame duration)
So, something I just noticed, while writing these lists, is that size increases are usually "more" of something, and quality improvements can usually be worded as "less" of something. Maybe it's the old expression - "Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away." (Antoine de Saint-Exupery)
Or maybe that's going too far: was Pong the best game ever?
If this all seems obvious, I have to ask - why does choosing size over quality seem so epidemic in our industry? Maybe it's the schedule - it's easy to write down an estimate for how long it will take to "Get Snowblower Mode In"; it's not so easy to estimate how long it will take to "Get framerate to 60" or "Smooth out player experience."
And, then, there's the contract. If you're an external developer, you may be contractually obligated to provide n levels and m bosses. Even though that has nothing to do with how well the game will be received, publishers want to hold you to something.
Pithy conclusion sentence here.