Big social events are a great set piece for an RPG campaign: They’re hotbeds of intrigue. If violence needs to break out, the innocent bystanders raise the stakes. If there’s to be a murder, they provide a wealth of suspects. If the PCs are trying to pull a heist, they delightfully complicate the proceedings.

I’ve also found them to be effective as a way of signaling when the PCs have changed their sphere of influence. You rescued the mayor’s daughter from a dragon? Chances are you’re going to be the belle of the ball. And you’re going to discover that powerful and important people have become very interested in making your acquaintance.

When these events work, they’re exciting and engaging experiences, often providing a memorable epoch for the players and spinning out contacts and consequences that will drive the next phase of the campaign. The difficulty, of course, is getting them to work properly: They require the GM to juggle a lot of different characters and getting the players to actually form a meaningful relationship with the NPCs at the party can often feel like a crapshoot.

Fifteen years ago, however, largely through trial and error, I sort of “cracked the code” on how to prep and run these types of scenarios. Over the years, I’ve used the same scenario structure repeatedly in a wide variety of circumstances – political caucus, soiree on a flying ship, dinner in a mystic castle, journey on a long-haul space freighter – and it’s proven to be remarkably reliable in producing great gaming experiences featuring intensive roleplaying opportunities.

The structure can be broken down into four tools: The location, the guest list, the main event sequence, and the topics of conversation.

LOCATION

Where is the social event taking place?

You’ve got a lot of flexibility with this. I’ve run these types of events in everything from a simple ballroom to multiple flying ships (with the event moving back and forth between the vessels).

What you want to avoid, however, is making the location too small or too simple. The key to any good party is having multiple zones of activity, so that social groups can form and break apart freely. Similarly, as we’ll see, what makes this scenario structure tick is that the PCs are NOT simultaneously engaged with every single NPC at the event. (That’s a different kind of event – a board meeting or a union rally or something of that ilk.) In order for that to work, there needs to be a lot of different areas that the group can move between.

This doesn’t necessarily mean that you need lots and lots of different rooms. For example, in a nightclub the dance floor, the bar, and the VIP area are probably all in view of each other, but they’re distinct areas that people can congregate in.

On the other hand, it doesn’t hurt to incorporate a wholistic environment, either. The Enchantment Under the Sea dance in Back to the Future, for example, uses the dance floor, the punch bowl, the backstage area, and even the parking lot outside. Including private areas (or at least theoretically private areas) can also be a good idea, not just for the opportunities they provide for the PCs to seclude themselves, but because seeing NPCs slipping into or out of such privates areas can immediately invoke intrigue.

GUEST LIST

Next, you’ll want to prep the guest list. In my experience, you’re generally going to want 10-20 people. Fewer than ten and the event isn’t dynamic enough and doesn’t really feel “large”. More then twenty and the lack of focus kind of just devolves into noise. Fifteen or so feels like a pretty good sweet spot to aim for.

(Obviously many events will have a larger attendance than that. But you’ll want to focus on the circle of NPCs that are immediately relevant to the PCs.)

First, you’ll want to prep a master list of names that you can use as a quick reference while running the event.

Next, you’ll want to prep each of these important NPCs using the Universal NPC Roleplaying Template. The template will let you quickly pick up each NPC and slip into their role during the event.

I recommend printing out one NPC per sheet and keep them loose-leaf. That will let you quickly pull out the sheets for each NPC participating in a particular conversation for easy use. If you’ve got the time and resources, it can also be rewarding to prep a visual handout for each NPC. During each conversation, you can just quickly prop up the visual handouts for each NPC present, making it easier for the players to track who they’re talking to and enhancing their memory of each character as a separate individual. (They can also serve as handy visual reminders for you.)

KEY INFO: The Key Info section of the roleplaying template is designed for scenario-essential information that is crucial for the GM to remember when using the NPC. When using the template for a social event, this can include:

• The character’s relationship with or attitude towards other NPCs. (“Despises Susannah.” or “Will enjoy swapping war stories with the naval officers.”)
• Specific reactions that they might have to stimuli. (“Is angered by anyone suggesting that her father is dying.”)
• Particular actions or interactions that should be triggered. (“Will try to poison Cassandra’s drink.” or “Wants to sell the PCs timeshares in Venice Beach.”)
• Clues that can be gleaned from them. (“Knows the knife belonged to Cassandra.” or “Perception check (DC 20) to notice that her dress has been torn.”)
• Scenario hooks.
• Cross-references or common experiences that they share with particular PCs. (“Was raised in the same orphanage as Bella.” or “Was a friend to the duke they killed in session 3.”)
• Unusual or important gear they might be carrying. (“Her glass eye allows her to see through walls.” or “The golden cross she wears is made of aurum (true gold).”)

Obviously some of these categories overlap with each other, and there are plenty of other essential details that will be scenario- or character-specific.

MAIN EVENT SEQUENCE

Next you’re going to prep what I call the main event sequence for the event. For example:

• Announcing Guests of Special Honor
• Iron Mage Appears
• Aoska Arrives
• Urlenius Arrives
• Lord Dallimothan Arrives
• Lady Rill Joins the Party
• Arguing About the Balacazars
• Debate of the Twelve Commanders
• Sheva and Jevicca Seek Out the PCs
• A Poetry Reading

I usually prep these as a linear sequence (A happens, then B happens, then C happens). You could also just prep a grab bag of events that could happen in any sequence. (You could even stock a random table and roll to see what happens next.) If you want to run something a little more complicated, you could also try prepping multiple event sequences. (This is a variant of the Second Track.)

Obviously the PCs can also initiate alternative “major events”, or they may end up derailing (or transforming) the events that you’d originally planned. More power to them. The main event sequence should be seen as a tool, not as destiny.

It can also be tempting to think of the main event sequence as the “Story of the Party”. But it isn’t. It’s more like the piece of string that you dip into a saturated sugar solution in order to make rock candy. The experience of the party – the cool and unique events that you and your players are going to remember – will crystallize around the string. If you’re eating the string instead of the candy, you’re doing it wrong.

TOPICS OF CONVERSATION

The last tool you’ll prep are topics of conversation. These might be momentous recent events, fraught political debates, or just utter trifles (like the series finale of a television program). For example, in a scenario I ran as part of In the Shadow of the Spire, the topics of conversation included:

• A recent riot
• A magical battle that the PCs had been involved in
• A string of terrorist attacks that had been plaguing the city
• Rumours of war to the south
• The health of a guest who canceled at the last minute
• A magical STD that had been afflicting merchant families
• The recent prison escape by a criminal the PCs had arrested
• A new restaurant that recently opened in the Nobles’ Quarter

I recommend mixing in a few “irrelevant” topics of conversation to camouflage (or, at least, contrast) the “important” stuff.

The topics of conversation can also pick up elements from the main event sequence as they happen. (“Did you see Astoria rush out in tears? What could Rupert have possibly said to her?!”)

In some cases, you may want to reference topics of conversation in the Key Info section of the NPCs from your guest list (i.e., what they think about or can contribute to a particular topic). But for the most part you should be able to simply improvise what various people have to say about each topic. What can be more useful is figuring out two or three different general viewpoints on a particular topic (supporting the new Ironworkers’ Guild vs. thinking it’s a front for criminal activity), and then you can just have each NPC ad lib within that debate.

RUNNING THE PARTY

First, you’ll want to know what happens in the first moment that the PCs show up for the event. What will immediately attract their attention? Who will they see? Is there a major announcement (about them or otherwise)? Is there something big and loud going down? Is there something subtle that only they might notice?

This will generally be the first event on your main event sequence. It’s the initial hook and it should give your players enough context to begin taking action in the scene. (Reacting to what they see. Going to speak with someone they know. Et cetera.)

From that point forward, running the event is largely a matter of picking up the various toys you’ve constructed and then putting them into play in different configurations.

• Which NPCs are talking to each other? (Consult your guest list.)
• Who might come over and join a conversation that the PCs are having? (Again, guest list.)
• What are they talking about? (Look at your topics of conversation.)

Encourage the PCs to split up. Cutting back and forth between various conversations is extremely effective in large social events, and you’ll want to use crossovers between various interactions to make the party feel like a unified whole. (For example, if one of the PCs gets involved in a huge shouting match with the Ariadnan diplomat, the other PCs should either hear it directly or hear people talking about it.)

Keep the social groups circulating. You don’t have to completely use up everything interesting about a particular NPC in a single interaction. In fact, you shouldn’t. Reincorporate characters that the PCs met earlier in the scene. Similarly, reincorporate topics of conversation – let the players discuss similar things with different people in order to get (and argue) different points of view.

Pay attention to which NPCs “click” with the PCs (whether in a positive or negative way). In my experience, there’s really no way to predict this: Part of it is just random chance. Part of it is which character traits particularly appeal to your players. Part of it will be which NPCs are clicking for you (and therefore providing stronger and more memorable interactions). Regardless, make a point of bringing those NPCs back and developing the PCs’ relationships with them.

If things feel like they’re lagging, either cut to another group of PCs or trigger the next event on the main sequence.

Don’t hog the driver’s seat. Allow the PCs to observe things that they can choose to react to. (For example, instead of having every NPC come to them, instead allow them to notice NPCs walking past or overhearing a group talking about a topic of interest. Let them choose whether and how to engage.) Make a point of asking them what they want to do (and if they don’t have an answer, trigger the next event).

What essentially makes this scenario structure work is that you have not prepped a dozen specific interactions for the PCs to have. Instead, you’ve prepped a couple dozen different toys – people, topics, events – and you’re going to constantly remix those into new configurations for as long as they hold the players’ interest.

QUICK ‘N DIRTY VERSION

The full scenario structure I’m describing here obviously requires preparation to run to full effect. But what if the players have just spontaneously decided to crash the society debut of the Governor’s daughter? Is there any way to use this scenario structure on-the-fly?

Here’s the five minute version for emergency use:

• Make a list of 3-5 places people can congregate.
• Make a list of 10 characters.
• Make a list of 5 events.
• Make a list of 5 topics of conversation.

Don’t go into detail. Just list ‘em.

If this social event is growing organically out of game play, then you’ve probably already got the NPCs and the topics of conversation prepped – you just need to pull them onto the lists for this event.

Finally, if the PCs are going to the social event in order to achieve some specific goal, use the Three Clue Rule and figure out three ways that they can do that. Notate it in the appropriate places. (For example, if they’re trying to figure out who in the Governor’s circle of friends might have assassinated Marco’s sister, then you’ll probably want to identify a couple people who can tell them that. And maybe one of the events is an opportunity to witness the Governor’s chief of staff slipping off to talk to a known Mafioso.) Of course, when you’re actually running the scenario don’t forget the principle of Permissive Clue-Finding – there may be a bunch of other ways for the PCs to also accomplish their goal. Follow their lead.

For a detailed example of this scenario structure in practice, check out Running the Campaign: A Party at Shipwright’s House.

The handling of distance in roleplaying games can be roughly broken down into two types: First, there are systems which calculate and manipulate the specific measurements of the game world (measured in feet or meters or whatever). Second, there are systems which handle movement and distance through some form of abstract mechanic.

Let’s refer to these as “precise” systems and “abstract” systems, respectively.

When executed properly, abstract distance systems are really just formalizing the way that people handle “precise” distance without using some form of visual reference.

For example, imagine that you’re playing D&D without a grid or battlemap and the GM says, “They’re about 20 feet away from you.” What’s the GM really saying there? There’s no tape measure. He imagined the scene, eyeballed the distance in his head, and gave a figure that’s basically in the right ballpark. He could have just as easily said 15 feet or 25 feet.

In general, the GM is going to make these decisions based on one of two criteria:

(1) A visualization of the game world (“they just came out of the tree line and that’s a fair distance away, let’s call it 150 ft.”); or

(2) A mechanical assessment (“a typical PC should need to run for at least two rounds before reaching them; they can run 120 ft. per round, so let’s say it’s 150 ft. away”)

When using an abstract system, a GM should be able to use these exact same criteria.

Numenera, for example, breaks distance down into four categories: Immediate distance (anything up to about 10 ft.), Short distance (anything up to about 50 ft.), Long distance (anything up to about 100 ft.), and Extreme distance (anything beyond that).

So now the GM can use the same basic process:

(1) The archers came out of the tree line. The PCs are really far away from the tree line, so that’s an Extreme distance.

(2) The PCs shouldn’t be able to reach them in a single round, so they must be at an Extreme distance.

ZONES

When not using a precise visual reference, the other thing a GM needs to keep track of is the relative position of the various characters in a combat scene. This is relatively easy if there are only a few characters, but as the number of characters grows it will eventually surpass the GM’s capacity unless (a) they’re some kind of savant, or (b) they figure out shortcuts. One of these shortcuts is to simply group characters together: You know that Gwen and Cassie are engaged in melee with the ogre, so all three of them are in one group. There are a couple of PC archers standing a few feet behind Gwen and Cassie, so that’s another group. And then you’ve got six goblins running towards the party from across the room. (This way you’re only tracking three groups instead of eleven characters.)

Another common form of abstract distance mechanic are Zones. (We’re using those in Infinity.) And what zones basically do is formalize the mental process of grouping characters together: Gwen, Cassie, and the ogre are all standing near each other (they’re in the same zone). The two archers are a little bit off to one side (one zone away). And the goblins racing towards them are still a couple zones away.

One of the common problems people seem to run into with abstract distance systems, in my experience, is that they try to translate the abstract system back into specific measurements. Then they run the specific measurements back through whatever mental process they use for abstracting it in the theater of their mind, and then they try to translate it back into the abstract mechanic. The result tends to be like a drunk centipede trying to tap dance — they end up tripping over themselves a lot.

Okay, so if all these abstract mechanics are basically doing the same thing as the “theater of the mind”, what’s the point of them?

First, it gets away from the false deity of “precision”. Precision is great if that’s what you want and if you’re using a visual representation (usually miniatures) and mechanics which allow you to take advantage of that precision. But if you’re not, pretending that there’s any real difference between 125 feet and 130 feet is an illusion.

Second, it can eliminate irrelevant mathematical calculations by cutting directly to the mechanically relevant distinctions.

Third, these mechanics can also serve as a nice, flexible foundation for other mechanical features. For example, you can define zones with various effects that can make it easier to manage strategically interesting terrain without using battlemaps.

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 certain types of dice-fudging or groups that simply ignore certain types of mechanics.)

Go to Part 4

Places to Go, People to Be has translated the Three Clue Rule into French as La Règle des Trois Indices!

I can’t read a word of it, but it does remind me that in French the word for “clue” is the same word as “indication” — i.e., it is something which indicates something else. (I think I first encountered this when reading essays about the Arsène Lupin stories.) That seems like a particularly useful bit of alternative etymology in the particular context of the Three Clue Rule (or Three Indication Rule), since the rule can actually be applied widely beyond the format of a mystery.

(For those curious, the English word “clue” derives from “clew”, which originally referred to a ball of thread: Just as Ariadne’s thread led Theseus to the entrance of the labyrinth, so clues will lead you to the solution of the mystery. The example of the labyrinth, I suppose, just indicates another way in which the provenance of the Three Clue Rule can be extended.)

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 be basically 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 is 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 is 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 potentially provide 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 are 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 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