Go to Part 1

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 3^rd 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.)

SETTING DIFFICULTY

There are basically two ways of assigning difficulty:

1. Look at a list of difficulties and assign the difficulty by either description or analogy.
2. 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 3^rd Edition terminology for them because that was the system where my thinking on this first crystallized. (Players of 4^th or 5^th 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 3^rd Edition:

SKILLED PROFESSIONALS

GENERIC DIFFICULTY CLASS

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 reliably 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.

Go to Part 6

Go to Part 1

We started by looking at how player declarations (or the lack of one in terms of passive observation) trigger the process of making a ruling. Then we broke that declaration down into intention, method, and initiation. Now we’re ready to move into the real meat of the rulings process: Resolution.

Resolution is the bridge between intention and outcome. In many ways, you can think of it as a test: The character’s intention is being tested and the result of that test is the outcome of the action. In the most basic terms, therefore, resolution determines whether the character succeeds or fails at their intention. (Although, as we’ll shortly discover, it’s not always that simple.)

DEFAULT TO YES

The easiest ruling for a GM to make is, “No.”

Player: I want to jump over the chasm.
GM: No.

Player: I want to convince the Duchess to support Lord Buckingham.
GM: She refuses to listen.

Player: I ask around town to see if there are any rumors of an ogre in the area.
GM You don’t find any.

When you use “no” everything is simple: There are no complications. No consequences. It’s clean, tidy, and definitive in its finality.

That makes it an incredibly useful tool. It’s also why you should basically never use it.

What you actually want to do is almost the exact opposite: Default to yes.

Player: I want to jump over the chasm.
GM: Okay, you’re on the other side.

Player: I want to convince the Duchess to support Lord Buckingham.
GM: She listens to your proposal and agrees to its merits.

Player: I ask around town to see if there are any rumors of an ogre in the area.
GM: Old Man Hob says that a farmer named Willis was complaining about an ogre killing his sheep last month.

“No” inherently stagnates the action. It leaves the situation unchanged. “Yes”, on the other hand, implicitly moves the action forward: It creates a new situation to which both you and the players will now be forced to respond. Now that they’re on the other side of the chasm, what will they do? How will Lord Buckingham respond to the Duchess’ unexpected support? Will the PCs hunt down Willis’ supposed ogre?

The other reason to default to yes is that, generally speaking, people succeed at most of the things they attempt. You want to drive downtown? Find some information by googling it? Book plane tickets to Cairo? Those are all things which are generally going to happen if you decide to do them.

YES, BUT…

The problem with always saying “yes”, however, is that it lacks challenge. It’s boring and it’s predictable. (It’s also not reflective of the way the world works: Failure, or potential failure, is part of life.)

This means that we need to add another tool to our repertoire: Yes, but…

Player: I want to jump over the chasm.
GM: You leap over the chasm, but as you land on the other side the floor collapses under your weight, sending you plunging down into an abyssal pit…

Player: I want to convince the Duchess to support Lord Buckingham.
GM: She listens with interest to your proposal and seems intrigued, but she wants you to promise that her ancestral rights to the Eastermark will be guaranteed.

Player: I ask around town to see if there are any rumours of an ogre in the area.
GM: Old Man Hob says that a farmer named Willis was complaining about an ogre killing his sheep last month. But as you’re speaking with him, you notice a shadowy figure watching from the corner of the tavern…

“Yes, but…” adds to the idea proposed by the player. It enriches the player’s contribution by making a contribution of your own. Unlike “no” it doesn’t negate. Unlike “yes” it isn’t predictable.

NO, BUT…

That all sounds great, right?

But what happens if what the players want contradicts the known facts of the game world? For example, they want rumors of an ogre, but you know there are no ogres in the area.

You may think that this will bring us back to “no”, but we’re not quite there yet. Generally speaking, the only time “no” is acceptable is if the intention directly contradicts the reality of the game world. So before we get back to “no”, we’re going to make a pit stop at No, but…

Player: Can I find a wizard’s guild?
GM: Yes.

Player: Can I find a wizard’s guild?
GM: Yes, but you’ll have to go to Greyhawk. There isn’t one in this town.

Player: Is there a wizard’s guild in this town?
GM: No, but there’s one in Greyhawk.

Player: Is there a wizard’s guild in town?
GM: In 1982 Berlin? No.

As you can see, No but… is in many ways just Yes, but… looked at from a slightly different angle. Where a clear distinction does exist is when the method by which the character is attempting to achieve their intention isn’t viable: “No, that won’t get you where you want to go. But here’s an alternate way you could achieve that.”

THE SPECTRUM OF GM FIAT

Collectively, let’s refer to this as the spectrum of GM fiat:

• Yes
• Yes, but…
• No, but…
• No

The reason we default to yes – i.e., default to the top of this spectrum and work our way down it – is because any requests being made by the players generally reflect things they want to do. When they say, “I want to do X,” what they’re saying is, “I would find it fun if I could do X.” And unless you’ve got a really, really good reason for prohibiting them from doing those things, it’s generally going to result in a better session if you can figure out (and offer them) a path by which they can do the things they want to do.

Sometimes they’ll reject that path. (“I don’t want to go to Greyhawk. It’s too far away.”) That’s OK. That means they’re prioritizing something else. But give ‘em the meaningful choice instead of taking it away. Choice is, after all, what roleplaying games are all about.

And one of the great strengths of Yes, but… is that it’s actually quite difficult to game the system:

Player: Can I build a nuclear bomb?
GM: Yes, but you’re going to need to figure out some way to get your hands on enriched uranium. And if the government figures out what you’re doing, the words “terrorist watch list” will be the least of your problems.

Sometimes, of course, you might be dealing with a troll player who keeps asking to fly to the Andromeda galaxy during your World War II campaign. But if that’s routinely happening, then you’ve got a problem that needs to be dealt with in ways that have nothing to do with action resolution.

If you’re really struggling to avoid No, another useful thing to remember is that a close cousin of Yes, but… is, “Tell me how you’re doing that.” Which is basically the same thing, except that you’re prompting the player to think of their own “but”.

Player: Can I build a nuclear bomb?
GM: Okay. Tell me how you’re doing that.
Player: Well… I’ll need to find a source of enriched uranium. Can I make a Contacts check to see if one of my old Russian buddies might have a hook-up on the black market?

This last exchange also points us in the direction of the exit ramp which will carry us away from the spectrum of GM fiat: “I’m not sure. Let’s find out.”

This is the point where both the GM and the player turn collectively towards fickle fortune (i.e. the game mechanics) to seek an answer. Of course, the GM’s role is not yet complete: If resolution is the process of testing the character’s intention, then this is where the GM designs the test.

Go to Part 5

Go to Part 1

Something to consider when it comes to declaring intention is the difference between a mechanics-first declaration and a fiction-first declaration.

A fiction-first declaration describes the intention in terms of the game world. After the fiction-first declaration has been made, a decision will be made (probably by the GM) about how to model that declaration mechanically. For example:

GM: The courtyard is filled with guards.
Player: Can I sneak around the perimeter of the courtyard? Stick to the shadows?
GM: Yes. Give me a Stealth check.

A mechanics-first declaration, on the other hand, states the mechanic the player wants to use. For example:

GM: The courtyard is filled with guards.
Player: Can I make a Stealth check to get past them?
GM: Yes. [after the check] You sneak around the perimeter of the courtyard, sticking to the shadows.

In my experience, a mechanics-first declaration usually results in the GM providing the fictional description (usually as part of the narration of outcome after the check has been resolved), but this isn’t always the case. You could just as easily see:

GM: The courtyard is filled with guards.
Player: Can I make a Stealth check to get past them? Maybe sneak around the perimeter of the courtyard?
GM: Sure. There are a lot of shadows. Give me the check.

If you’re still not clear on the distinction being drawn here, imagine a player who does not know the rules declaring actions for their character: They just tell the GM what they want their character to do and then the GM figures out what mechanic to use. Their declarations are, by necessity, fiction-first declarations.

Conversely, consider someone using a dissociated mechanic. For example, someone spending a Luck Point to re-roll a die. Their character doesn’t know what a Luck Point is, so the decision to use the Luck Point or not is, by necessity, purely mechanical and any declaration to use a Luck Point is automatically a mechanics-first declaration.

(One of the major disadvantages of dissociated mechanics is that they prevent or disadvantage fiction-first declarations. And their mechanics-first declarations aren’t roleplaying.)

Those distinctions are really clear, but the difference between fiction-first and mechanics-first declarations can get pretty muddy in practice. Generally speaking, the less abstract the mechanic is the muddier the distinction becomes. For example, when you say, “I attack him with my sword!” in most systems, you are making a statement which is simultaneously mechanical and fictional.

Things can also get muddy if the player is making their own fictional description of a mechanics-first declaration, but semantically swaps the verbal expression of their decision-making process. For example, this:

Player: I’m going to sneak around the perimeter of the courtyard and make a Stealth check to get past them.

Looks superficially like a fiction-first declaration because the “fiction bit” came first in the sentence. But, functionally speaking, it’s identical to:

Player: I’m going to make a Stealth check to get past them by sneaking around the perimeter of the courtyard.

That player is making a mechanical choice and declaring their intention to use that specific mechanic. (This is not to say, however, that a player can never make a fiction-first declaration and then be the person to suggest the appropriate mechanic to model that action. That’s why the distinction can get pretty muddy.)

ONE TRUE WAY

So which of these is the “wrong” way to do it?

Neither.

Occasionally you’ll get purists who think one approach or the other is the one-true-way of roleplaying games: The fiction-first purists will generally talk about how it’s more immersive or how a mechanics-first approach “isn’t really roleplaying.” The mechanics-first purists will talk about how a simple mechanical declaration is concise and clearer or get upset that the fiction-first purists have “forgotten the game part of roleplaying game.”

But while personal taste (of both the group and the individual players) will obviously have an impact on how intentions are declared at the table, the reality is that pretty much any game being played in the real world is going to see a mixture of fiction-first and mechanics-first declarations. It’s a pain in the ass to spend every single round trying to figure out whether the description of a particular sword thrust is a full attack, a standard action, or fighting defensively. And a roleplaying game that consisted of nothing except purely mechanical interactions would be bland as hell.

As for the claim that mechanics-first declarations aren’t “real” roleplaying, fuhgeddaboutit: With the exception of occasional dissociated mechanics like Luck Points or GM Intrusions, the mechanical decisions in a roleplaying game ARE roleplaying decisions. And if by “roleplaying” you just mean “speaking immersively and/or in character”, it’s also notable that mechanics-first approaches are also a prerequisite for fortune-at-the-beginning resolution techniques, which are frequently employed in order to create rich, challenging roleplaying-as-acting opportunities. (We’ll come back to that.)

As a final note, most of the problems I see people associate with mechanics-first declarations are actually the result of a missing method: If someone says, “I want to use Diplomacy to talk to Lady Veronica,” the problem isn’t that they invoked the name of a specific skill; it’s that they’ve failed to explain how they’re using it. Similarly, if someone says, “I want to attack the orc,” the correct response is, “What are you attacking with?”

MECHANICS-ONLY

The terms “mechanics-first” and “fiction-first” both inherently imply that the other half of the equation is following in the footsteps of the first: You do mechanics first, then fiction. You do fiction first, then mechanics. You take the mechanical model of the game world and you describe what the model tells you happens in that game world. Or you describe what’s happening in the game world and you model that mechanically. It’s a linked cycle.

Because it is part of this linked cycle, the mechanics-first approach should not be mistaken for another style of play which I’m going to call mechanics-only. In the mechanics-only approach, the link between the mechanics and the description of the game world is broken and the course of play becomes solely determined by the mechanics.

In reading that description, you may be thinking of something like this:

Player: I attack the orc. 22 to hit.
GM: You hit.
Player: 18 points of damage.
GM: The orc swings at you. Give me a defense roll.
Player: 12.
GM: The orc misses.

But while that might be an example of mechanics-only play, it isn’t necessarily so and isn’t what I’m talking about. In fact, I’ve found it quite difficult to find a way to clearly explain the mechanics-only approach in a way that people can understand it, because superficially it seems so similar to forms of play from which it is actually very, very different. This is particularly true because mechanics-only play will often feature rich and detailed descriptions of what’s happening in the game world… it’s just that those descriptions aren’t connected to the mechanics. (And it’s intriguing to note that the people who seem to struggle the most in understanding the distinction are the people actually engaged in mechanics-only play, largely because they don’t seem to realize that they’re doing something different from everyone else.)

Perhaps it will be clearer if I point out that mechanics-only play frequently shows up in board games: When playing games like Arkham Horror or Imperial Assault, people will often describe narrative details or even make a point of speaking in character. But none of that material is ever fed back into the mechanics of the game; it’s merely an improvisational layer that’s separated from the game like oil is separated from water.

For example, consider a game of Risk. You’ve got an army in Yakutsk and you’re invading Siberia. You give a rousing speech to your troops and then describe how you divide your army in a brilliant flanking action. Then you roll the dice… and none of that has any impact on the result. And it’s not just that the game lacks a morale mechanic or that its combat mechanics are so abstract that precise troop movements aren’t mechanically modeled – it’s that the improvisation (while undoubtedly entertaining) is fundamentally divided from the actual game play. They are both happening in the same space, but there is no connection. (Or, at best, the connection is unidirectional.)

On the flip-side of the coin, in mechanics-only play you’ll see mechanical actions allowed even when the given circumstances of the fiction should disallow them.

For example, consider a roleplaying game which has a Leg Sweep combat maneuver: It’s specifically and explicitly designed to model you sweeping someone’s legs out from underneath them. Now imagine someone fighting an Undulating Hulk: It doesn’t have any legs, but for the mechanics-only players that won’t matter. Nothing in the rules say you can’t use the Leg Sweep maneuver on the Undulating Hulk, so you can do so.

Maybe you’re thinking that this is just an example of the GM deciding that a particular mechanic (the Leg Sweep) is close enough to whatever effect the PC wants to have on the Undulating Hulk (delaying them for a Minor Action or whatever) so that they can use it as the basis for adjudicating the action. But that’s not what’s happening in mechanics-only play.

Imagine a spell that stops the target’s heart from beating and, thus, kills the target. Unless the explicit mechanics of that spell limited its potential target list, the mechanics-only player will allow it to be cast on a vampire, even though their heart is no longer beating in the first place. They’ll even allow it to be cast on an animated skeleton, despite the fact that the skeleton has no heart to be affected by the spell.

I generally try to avoid making one-true-way statements about how games are supposed to be played. The medium of roleplaying games is pretty flexible and, historically speaking, the best and most successful games have been those which have allowed multiple styles of play to come together at the same table (which is a testament to the breadth of experience that RPGs can provide). But when it comes to mechanics-only play, I’m comfortable saying that you are doing it wrong.

The net effect of mechanics-only play, when applied to a roleplaying game, is to needlessly turn associated mechanics into dissociated mechanics. As I’ve noted in the past, I don’t have an automatic objection to dissociated mechanics existing in an RPG, but those mechanics should bring some distinct benefit that would otherwise not be achievable. The mechanics-only approach has no discernible benefit. It’s not so much that you’re tossing the baby out with the bathwater, you’re just tossing the baby out.

It’s hard to say exactly how prevalent the mechanics-only style of play is. I haven’t encountered it much “in the wild,” so to speak, but online discussions of dissociated mechanics often attract these players. (Because mechanics-only players turn associated mechanics into dissociated mechanics, they can’t really comprehend how anyone else can see a distinction between them.)

I do have a sense that mechanics-only play may crop up more frequently in combat, even among players who don’t otherwise engage in it. This may even be a significant contribution to the common belief that there’s some sort of division between “combat” and “roleplaying”. (Which I’ve always had difficulty grokking, because life-or-death stakes should be a crucible of character development. It shouldn’t be a place where characters get turned off.)

(What about fiction-only? That’s playing “let’s pretend” without any mechanical structure. It tends not to crop up in roleplaying games because it inherently doesn’t require the game, although you can see certain tendencies towards it in some types of dice-fudging or groups that simply ignore particular types of mechanics.)

Go to Part 4

Go to Part 1

The player says, “I want to do X.”

This is the moment at which the GM must make a ruling. It’s the moment in which they must decide what the result of the player character doing X will be. And, at a very fundamental level, this is what a roleplaying game is all about: Any given session of play can basically be defined by the sequence of these interactions.

In the previous installment we talked about how player expertise activates character expertise (i.e., a player must say that their character is doing something before the character does it) and also how player expertise can trump character expertise (i.e., you don’t need to mechanically determine whether a character makes a particular choice if the player has already explicitly made that choice).

Keeping that general philosophy in mind, we’re now going to look at the Art of Rulings from a slightly different angle by breaking the ruling down into three concrete steps:

1. The player states their intention.
2. The action being attempted is resolved.
3. The outcome of the action is narrated.

At face value, these seem pretty simple: The player says they want to hit someone with a sword. You make an attack roll to determine whether or not they do. Based on the mechanical resolution, you say whether or not they hit them.

In practice, though, things can get a lot more complicated than that. And you’ll find that there are more than a few pitfalls along the way.

ARE YOU SURE YOU WANT TO DO THAT?

It’s become something of a cliché:

Player: I jump down to the ground.
GM: Are you sure you want to do that?

Here’s the thing: If your players are suggesting something which is self-evidently suicidal to the GM, then there has probably been some sort of miscommunication. Simple example—

Player: I jump down to the ground.
GM: Okay. You fall 200 feet, take 20d6 points of damage, and die.
Player: What? I thought the building was only 20 feet high!

That being said, I’m not a big fan of the coy, “Are you sure you want to do that?” method. While it may warn the player away from some course of action, it’s unlikely to actually clear up the underlying confusion.

It’s generally preferable to actually explain your understanding of the stakes to the player to make sure everyone is on the same page. For example—

Player: I jump down to the ground.
GM: The building is 200 feet tall. You’ll take 20d6 points of damage if you do that.
Player: Ah. Right. Well, let’s try something else then.

Although the misunderstanding can just as easily be on the GM’s side—

Player: I jump down to the ground.
GM: Are you sure you want to do that?
Player: What? Is it covered in lava or something?
GM: No, but the building is 200 feet tall. You’ll take 20d6 points of damage if you do that.
Player: I’m planning to cast feather fall. I just want the princess to think I’ve committed suicide.
GM: Carry on.

This carries beyond deadly situations. For example, if you’re running a mystery scenario and one of the players says, “I inspect the carpet.” and you don’t know why they want to inspect the carpet, just ask them.

Player: I inspect the carpet.
GM: What are you looking for?
Player: You said it rained last night at 2 AM. If the killer entered through the window after 2 AM, there would be mud on the carpet.
GM (knowing the murder took place at 4 AM): Yup. It looks like somebody tried to clean it up, but you find some mud scraped onto the molding near the window.

If you don’t ask the question and you don’t understand what they’re looking for, you might end up feeding them false (or at least misleading) information.

Which suggests a general principle:

If you don’t understand what the players are trying to achieve with a given action, find out before adjudicating the action.

INTENTION IS NOT INITIATION

It also suggests something else: Intention is not initiation.

In the excitement of the moment, we often use strong declarative statements at the gaming table: “I jump off the roof!” or “I stab him with my sword!”

It’s certainly possible to interpret such statements as irrevocable (and there are some inexperienced GMs who do), but as we’ve just seen that frequently results in unsatisfying results. It’s better to understand those statements for what they really are: “I am intending to jump off the roof.” or “I want to stab him with my sword.”

With that being said, there obviously is a point of transition beyond which the player can’t “take back” their action: It’s the point at which we begin to resolve the intended action. That tipping point is where the action is actually initiated.

Intention should also not be mistaken for outcome. For example, if a player says, “I want to stab him through the chest with my sword!” that is not necessarily what will happen. It’s not even necessarily what will happen with a successful attack roll. For example, the player might succeed on their attack roll (successfully striking their target), only for the halfling’s shirt to be ripped aside revealing a shirt of mithril. (Or, alternatively, maybe their damage roll just isn’t high enough to support the outcome of their sword passing through the target’s chest cavity. We’ll come back to this.)

Of course, in practice the divisions between intention, initiation, resolution, and outcome will frequently collapse at the table. For example, if a player says something like, “I tell Lady Gwendolyn that she is the most beautiful maiden I have ever seen.” then, in practice, that simply happens. Similarly, “I walk across the room” usually has the automatic result of that happening – intention, initiation, and resolution are simultaneous, and outcome is almost simultaneous because the next words spoken are likely to be some variation of, “You are now on the other side of the room.”

Obviously, this is good for the flow of gameplay. You don’t have to (nor should you) pause and break the interaction down into its constituent parts every single time. But keeping in mind that these are, in fact, separate steps will be useful whenever the matter becomes contentious or confused and troubleshooting is required.

SINGLE-STEP vs. MULTI-STEP INTENTIONS

Something else to note is that single-step intentions are usually pretty easy to figure out: “I want to stab him with my sword!” is fairly self-explanatory.

But some things that look like single-step intentions actually aren’t. For example, if a player says, “I want to jump up on the crates!” then the single-step intention is “get on top of the crates”. That’s easy. But the actual goal of getting on top of the crates might be to have a better angle for shooting the bad guys. If that’s true, great. If it’s not true, though, then it might be another full round before you discover the misunderstanding. (And by that time, of course, it’s far too late to fix it.)

Ultimately, this takes us back to our general principle (understand why the players are trying to do something before adjudicating the action). It just means that you need to understand things on the macro-level, not just the micro-level. (And, in fact, it is these macro-level misunderstandings which can wreak far more havoc on a game, specifically because it’s possible to invest so many resources into them before realizing the problem.)

UNDERSTANDING THE PLAYER’S METHOD

Understanding intention, however, isn’t enough. You also need to know what method is being used to achieve that intention.

Intention and method are things that, once again, often get conflated in practice, usually because people naturally jump straight to method. “I want to stab him with my sword!” is a method which is hiding the generic intention of, “I want to hurt him!” (And, in fact, I’m generally going to discuss intention and method as if they are the same thing, because most of the time they are.)

Every so often, though, a lack of method can become a problem. This usually happens at a macro-level, and I find it most frequently crops up with social interactions: “I want to seduce the Princess.” or “I convince him to give us the troops we need.” are statements of intention, but they notably lack any method for achieving those intentions. One could similarly imagine someone saying, “I want to get to the other side of the wall” or “I want him dead!”

If we assume that player expertise activates character expertise, then another way of looking at this problem is that the player hasn’t given you enough specificity to activate their character’s expertise yet.

Fortunately, the solution to this problem is pretty easy: “How do you do that?”

That generally takes care of it. You may occasionally run into players who just want to “throw a mechanic at it.” These are problematic because (a) they often require you to frequently demand additional details and (b) they often believe that “I use Diplomacy to seduce her” or “I use Dungeoneering to get to the other side” are actually meaningful responses to the question. At that point, you just need to start pushing for specific details: How do you greet her? What do you say to her? When she says such-and-such, how do you respond?

It should be noted that this is one of the reasons why it’s the ART of rulings and not the SCIENCE of rulings. There is a sweet spot at which the method has been detailed sufficiently for the player’s expertise to activate the character’s expertise. That sweet spot depends on you, on your players, on the system, and on the immediate circumstances of the game session

For example, imagine that the PCs are police detectives and they walk into a room that has a corpse lying in the middle of it. The intentions in this scene will most likely take the form of questions they want answered. But how specific do the questions need to be before the GM can make a ruling on whether not they can find an answer?

For most groups simply asking, “Who did it?” is probably too broad. (We could imagine someone asking that question and the GM simply telling them to make a Detective skill check to figure it out, but that’s probably not how it’s going to work 99.99% of the time.) At the other end of the scale, though, “I want to examine the body to determine a time of death.” is almost certainly specific enough. (We could imagine a GM demanding that a player specify that they’re checking the corpse’s lividity before they’ll even consider providing an answer, but that’s similarly unlikely.)

Inbetween these extremes, however, there’s a lot of room for personal preference. Nor is it a purely linear scale. For example, is “I search the room for clues,” specific enough? It’s a concrete action which, in most systems, can be associated to a fairly obvious skill check. But would you rather know exactly what they’re looking for or how they’re looking for it? Alternatively, what if someone says, “I want to figure out how they were killed.”? That’s more specific in intention, but vaguer when it comes to method. Are they examining the body? Searching the room for physical traces? Checking security footage?

FINDING THE SWEET SPOT

There’s no “right” answer here, but what’s right for you will generally be pretty intuitive.

My recommendation is that the GM should set a relatively low threshold of “that’s enough specificity to make a ruling.” If the players want to give you more specificity than that – if there are more detailed choices that they feel are meaningful to the situation or to their character – then they’re free to make those choices.

So if the PCs encounter a chest in the dungeon, their typical response might be, “I search it for traps.” And the GM can say, “Okay, that’s enough specificity. Roll a Search check.” But later on there might be another chest that they’re feeling particularly paranoid about, and so they say, “I’m going to start very carefully checking the floor around and under the chest for pressure plates” or “I’m doing a thorough visual inspection of the chest before I even touch it.” And the GM can respond to that by incorporating those additional details into their ruling. (Player expertise trumps character expertise.)

The reason this works is because the players can be assumed to provide the amount of detail that they’re currently interested in. And as long as that amount of detail is enough for the GM to feel like they can make a ruling, the result is automatically calibrated to whatever the table collectively feels is appropriate in that specific moment. (Later, in some other moment, their preference may be different. But that moment will also auto-calibrate itself without you needing to really think about it.)

INITIATION

Once you have a sufficient understanding of intention and method, it’s time to move on to the actual resolution of the action. That transition is the point of initiation, and past that point the player (and their character) has committed to it. They can’t go back and make a different decision.

This “point of no return” is fairly obvious for a sword swing: You can’t decide to take a different action after you’ve seen that your attack roll has failed. But in other circumstances it can get a little muddled. For example, if you were playing with a battlemap and someone said, “I move to this square. No, wait, I actually want to move to this square,” is that okay? Probably.

But what if they “finish” their move, take their first action, and begin discussing their intention for their second action, only to realize that they should actually have moved to a different square in order for their second action to work to best effect? Or what if, as they move out into the hallway, an ogre takes a readied action to shoot at them, and then they say, “Actually, I think I would have stayed in cover”?

My general rule of thumb is that if

(a) New information has been introduced as a result of the action; or
(b) Someone else has taken an action

then we’ve passed the point of no return.

Your mileage may vary, and in practice there’s probably still going to be a lot of situational fuzziness. Generally, that’s not a problem. But if you’re running into frequent disagreements about this with a particular group, then it may be valuable to call specific attention to the initiation point and set a clear standard.

Go to Part 3

In response to the Update from the Crypt of Luan Phien, Poe asked me:

Out of curiosity, do you rely solely on the players’ expertise when developing maps or do you use some form of skill checks to indicate a character’s expertise in determining what’s going on with an unusual map situation like this one?

In the case of that particular map, it was primarily player expertise that crunched out the workings of the crypt. But Poe’s question got me thinking about the wider question of how GMs make rulings while running a roleplaying game.

First, I prefer to use systems which offer broad mechanical support for GM rulings. Some people prefer pure GM fiat, but I like having a mechanical base to make rulings from because:

1. It allows me to make a ruling of uncertainty. (Instead of saying “that definitely happens” or “that definitely doesn’t happen”, I can say, “That sounds likely, let’s see if it happens.”)
2. It allows for varying character capacity to have a meaningful impact on events.
3. It can provide guidance when I’m not certain how to rule.
4. The mechanical outcome is an improv opportunity, often spurring me to create things which I would not have created otherwise.
5. It provides a consistency to similar rulings over time.

And so forth. In general, badly designed rules act as unreasonable straitjackets. Good rules, on the other hand, enable new forms of play and expand the scope of the game.

With all that being said, my general approach to making rulings as a GM basically looks like this:

1. Passive observation of the world is automatically triggered.
2. Player expertise activates character expertise.
3. Player expertise can trump character expertise.

PASSIVE OBSERVATION IS AUTOMATICALLY TRIGGERED

Passive observation may include stuff that’s obvious to everybody (like walking into a room with a giant ball of flame hovering in the middle of it), but it might also include reactive mechanics for determining whether or not characters notice something that isn’t automatically apparent. In OD&D this would include surprise tests. In D&D 3rd Edition, this would include Listen, Spot, and Knowledge checks (although these skills can also be used in non-reactive ways.)

(Why am I including Knowledge skills here? Imagine that the characters walk into a room with a large heraldic shield painted on the wall. Do the characters recognize that as the archaic heraldry of King Negut III of Yrkathia? If they do, the players shouldn’t have to ask if they recognize it — they just recognize it.)

But now we get to the real heart of the matter. This is where a player says, “I want to do X.” And you need to make a ruling about how to resolve the outcome of X.

PLAYER EXPERTISE ACTIVATES CHARACTER EXPERTISE

What I mean by this is that the characters don’t play themselves. With the exception of purely passive observation of the game world, players have to call for an action which requires a skill check in order for the skill to be activated.

If we consider a simple example, like:

Player: I check the chest for traps.

GM: Make a Search check.

This may seem self-evident to most of us. On the other hand, I have seen games where GMs will respond to “I open the chest” by calling for the Search check. You may have also heard players say things like, “My character is a 12th level rogue. She would have known better than to open a chest without checking it for traps first!”

I can see the potential legitimacy of the philosophical question being raised. Regardless of which approach we take, there is a point at which the player’s control of the character seems to stop. Consider that simple Search check again: The player decides to check the chest for traps, but then we’re allowing the mechanics to determine how, based on the character’s expertise, that search happens. But could we not, with equal validity, say that when the player decides to open the chest, we should allow the mechanics to determine how, based on the character’s expertise, that happens?

In general, however, I would point out that an integral part of roleplaying is, in fact, playing your role — i.e., making choices as if you were your character. When you turn meaningful choices over to the game mechanics instead of making them yourself, I would argue that you are no longer roleplaying.

Of course, on the other end of the spectrum you have a variety of pixel-bitching. Here you’re never allowed to turn the resolution of an action over to your character and searching the chest becomes a litany of detail:

Player: I check the chest for traps.
GM: How do you do that?
Player: I check under the chest for a pressure plate.
GM: How do you do that?
Player: I run my fingers around the perimeter, looking for any edges. Then I’ll pour some water around to see if it sinks into any sort of depression. Then I’ll very carefully lift one corner of the chest just high enough that I can slide a piece of parchment under there and see if it strikes any sort of spring-loaded trigger that’s rising with the chest.

(Or, if you’re playing with GM bastardy: “I check under the chest for a pressure plate.” “You lift the chest to look, triggering the pressure plate!”)

There is certainly some art in figuring out where the “sweet spot” is for activating the character’s expertise. But 99 times out of 100 it’s going to be fairly self-evident. When in doubt, look for the meaningful choice. Or, rather, never assume that a character is doing anything which requires a meaningful choice unless the player makes that choice.

PLAYER EXPERTISE CAN TRUMP CHARACTER EXPERTISE

On the other hand, you also don’t want to negate meaningful choices by insisting that certain actions must be handed off to the character’s expertise. That’s why I say that player expertise can trump character expertise.

Sticking with our chest-searching motif, consider a scenario in which there is a hidden compartment in a chest which can be accessed by lifting out the bottom of the chest. We’ve determined that the hidden compartment requires a DC 17 Search check to discover. The player says:

• “I search the chest.”
• “I check the bottom of the chest for hidden compartments.”
• “I take my axe and smash open the bottom of the chest.”
• “I check the chest for traps before opening it.”
• “I check the lid of the chest for hidden compartments”.

The first example is vanilla. You’ve handed the resolution over to the mechanic and you get a flat Search check against the DC of the hidden compartment. A success could generate a number of different responses (ranging from “yup, there’s a hidden compartment” to “you notice that the exterior of the chest is several inches deeper than the interior of the chest“).

The second example is more specific (and happens to coincide with what’s actually there to be found). I would tend to grant some kind of bonus to the Search. If there were other things to be found in the chest, I might also allow the Search check to find them (but since you’re specifically looking for something else, such a check might have a penalty applied to it).

In the third example you’ve taken an action which would automatically find the compartment. No Search check is required. (Player skill has completely trumped the mechanic.)

The fourth and fifth examples demonstrate that trumping character skill isn’t always a good thing. In the fourth example, you have no chance of finding things hidden inside the chest if you’re limiting your search to the exterior. Similarly, in the fifth example you’re specifically looking in the wrong place.

As another example, consider a hallway with a pit trap in it. The pit trap has a 50% chance of activating whenever someone steps on it and it requires a DC 17 Search check to find it. The player says:

• “I search the hall for traps.”
• “I proceed carefully down the hall, tapping ahead of me with my 10-foot pole.”
• “I summon a celestial badger and have it walk down the hall in front of me.”
• “I pour a waterskin onto the floor to see if it runs down any seams or gaps.”

The first example is, once again, a straight forward Search check. The second and third examples bypass the Search mechanics, and instead grant a 50% chance that the pole or summoned creature will trigger the trap.

The fourth example, on the other hand, could be handled in several ways. One could easily rule that such a technique would automatically find the trap (particularly if the player specifies exactly which section of corridor they’re checking). If not, I’d probably at least grant a hefty bonus (say, +10) to the Search check for using an appropriate technique.

In many ways, this comes back to meaningful choice: We assumed before that characters don’t take actions which require meaningful choice unless the player makes that choice. Here we assume that any choice the player makes is probably meaningful and take the specificity of those choices into account when we make our ruling.

THE CRYPT OF LUAN PHIEN – AN EXAMPLE FROM REAL PLAY

Let’s consider the specific example of mapping the Crypt of Luan Phien, a segmented dungeon in which each section periodically rotates independently in order to change the layout of the dungeon.

At the high end, we can imagine a player saying, “I make a Knowledge (dungeoneering) check to make a map of the dungeon.” To which my answer would be, “No.” (They’ve failed to achieve the necessary specificity to activate their character’s expertise.)

In actual play, the mapping of the dungeon was solved almost entirely through player expertise. They simply observed which rooms connected to each other and slowly built up an understanding of the possible configurations of the dungeon. (The sole exception would be late in the process, when they started checking corridors to find the wall seams which would confirm their understanding of where the breaks between segments lay.)

But I can think of several ways that they could have activated their character’s skills:

• Check the curvature of the stone walls that periodically blocked various hallways in order to determine (at least roughly) the circular diameter of each section.
• Try to determine the direction in which each section was rotating.
• Try to figure out how much stone would slide past an open corridor between sections in order to determine how far each section was rotating.
• Use a compass or spell to determine orientation before and after a shift.

And so forth.

Go to Part 2

THE ART OF RULINGS
Part 2: Intention and Method
Part 3: The Fiction-Mechanics Cycle
Part 4: Default to Yes
Part 5: Skill and Difficulty
Part 6: Fictional Cleromancy
Part 7: Vectors
Part 8: Let It Ride
Part 9: Narrating Outcomes
Part 10: Fortune Positioning
Part 11: Narrative vs. Action Resolution
Part 12: Hidden vs. Open Difficulty Numbers
Part 13: Hidden vs. Open Stakes
Part 14: Group Actions
Part 15: Making Plans

Addendum: Let It Ride on the Death Star

Rulings in Practice: Gathering Information
Rulings in Practice: Perception-Type Tests
Rulings in Practice: Social Skills
Rulings in Practice: Sanity Checks
Rulings in Practice: Traps

FURTHER READING
The Art of Pacing
The Art of the Key
Gamemastery 101