On Metagaming

Depending on who you ask, metagaming can vary between 'the reason we play' and 'cheating, get out'.  This is in part due to changing definitions over time and in part due to differing expectations.  The basic problem is that we're all using the same word to mean different things, and then interpreting the meaning differently, and the whole thing is a huge mess.  I'm going to muse about the different kinds of metagaming, and the different ways that it was expected to be used in old-school games, here for a little bit.

First to note, although oldschool and OSR gamers are among the most likely to call metagaming cheating, there were absolutely aspects of what we'd call today metagaming that were a normal and expected part of OSR gameplay.  I've mentioned a little of this elsewhere and may talk more about it in the future, but a lot of the very early games were actually more roguelikes than they were a modern conception of RPG.  If you consider the original stories of Castle Greyhawk gameplay, the expected pattern of play was to go into the dungeon, die, make a new character, and try again with the information you learned from your previous character.  This is a roguelike play pattern (and also obviously a form of metagaming).

As a result, in old-school expectations, the core distinction between 'normal gameplay' and 'cheating' isn't whether or not the knowledge is purely in-game; the distinction is whether or not the knowledge was gained through gameplay.  It was expected and normal for you to use your own knowledge and your own experience, about the game and about things outside the game, to assist in gameplay, and that's still expected today; anyone someone mentions 'player skill', that's a form of metagaming.  It's not a negative thing and is designed as part of the games and play culture.  The most common example of this is the fact that trolls are weak to fire.  An experienced player, who has encountered trolls hundreds of times before, is expected to know that trolls are weak to fire and no one considers this a problem.  This is because the experienced player has learned that through gameplay.  If, on the other hand, you encounter a unique monster and you learned its weakness by reading its statblock, this is considered cheating.  That's because you didn't earn that knowledge through gameplay; you got it by reading the module or the splatbook or whatever.

Similarly, if your new characters go back into a dungeon that your former characters died in, that was expected for you to use your player knowledge; your existing maps, your knowledge of traps and monsters.  You earned that knowledge yourself by playing through it.  If you've never been in this dungeon before, and you learned about it through reading the module, that's cheating.

So we can see different kinds of metagaming here, and distinctions between them, and one is considered good and normal part of gameplay and another kind is considered cheating.  Obviously, the line as to whether something is good or cheating is about play culture and expectations.  Talk to your groups, people.  In order to help distinguish between different kinds of metagaming, I'm going to classify a few types and give them names.

First up is meta-consideration.  Meta-consideration is the recognition that you are playing this game with real humans and you should consider their existence, experience, and opinions when you make decisions.  Every form of RPG gameplay that I'm aware of considers meta-consideration to be an unalloyed good, and frankly I wouldn't want to play with anyone who disagrees.  An example of meta-consideration is choosing not to summon a giant spider, and getting a pair of wolves instead, if a fellow player is arachnophobic.  The vast majority of meta-consideration boils down to 'don't be a dick', but sometimes it's more complicated.  Usage of safety tools is also an example of meta-consideration.

The second type identified is meta-tactics.  This includes knowledge like 'trolls ill like fire', or simply discussing tactical options with players out of character (whether it's done in downtime or during combat).  I have encountered traditions of roleplaying where meta-tactics is considered negative (I used to play a LARP that permitted some forms of meta-tactics, but considered others to be cheating), but in the majority of situations, it's considered fine to good.

Our third type listed here is meta-knowledge.  This would be using knowledge about the game world that was learned through gameplay or appropriate player-available sources, but not with your current character.  An example would be using the same dungeon map for Castle Greyhawk despite the fact that you started that map six characters ago.  Meta-knowledge is considered negative or up to cheating in most traditions of roleplaying I'm familiar with; but as described above, in sufficiently old-school traditions, it was normal and approved.

Finally, we have meta-cheating.  I feel no need to hedge on this category because every tradition of roleplaying I'm familiar with considers it cheating.  This would include things like reading the DM's notes, reading the module ahead of time, playing the game with a Monster Manual open to read all enemy stats, and so on.  The use of knowledge that was never gained, never earned, and is not expected to be available to players, and usually includes lying to the other members of the group about where the knowledge came from.

I don't expect people to start using these terms instead of calling things metagaming; I'm probably not going to use these different terms myself.  But I think splitting it out like this helps identify, at least, the idea that there are different kinds of metagaming, and that different traditions and cultures of play will approve or disapprove of these things in different ways depending on context and details.  In very old games, meta-cheating is the only kind that is explicitly considered negative and meta-consideration the only explicit positive; but the other kinds could be positive or negative, depending on whether or not the knowledge was earned through your own gameplay at some point.  In more modern, more character-focused gameplay, meta-consideration is usually positive, meta-tactics are a maybe, meta-knowledge and meta-cheating are a no go.  

Find your culture and find your sweet spot for your own group; both blanket bans and blanket approvals will tend to fail because context matters.

Design Threads, Compiled

This post is a compilation of some threads that I wrote on twitter about game design a few years ago.  I'd probably write them a little bit differently if I was writing them today, or not for twitter, but instead of rewriting them I'm just copying and pasting.  This is currently a draft as I type this, maybe by the time it's a post I'll actually edit them.  On the other hand, if you're reading this, that means I didn't.

Basic Mechanic Design Steps

So here's a ramble about my process when designing a new mechanic.

The first step is to ask some questions: Why do I want this mechanic? What is the use case where players will interact with it? What is the intended gameplay experience? Do I need this mechanic, or are these use cases and gameplay experiences already adequately covered by existing mechanics?

Assuming I decide that the mechanic is needed, then I continue. At this point I have the expected use case and desired gameplay experience. These are the two most important things about the mechanic and the things that I keep in mind throughout the entire rest of the process. Let's take an example I designed; rules for running away from combat in Against the Fall of Night. Sometimes a combat just goes bad and you want to run away.

My expected use case is: Players are in a combat that they don't want to be in, so they decide to run. My desired gameplay experience is: Running has a cost, you can't just run at the drop of a hat, but you're reasonably likely to make it if you flee and the cost doesn't feel punishing even if you fail.

Is this a needed mechanic? Standard D&D-like combat movement systems make fleeing basically impossible. You can disengage, but they'll just follow you, and unless you move faster than them (which you usually don't, especially not in armor) then you're not making any real progress. AFN has similar combat movement mechanics, so yes, this is a desired experience that is not served by existing mechanics; it's worth adding.

The mechanic that I designed, put in what is basically system-neutral psedudocode, is: Everyone fleeing gives up their turns for a round. At the end of the round, everyone fleeing makes a check and everyone chasing makes a check. If half of the fleers succed, and half of the chasers don't, they get away. If half the chasers succeed, and half the fleers don't, escape is impossible. Any other result, it becomes a running battle where you automatically check again at the end of each round.

I check it against my ideals. Use case: Yes, you can run away in combat using this rule (you better be able to, that's all it does). Yes, it costs you something (all your actions for one round); but it's not a one-and-done roll. It always only costs you your actions for one round, not your actions for the rest of the combat, even if you fail. And if you end up in a running battle, it adds tension and changes the nature of your choices; with you knowing that the fight might end at the end of each round, you'll make different choices than you might otherwise.

And it also adds possible tension in the form of heroic sacrifices, by specifying 'the enemies chasing' instead of 'all enemies'; if you can make it so that some enemies can't chase, maybe by blocking the corridor, then those enemies don't get to be part of the check.

This is obviously an alpha rule, since I wrote it the same day as this original thread, and it's subject to plenty of change and revision. Almost nothing ever stays in its original form (iterate, iterate, iterate!) But, at least on a twitter-appropriate level of verbiage, that's my basic mechanical design process. Focus on the use case and the gameplay experience, make the math and design match it, and then iterate it until your eyes bleed.

Dice Mechanics

Last time I mentioned making the math and design match the use case and gameplay experience, but didn't actually say anything about how to do that. This time I'm going to talk about dice and how I pick which dice to use for a mechanic.

It doesn't cover every possible trick you can do with dice, but most of the time, you can separate dice mechanics into two kinds; one die or multiple dice. One die is a mechanic like D&D's d20 rolls; you roll a single die, you add whatever, you compare it to target, you're done. Multiple dice can be done by adding the pool vs a target, or by checking each individual die against a target. The big difference between the two is probability.

On one die, all results are equally likely. On multiple dice, the results are on a bell curve. One die has a lot more swinginess as a result. If you're rolling a d20, a 1, a 10, and a 20 are all equally likely. If you're rolling 3d6, a result in the 9-12 range is almost 50 times as likely as getting a 3 or 18! (100 times as likely as 3 or as 18, each). So if you have, say, a +1 modifier and you need a 10; this is a 60% chance on a d20, but a 74% chance on 3d6. As your modifier grows, the difference gets bigger. With +5, it's a 80% chance on a d20 but a 98% chance on 3d6! You're ten times as likely to fail on the d20.

What does this mean for game design? It means that a single-die system emphasizes randomness and elements outside your character's control, because failure is always a meaningful chance due to the machinations of the die. If your goal is to create a mechanic where the player is never sure what's going to happen, and where failure is always an option, a single-die is a good choice.

If your goal is to create a system where predictable tasks can be performed predictably, then a single-die is probably going to be too swingy for you (which has led to some of the complaints about D&D's skill system, historically). To emphasize skill and experience over chance, a multi-die system will give you results that are capable of staying random at low modifiers but scale towards determinism at higher modifiers.

Does it matter what kind of multi-die system you use? Yes, but not for this discussion. Successes and sum vs target both follow a bell curve and both fundamentally share the same elements in this regard, but they have different secondary tricks that you can do with them. It's also worth noting that the more dice you're throwing down, the more tightly bound to the bell curve the result will be.

Adding more dice to the pool isn't just a modifier on success; it changes the shape of the curve, which limits the effect of outlying results all on its own. It's a form of bounded accuracy enforced by probability, with the small chance of going way outside the expected results. If you roll 10d6, 68% of the time, it'll be between about 30 and 40. 95% of the time, it'll be between about 25 and 45. 99.7% of the time, it'll be between about 20 and 50. But 0.3% of the time, it'll be lower than 20 or higher than 50.

The mathematics of the dice bound the possible results pretty tightly, but allow for exceptional results in very rare cases. (For reference, the odds of having advantage and rolling a pair of 1's anyway is 0.25%; about the same as the odds of going below 20/over 50 here.) If you roll a d20, on the other hand...68% of the time it'll be between 5 and 15. 100% of the time it'll be between 1 and 20. That's it, that's all the confidence you get.

So what's the summary? Dice and math matter when designing a mechanic, because the players are going to interface with them, and the mechanics of the probability will determine the experience that the players have with the mechanic. If the players expect the mechanic to be predictable, but instead it's swingy, then your mechanic doesn't match the expected use case. Conversely, if the players expect it to be swingy and random, but it's actually very predictable, same problem. Make the mechanic as players experience it match what you want the gameplay experience to be; and picking dice is one way to control that.

Implied Incentives in Design

Today's discussion is about player choices and incentives as they relate to the mechanics that you design. Incentives and the results of choice are an important part of the experience that players will have as they interface with a mechanic.

Imagine you're designing a skill system. You have a variety of possible ways to do this. As always, we start with the goals; use case and intended experience. We'll assume that your game doesn't have a skill system yet and that you do need this mechanic. The use case is that a player wants to do a thing that isn't directly combat-related. The intended experience is that the more resources the player invests into doing this thing, the better they are at it.

There's already a lot going on here, and it ties into the tone and genre expectations of your game. But that's not the topic here so I'll just assert something. I assert, for this example, that characters should be able to range from untrained to highly skilled, and that their chance of success at a given task should increase each time they invest character resources into this skill.

Already we're making incentive choices. The incentive we're giving is that players can improve at their skill by spending resources. But the question becomes, then, how much do they improve? Is it better for them to specialize or spread it out? Will any choice offered to them ever feel like it was a trap?

(Don't do that, btw. Trap options aren't real choices.)

You can adjust these knobs with mechanics changes, and there's a lot of ways to get any given result, and this is (originally posted on) twitter. So instead I'm going to talk about why you might aim for one goal or another, and what that does to the player incentives.

Let's say that you decide that you start with 50% success, and you have four ranks, and each rank gives you +10% success. You can focus them in one skill or spread them across others. This is a fairly balanced option that makes both specializing and focus decent options. What if your success rates by rank 0-4 are, instead, 10%/50%/80%/90%/100%?

You can see a strong incentive here to have at least one rank in anything that you want to get done, and a second rank if you want to get it done reliably. Because of the huge jump between ranks 0 and 1, it's unlikely that anyone would put all four ranks in one skill, so they're rewarded with 100% success rate if they do. There's incentives for both.

But what if it was 10%/50%/80%/90%/91%? I don't think you'd see a lot of rank 4's in there. That extra 1% is not a strong incentive and would not feel rewarding, especially not when they could be putting that to make something else from rank 0 to 1 and getting a 40% boost. By considering the incentives that your mechanics offer to players, you can analyze the experience that they'll receive when making these decisions, which in turn will affect their satisfaction with the mechanical interface of your game.

I've only been talking about character building here, but the same principle can be applied to actions in-game. Some games have a stunting mechanic, where if you take a recklessly awesome action, you get a bonus to your resolution. This is an incentive. Recklessly awesome actions are often unlikely to succeed and very dangerous to the player; so they're fairly uncommon. If you want to make them more common for genre or gameplay experience reasons, you can provide players with an incentive to take these actions, and that's what stunting does. (Of course, this can also generate undesired results, like players competing to take the most over-the-top action, but that's a separate topic.)

Another example of an incentive in gameplay is the oldschool XP for GP rule. You gain one XP per GP value of treasure that you safely return to town with. XP for GP reduces the value of combat, because combat is dangerous and grabbing unguarded loot isn't. It leans players towards wanting to play carefully, because they need to return safely, and to find ways to get loot without combat. If that's something you want for genre or gameplay reasons, that's something that XP for GP can do.

Incentives can be a very strong design tool for gently leaning players towards the expected experience. Don't go too heavy with them, though, because an incentive that's too heavy isn't an incentive anymore; it's a balance problem. But whether or not you use them intentionally, they'll always exist in your design. Thinking about your mechanics in terms of incentives is a useful way to help predict what kind of gameplay experience a player will have, and to figure out whether or not that matches your intent.

Mechanical Variance

Today, I'm talking about the value of variability in mechanics, and why you might want a mechanic to be highly variable; or, perhaps more accurately, why you want to avoid an entire character being low-variance.

High-variance and low-variance characters have existed in a variety of ways in different RPGs. I'm going to draw my examples in this thread mostly from D&D 5E, because lots of people are familiar with it and it can handle it if I say anything that could be considered negative. One of the most traditional examples of variance differences is the fighter versus the wizard.

A fighter, in the majority of combat situations, will find themselves taking the Attack action. Because of the way 5E balances attack bonuses vs AC, using HP as a primary defensive stat, you can have a pretty good amount of confidence in what the attack will do. It will very likely do damage within the expected bounds.

A wizard, in most combat sitautions, will cast a spell. What will the spell do? That depends on the spell, the targets, any required saving throws, the terrain, and so on. It's almost impossible to predict the actual result on the battlefield just by knowing that a spell will be cast; whereas the fighter's attack is very predictable.

So we can see that the wizard has much higher variance in combat than the fighter. There are other ways to increase variance too. A fighter using Sharpshooter or Great Weapon Mastery will have a higher variance than one who isn't; with the attack penalty and damage boost, they can get huge swingy differences outside of their average result. So we know that there's ways to get lots of variance in combat. What does this tell us about the value of it, though?

If we look at the most common complaints about the fighter, it tells us that variance is fun. Variance feels like power. The most common complaints about the fighter are that it's boring or underpowered. The fighter isn't underpowered. It's a very strong class. But it doesn't always get those same kind of high-variance spikes that we can see from other classes, which can make it feel less powerful.

Imagine a class that had one attack, always hit, and always dealt 5 damage (at first level). This would be a very strong class! But would it feel strong, next to a character who might occasionally spike something much more effective than it?

Introducing high and low points into a class experience, rather than keeping them as a smooth average, allows for players to feel good about the awesome thing they just did. Assuming the amount of low points are kept in check (missing all the time isn't fun, but the attack roll itself wouldn't be fun if you could never miss), and the high points need to be kept appropriately rare as well - it's not as awesome if it's just something that you can do all the time, variance introduces a feeling of power and fun that can be lacking when things are too predictable.

This is all, of course, in addition to the fact that variance introduces tension and excitement to dice rolls (if there's no risk of a meaningful failure, why are you rolling?), but that's generally better-understood intuitively and I rambled on long enough for today. Agency is also a different topic; variance can be controlled or uncontrolled, and that's about agency, not the variance itself.

System is Setting

This time, an opinion that not everyone might agree with. But I think it makes better games. System is setting.

What does 'system is setting' mean? All mechanics contribute to the experience of gameplay. A setting is implied by the system, and if the implied setting does not match the narrative setting, you end up with a disjointed experience. You can't play LoTR in 5E any more than you could play WoW in 1E. (Side note: You can play LoTR in 5E with Adventures in Middle-Earth, if you have a copy. But AiME makes significant systemic changes to make this possible. Which goes to my point; system is setting, and in order to make the setting work with LoTR, it was necessary to adapt the system.)

While I'm talking about this, this is something that @\cavegirl knows very well and talked about while designing Dungeon Bitches. It's on DTRPG now and you can go check it out. She designed mechanics of the game not just to create the desired gameplay experience, but to reinforce the themes and tell a story about the world at the same time.

So back to system is setting. All systems create an implied setting with what they put in the book, even if they don't have a specific setting. Some of this is place names and monsters and so on, some of it is mechanics. This was commonly seen in 3E, where people would use the demographics and magic shop tables from the DMG to create the setting of their world.

Another common example is when people try to play Star Wars in whatever system they like, often 5E currently, and it doesn't work at first. You can't just add mechanics and make the system Star Wars; you need to remove mechanics too. For Jedi to make sense and tell the same stories that they tell in SW, you can't just have space monks with laser swords. You need traditional spellcasting to not exist, you need armor and weapons to work differently, and you need the Dark Side to be a thing.

This is in part why generic systems almost always lead to kitchen-sink fantasy worlds. Again, something that we saw a lot of in 3E. As book after book was released and more and more options crowded their way into the world, whatever setting you started with became less distinct over time as it just continued to be the same kitchen sink as every other setting that had all these same elements in it.

5E was originally designed as a modular generic core where you'd add only what you needed for a given campaign, and you can still see an echo of this in the DMG in the section where it just has ~100 pages of optional rules. That would be a very flexible system, where you could just have your core resolution mechanics as reliable and then add in what you needed bit by bit.

But even then, something as generic as a core resolution mechanic of roll d20 + mods vs DC still implies things about the setting. It doesn't work for professionals doing professional tasks; a character with +5 vs a DC 10 (Routine) task has a 25% chance of failure! But a roofer, even a 1st level one, does not have a 25% failure rate per roof or per shingle. The d20 is designed to create that failure chance to generate interesting gameplay in the aspects that D&D focuses on, high-tension moments, and is not well-suited for reliable tasks in low-tension moments.

So we can see that even a mechanic as simple and generic as the d20 + mods vs TN still contributes to the implied setting and expectations of what the characters will be doing. Any mechanic that is generic enough to work for every possible setting is too generic to be interesting. Similarly, we can see the same kind of thing in a healing system; imagine a system where all characters are healed to full after every encounter, all resources recovered, everything is perfect. It would be impossible in this system to tell the story of a group of rag-tag adventurers getting beaten down over time but refusing to give in, because they're always at full resources!

The system influences and guides the kind of stories that the gameplay can tell. This is part of why I feel it is so important, when creating a system and making mechanical design choices, that you consider these questions. What kind of setting is implied by this mechanic? What kind of stories does this mechanic enable? What kind of stories does this mechanic make more difficult or impossible?

System is setting, and it's important and valuable to ensure that your system supports and enables the kind of stories that are core to your setting.

A Rule Is An Answer

As is eternal, there is discussion about RPG design theories, what is a rule, what is the purpose of a rule, etc.  I offer a definition that may be of some use, by looking at what might be the most fundamental way to define it (or, at least, the most fundamental way I can think of).

I don't think it's useful to try to say that all rules have the same purpose.  Obviously different rules, in different games, are designed for different things and for different reasons.  To actually get something universal, I think we need to go deeper, to a definition so obvious that it's almost useless on its own (but we can still use it in context to analyze things, and get use out of it when combining it that way).

So.  A game is made of rules.  Some of these rules are obviously game-rule types; a pawn can only move one space forward, while a rook can move any number of spaces in a straight line.  Other rules are less apparently part of the game, but are part of the game nonetheless; a Dungeon Master builds encounters following guidelines.  A player builds their player character and chooses their actions.  These are rules of a game as much as a rule about movement.

Combined, all the rules form the system or the game.  We're not debating whether or not the text on its own counts as a "game", we don't need that level of pedantry here right now.  Now that the game exists, the next question becomes; how does one play it?

Regardless of what the game is or what its rules are, you play the game by asking it questions, by interrogating it; what can I do, what can you do, what does this do, what's over there.  In TTRPGs, the process is the same whether you're trying to resolve a mechanical loop or if you're trying to explore the imagined world the game takes place in.  The way that those questions are resolved is by consulting the rules of the game.  A rule is an answer.

The most fundamental question to ask is "What happens next?"  and every game will be able to answer this.  Whether the answer is move to the next phase, roll some dice, ask someone at the table, end the game, or do something else, the game will provide an answer when you ask it what happens next.  As players (including GMs), your actions set up the context for the next question that the game is asked, and the rules provide the answer.

For example, a player says "I attack the guard".  This implies a question; what happens when you attack the guard?  The rules will answer that for you.  In another game, the player moves their pawn into a square containing an opposing piece; what happens next?  The rules answer.  Most TTRPGs have examples demonstrating that this is their core gameplay loop; the player declares an action, the GM consults the rules, and the GM says what happens next.  The rules are how the GM determines what happens next; they provide the answer to the player's implied (or explicit) question.

This is equally true for questions about the fictional world the game takes place in, such as "what's over that hill" or "what's in the chest".  The game will provide rules to determine that.  Depending on the game and what it cares about, these may be distinct rules, or they may be guidelines.  The way most RPGs are written, there's no real distinction between GM rules and GM guidelines, for the purpose of this discussion they're both rules.  The rule might be "the GM decides", "the GM rolls on a table", "the group determines by consensus", or anything else.  The point is that the rule is the answer.

Depending on what the rules care about, the answer might vary.  Some possible answers might be "You can't do that" (no, your bishop can't cast Meteor Swarm), "I don't care.  Three." (for things that the game doesn't really care about, it just gives you a quick answer and you move on), or "That's a great question!  Here's ten pages of charts to figure out the answer." (for things that the game wants to spend time understanding and resolving).  In some ways, this might cause the rules to abstract a complicated task.  Sometimes it might add complexity to something that seems like a simple task.  Sometimes the rules will restrict you with their answer, and sometimes they will empower you.  Most TTRPGs that lack a specific answer do have a general rule covering that situation, "Ask the GM/group", while most board games default to an answer of "You can't do that" if it's not covered by a rule.  (No, the Air Bud clause does not work in Monopoly.)  (The two types of games are more alike than most people think.  This general rule is the biggest difference between them.  The reason you can do anything in TTRPGs, and not in Monopoly, is because TTRPGs have a general rule that says if there's no rule that covers the situation, there's a person at the table empowered by the game rules to add a rule.  If Monopoly had Rule 0 for the banker, you could reinvent financial derivatives and sub-prime loans just like real banks!)

The only thing that every rule will always do is to answer you, when you ask the game a question.  To make this interpretation useful, we need to think about questions.  What we can do to use this is to think about what questions people will be asking our games, and what answer will we give?  How long will the answer take to understand and implement?  Do we really care about this question; is it really that important to have a good answer to it, or do we want to just pick something and move on?

(Generally, the less the game cares about a question, the more abstract and quick-to-resolve the answer will be.  If your game doesn't really care about traveling the wilderness, fine, make a single check for your journey.  If your game thinks this is an important and valuable question, provide a whole system for the experience.)

Appendix:  Semi-Related Rambling

Rulings over rules is a popular phrase these days (not quite as popular as it used to be, which is good).  It fits into this paradigm without any issues; it just means that it is not providing answers for many things, and answering those questions follows the default rule of ask the GM.  This is also totally consistent with the feedback that GMs of this game often give, which is that they feel like the game isn't helping them answer the questions that come up in play.  A rules-light game can avoid this problem by focusing the questions being asked.  If you only expect players to ask one or two questions in gameplay, then you only need one or two answers.  If you bill your game as an anything game that can do anything, you're going to need either some very broad answers or a whole lot of answers.  

This is where the importance of a game setting expectations comes in; these expectations can be set with prose, art, layout, and many more parts of a game.  If your game as a whole can get players to understand which questions to ask, and provide answers (in the form of rules) to those expected questions, it will generally be a smooth and understandable experience.  Conversely, if your game prompts players to ask questions that it doesn't provide answers for (again, in the form of rules), it will tend to be a frustrating experience that feels like it requires a lot of patching.

This was originally posted elsewhere but is being reposted here to pretend that content exists.  You're welcome.

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.