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.
![Roll (1d12) Event Name 1 The [Time] of the [Adjective] [Noun] 2 The [Noun] 3 The [Time] Without [Noun] 4 The [Time] of [Noun] 5 The [Adjective] [Time] [Noun] 6 The [Noun] of the [Adjective] [Time] 7 The [Noun] of [Noun] 8 The [Noun] [Time] 9 The [Noun] [Noun] 10 The [Adjective] [Noun] 11 The [Adjective] [Time] 12 The [Adjective] [Time] through [Noun]](https://blogger.googleusercontent.com/img/a/AVvXsEi-8F_6STdzeAw_cPM5smpclBtz6-zx8pRRz7H38mKHOLgF7KvCM3AtyhV69plNMnQ3loXO-ExiOszmFMv4_Iv2S5Jnng6eY6H6mHa0DXbDFZWRz4ghfyrbNkRqpzqmGopn8BcG0-s7N8iuxYwbvpGnfJu1Qq_mkbagEeoIWt6IWiXOjLULI8emZDhI-aTW=w423-h287 "Event Name Table (1d12)")
