The Alexandrian

Posts tagged ‘art of rulings’

Go to Part 1

Banksy - Surveillance Team

It is surprisingly easy to mess up the resolution of group actions. (In no small part because so many games include group resolution mechanics that are flawed. Or don’t offer a group resolution mechanic at all.)

The primary problem is skewed probabilities. The classic example of this is a group of five PCs trying to sneak past a guard. The GM looks at the standard mechanics for this sort of thing and, with logic seemingly on their side, has each PC make a Stealth test.

Say that these PCs are pretty good at stealth, so they each have a 70% chance of passing the test. “Since they’re all pretty good at this,” the GM thinks, “they’ll have a pretty good chance of sneaking past this guy.” But, in reality, they don’t. Because the failure of any single character is a de facto failure for the entire group, they now only have a 17% chance of successfully sneaking past the guard.

This categorical error happens because our brains do not intuitively grasp probabilities. So we set up a stack of “pretty good odds” and fail to realize that, collectively, a string of uninterrupted successes is still incredibly unlikely to happen.

This gets even worse if five PCs are trying to sneak past a group of five NPCs. In 3rd Edition D&D, for example, this effectively becomes a check in which the PCs are rolling 5d20 and keeping the lowest result while the NPCs are rolling 5d20 and keeping the highest result. The average roll of 5d20-keep-lowest is 3. The average of 5d20-keep-highest is 17. That 14 point differential means that it’s virtually impossible for a part of characters to sneak past a group of evenly matched opponents.

(The odds are actually even worse than that in 3rd Edition, because virtually all stealth attempts will require both a Move Silently and a Hide check.)

The argument can certainly be made that this is realistic in some sense: A large group should have a tougher time sneaking past a sentry than one guy and more eyes means more people who can spot you. But I would argue that the probability skew is large enough that it creates results which are both unrealistic and undesirable.

In the case of stealth, for example, the effects of the skew are obvious: Since it’s virtually impossible for them to succeed, group stealth attempts quickly drop out of the game. When stealth is called for, it takes the form of a sole scout pushing out ahead of the rest of the group. And when the scout becomes too fragile to survive when the check finally fails, stealth stops being a part of the game altogether.


When dealing with a group action, the first thing a GM must determine is what type of group action they’re dealing with. In general, I find this breaks down into four categories:

(a) Everybody is performing individually and succeeds or fails individually.

(b) Everyone is attempting the same task, but as long as one of them succeeds it’ll be fine.

(c) Everyone is working together to accomplish a single action collectively.

(d) Everyone is working together / assisting each other, but everyone still needs to accomplish the action (i.e. succeed).

Consider a Climb check, for example:

  • Everyone starts climbing the wall independently.
  • Bob tries to climb up and grab the idol. Then Nancy does. (Or maybe they’re both trying at the same time, but as long as one of them gets the idol, the idol has been gotten.)
  • People lower a rope and help pull someone up. (Limited by the number of additional people you think pulling on the rope will meaningfully help.)
  • Everyone is belayed together and assisting each other in scaling the mountain.

Or a Stealth check:

  • Each person tries to sneak past a guard one at a time.
  • Everyone simultaneously tries to infiltrate the room with The Button in it from radically different directions, so that even if one of them gets discovered (i.e. fails the check) the others are unaffected by it. (This is somewhat contrived, but I can’t actually think of a non-contrived example of a Stealth check where members of the group can fail as long as one member succeeds.)
  • Steve distracts the guard by showing him a nudie mag while Gwen sneaks past him.
  • Aragorn leads the hobbits through the dark wood, working to keep the whole group concealed from the roving Nazgul.


Everybody is performing individually and succeeds or fails individually.

The first type is not, in fact, a group action. It is many simultaneously individual actions which, although they are identical to each other, are each seeking to accomplish a separate goal.

When resolving “group” actions of this type, use the normal process you use for resolving individual actions.

Here’s a relatively clear cut example: The group needs to make six porcelain dishes. There are six PCs, so each of them makes a Craft check in order to make a single porcelain dish. If they all succeed, then each of them has separately created a porcelain dish and, as a result, they have created a total of six porcelain dishes.

Despite these types of actions not actually being a group action at all, this is the form of group action resolution that most GMs seem to default to. I think this is a combination of most systems (notably those most GMs start out with) not featuring an explicit mechanics for other types of group actions, and the fact that it’s also frequently the easiest resolution method. (It’s really easy to simply say, “Everybody give me an Athletics test.” And it’s also really easy to use the resolution mechanics for individual actions because those are, generally speaking, the simplest mechanics and the default mechanics in any roleplaying game.)

Basically my whole point here is that rather than defaulting to this form of resolution, I think most GMs would benefit from thinking of this as the last resort when it comes to resolving group actions. In other words, make sure that it’s not a group action before defaulting back to simultaneous-individual resolution.

But if you’re looking for a general rule of thumb on when it’s “okay” to use Type 1 resolution, look at any situation where the failure of one character doesn’t cause the other characters to ALSO fail. Thus, it’s okay for everyone to climb up a wall separately, because one character falling behind the rest doesn’t mean that those who succeed are automatically held back. (Although the consequences may nonetheless be dire.)


Everyone is attempting the same task, but only one of them needs to succeed.

Use this type of group action when the characters are all aimed at accomplishing a single goal, but are each acting completely separately in their efforts to achieve that goal.

When resolving an independent group effort, you’ll actually still use the normal process for resolving individual actions. But as long as at least one of the individual actions succeeds, the attempt is successful.

You can also think of this as “best result counts”.

To use our previous example: The group needs one porcelain dish. Each of the six PCs makes a Craft check in order to make a single porcelain dish. As long as at least one of them succeeds on the check (i.e., makes a dish), the group will have the one dish that they need. If the quality of the dish matters, the dish they’ll use will be the best one they made (i.e., the one with the highest check result).

The disadvantage of this method is that it actually causes probability to skew in the other direction. It’s the situation you end up with where everybody in the group says, “I search the hall for traps” (either simultaneously or sequentially), greatly increasing their odds of success.

Once again, it can be argued that this probability skew is realistic. (More eyes on a problem makes it more likely that someone will spot the solution.) And I, personally, tend to have much less of a problem with this sort of skew because (a) success rarely causes the gameplay experience to flatten (due to dropped strategies) and (b) I think it’s actually very difficult for a GM to err too much on the side of the PCs succeeding.

However, when it’s necessary or desired, this skew can be counteracted by having consequences — or the risk of consequences — for participating. This often takes the form of something bad happening on a failed check; or on a failed check with a sufficiently bad margin of success. (Are you sure you want to search the hall when a poor check means potentially triggered a trap? The materials for making a porcelain dish are expensive, so does it make sense to have Sally — who’s terrible at the Craft check — participate in the group pottery session?)

One thing to consider is the possibility for a sufficiently large margin of success by one character participating in the independent group effort to negate (or ameliorate) the consequences of failure for another member of the group. (For example, Elyssa fails her Search test by 5, but Raasti succeeds on his by 10, so he reaches over and snatches her back mere moments before she bumbles into the tripwire.)


Everyone is working together to accomplish a single action.

For example, when multiple characters are working together to fix a car. Or build a gravity gun. Or research an obscure topic at Miskatonic University.

The distinction here is that there is one thing the group is attempting to achieve, and they are all contributing to that single attempt. Mechanically speaking, there are a couple of broadly applicable approaches.

Assistance: One character is “taking point” on the attempt. (This is generally whoever the most skilled character is at whatever the primary task is, but not necessarily depending on circumstance.) The other characters who are assisting the point man grant a bonus to the point man’s test. This assistance may require a successful skill test in its own right, which may or may not be the same skill test that the point man is making (and may or may not be made at the same difficulty).

The form of this bonus can vary. 3rd Edition D&D, for example, hard codes this as the Aid Another action and grants a +2 bonus. In a dice pool system you might grant the point man a bonus die. The Cypher System has several different bonuses depending on the relative skill levels of the characters involved and the type of help being given.

Collective Margin of Success: An alternative method is to look at the total margin of success generated by the entire group and compare that against a target number. (This is very common in dice pool systems where you count successes, since it’s just as easy to count successes from multiple sources as it is to count them from a single source.) This approach can be quicker (since all of the skill tests can be resolved simultaneously), and can also be particularly appropriate in scenarios where there’s no convenient “point man”. The disadvantage is that the target numbers from these collaborative actions tend to be out of sync with the target numbers for individual actions, which lacks elegance and can cause some headaches when it comes to consistency.

With either approach, there may be practical limits on how many characters can simultaneously assist in a specific attempt. (You can only squeeze so many people under the hood of a hotrod.)


Everyone is assisting each other in a task where all need to simultaneously succeed.

The distinction between Type 4 and Type 1 can be something of a gray area: Everyone climbing a wall separately is clearly a Type 1. But if the team is working together, employing belaying techniques, and the like, at what point does it become Type 4?

Banksy - Anti-Climb PaintIn my opinion, when in doubt, default to Type 4. I don’t always do a great job of this myself, but for all the reasons discussed above I think it’s the better way to go.

Basic Version: One character takes point on the attempt and everyone else “piggybacks” on their success or failure. (If they succeed, everyone succeeds. If they fail, everyone fails.)

In GUMSHOE, the point character suffers a penalty based on the number of characters that are piggybacking. However, piggybacking characters can spend a single point from a skill pool (usually, but not always, the same skill pool as the point character’s test) to negate their penalty.

When I adapted piggybacking to the D20 system, the piggybacking characters needed to succeed on a skill test at one-half the normal DC of the test. The point character could reduce the DC of the piggybacking test for their allies by increasing the difficulty of their own test.

Simple Variant: Have every character participating make a skill test. If at least half of the group succeeds, the entire group succeeds.

Complex Variant: Everyone who succeeds on the test grants a bonus to those who would have otherwise failed. If the collective bonus from those succeeding is enough to bump all the failures up to successes, the attempt succeeds.


I’ve jotted down several different options for resolving the various group actions. For any system you’re running, however, you generally only need one for each type of group action. In some cases, of course, the system itself may come prepackaged with a mechanic for doing that. If you find yourself needing to add a mechanical structure for one of the types, you should hopefully find it relatively easy to take one of the options presented and find a way to use it in the system you’re using.

Practical experience has taught me that, generally speaking, the GM should make the determination of whether or not a group check is appropriate and what mechanic should be used for resolving it. For example, when I first introduced piggybacking mechanics into my D&D games, I left it up to the players to determine whether or not a particular attempt at Stealth would be a “normal check” or a “piggybacking check”. The problem was that players fairly consistently went with the default method of resolution, and they would also consistently rebel the minute the point character failed their test and would want to default back to individual tests.

So I recommend that, in practice, you treat group checks just like any other ruling: Determine how the action should be resolved and declare that to the PCs.

“Okay, this will be a piggyback check. Who’s taking point?”

Go to Part 1

Banksy - Blind Water Sniper

A subject somewhat related to hidden vs. open difficulty numbers is the matter of open and hidden stakes. In other words, whether or not the players know why they’re rolling the dice.

In most cases, of course, the stakes are known: If you’re trying to jump over a crevasse, the dice roll is determining whether you do so or not. But there are action checks where that isn’t necessarily true: If the GM calls for a Perception test while the PCs are traveling through a jungle, the players don’t necessarily know if it’s to notice a tribesman lying in ambush, a hidden treasure, a treacherous piece of terrain, or something else entirely.

Perception tests are, in fact, probably the most common form of this. (Since they literally determine whether or not you’re aware of something.) But the principle can be applied to other tests and reactive mechanics, too. Calling for a saving throw against undetected dangers or unknown spells before explaining what the consequence of a failure will be is a great way to ratchet up the anxiety at the table (particularly if it’s the exception rather than the rule).

I’ll sometimes do the same thing with Sanity checks in Call of Cthulhu, Stability tests in Trail of Cthulhu, and similar mechanics: Call for the check (the magnitude of which in Trail of Cthulhu can foreshadow just how bad things are about to get) and then describe the eldritch horror, allowing the players to immediately respond according to whether or not (or how badly) their character failed the test.

(Enabling this immediate, immersive response to narration by preemptively resolving a mechanical component which might normally follow the narration is why I also roll initiative at the end of each encounter and keep it stored for future use.)

One potential pitfall of such checks, however, is that you’re unable to take advantage of a player’s familiarity with their own character: If you’re asking them to make a saving throw vs. fireball, it’s much more likely that you’ll forget that they have a +2 bonus to saving throws involving fire than it is that they will. And if you do forget, then the subsequent revelation can deflate as the mechanical resolution needs to be revisited.


The existence of hidden stakes also opens the opportunity for another technique: Rolling meaningless dice.

This generally falls into two categories. First, rolling dice behind the screen for the sound effect. That can be valuable as a tool of misdirection, but it’s not primarily what we’re talking about here.

Second, having the players roll for checks that don’t mean anything.

Now, we’ve already established that dice should only be rolled if the potential failure state is interesting, meaningful or both. And if it is neither, you shouldn’t roll the dice. If that’s the case, it would seem to follow that you should never have people rolling meaningless dice.

But here’s the exception: You only roll if failure is meaningful or interesting… but sometimes you’ll roll the dice because the character believes failure could be meaningful or interesting and saying that dice will not be rolled will reveal information that the character does not have.

Searching for a trap that isn’t there is an obvious example of this.

Paradoxically, the reason you roll the meaningless dice generally isn’t to the benefit of the meaningful roll; it’s to enhance the meaningful rolls of the same type. For example, there’s seemingly no harm in cutting to the chase with exchanges like:

Player: I search the hallway for traps.

GM: There are no traps in the hallway.

It even seems to follow logically from the principles we’ve established. The GM is defaulting to yes (the “yes” in this case being “yes, your search of the hall is successful in determining there are no traps”; don’t be fooled by the presence of the word “no” in what the GM said). But if do that a dozen times and then have this interaction:

Player: I search the hallway for traps.

GM: Okay, make a Search test.

The player automatically knows there’s a trap in that hall before they even pick up their dice. The GM’s pattern of behavior has revealed metagame knowledge that puts the player in the position of knowing something that their character does not.

And sometimes metagame knowledge is unavoidable (but in this case, it’s unnecessary). And sometimes that’s desirable (but in this case, there’s nothing being gained). And some players believe it won’t make any difference (but for someone who values immersion, it will). In my experience, nothing ever seems to be gained from this interaction and almost always there is something lost, so I recommend rolling the meaningless dice and preempting the loss.


In some cases, you can deliberately use this effect reactively.

For example, as I’ve discussed previously in Metagame Special Effects, I not infrequently call for Perception checks even when there’s nothing to perceive. In addition to camouflaging which Perception check failures are important and which aren’t, this can also be an effective technique for heightening paranoia at the table.

The biggest reason I do it, though, is that I’ve found it’s the single most effective way to refocus the table’s attention on the game world when extraneous distractions and chitchat have derailed the players. (You’d think that just saying, “Okay, let’s focus.” would be equally effective, but I’ve found that it isn’t. Ask people to focus in a kind of general way and they engage in a “focusing process”. Ask them to do something specific and concrete, on the other hand, and they become immediately focused.)

Eventually, of course, all of my players eventually figure out that I’m frequently “crying wolf” with these checks. But it doesn’t matter: The more experienced heroes may no longer be quite so skittish or paranoid as they jump at imaginary shadows, but the tool still works.

And, of course, in a dangerous universe filled with wandering encounters, some of the Perception tests you use to refocus the table won’t be meaningless at all.

Go to Part 14

Go to Part 1

Banksy - Dorothy in the Security State

It’s time to discuss a topic which is surprisingly contentious: Should the GM tell their players the target number of a skill test?

(Seriously. Go to any online RPG forum, ask this question, and watch the long knives come out nine times out of ten.)

My personal approach to open and hidden difficulty numbers is to consider them a tool rather than an ideology, with their use being a blend of utility and practicality. What information in the game world does the difficulty number represent and does the character have access to that information?

  1. If the difficulty number represents something that the PCs can directly observe, tell the players the target number of the check. (An easy example would be the difficulty of jumping over a crevasse: The character can actually see the crevasse and make a pretty good guess about how difficult it is. Telling the player helps give them a clarity similar to their character’s vision.)
  2. If the difficulty number represents something that the PCs can’t observe, keep the number hidden from them. (For example, they’re walking through a jungle and I want to know if they spot a tribesmen hiding in the canopy above them. The difficulty of the spot task is based on how good the tribesmen are at hiding. Does the PC know how good the tribesmen are at hiding? No. They don’t even know it’s tribesmen they’re trying to spot. Therefore, they don’t get the target number.)
  3. If you’re feeling tricksy, you can give the players an estimated difficulty number based on what their PC does know and only reveal the real difficulty number when they’ve realized their error. (“The guy is standing nude in the middle of the field. Should be really, really easy to hit him…” “Your shot bounces off the force field surrounding him. This might be trickier than you thought.”)

When in doubt, I will generally default to not telling the players the target number. But this default position can be flipped in some systems for reasons of practicality. For example, in Call of Cthulhu you apply difficulty to the character’s skill rating and then attempt to roll under the modified rating. I’ve found it’s generally easier to give the players the difficulty modifier and simply report their success or failure rather than getting them to report a margin of success that I can then compare to the difficulty rating. (Your mileage may vary here, obviously.)

In addition to simple practicality and efficiency in game play, my method is influenced by a couple of factors. First, there is a limited bandwidth by which the player perceive the game world compared to their characters: They are relying almost entirely on imprecise verbal descriptions, whereas their characters have access to their full panoply of sensory input. While it is true that their characters cannot necessarily measure their chance for success at a task with mathematical certainty, I find that this nevertheless achieves more associated results than characters, for example, leaping over crevasses that no sane person would attempt if they could actually see it with their own eyes. Open difficulty numbers reduce the frequency with which there is miscommunication between the GM and the players, which can help minimize the old Are you sure you want to do that? problem.

Second, there are many circumstances in which the players will be able to figure out what the target number is. (Multiple characters making attacks against a fixed armor class, for example.) In some cases this experience can be very immersive (as the characters slowly figure out just how skilled their dueling partner is before declaring that they’re not actually left-handed, for example). But that also makes it an example of how knowing a difficulty number doesn’t instantly implode the table’s immersion, and even in circumstances where difficulty numbers are initially hidden, it can often make sense to explicitly lift the veil of mechanical secrecy after a short period of time in order to facilitate the practicality of speeding up play.


Over the last decade or so we’ve seen a proliferation of RPGs featuring mechanics where the players will spend points from a limited pool as part of a skill test. GUMSHOE and the Cypher System offer one common form, with points being spent from skill or attribute pools in order toTales from the Loop provide a bonus to the skill test. Tales from the Loop offers another variety, featuring a variety of resource pools which can be spent to reroll failed checks.

I’ve found that these types of systems — particularly the GUMSHOE and Cypher System variety — require some special attention when it comes to open vs. hidden difficulty numbers. Blindly spending limited resources on tasks with unclear difficulties generally doesn’t seem to work well in these types of systems: Players often get frustrated and resources are generally overspent, which can rapidly propel a session towards the hard limits of the system and really limit effective scenario design.

Which is not to say, of course, that difficulty numbers should NEVER be unknown in such games. The occasional spice of an unknown search test, for example, can be really rewarding: The player doesn’t know if there’s anything hidden in the room or how valuable it may be, so they have to make a tough choice about exactly how much effort they’re going to put into searching it. When facing a previously unknown creature, they have to make a choice about snapping off a shot or really taking the effort to aim. That’s immersive and effective.

But if the whole game is cloaked in perpetual mystery, it’s much less effective in practice. It muddies decision-making (particularly in these resource spend games) and hurts immersion.

Another way of looking at this is that there is a “threshold of knowledge” at which the GM deems it appropriate to reveal the difficulty number. This threshold, however, is basically a slider. What I’m suggesting is that for these resource spend mechanics you want to radically reduce your threshold (particularly if you normally keep it relatively high).

For these resource spend games I have also coined the term “routine check” so that I can still call for things like routine Perception tests to determine which character spots something first without having everyone burn away their resource points, uh… pointlessly.


Traveller 2300 included an interesting resolution method that I have never seen reproduced elsewhere, but which can be trivially adapted to virtually any RPG system. For any uncertain task, in which the actual success or failure of the outcome may not be immediately clear to the character (such as gathering information, convincing someone to help you break the law, or repairing a buggy piece of equipment):

… both the player and the referee roll for success (the referee rolls secretly). If both are unsuccessful, the referee provides no truth. If one is successful and the other is unsuccessful, the referee provides some truth. If both are successful, the referee provides total truth. In all cases, the referee does not indicate whether the answer or information provided is truth, some truth, or total truth.

A result of no truth means the character is totally misled as to the success of the attempt. Completely false information is given.

A result of some truth means the character is given some idea of the success of the attempt. Some valid information is given.

A result of total truth means the character is not misled in any way as to the success of the attempt. Totally correct information is given.

Because of the hidden nature of the referee’s throw, the character cannot know for certain the nature of the information being obtained. A referee may find characters doubting total truth, accepting some of no truth, or accepting all of some truth.

Marc Miller, the leader designer for Traveller: 2300, wrote about this mechanic in “Traveller: 2300 Designer’s Notes” in Challenge Magazine #27:

Setting fuses for demolitions is an uncertain task contained in the Traveller: 2300 rules. It is classified as easy, and anyone with any skill will usually succeed. Once in a while, the referee will roll a failure while the player succeeds: somehow the fuse setting failed (although it looks OK) and the explosive won’t detonate when the proper time comes. And once in a while, the player will roll a failure (and immediately realize that he has wired the explosive wrong), he can rewire them immediately to try to fix the fault. And sometimes, the player will roll a failure and hear the referee tell him the charges have exploded – because the referee also rolled a failure.

This method is an incredibly clever way of reintroducing uncertainty into the player’s (and character’s) perceptions even when embracing the practical advantages of player rolls and open difficulty numbers. I think it deserves to be much more widely known and used.

Go to Part 13

Go to Part 1

As a result of long tradition, most mechanical resolution in roleplaying games takes the form of action resolution. There is, however, an alternative paradigm that you may find useful: narrative resolution.

The classic example for distinguishing between the two involves the PCs trying to find hidden documents in an office with a locked safe. With action resolution, the mechanics determine whether or not they can crack the safe. With narrative resolution, the mechanics determine whether or not they find the documents. (The distinction, it should be noted, doesn’t necessarily require a different set of mechanics: Either attempt can boil down, mechanically speaking, to the exact same Lockpicking check. The difference is in how you set up the stakes for the test and in how you interpret the results of the test.)

With action resolution, the player declares “I want to do Y” with the expectation or hope that it will result in X being accomplished.

With narrative resolution, the player declares “I would like to accomplish X by doing Y”.

There are advantages and disadvantages to both approaches.

With narrative resolution, being able to say “this is how I would like to solve this problem” allows players to control their spotlight and it allows the GM to take a more general approach to prep. (The GM knows that there is incriminating evidence to be found in the club. The players decide whether they want to get it by sneaking into the office and cracking the safe, seducing the lounge singer, interrogating the club owner, or putting the place under surveillance.)

On the other hand, action resolution typically allows for a more simulationist experience of the game world (which, in its verisimilitude, can be more immersive for many). And it also allows for a more diverse array of possible outcomes (which can prevent the game from becoming predictable). (For example, the PCs succeed at opening the safe, but instead of finding the incriminating evidence of a criminal enterprise they find the mob’s blackmail photos of JFK schtupping Marilyn Monroe. Now what do they do?)


Unsurprisingly, narrative resolution is often conducive to (and associated with) storytelling games and RPGs with a dramatist focus. But this isn’t necessarily the case: Remember that undetermined external factors are usually factored into mechanical resolution. There’s no reason that one of those undetermined external factors can’t be whether or not the documents the PCs are looking for are in the safe. The GM is simply saying, “I don’t know whether or not there’s incriminating documents in there; let’s ask the game mechanics and find out together.” (This may require a radical shift in your thinking — it’s literally a different paradigm for interpreting mechanical results — but it’s no less valid.)

Oddly, narrative resolution often combines well with failing forward. I say oddly because it seems counterintuitive that a system predicated on determining whether or not your goal succeeds would pair well with a technique predicated on assuming that your goal fails (albeit with complications). But I think it works because, first, narrative resolution is focused on the goal, and that focus makes it more natural for failing forward (which also focuses on the goal) to come into play. Narrative resolution also tends to lend itself well to larger chunks of resolution, which opens up a lot more breathing space for the sorts of interesting complications which really make failing forward worthwhile.


When trying to grok the distinction between narrative resolution and action resolution, there are a couple common ways that I’ve seen people get confused.

First, it’s not unusual for those being introduced to the concept of narrative resolution to frame a mechanical resolution in such a way that the desired goal of the PCs is identical to the action resolution and then claim that there is in, fact, no difference between the two.

For example, you might set up a scenario where the player says, “I want to sneak over and grab the guard’s keys.” The action is to sneak over and grab the keys; the desired outcome is to sneak over and grab the keys. So, what’s the difference? Well, in this case, there is none. The two techniques resemble a Venn diagram in this regard.

Action Resolution / Narrative Resolution - Venn Diagram

Second, it’s oddly not unusual for those trying to explain the concept of narrative resolution to claim that traditional combat mechanics are a form of narrative resolution mechanic. The argument is that “make that person dead” is the desired narrative outcome and, therefore, the combat mechanics provide a narrative resolution of that outcome.

This is actually just the same error from a different angle, though. “HP 0 = DEAD” isn’t a narrative resolution mechanic. It’s just telling you whether or not you’ve killed somebody (just like an attack roll tells you whether or not you’ve hit someone with your sword). By setting the narrative goal to be “kill that guy”, you once again superficially make the action resolution look like narrative resolution.

What would a narrative resolution mechanic look like? Well, it would be “HP 0 = you accomplished whatever you goal was”. Was it to escape? Was it to convince the princess that you’re a better swordsman? Was it to impress your master? Was it to kill somebody?


This concept – including the classic safecracking example – was pioneered by D. Vincent Baker using the terms “task resolution” and “conflict resolution”. Those terms have become relatively popularized and many of my readers may be wondering why I’ve chosen to swap them out for the terms “action resolution” and “narrative resolution”.

Basically, having participated in several dozen discussions about this topic over the last decade or so, I have found that the terms “task resolution” and “conflict resolution” are a source of deep and consistent confusion.

First, the common definition and usage of the term “task” is frequently goal-oriented: You are assigned a task and then determine how you are going to accomplish that task. This seems to heavily contribute to the first point of confusion described above (where people can’t distinguish what the difference is supposed to be between the task-oriented and goal-oriented resolution methods).

Second, the term “conflict resolution” only makes sense within a very specific and adversarial understanding of the interaction between the GM and the players. If you look at the lump sum of Baker’s thoughts back in 2004 (when he was struggling with and exploring the implications of this relationship), it makes a lot of sense why he chose the term “conflict”. But outside of that specific context, it tends to lend itself to the second point of confusion discussed above. I’ve also seen it frequently lead people astray who then believe that “conflict resolution” only applies if an NPC is opposing the PC (either directly or indirectly).

I don’t really consider it likely that my revised terminology will have widespread adoption at this point, but that’s not my primary concern: My primary concern is to attempt to clearly communicate a useful set of concepts to those reading this essay.

Go to Part 12

Go to Part 1

Death on a Clock - BanksyNow that we’ve discussed the totality of making a ruling from beginning to end, I want to discuss a handful of advanced techniques – various tips and tricks I’ve picked up or created over the years.

We’ll start with fortune positioning. As we’ll discuss in detail in a moment, this is a really valuable concept revolving around the point at which you roll dice (the fortune) during the process of resolving an action, and what happens before and after you roll those dice. Before we begin, however, I need to briefly discuss the history of this terminology to clear up some difficulties.

The basic principles of fortune positioning were first laid out by Ron Edwards, who coined the terms fortune in the middle and fortune at the end to describe unexamined practices that had been hanging around the hobby for decades. They were useful terms and they caught on. A few years later, however, Ron Edwards decided to redefine the terms because he’d decided that it didn’t actually have anything to do with mechanics (despite the use of mechanics being in the damn name). Around this same time period, he also decided that fortune at the beginning didn’t exist (which, as we’ll see, is also wrong). The result was a complete muddle, but since Edwards had coined the terms his nonsense follow-up held a great deal of sway. People tried to solve the problems Edwards had created with various patches (you’ll see people using terms like “with teeth” if you go poking around), but this just sort of added to the confusion and debasing of the terminology.

With the terms being thoroughly mucked up, therefore, I had to make a decision about whether I should abandon them entirely (and try to come up with new terms to cover the same territory) or just clarify that people should ignore the later nonsense. After considerable thought, I decided that the concept of “fortune positioning” was too intuitively obvious to discard, so I’m sticking with it (and you get this preamble explaining why).

Final note here: Any time I talk about “fortune” or “rolling the dice”, that’s shorthand for any sort of action resolution. These concepts are generally most applicable to mechanical resolution (whether that involves rolling dice or not), but they have some applicability even on the spectrum of GM fiat.


Fortune at the end seems to be what most GMs and groups default to. (I’m not sure if that’s because it’s actually clearer and conceptually simpler, or if it’s just a legacy of D&D’s wargame-derived mechanics and familiarity makes it seem more natural.) With fortune at the end you:

  • Establish method.
  • Check the fortune.
  • Describe the result.

You say, “I want to shoot the blade runner!” (Establish intention.) You make an attack roll. (Check the fortune.) And the mechanical result tells you whether the intention succeeded or failed. (You either hit the target or you miss them, which means you can now describe that end result.)


Fortune at the beginning is a technique in which you ask the mechanics what happens and then you use the mechanical result to decide what you attempt. To put it another way, fortune at the beginning means putting the mechanical resolution between the statement of intention and the statement of method.

  • Indicate intention.
  • Check the fortune.
  • Determine method.
  • Describe the result.

Whereas fortune at the end has a player activate character expertise to determine whether or not the method they’ve proposed succeeds, fortune at the beginning has the player activate character expertise to tell them what method the character would use to achieve a general intention.

This can be useful when playing out a social situation: You state your intention (“I want to convince the Duke to give us troops”), then make your Diplomacy check, and then use the outcome of the Diplomacy check to inform how you roleplay the scene.

Fortune at the beginning is often used in personality mechanics: You make a madness check or you make a check to see if you can resist temptation, and if you can’t that determines how you play the next action (whether it’s running away screaming or turning away from Madame Shadow’s insistent kisses).

I also often see player do things like making an Intelligence check to see whether or not their character is smart enough to think of the idea they just had. (And if they fail, they won’t share it.)


Fortune in the middle means that your first action check determines the initial momentum of the attempt, but then the player/character has another choice that can affect the ultimate outcome. So you might make a check to resolve a social encounter, discover that you’ve made a bad first impression, and then have an opportunity to recover from that. (Or just shoot the guy in the head. “It was a boring conversation any way.”)

Basically, fortune in the middle creates an additional decision point in the middle of resolution:

  • Establish method.
  • Check the fortune.
  • Make a secondary decision.
  • Check secondary fortune.
  • Describe the result.

Sometimes this decision point is actually baked into the mechanics. The use of Fate Points is a simple and common example. Apocalypse World uses a number of “moves” which are resolved with a 2d6 roll in which there is a failure range, a success range, and Apocalypse World - D. Vincent Baker(between the two) a range in which the PC has to make a secondary decision between consequences and/or partial successes.

Speaking of partial successes, a GM can often resolve a partial success by asking for a fortune in the middle response. They can also be used in other situations: For example, after a successful Dodge roll the GM might ask, “Do you want to duck through the door on your right or behind the wooden crate on your left?”

The resolution of the secondary decision may not require another action check; i.e., whether you duck through the door or behind the wooden crate success is automatic (the GM is defaulting to yes). Alternatively, the options could easily require additional mechanical resolution (and choosing between the form of mechanical resolution could be the primary difference between choices). It’s also possible that only some of the choices would require additional mechanical checks (you need to make a Strength check to bash through the closed door, but you can duck behind the crates automatically).

And, of course, the GM doesn’t have to be the one to come up with the options. “Okay, you succeeded on your Dodge roll. Where do you want to seek cover from the hail of machine gun fire?”


The principles of fortune in the middle resolution can be extended to include multiple decision points, opening up the potential for a variety of multi-stage resolution methods.

In my experience, this is a poorly explored region of mechanical design. Probably the most prominent example are the skill challenges from 4th Edition D&D, and those were absolutely terrible to the point where the designers had to completely rewrite the mechanics multiple times within mere weeks of the game being released… and still didn’t fix it.

Dice pool systems have fared a little better because the ability to count a variable number of successes in each dice pool allows for a simple complex skill check mechanic (continue making checks until you’ve achieved X number of successes).

But much like Apocalypse World and other games have begun making specific mechanics which exploit fortune in the middle resolution principles, I think there’s a real potential for more specific multi-stage resolution mechanics (particularly if you start allowing for decision points by those opposing the character or characters carrying out the multi-stage resolution).

But I digress.

What distinguishes multi-stage resolution from simply being a series of discrete actions? Because there’s a single intention and each stage of resolution carries you towards discovering the ultimate outcome of that intention, either through a variety of methods or by the progression of a single method through discrete steps.


Over the years I’ve seen a surprising amount of one-true-wayism when it comes to fortune positioning. This makes little sense to me: The ideal fortune positioning varies by both type of action and the situation in which the action is taken. And even people who aren’t familiar with the terminology will often freely flow from one to the next depending purely on the instinct of the moment

Fortune at the end has simplicity to its advantage: You ask a question of the system, the system provides a yes-no answer.

Fortune at the beginning allows the mechanics to provide you with an improv seed that you can then flesh out accordingly. (This makes it particularly good for determining the outcome of larger actions: The more specific the action the more awkward it can become to resolve with fortune at the beginning. For example, if your mechanics resolve a single attack, fortune at the beginning generally isn’t useful. If they’re resolving an entire fight – or, say, a jousting pass – then they become more useful.)

Fortune in the middle is more complicated, but allows for a richer interplay between the player and the mechanic along with a greater range of potential outcome. It can also focus your attention on the action being resolved, signaling that this particular action is more significant than others.

Each of these has its place. And, as I implied before, trying to rigidly define that place is not always the best answer. (Maybe this time you roll the dice to see how your negotiations with the Duke will proceed before roleplaying it, but next time you’ve got a “surefire” idea for how to seduce the Duchess.) But they’re incredibly useful tools for expanding and varying the experience at the game table, and if you find that your rulings are generally limited to only a single fortuning position, you may find it useful to practice using others until you become comfortable and familiar with them (whether that involves playing games with explicit fortune positioning in their mechanics or simply challenging yourself to explore a particular type of fortune positioning for the next few sessions).

Go to Part 11



Recent Posts

Recent Comments