posted 06.05.04
by , 5 Jun 2004 | revised 21 Aug 2004
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.
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.
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?
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.
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 .
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:
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.
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.
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.
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 componentsrulesthat make it work. If any one of these were different, the game wouldnt 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.
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 kind of game you’re making.
With the idea of a core concept, you may have a connection between a possible rule and some aspect of your game—but how to forge a solid mechanic that will make one influence the other? This is the question of how to make rules effective—or how to give them “oomph.” Oomph is most especially critical for core concepts, because without oomph, core rule are weak and like a flimsy bridge, won’t support the rest of game.
Basically, creating oomph comes down to making use of what you know about people, and taking advantage of itnot in a sinister way, but to aid your design.
Oomph is about how rules are made important to players. Rules may interact in complex ways, have intricate subtleties, and relate to all your major goals. But if players don’t see the point to them, they won’t get used—at least nor properly; not fully. This requires you to step away from the technical side of design: away from dice and statistics, charts, and technical writing. It requires consideration of your players not as robots who will mindlessly follow rules you set down, but as human beings, who are subject to emotions and quirks of thought. Basically, creating oomph comes down to making use of what you know about people, and taking advantage of it—not in a sinister way, but to aid your design.
One simple example: people like dice. They like rolling dice. They like lots of dice being rolled. There’s a visceral attraction to dice, and because they are physical objects, it’s also easy to relate dice to some quantity that is otherwise only an abstraction in the game rules. While you could have each missile a player in a tank fires give a +3 to damage, having the player roll a die for each missile makes more intuitive sense and is probably more engaging. Conversely, players hate counting up dice and doing mental arithmetic—even if they can do it, they still don’t like too. But that’s another consideration...
The list of ways to achieve oomph goes on and on. However, what promoting oomph often comes down to is punishment and reward. These two methods will allow you to guide player behavior in terms of making effective use of your rules, and will allow the rules to work in the first place.
It’s important to note that we’re not talking about rewards for characters here. Characters aren’t people—they don’t make decisions about how to play your game: their players do, so it’s them you need to target. Rewards and punishments can do several things:
Rewards are almost always more effective than punishments. I’m not prepared to say entirely why, since I don’t know, but there are likely many reasons. One is simply that humans don’t like being punished—though of course that’s the whole point. In an activity that is supposed to be light and fun (potentially), heavy-handed punishment may ruin the mood. The ineffectiveness of punishments probably also just has to do with human psychology: we’re just prone to chase the carrot harder than we run from the switch.
Thus, when designing rules, and especially when designing core concept rules, you need to think about how players will actually use them, and how you want them to use then; which of the three items above do you want to achieve? Then you have to decide how to do it: there are many kinds of rewards, the standard of character “advancement” being only one. Just a big bag of tokens that the GM hands out called “Cool Points” may be more than enough.
What’s the worst thing that could probably happen to your design process, other than you simply losing interest in it? High on my list would be its completion—followed by it’s first stage of testing, in which it’s revealed that nothing works as it should. Major parts have to be reconsidered, everything else modified to accommodate those changes, and the whole thing re-written. Doesn’t happen? Maybe not to people who write for Steve Jackson Games who have ready beta-testers, but it happens to other people all the time. A lot of the games that go up on the net have never been tested in any significant way, with the designer merely presuming that everything will work the way he imagined it too (or not caring if it does). Unfortunately, this is usually far too optimistic, and neglects both the vagaries of human behavior and the complexities of game design (game design is hard).
And frequently youll be surprised: both by what seemed a sure shot but fails miserably, and by what you thought was a placeholder but which turns out to be a perfect fit.
I always admired a design philosophy espoused by computer game designer Peter Molyneux: always work from playable versions, and then play them. Of course, with role-playing games this may be a little harder since it’s not so easy to boot up your friends and reload the scenario you were testing last time...but it’s still eminently possible. In both computer and role-playing games there are many ways to proceed with the design and implementation.
In one method, you create lots of little pieces, slowly fit them together, and finally—voila!—you have some kind of product. This method unfortunately makes testing at earlier stages nearly impossible. Even if you can find people willing to play your “game,” it will be so incomplete that what you’re really doing is playing make-believe, and sticking your game’s name on it—it’s not the same unfortunately.
The other method is to identify core concepts early on, get some possible working implementations of them, string on a few other necessities—even if they’re highly provisional—and play the thing to see how it works. Only like this can you know whether that provisional implementation is actually any good. And frequently you’ll be surprised: both by what seemed a sure shot but fails miserably, and by what you thought was a placeholder but which turns out to be a perfect fit. Since RPGs are meant to be played, how can you know if they work without playing them?
In addition to having your rules in a semi-workable state, periodically write up major changes into some kind of document that could be read by other people. Firstly this will facilitate your actual playtesting sessions, or make them possible if you can’t personally be there (though of course you will generally want to be). Additionally, writing up rules can expose potential problems. When writing up a rule, you have to ask yourself how it can best be explained to others: when can it be used, and when can’t it? What exceptions are there to it? How does it interact with other rule? When you force yourself to answer these question through writing, you’ll have a better idea of how a rule might work before you even pick up a bag of dice.
Of course, playtesting shouldn’t get in the way of actual designing either. It’s a necessity, but only a tool at this stage, not a goal in itself. Don’t waste time wrapping your game in a fancy commercial package or take time writing endless and exacting descriptions that your playtesters realistically don’t need. Of course it also depends on how you work. Personally, I like to work from a master “playtest beta” file on my computer which has rules written up to the point that problems are exposed, and that other people could understand the basics of the rules if need be. At the same time, I periodically write up notes—also on the computer—to add details and list possible alternatives for one rule or another. I never show these to other people, although occasionally chunks of text get pasted into other files. And all this is on top of a myriad of index-cards I keep around the desk for jotting things down. This style lends itself pretty well to playtesting...but can also lead to wasted time in the preparation of the working draft.
Other people work in different ways. If you’re someone who’s tendency isn’t to write things into a working rule set, then you may need to make yourself do it every week or so. It may not be fun—it may be downright onerous—but game design is hard work. Without the tools to test a game, you can’t expect your test to be a good one.
Playtesting often is good—heck it’s great—but there are many kinds of playtesting and quality counts too. There are several things you can do to help ensure that the playtesting you do is useful.
Of course you need players that are enthusiastic about your project and thus committed to it. One kind of playtesting involves a single group that constantly sees the revisions and design changes you make, absorbing them into an ongoing, regular game. This can often be frustrating both for the players and for you if you’re GMing it. If you have a loyal crew though, it can be highly valuable to have players who know your game inside and out and can compare this week’s newest rule to the one it just replaced. This kind of “in house,” “closed-beta” playtest can work very well, particularly during the middle of the design period,
On the other hand, getting fresh perspectives on your game is important too. New perspectives allow you to guage how people react to the game, and how easy it is to learn—both in terms of the rules themselves, in abstract, and in their present written form—giving you a chance to revise the text in the future. Until you’re game is almost done, the clarity of your writing should be a secondary or tertiary concern. A far more important aspect of this kind of testing is the fact that a bevy of your old role-playing chums may not be representative of gamers at large. You need to know not just how one group plays your game, and how a new rules functions for one person, but how they work in general. Thus, you need fresh recruits. This is a hard thing to do. If you are well connected to your local hobby shop, that’s likely the best place to start. The internet is also a possibility, but you may want to wait for a separate “open beta” phase later on, when the design is more polished. I can’t give much more practical advice on getting playtesters. My main suggestion: more is always better.
When you do get playtesters, make sure you get the most out of it. Take copious notes during play. See how players react to the rules and use them before you jump in to explain how they “ought” to work. Observe players closely to see what they like and what they don’t, and how the game influences their mood and behavior. Finally, ask players after a game what they thought about it—ask specific questions if possible, but be open to anything. You may need to give them a few days to think it over.
Assure your testers that you’re not wed to anything; that while it is your baby, it’s not done yet, and you only want to make it better. Likewise, if someone does criticize your game, don’t take it personally but see it for what it is: another tool you can use to improve your design.
With good game testing you can constantly evaluate your rules (and your write-up of those rules) on the basis of how they actually affect play, and how they contribute to your game’s purpose. You will frequently need to go back to your early design notes that list your Big Goals for the project: such-and-such a rule may be really cool and original...but if it doesn’t contribute to the goals of the game, it’s place in the design needs to be seriously questioned. Rules bloat is a constant temptation unless you stick to your goals. Focus rules on the core concepts you’ve identified in order to strengthen them and link together the different facets of the design.
Also trim anything that doesn’t turn out to work in practice. No matter how beautifully wrought, a functionless rule is a waste of space, and you owe it to yourself to hoist it over. Self-evaluation can be hard, especially when it’s a project you’ve put a lot of time into. Playtesting can help you get around that difficulty by involving other people. Of course you always call the final shots on what stays and what gets changed, but as I’ve said before, RPGs are here to be played. You are your number one reader, but if you’re the only one, who will you play your game with?
Just sticking with a project is often a major hurtle on the road to its completion—at least when you're not getting regular pay for it. You have to love what you’re doing. Game design is hard work, and it’s not always fun, but you still have to be passionate about it in some way or another. If you lose interest in a project...set it aside. Potentially you’ll never look at it again. But it’s also possible you’ll get inspired again later and resume work with even greater energy than before. Don’t force yourself to work on something you don’t feel is worthwhile. This is a hobby after all—no lives, fortunes, or reputations are being put at stake. (Okay, maybe reputations, but only within a very narrow sub-culture that probably has no bearing on the rest of your life.)
Playtesting is also a great way to get away from designing without totally getting away from the project...
That said, there are things you can do to keep yourself motivated. If you’re still interested in a project but find your energy waning, take a break from your current task and do something different. This may mean working on a different rule or idea, but it could also mean something unrelated to rules. Write background material. Prepare playtest versions of existing rules. Go back and re-read your earlier notes. Design a logo for your game. All these things are far less important than actual design, but they keep your brain from frying itself while still keeping it focused on the project.
Playtesting is also a great way to get away from designing without totally getting away from the project, especially if the game is nearing completion. You can relax a little with some friends and enjoy yourself, and maybe have a flash of inspiration at the same time.
On the other hand, taking breaks is also smart. This works at many scales. I personally find my productivity drops off after a few hours of writing and I need to get up and do something else. At the very least stretch and rest the eyes. In the longer term, you can also get burnt out on a project when thinking about it too much for days on end. Take a weekend off to let your thoughts settle, then come back to it. Alternately, if your design is coming along well, take a couple weeks off from it, or more, to gain some valuable perspective. You’ll forget your previous train of thought, and when you come back to the game you’ll be less attached to the rules you just wrote—allowing you to be a more honest critic and to strip away what’s not necessary.
Game design is not easy. It takes hard work, dedication, ruthlessness, a vision, and maybe some creativity too. But it’s also highly rewarding—potentially as rewarding as any artistic endeavor. By using the right tools, and the right approach, design can be made easier, and will more consistently give fruit. This essay has not been totally comprehensive, nor is it intended to be. But I hope that the general concepts discussed in it prove helpful to you.
I don’t necessarily claim that anything here is highly innovative—it is rather a synthesis of ideas, forming a general manifesto for design that reflects my own current thoughts, and which I myself try to follow. Despite that disclaimer, I’m happy to hear whatever you might think of it, so feel free to .
Credit goes to many people who I couldn’t hope to remember or name—no doubt I’ve stolen some ideas wholesale, and adopted others from various sources. Many certainly originated with frequent posters at The Forge discussion forums.
May all your design projects be rewaring as well as hard, and all your designs focused, complete, and in the end fun.
Jump to Top06.10.05
Thanks, Adam. Was there any part that struck you as more useful? I'm thinking it's about time for a new article on this topic, since my thoughts have changed a bit in the past year.
06.13.05
The two most useful things to me would have been the two Big Questions (What do players do? What do characters do?) and the Reward and Punishment section.
08.03.05
Okay, thanks.
08.17.05
© by Jasper McChesney, 2007
I love this. I wish I'd found this about a year ago!