Methods of Game Design

by , 5 Jun 2004 / revised 21 Aug 2004

Introduction:
The Need for Design

A lot of people are making role playing games these days. A lot. And yet we’re in a small hobby. I'd bet that the ratio of those who create and those who consume is higher within tabletop gaming than nearly any other hobby or art, even given that I'm including free publication of games on web sites and at local hobby shops. I suspect this is partly because gaming tends to attract creatively minded people, and partly because not having a formal publishing deal doesn't prevent a game from being widely seen (thanks in large part, but certainly not only to the internet).

This huge surge in game availability has meant an enormous product to player ratio as well: even if your own interests are narrow, there are hosts of games out there for you to consider playing. This state of affairs may not be permanent, and is probably both a boon and a curse (although on balance I'd say it's positive), particularly to designers and would-be designers: on one hand, you can make a game and get it out to people, even with a minimal budget, but on the other those people are unlikely to notice it amidst the tumble of high-quality books and the clamoring of web-based publishers.

Getting noticed must therefore become the chief concern of any designer who wants his game played —for money, vanity, or whatever. There are lots of issues to consdier on this front, not least among them advertising, presentation, internet-presence, and so on and so on. However, all but the most jaded and corporate-minded designer (and are there really any who fit this description?) realizes that the quality of his design itself—the rules—is ultimately on the top of the heap. Of course, even once designed, rules must be clearly explained, packaged, and advertised, and they must deal with unpredictable economic and competetive forces. But none of this matters one whit if the rules themselves are drab. This article is about avoiding “drab” rules.

What Design Is

To make good rules, and thereby a good game, you must care about those rules. Not just care that they get done, that they seem okay, that your friend Jed likes them a whole lot, but care that they are the absolute best rules you can come up with to do what you want them to. This care, and the work that it implies, is what real game design is all about. For me (when splitting hairs) design is different from simple creation, and not every game that exists was necessarily designed. Of course, this is pedantism plain and simple, and probably somehow elitist as well, but limited pedantism still has its place.

Although every piece of architecture is a building, not every building is architecture; and while by necessity each one is planned, not every one is designed. The same is true of most creative and artistic pursuits: there is one level at which product is made—even manufactured—and another at which it is really created; with games as elsewhere we call it "design." The gap between the two must be bridged with effort, technique, and most of all desire.

Even those who rise to greatness must start out producing amateurish things, in role-playing as anywhere else...

The difference between "made" and designed role-playing games is usually obvious. I would be loath to point to any specific examples of the former, but I suspect we've all seen out fair share—including, often enough, ones we ourselves are responsible for. The hallmarks of simple manufacture at its worst are derivative qualities, inconsistencies, and rules that simply don't work as expected (and hoped).

But the point of my distinction is not to point fingers or laugh at amateurish work. Although a fair bit of money changes hands over role-playing games, it is nonetheless a hobby for most of us, and there is still a big place for hobby designers as much as for hobby players (and I hope this is true for a long time). Even those who rise to greatness must start out producing amateurish things, in role-playing as anywhere else, and only with very rare exception. This essay is aimed at those who want to attempt that rise, to transition from making to designing. It is, I think, a transition almost anyone can make, as long as his mind is set to it.

Note of Clarification

Just to be clear, I'm not trying to be dogmatic about "designer" and by no means insist everyone use my more precise, elitist, definition. If to you, game "maker" conjures up images of powerful and primordial creative energies in the hands of man, by all means use it so; like-wise for "game creator," "writer," or whatever other term strikes you—and although I personally steer away from what I perceive to be cute and artsy, you could hardly get more pretentious than the various synonyms for "game master" we've used over the years, so no worries there.

As an aside, I find it interesting that the RPG design process has frequently been associated with blacksmithing: Clinton R. Nixon's "Anvilwerks" and "The Forge" discussion forum that he co-administers, Tomas HVM's use of "gamesmith" instead of designer, and I'm sure there are other instances. (I particularly find it amusing since I do blacksmithing myself, so if I adopted "gamesmith" I'd be a smith on two fronts.) I wonder why no one chose to instead associate themselves with, say, stone masonry, where the metaphor of building a game out of parts is possibly more apt than that of shaping it from metal stock. Maybe some deep-seated human affection for fire?

Game Design is Hard

To really design a game is not easy though, and in fact good design is quite hard. The vast majority of people are not born game designers (and even though I was making games of one sort or another from the age of 4, I wouldn't say I was born a good game designer; merely that I had the interest). Becoming good at design takes practice: just as a painting student must churn out hundreds of mediocre studies, often intentionally imitative, so too must the game designer cut his teeth and frequently fail before he may feel reasonably proficient. Also as with painting and writing, game design cannot be done in isolation: a good writer must also read, and in fact read prodigiously. The game designer must therefore buy, read, and study, and play the designs of others to see what has been done, how it's done, and what hasn't been done yet.

You cannot be a successful "armchair" designer, thinking about games only in theory and never at the table, where real people will use it.

Good game design has yet another important element however, because games exist to played, and that play is a very complicated process. While an artist or a painter may be lauded by critics and become known as successful, a game designer will be judged by his peers alone, and an RPG that cannot in fact be played will never succeed. The use of a RPG is highly complex—potentially as complex as any social interaction humans have. Therefore a designer must think analytically about his design and apply whatever tools he can to its construction, foremost among them being his own experience: beyond reading other RPGs, a designer must play them (at least some of them). He must see for himself what works and what doesn't, and why. You cannot be a successful "armchair" designer, thinking about games only in theory and never at the table, where real people will use it.

In the end, becoming a game designer takes a lot of hard work. You must develop your own skills, and that development can take a long while. Even when you're competent, designing a game is not simple or easy, and just like with writing or painting you must still pour work into it: design work, as often as not, is not particularly fun, but often frustrating, exhausting, and yet addictive all the same. However, after all is said and done, a game designer can look at his work and be satisfied—even if not every wholly content with it. For unlike with writing or painting, a game designer does not need to design for the fun of design itself, but so as to have the product of his design sitting on his table, waiting to be played by no other than himself. While a painter can take pride in his work and even hang it on his wall, his most intense enjoyment of it probably came durign the painting itself; he did it to do, not to have. A game designer, while intimately connected to his own creation, can take most of his satisfaction through its actual use, and that is the real beauty of game design.

This Document

With all of the above in mind, you can see that some particular methods for game design could be well used, just as as writers have their methods, both to train themselves and to improve their work itself. The methods here are not concerned with the "fiddly bits" of RPGs, such as ways to roll dice, or other specific rules, but are rather techiques for the design process itself. This document contains a few such methods that I think are useful. It it primarily intended for those who are just starting down the design road, perhaps who have never created or designed a game ever before. Older hands might still find something interesting, but may also be familiar with most or all of what's discussed.

Before I get further into things, let me just note who I am and where I’m coming from. I’ve made a lot of games in my life: I’ve been making games since I was at least four years old, having boxes of the things getting moldy in the basement, and have been making role-playing games for at least ten years. I haven’t been designing games for nearly so long though. It’s been a slow evolutionary learning process, and my thoughts on game making have led me to write this article.

Most of my designs are now available from Primeval Games Press. They are mostly available for free, which has occasionally been a matter of choice and esthetics (I like free things), but has more often stemmed from my limited time and energy, and the accompanying belief that I would have to polish what I have far more were I to charge money for it. However I have also published through online distibutors, using the pdf format, and will likely do more in the future.

By this account, I am by no means an "industry professional" (such as they are), nor even one of the more successful independant designers. But I have gone through the design process many times, and in the end with decent results. I have seen projects through to completion, have set others aside for another day, and have abandoned others entirely. I may therefore have some sense of which approaches—which methods—work and which end in frustration. My goal here is to steer new and would-be designers away from the worst pot-holes and morasses, and perhaps lead them towards the grassy plains of true game design. If this article helps one good role-playing game get released, I'll feel well satisfied.

If you take issue with anything I’ve written in this article, think it was useful, decide that I’m totally full of it, or have any other comments, feel free—in fact feel encouraged—to .

The Big Question

When inspiration comes to you, and you think you might begin to design a role-playing game, you should ask yourself the following question:

What are my design goals?

It may also be phrased simply as “What am I trying to accomplish?” Of course you're trying to accomplsih the design of a role-playing game, but be more specific: what kind of game do you want to make? A good way to get at this is to ask one further question still:

How is this game going to play?

Role-playing games exist to be played. They don't exist to sit on a shelf or be admired by other designers. All role-playing games play differently: there is not just one role-playing game out there, and not just one way to play either. Each game must be played on its own terms, and you as a designer must figure out what those terms are. Only when you know how you want your game to be played (what they play “experience” will bel like) can you begin to think of how to accomplish that, and therefore how to actually design your game.

When asked about play experience, it's easy to begin rattling off minor rules, lists of powers, and descriptions of the setting you've been thinking about. However, it's way too early to be thinking about most of these things, except in the back of your mind for inspiration. Specific rules and fiddly details don't yet have a solid foundation to rest on, and trying to build the game around them will usually lead to an inconsistant design that lacks clear purpose, and therefore can't give one to players either. In the end, your game will be composed of numerous small rules, but you need an overarching plan to know what rules you need and how they'll fit together. This overarching plan comes from considering what kind of play experience you want, and potentially drawing inspiration from your setting and what you see players accomplishing. Specific rules can inspire other rules, but it's best to put those aside at this stage. Consider the following questions:

1. What will the characters in the game do?
2. What will the players in the game do?

Question #2 is ultimately includes #1 and is far more important, but #1 is probably easier to answer and can serve as a good starting point. You may be thinking, “Do? Players roll dice and decide what actions their characters take. Big whoop.” But players don’t do the same things in all games. Far from it.

Tip of the iceberg: what does the GM do, and what do other players do? Eh? In grand old D&D, the GM maight say:

There’s a dragon attacking the town. You want to shoot it? Okay, you miss. The dragon turns against you.

No big deal. In my game, ABSQVE ROMA, the GM would stop with “There’s a dragon attacking the town.” (Never mind that there are no dragons in Roman Britain.) If someone wants to shoot it, someone else, not the GM, says:

Okay, roll the dice: the difficulty is 6.

These two games do not handle the situation in the same way. The players do different things.

That was a fairly straightforward example, with simply a rearrangement of roles, but there are innumerable other alterations you can make on well-known paradigms. Here's another example:

The ship’s alarms go off: it’s about to be hit by an iceberg! You want to jump in a life boat right? Okay. Fortunately you survive and are picked up by a rescue ship.

Imagine that as actual literal dialog coming from someone’s mouth. Would you want to be playing in the above game? What kind of pacing does it show? What does it tell you about the relationships between the players of the game? Who gets to decide things? How are characters controlled?

You may think the above is a terrible example of game-mastering (and I sure set you up to think so with my first question). Even if it is, it should make you think about how you generally prefer things to work, or how you’re used to them working, by considering what’s bad about it. However, there isn’t just one good way to handle pacing and player relationships. What if the above dialog was from a game about immortals involved in political intrigue. The players in such a game don’t want to bother about life-rafts and gun-wales: that’s just filler before the real deal. So in a section that’s not about politics, like the above diolog, the pacing is fast, the questions are brief, and the GM presumes a lot. It’s not necessarily a case of bad game-mastering at all!

A lot of what happens in RPGs can work in many varied ways. If you write “The main character then takes action”, what exactly does this mean? Is everyone just supposed to know what he does? Who decides? When do they say what he does? How do they say it? Can anyone or anything later contradict them?

If the rules, as you provide them, don’t tell the players what to do—directly or indirectly—then how will they know? Will you just let them figure it out? You wouldn’t let players “just figure out” how to roll the dice when their characters are shooting up an enemy tank would you? You need to think about how your game should be played, in terms of actual diolog between real people, and how you can communicate that design to your readers.

Knowing how you want your game to play is the first step. What comes next is making sure that it actually plays that way. That’s the rest of your design work, from brainstorming, to drafting rules, to playtesting and revising.

Jump to Top

Clear Goals

Clear goals are essential for good design work. With them, you’re armed to go out and create rules to address your game’s premise. They also provide you with a means for constant self-evaluation: if the game doesn’t do what you want it to do, something has to be changed.

Knowing how you want your game to play is the big concept that you always need to keep in your mind. Whenever you create a rule, ask yourself:

What do I want this rule to accomplish?
What will this rule actually accomplish?
Do I need this rule?

A lot of rules get put in a lot of games because no one questioned the Way Things Have Always Been Done. Generally this means how a small group of designers, who wrote D&D, GURPS, and Vampire:TM did things—or how a lot of other designers who emulated those designers did things. Either way we’ve got a lot of collective baggage in this hobby. Analyze your game closely, looking at every rule that you write, to get at the smallest pieces of it, and then question them.

Let’s say you’re designing a game and there’s going to be a GM in it. Do you need one? You have ability scores, hit points, and toughness ratings...why? That’s not a “why” that says “You idiot! Design something new and different because the old stuff is gauche!” but rather “How does this rule help my game do what I want it to do—that is play how I want it to play?” Question everything. This may mean asking yourself hard questions and then ditching things you were attached to, but which don’t really serve the needs of your game. You might have really liked the idea of character classes, but realize they don’t do anything useful, or in fact clash with other aspects of the design. Throw them out. Throw out everything you don’t actually really need.

Although many games approach things with a kitchen-sink mentality—thinking perhaps that with enough rules, everything is bound to be covered and the game is sure to work—this is usually not a path to success: pairing down your game into the tightest package you can manage will, in the end, make it more coherent, more flexible, and more easily grasped.

When doing close analysis of your work, an important consideration is always the actual effect of a rule versus how you’d imagined it working. This happens to me a lot. I get a vague sense of a some way of rolling dice and handling certain character traits. Then I do the statistics and test it, only to realize it doesn’t really do what I want. Maybe the range is too small or it takes too long to roll; or it doesn't function with some other, more important rule. The only option is to replace it, reevaluate what my needs are, and try again.

It’s all too easy to try tweaking a rule to make it work even when it’s fundamentally flawed for your uses. Generally this is a slow road to frustration and lost time. Ditch the implementation and approach the problem from some other angle. If a tweaked rule really would have worked, you’ll get to it again anyway, probably by some other route entirely.

Jump to Top

Core Concepts

As you begin work on your game, you’ll come up with all sorts of rules and mechanics that will describe how the game works. You’ll usually start with a jumble of vague ideas, with just some sense of how they tie into the game’s main purpose, and some sense of what they will do. This jumble easily becomes larger and larger, as you think about all the different facets of your game. Having thought about everything, you may even think you’re done—to bad, you’re not! This process is entirely natural, but needs to be fought at every turn. It’s the game designer’s version of what’s termed “feature creep” in software programming circles: the product becomes larger and larger, with more and more “features” because each one somehow makes sense—at least when it was being created.

For example, you’re designing a kung-fu game set in ancient China about tactical combat and exploring the warrior code. You start thinking about how enemies will be handled. Adhering to the advice given in the previous section, you wisely decide to eschew hit points and other typical mechanics for rules that instead deal with “warrior spirit” and reference Chinese mythology and religion. Fine so far. But thinking about combat gets you to thinking about weapons, so you design a whole set of special rules for different weapons. Then magic weapons. Then how different schools make weapons. Jumping back to combat again, you realize you need tactical depth, so you think of rules for terrain, for visibility, for...and soon enough you have a 30 page file on your desktop full of stuff.

Core Concepts Defined

Stuff is not what you need for your game. “Stuff” does not just mean trivial lists of equipment or baddies to kill. It doesn’t mean rules or mechanics that don’t have a purpose. Stuff is rules that aren’t core to the game’s functioning, when even the core hasn’t been nailed down yet. While generating stuff is inevitable, there’s really only one good thing to do with it: treat it as a brain dump for future reference and inspiration, tuck your notes about it away some place you can get them later, and move on. Move on to more important things.

In most good RPGs, you would have no trouble identifying a handful of really key components—rules—that make it work. If any one of these were different, the game wouldn’t be the same.

Well what’s important? “Core concepts” are those aspects of an RPG that are what ultimately drive everything forward, and which set it apart from other games—not different for difference’s sake, or for marketing, but for the purpose of achieving something that those other games don’t. In most good RPGs, you would have no trouble identifying a handful of really key components—rules—that make it work. If any one of these were different, the game wouldn’t be the same.

Take D&D: classes, rolling to hit, experience, hit points. While now often copied, these are (at least potential) core concepts from the oldest RPG around. If you replaced hit points with something else, or modified how they worked, D&D wouldn’t be the game we all now know. But you could fiddle with the proficiency rules and add feats, because they’re not core to the game. Every game has core concepts. Many have very similar ones, and this should tip you off that the games themselves are similar—perhaps designed with rules that owe more to history than the actual needs of the game as envisioned.

Identifying Core Concepts

The trick then is to identify what your game’s core concepts are, and to do so early on. When first formulating your game you may have some big rules in mind that connect with nearly everything else in a neat, tight, little package—great, you’ve answered part of the question already. Often though, you won’t know quite how to start achieving your design goals, and no big rules pop into your head from the get-go. In this case, it becomes a matter of wading through the stuff and picking out the gems—those rules concepts that link in and support vital areas of your design.

For instance, say I’m making a game about space-mecha combat, anime-style. I come up with some thoughts on maneuvering, for weapons penetrating armor, for resolving tasks in general, and also some rules for pilot awareness. Hmm...of course task resolution in general is important, but it’s not a core concept unless there’s something about it that really supports the game’s unique goals—success/failure is just useful, not core. In my mecha game, pilot awareness sounds like it could be a core concept. That’s the key word: could. It depends on the specifics of my goal, the specifics of the idea, and also how I implement it. But the fact that it might be core separates it from the chaff of armor rules and the like right away. So I write it down.

How could this support the goals I have for the game? What would it need to do in order to be effective?

If you’ve identified a core concept or two, you can keep winnowing to get more, but eventually you’ll probably run out of potential ideas. The next stage is to develop those nuggets of potential that you already have and see where they take you. Key at this stage is a lack of commitment to specific implementations: these are ideas and concepts we’re talking about at this point, not nitty-gritty, hard and fast rules. Starting with a potential core idea, ask yourself, “How could this support the goals I have for the game? What would it need to do in order to be effective?”

For instance, in the Chinese kung-fu game, say I come up with an idea for a character trait having to do with resolve. This sounds promising, since the game addresses warrior codes, and resolve seems like it could tie into that. But what kind of resolve? And what kind of trait? Is it an attribute, or maybe a resource that fluctuates? What effects does it achieve? What do I want it to achieve? Not all of these questions have to be answered at once. Explore different pathways with an idea, playing around with it, and see what it could do for you. In the end, it may turn out that your potential core idea isn’t a core idea, or maybe not something you want at all.

Pinning down core concepts is key to doing the rest of your design work, because they form the underlying structure on which other rules hang. This isn’t to say that they need to be firmly established from the beginning and never change as your desig proceeds—far from it. But without some sense of how you’re addressing the big issues, your entire game becomes nothing but loose rules—stuff. It should also be noted that the number of “core rules” in a game may vary a lot. Some may only have two or three, while others—very distilled games—are composed of basically nothing but. As with everything, it depends on the