Tales of the Rampant Coyote
Adventures in Indie Gaming!


(  RSS Feed! | Games! | Forums! )

Monday, October 30, 2006
 
Kitchen Sink Game Design and Magic: The Gathering
I sometimes go off on "kitchen sink design."I still encounter it, and I still have to fight it in my own designs. But what is Kitchen Sink Game Design?

Kitchen Sink Game Design is the mentality that if something is good, then throwing yet more stuff into it would make it better. In other words, throwing in every idea but the kitchen sink. Or maybe including said sink. It's good marketing (as it adds to the perceived value), but horrible game design.

As an example: Would Unreal Tournament 2004 be any better with twice as many weapons? Many players and wannabe-game-designers might think so. But here's the trick: How would the player access all the different weapons? Would complicating the keyboard control make it better? And how would the weapons be differentiated yet balanced? If one weapon overbalances the others in the game (like the rocket launcher did in the original Quake), wouldn't it make the other weapons effectively useless and ignored? Suddenly the game becomes about the new Disintegrator Autorifle, so instead of having twenty weapons, you really have only one. And how do you balance ammunition pick-ups in the game?

In reality, by throwing more stuff that everyone wants into the game, you've actually made it less enjoyable.

As scope increases with added features, your needed time to develop to that scope may increase at a higher rate. To keep with the FPS example, let's say you double the weapon count. Obviously, this doubles the time it takes to design, model, texture, and code each weapon and its corresponding projectiles, effects, and pickups. But the time necessary to balance each weapon against all of the others (including tweaking all of its statistics, designing pick-up placement in all the levels, etc.) is an "Order n-squared" operation. In other words, for all n weapons, they need to be balanced against (n-1) others. Off the top of my head, I think the formula is actually (n x (n -1)) / 2... since once you've compared the chaingun against the rocket launcher, you don't need to compare the rocket launcher against the chaingun.

So what this means is that scope increase has the potential to geometrically increase your development time. Looking at the scope of modern, mainstream games, is it any wonder why the average cost of developing a game has increased by an order of magnitude in the last decade?

One lesson I learned about game design came from playing Magic: The Gathering. For those of you who haven't played this game (or other CCGs, or "Collectable Card Games), this is how the game works:

You have a collection of cards. The cards all have different effects on gameplay, of varying magnitudes. However, they also have costs in game resources - how difficult they are to bring into play from your hand. For example, a really powerful dragon might cost lots of very specific kinds of "mana" (the game resource in Magic), making it almost impossible to bring out into play until late in the game. However, once it is brought out, it has a high likelihood of winning the game for you.

The decks are shuffled and drawn into your hand at random. That means that you'll almost never have the card you really need when you want it.

A common mistake of many beginners (at least in the early days of the game - I don't know if even beginners do this anymore) is to throw in as many cool cards into their decks as they can. It's the "kitchen sink" design philosophy. They don't do this for very long - experienced players clobber them easily and repeatedly. The decks that win are designed around a much tighter focus and a narrow set of strategies.

One of the early guidebooks for the game gave great design advice for creating decks. When considering a card for inclusion in your deck, the book advised, don't just consider its added value to the deck. Also consider what card you might NOT be getting because you drew that card. Sure, that awesome legendary dragon might be really cool, but how are you going to feel if you draw two of those on your initial hand, when you have no chance whatsoever of playing them anytime soon, instead of cards that you could actually USE. They are simply wasted opportunities, and allow your opponent to get a good early start against you.

I think the same lesson applies to game designers. You should not only consider added features by their added value to the game and their cost in development time, but also consider their cost in the player's attention. Do you really want them paying attention to the kitchen sink you threw into the game instead of the core features? If said player is actually a reviewer, was your half-baked multiplayer mode really worth it if they spend most of their time reviewing it rather than your stellar single-player game?

It's a tough call. Sometimes the answer really is "yes." Sometimes the dreaded "feature creep" is actually a good thing, as you come up with ideas that actually enhance the whole package. Too little scope can result in a game that's shallow and uninteresting. But you can definitely have too much of a good thing in game design. Sometimes what a good game really needs to make it better is actually the removal of a couple of really good ideas.

(Vaguely) related bits of digital spewage:
* Keeping It Simple
* Rampant Games' Game Design Articles

Labels:



Did you enjoy this post? Feel free to share it: del.icio.us | Digg it | Furl | reddit | Yahoo MyWeb

Comments:
My experiment (due to lifelong rampant feature creep), requested by my wife who has observed my developing habits for years, is that my next game will be done the old-fashioned way. I write a design doc, not necessarily comprehensive in every aspect, but listing every major feature and mode in the game. Then I develop, and I can't put in anything that's not in the doc! It'll be an interesting exercise in restraint. Usually about 2/3 of my games come about during development.
 
That concerns me too, because sometimes that may be the best 2/3rds. The old fashioned way didn't lead to great games. (My whole, "You can't design fun on paper" argument).

The trick is knowing when to let those features stay, and knowing when to nip them in the bud. I still haven't quite mastered it.
 
That's what makes it an experiment! It helps that it's a sequel to an LD48 entry. I have few concerns over it being fun... unless I add too much to the original formula!
 
Post a Comment

Links to this post:

Create a Link



<< Home

Powered by Blogger