Game Design: Step by StepAnd Now, For Something Completely Different....
February 24, 2000
I almost didn't get this week's column off the ground, due to that all-time best of modern excuses, the dreaded "computer crash". However, thankfully, now I've got a working machine again, things (hopefully) will get back to normal (quick, ubiquitous Star Wars reference: "You hear me, baby? Hold together.").
Anyway, enough of my problems. (Maybe if I type *really gently* things will be OK...)
I thought that I would take a break from UnderWorld this week (while I get things ready for the playtest), and go into more detail on the general process of game design.
What I consider to be the first, essential step in designing a game (as should be evident, I suppose, from having followed the process of UnderWorld so far) is to develop the setting. This can be as detailed as designing a world from the ground up, or merely picking a genre that you like...it's a matter of personal preference how much detail you opt for at this stage. The setting will have to be fully detailed before the game is completed, but at this point, all you really need is a direction to go in.
Once I've decided on a setting (in my case, usually a genre), I break game design down into the following steps:
1) NiftiesNifties: As I told you way back at the beginning of this column, I try to come up with some kind of innovation or gimmick that will make the game stand out. I refer to these as a game's "nifties". They're usually the first thing that I think about after deciding upon a setting for the game. The cool thing about nifties is that more often than not, ideas regarding them will come to you throughout the process, and so you can continually refine them as you go. They're an on-going part of the design process.
Resolution Mechanic: The next thing to figure out is one of the most important factors in the design of a game: the basic resolution mechanic. This will require a great deal of thought, since every other activity in the game will use some form of this. Here is where you decide what dice you're using (if any), how they will be read, what the scale of results are, and what they will mean for your game. In my personal process, I try to come up with a resolution mechanic that is as unobtrusive as possible, and maintains the feel of the genre that I'm working in. For example, I'm not likely to pick a percentile system for a fantasy game, since, in my opinion, percentiles feel very precise and technical...something that I don't think fits in a fantasy, but works great for a sci-fi setting. You will need to understand the probabilities involved, so that you can tailor your system to adequately reflect the difficulties of performing certain tasks....but fear not. Once you've worked those out, that's probably the worst of the number-crunching that you'll need to do during this process.
Character Creation: The next step is to consider two things: What sorts of characters should play a major role in this setting (since the players will be the focus of the stories, their characters should be of a type that plays a major role...after all, nobody wants to play "Guard #4"), and how do you go about defining those characters so that they can interact using the Resolution Mechanic that you've devised. You will find that thinking of character creation in terms of what is necessary to define them in rules terms as well as in setting terms will result in a creation system that almost designs itself. It's almost like reverse engineering. You are allowing the setting and rules to dictate what will be needed for character creation. You can add more to that basic framework, if you feel like it.
Combat: Like it or not, these are adventure games after all, and the form that most conflicts take will be combat. Using the basic resolution mechanic, come up with a system that determines strikes, defense and wounding. The realism, level of detail and severity of the combat system will hinge upon the tropes of the genre of your game setting. In my opinion, too many games violate this principle (for example--do we really need all of those weapons charts that cropped up in Vampire after a while?). In its most basic form, a combat system really only needs a method of determining strikes (against either passive or active defense, depending upon whether or not such defense is possible, which again can be largely a matter of genre...i.e. dodging bullets in a pulp game), and determining the damage done by those strikes. Some people prefer "wound levels" which represent differing degrees of injury...others prefer the simplicity of a point system, where damage is ticked off until the counter reaches zero. Again, a matter of personal preference.
World-specific mechanics: This is where those facets unique to your game world are resolved. Here is where you work out the systems for Magic, Cyberware, Starships, The Force, or whatever other game-world concepts need rules definition. At this point, keeping in mind all of the rules elements that you have already designed, defining your World-specific mechanics comes pretty easily. Once you have decided the scale of impact that the concept will have in your game world (i.e. how much it effects the setting), plugging that into your rules system (which at this point is largely already complete) is not as daunting a task as it first seems.
The last step is Detail. This is where you go back, polish your concepts, fill in any blanks that you find, and put the finishing touches on your setting and your rules system. Think of it as working on your second draft. After that, your game goes into playtest, where any weak elements are discovered, and rectified. Following playtest comes one last re-write, incorporating the changes brought about during playtest, and that's it. There you have it---game design in a nutshell.
Now, obviously, anyone who's been reading this column from the beginning will recognize that the reality is much more complicated that the outline of the process that I've given here. Each one of the steps that I list in this article can take months to work through to your satisfaction. Essentially, however, the above listed framework is exactly the steps that I go through when designing a game. A game is a big project. Like any big project, you'll find that the work comes more easily if it is broken down into smaller tasks...and that precisely is the function of the framework that I've given here. Try it out...I think you'll find that it helps.
Er...or maybe don't try it out. I wouldn't want a sudden influx of game designers to put those of us already out here out of a job!
See ya in 7,
Underworld, and all related terms and concepts contained herein are copyright 2000 by Gareth-Michael Skarka. All rights reserved.