When you set out to design a game it’s important to know what you want that game to do. It’s much more important to know how the game is going to do it. Beginners trying to design a video game tend to focus on how kewl it will be, not how it will work.
This is something that should be obvious, yet despite everything I’ve written about beginners designing games I have not said it explicitly. But 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. 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. (I don’t mean the details of programming, I mean the mechanics that the programming will enforce.) And if you try to pin them down to how the game is going to do it they have no clue. 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.
Some designers like to make a separate list, which might be called a “why” list, to indicate what they want the players to experience, what the personal impact will be on the players. This is more likely for video games, which can use the power of the computer to provide a greater variety of personal experience than is possible with board and card games. Sometimes your decision about what genre of game to make provides sufficient “experiential” intent. For example, if you make a survival horror game, or a real-time-strategy game, much of the experience of the player is fairly well determined. Or for tabletop games you might choose a family game, a screwage game, an historical wargame, a multi-sided representational wargame, an abstract game, and so on.
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.
You May Also Like
.png?width=300&auto=webp&quality=80&disable=upscale)
