Tuesday, October 11, 2011

When you start a game design, conceive a game, not a wish list



This is something that should be obvious, yet despite everything I’ve written about beginners designing games I have not said it explicitly.  And I know from my teaching experience that to many people it isn’t obvious.  It is especially important for people who want to design video games rather than tabletop games. 

When you set out to design a game it’s important to know what you want that game to do, what the impact will be on the players.  But it’s much more important to know how the game is going to do that.  Typically, beginners trying to design a video game will have visions of how wonderful it will be and how “kewl” and how much it will be just what they want to play, but if they try to solidify their notions they end up with a wish list of what they want the game to do, not a description of how the game is going to do it.  And if you try to pin them down to how the game is going to do it they have no clue.  (I don’t mean the details of programming, I mean the mechanics that the programming will enforce.) This is a special case of “hiding behind the computer”.  The would-be designer completely loses track of the link between where he wants to go and where he is now, he more or less assumes that the computer will make it possible.  “And a miracle occurs”.

What you want the game to do is part of the “idea”, how it will do it is part of the “structure”.  As many have said, ideas are a dime a dozen.  It’s the execution, the how, that makes a difference.  The structure provides the framework for “how” to happen.

A wish list is OK, but if you don’t know how to get there you may just be describing your favorite game on steroids, your favorite game “to the max”.  Frequently in such lists the would-be designer will say that he or she will have the best story ever, the best graphics ever, and so forth, which actually doesn’t mean anything at all.  Because unless you know some practical method that will let you have the best story or the best graphics or the “best _____”, no one’s going to believe you’ll do it and it’s most unlikely to happen.  In other words you’re wishing, not designing.  In a sense it’s a form of fanboy-ism.

The tabletop game designer is less likely to fall into this trap because there’s no computer to hide behind.  It’s much more obvious that the designer has to figure out the mechanisms the game will use to reach the desired result.  This is yet another reason why it is more practical and more instructive to learn to design with tabletop games even if you intend to be a video game design.

2 comments:

Paul Owen said...

I'm learning this lesson first-hand with my current project, "Gold on Mars." I have a pretty clear idea of what I want the game to "be," and the kinds of decisions I want the players to face and the nature of the outcomes of those decisions. But I'm having a hard time translating those concepts into a structure that works in a table-top game.

So far I'm faced with some pretty cumbersome mechanics that are just not practical - too many pieces, too much math, that kind of thing. So right now I'm kind of in the thick of hammering away at the problem, trying to bridge the gap between what's practical at the table and the vision that I have for the game experience.

Anonymous said...

Hi

Tks very much for post:

I like it and hope that you continue posting.

Let me show other source that may be good for community.

Source: Game designer job description

Best rgs
David