Because I don't have a blog and didn't feel like making one, I decided to just throw this on my itch page.  This is an essay about ten rules of RPG design.  They're not the only ten rules, and like any rules they can be broken as needed, but they're a good foundation to start with.

The essay is included in full in this description.  If you prefer it as a PDF, you can download it here as well.

Ten Rules of RPG Design

The Preface

First, this is about roleplaying game design, in which the players assume the role of a fictional character to guide them through an imagined world.  It is notably not about similar types of games, such as narrative engines (sometimes called “storygames”), because frankly those aren’t my thing and I don’t know how to design them.  So we are discussing only roleplaying games here. Although some of the rules here may be useful for other types of games as well, they’re mentioned in the context of roleplaying games.

I believe that these are fundamental parts of designing a roleplaying game.  These are not about my style of design or about how to design a specific game, but should apply for anyone who is trying to design any kind of roleplaying game.  As a result they are very general and if you’re looking for help designing your existing game, they may not be super helpful.  On the other hand, they are things that you should be thinking of before you begin your design.  They won’t tell you how to build a living room, but you can’t have the living room without the foundation.

There are other rules not listed here.  I’m not trying to list every possible thing that you could want to know when designing a game.  But I’m trying to list a good set of fundamentals; if you start with these rules in mind, you might need to learn, discover, or invent other rules, but you’ll at least have a good starting point on how to think about your game.

Every rule listed here has exceptions.  Even if I present something as a hard and fast absolute rule, I’m speaking in generalities here. 

The Rules

Every rule requires a reason.  When you create a rule, you need to think about what it does and why it does that.  Intentionality is the single most important part of any rule; why does it exist?  What effect will this rule have on a player who encounters it?  What effect will this rule have on the imaginary world?  What effect will it have on the table experience?  If these effects aren’t what you want, then maybe the rule isn’t what you want.

Every reason requires a goal.  What is your game about?  What experience should the players have?  When it’s over, what stories should they tell?  Before setting down a single word, you need to start by knowing that your end goal of creation is.  It doesn’t need to be in perfect detail, and you might change your mind at some point, but you need to have a goal that everything is working towards if you want to have a fully coherent and well-designed game.  Your goal should reflect the intended experience of playing your game, including both what kind of stories can be told with it and what genre those stories will fit best in.  For example, a fantasy adventure game, a cyberpunk heist game, or a sci-fi exploration game are viable (if bare-bones) goals.  You’ll need to define what your goal means to yourself, but as long as you have a clear image in mind, it doesn’t matter at this stage if you can explain it to other people (unless those other people are also designing with you, in which case, you should probably explain it to them). Don’t moderate your game design to try to appeal to people who dislike your goal.  Everything you design should be in service of your goal.  If people don’t like your goal, then your game won’t be for them, and that’s ok.

The player’s incentive should match the character’s incentive.  If you have a rule that rewards a player for doing something, it should be a thing that the character also wants to do.  Conversely, if there is a thing that you believe characters should want to do, then you should provide an incentive for players to do that as well. Not everything requires an incentive, and incentives don’t need to be used to try to ‘fix’ players or table issues.  It is not the responsibility of a game designer to deal with bad behavior or other issues.  But if you do create an incentive, then you want to make sure that it makes sense for both the player and the character.  If the incentives don’t match, then you get incoherent results.

System is setting.  The rules of the game dictate the stories that can be told with that game.  Yes, this is fundamental.  This goes back to every reason requires a goal; before you create rule 1, you should know what your game is for and what you want to do with it.  If your system states that all characters heal to full after every fight, then it’s impossible to tell a story about scrappy underdogs fighting the odds and being worn down but never giving up.  This is also true about genre, but is true about the implied settings as well.  Any setting that the system is used in will have certain things about it be necessarily true, because they’re defined in the system and its impact on the imaginary world.   Some systems are more flexible than others, and any system will be able to support multiple settings, as long as the settings all understand that they possess the intrinsic elements of the system.  But in the end, it must be known that the things you define in your system will be true in the setting as well, and that should be taken into account when defining things.

All rules and other game elements should be integrated into a seamless whole.  This doesn’t mean that you can’t have subsystems, but the subsystems should pass back a result that integrates into the core systems of the rules.  Everything should feel like it fits together and makes sense when interacted with.

Balance is a tool, not a goal.  Its purpose is to create interesting choices.  It does not actually matter if every choice is equally effective at all times, and in fact this is actively bad (that’s homogeneity, not balance).  As long as the choices that are provided are interesting, then the balance is sufficient.

The goal of progression is not the same for every system.  Campaign length is one of the things you should consider when designing mechanics.  Progression matters, and the way that your game changes as progression occurs matters as well.  Do you want characters to journey from zero to hero?  Do you want them to start at a particular power level, and just have adventures around there?  Do you want them to start by saving the village, and move up all the way through saving the multiverse?  The progression system is part of what determines the bounds of these stories.  Additionally, the progression system affects the meaningful length of campaigns and should be considered for its impact on abilities.  Many games are considered to “fall apart” after a certain amount of progression because the cumulative impact of progression on character abilities results in an unintended experience.

Design elements can carry both Breadth and Depth.  Roughly speaking, Breadth is how many different choices you can make, and Depth is how much each individual choice affects your gameplay experience.  A game that is Broad can be easily replayed in a lot of different campaigns, while a game that is Deep supports a long-term campaign with a single character.  When designing your game, you should think about this, and what kind of play structure you want your game to have.  Is it a beer and pretzels game that people will play one-shots of repeatedly?  Make sure it’s Broad.  Are you designing to support 20-year campaigns?  Make sure it’s Deep.  (It is possible to be both, if you add all the rules to support both.)

Let players engage with the things that they want to engage with.  If a player repeatedly selects game elements that improve their abilities at a specific thing, that means that the player wants to engage with that thing.  Many games will have these mechanics remove the need to engage with that thing; this is a mistake.  If a player wants to focus on something, and the mechanics are there to allow them to focus on it, then the mechanics should not prevent them from engaging with it.

Games that contain a small but nonzero percentage of ridiculous bullshit are more fun.  A game that’s purely predictable feels sanitized.  Don’t try so hard to make the game balanced or predictable or fair that you squeeze all the life out of it.  Let ridiculous things happen.  Let the players be frustrated occasionally and let things that aren’t fun in a vacuum happen.  Without valleys, the peaks aren’t meaningful.  Of course, a balance needs to occur, and presumably your goal is for the game to be fun overall; but if you try to make it so that the game is never even a little bit un-fun, you’ll end up making it so it’s never exciting and fun, either.