Manager In A Strange Land: Quality vs. Scope

[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:
Geometry Wars
Tetris
Zuma
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:
Superman Returns
True Crime 2
Battlecruiser 3000AD

And here are some good, big games - but I believe these all slipped:
Zelda: Ocarina of Time
Neverwinter Nights
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:

Size Increases:
More enemies
More bosses
More worlds
More levels
More moves
More weapons
More player verbs
More characters
More modes
More minigames

Quality improvements:
Removing texture seams
Less robotic animation
Shorter load times
Less frustration
Less grinding or bottom-feeding
Fewer crashes
More responsive controls (less latency?)
More intuitive controls (less complexity, confusion)
Fewer hitches
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.

Comments

[davidicus]

some people are familiar with adding value, and the features-to-price ratio. design-thinkers tend to enjoy efficiency, polish, and clarification.

why does choosing size over quality seem so epidemic in our industry? because it's young, and suits are still fighting in the initial growth and shakedown phases.

plus, culture has discovered "experience" as an eventual commodity, and the industry is still confused about the differences and overlaps between experiences and games. products have been struggling to be both just to cover their bets.

[Anonymous]

The division between "more" and "less" seems bogus to me. They can all be phrased to suit your point (by saying "more frames per second" instead of "less inverse frames per second").

I think a simpler measure is "is this a bulletpoint that could be put on a box/publisher pitch, or is this improving an existing bulletpoint?"

[greggman]

I agree with your premise but some of your examples

Frame Rate? Since when did 10hz-30hz Halo loose out to faster FPSes? Load Times? If that was true EA wouldn't be #1. Texture Seams? All over the place in many hit games, Half Life 1 and 2 for instance.

I guess it's fun to try to find the "less" theme though. How about less nonsense. Less inconsistancies. Less non-interactive stuff. Less artificial barriers.

[Pag]

The cynic in me would say that scope is emphasized more than quality because of lazy marketing. There's no challenge making the marketing for a game if all you have to do is write "more weapons! more enemies! more levels!" -- it's going to be mediocre marketing, but it requires little efforts. Marketing quality, however, is more challenging -- you have to think about how to communicate that quality to consumers.

Still, I do think this is a bit too cynical. There's more to it than that. I'd say another large part of it is that it's hard to recognize quality before the game is done. So between a design doc that describes a few high quality features or one that describes a lot of poorer ones, the latter seems more exciting. And my inner cynic shimes in again to say that maybe some designers aren't skilled enough to make good designs so they compensate with quantity...

I'm a bit in a cynical mood today, it seems ;)

[Sande Chen]

At GirlsinGames, we tried to determine what was "essential" (our level of quality) and what was "optimistic." (great if we could do it) So, if we ever needed to make cuts (because of time, money), we knew what would get shifted to the "wish list."

[ddoine]

One thing you can do is include QA into your design phase and find out what the cost is going to be.

Many teams do not do this and then they continue to grind the game well into alpha, hours increase and panic insues...

Try designing the game with QA/Test in mind and maybe that would, in the long run, result in a better game.

[Anne]

The problem with scope versus quality is that it's sometimes unclear how big a game should be to qualify for its genre. MMOs pretty much have to be big to live up to players' expectations. For example, early in Star Wars Galaxies, there wasn't much content. Is that a quality issue, or a scope issue? Probably both.

[Factory]

"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."
I don't quite see that, at least in the list you gave.
But really, if one gets given some time, then one can say that you can either spend it on either adding functionality, or improving existing functionality.
I'd say that good quality games tend to do alot of the latter and not much of the former, so the lack of 'more' might be a side effect, than an intended cause.

OTOH there are alot of ppl who think more==better, and I suspect that it comes out in the games they make.

[unmatchedsocks]

In addition to including QA in design (essential in my opinion!), another element that should be included in all design is usability and user acceptance testing. How disappointing to finish coding and then find out no one can understand how to play the game easily. Or to find out the premise or content does not appeal to the target audience.