The act of turning to the game mechanics is, ultimately, an assessment that there is variability in the potential outcome of an action. At the simplest level, we are saying that there is a chance the intention will succeed and a chance that it will fail.
Before we pick up the dice, however, we should take a moment to consider the potential failure state: Failure should be interesting, meaningful, or both. If it is neither, then you shouldn’t be rolling the dice. The clearest example of this is when the response to failure is to simply try it again:
Player: I try to pick the lock.
GM: You fail. What do you do?
Player: I try to pick the lock again.
GM: You fail. What do you do?
Player: I try to pick the lock again.
This is the gatekeeper of mechanical resolution. If the gate is locked (i.e., failure is neither interesting nor meaningful) then you should go back to the spectrum of GM fiat and remember to default to yes.
(It’s equally true that success should be interesting, meaningful, or both. But this generally takes care of itself because the players are not going to propose actions they are not interested in achieving.)
A common mistake GMs make, however, is to think that expending resources is automatically meaningful. For example, the most basic resource that one can expend is time. So they’ll look at the lockpicking example above and conclude that the failed checks are meaningful because they chew up time. However, this lost time only becomes truly meaningful it has consequences (i.e., wandering monsters, time ticking down towards a deadline, enemies on the other side of the door having more time to prepare, etc.).
The actual process by which an action check is made is obviously dependent on the game system you’re using. I’m not going to attempt a complete survey here, but what this usually boils down to is identifying the skill and setting a difficulty.
IDENTIFYING THE SKILL
Identifying which skill to use is pretty straightforward: Each skill will have a description which defines its parameters. You simply need to figure out which skill’s parameters the proposed action fits, and this is usually obvious.
In some cases, you’ll find that the proposed action can fall into the purview of multiple skills. Generally speaking, you can just let the character use whichever skill is better for them. The exception is if you feel that one of the skills is less related to the task at hand than the other: Systems vary in how they handle this, but allowing the check to be made with the alternative skill at a slight penalty is usually a good one-size-fits-all solution. (Another option is to allow a skill check using the alternative skill to grant a bonus to the primary skill. Or, as in D&D 3rd Edition, allowing the character’s expertise in the secondary skill to simply provide a synergy bonus without any check.)
My personal preference is for systems that don’t have a lot of overlap in their skill descriptions. Some overlap is basically unavoidable, but being able to clearly call for a specific check generally streamlines the action resolution process by eliminating the back-and-forth of figuring out whether or not a particular skill would apply to this particular check. This is also why overlapping skills that are frequently used “in the blind” – like a Spot check to notice ambushers – are a particular pain in the ass: Since the player doesn’t know exactly what the check is being made for, they can’t let the GM know if they have an alternative skill they could be using: The GM calls for a Spot Tusked Animal check to notice the brain-eating walrus, but it turns out that the character actually has Spot Carnivorous Sea Mammals at a higher rating.
(Not an actual game. But it should be.)
Not all games have skills, of course. In most of those cases, however, you’ll generally follow the same basic procedure using attributes instead. (In many systems, skills and attributes are actually the exact same thing using different names: You take a single “this is how good I am at doing things” number and you want more detail, so you split it into a half dozen attributes. But then you still want more detail, so you split each attribute into a half dozen skills. It’s only when you get systems that freely pair skills with multiple attributes that the mechanic actually shifts. But I digress.)
There are basically two ways of assigning difficulty:
- Look at a list of difficulties and assign the difficulty by either description or analogy.
- Start with a “default” difficulty and adjust it by considering the factors that modify that difficulty.
Some systems lend themselves more readily to one approach or the other. For example, D20 systems lend themselves to assigned difficulties and include difficulty tables that say things like, “A Hard task is DC 20.” or “A Formidable task is DC 25.” Call of Cthulhu, on the other hand, lends itself to adjusted difficulties by setting the default target number to the character’s skill rating so that the GM adjusts difficulty by applying a modifier to the rating.
Regardless of the system, however, you can use either technique. (And, in practice, you are likely to use combinations of both.) For example, when running D&D you could easily start with a default difficulty of DC 15 and then say, “Okay, it’s been raining and the rocks are slick, so let’s bump that up to DC 18.”
TAKE 1 / TAKE 10 / TAKE 20
When considering difficulty, there are three additional metrics I find useful. I’m going to use D&D 3rd Edition terminology for them because that was the system where my thinking on this first crystallized. (Players of 4th or 5th Edition may find this confusing because the designers made a really weird decision regarding the handling of “passive” checks such that the description of the mechanics don’t match the mathematics of the mechanics. You’ll just have to suck it up, because I’m not going to try to jump through the broken hoops of poor mechanical design.)
TAKE 20: When you Take 20 in D&D, the result is calculated as if you had rolled a natural 20 on a d20. In other words, it’s the best possible success that the character is capable of achieving. It’s used in situations like our lockpicking example: The character is free to repeatedly attempt the task until they succeed, which means that we can just check the Take 20 to see if it’s a success or not.
TAKE 10: You can Take 10 in D&D when you’re not under any pressure. It’s the average result possible if you were rolling the dice, but the mechanic basically says “this is the level of success the character can achieve if they’re not under pressure or pushing themselves”.
TAKE 1: This concept is not labeled as such in D&D, but it flows naturally out of the mechanic. If you Take 1 on your roll, then it’s the worst result the character can have. If the difficulty of the task is equal to or less than the character’s Take 1, then the character will automatically succeed on that task.
Basically, these concepts break tasks down into three states: What characters succeed at without evening trying (Take 1). What they always succeed at if they make the effort (Take 10). And what they will eventually succeed at if given enough time (Take 20).
(For example, imagine that there’s something hidden in a room that requires a DC 25 Search check to find. A character with Search +5 will always find the item if they take the time to ransack the room. A character with Search +15 will find the item if they just quickly poke around the room. And a character with Search +25 will notice the item just by walking through the room.)
These concepts are generally useful in D&D (and other systems) for streamlining action resolution. But they can be specifically useful when setting difficulty by considering the type of person who would be attempting such actions and then using them as the analogy.
For example, I constructed these tables for D&D 3rd Edition:
|Skill Bonus||Level of Training|
|-1 or worse||Untalented|
GENERIC DIFFICULTY CLASS
|DC||Task||Take 10 Training||Take 20 Training|
|40||Nearly Impossible||Mythic Mastery||Grand Master|
TAKE 10 TRAINING: Ask yourself, “How much training would it take for someone to be able to succeed at this task as a matter of routine?” Find that level of training on the table and then add 10 to determine the DC of the check (as summarized on the Generic Difficulty Class table).
Example: Even someone without any training in pottery should be able to make a simple, crude bowl if they’re shown how the equipment works, so making such a bowl should only require a DC 10 check (0 + 10 = 10). On the other hand, it takes some training before someone should be able to perform a backflip, so performing a backflip might take a DC 12 check (2 + 10 = 12).
TAKE 20 TRAINING: When dealing with particularly difficult tasks the question to ask is, “How much training would a person need in order to even have a chance to succeed at this task?” Find that level of training on the table and then add 20 to determine the DC of the check.
Example: An average person can’t just pick up a paperclip and pick an average lock. It takes training. So opening an average lock should be a DC 25 check (5 + 20 = 25).
Even if you’re not performing this mental calculation in the moment, this can still be a good exercise to familiarize yourself with what different difficulty numbers really mean in a new system. (I find these techniques particularly useful if you’re trying to calibrate difficulty ratings for characters outside of the human norm.)
But don’t use the character as their own analogy! Setting difficulty by looking at the stats of the character attempting the action and then calculating what you want the percentage of success to be is a pernicious practice. It can seem like a good idea because you’re gauging what an “appropriate” challenge would be for them, but the end result is to basically negate the entire point of having mechanics in the first place.
Some systems – like D&D or Numenera – lend themselves easily to this kind of analysis. Other systems, however, will obfuscate it. This is often true of dice pool systems. For example, the 2d20 System we use in the Infinity RPG uses a base dice pool of 2d20 which can be expanded through various mechanics up to a maximum pool of 5d20. The target number you’re trying to roll equal to or less than for a success is determined by the character’s skill rating, and the difficulty of the task is rated in the number of successes you need to roll: No matter how skilled you are, there’s no minimum level of guaranteed success. Nor, because of how the ancillary mechanics are designed, is there really a cap on the maximum success you could theoretically achieve.
You could still crank through a bunch of math and get some decent guidelines for dice pool systems like this, but in general you’re probably better off accepting the nature of the beast and using the adjust-from-default method of setting difficulty.
The 2d20 System largely sidesteps these issues, actually, because it doesn’t rely on the GM setting difficulty levels: At least 95% of the time the GM is basically deciding whether the task is of Average (1) difficulty or Challenging (2) difficulty. (Difficulty ratings of 3, 4, and 5 also exist, but are extremely rare in their application.) This is because the system is far less interested in the simple binary of passing or failing the check, and is instead intensely interested in the margin of success the character is achieving.
Which is exactly what we’re going to be discussing next.