Secret RP Article Resources

Prep Situations, not plot

If you’re GMing a roleplaying game, you should never prep a plot.

Everyone’s tastes are different. These matters are subjective. What works for one person won’t necessarily work for another. Yada, yada, yada.

But, seriously, don’t prep plots.

First, a definition of terms: A plot is the sequence of events in a story.

And the problem with trying to prep a plot for an RPG is that you’re attempting to pre-determine events that have not yet happened. Your gaming session is not a story — it is a happening. It is something about which stories can be told, but in the genesis of the moment it is not a tale being told. It is a fact that is transpiring.

PREPPING WITHOUT PLOTS

Don’t prep plots, prep situations.

What’s the difference?

A plot is a sequence of events: A happens, then B happens, then C happens. (In more complicated forms, the sequence of events might fork like a Choose Your Own Adventure book, but the principle remains the same.)

A situation, on the other hand, is merely a set of circumstances. The events that happen as a result of that situation will depend on the actions the PCs take.

For example, a plot might look like this: “Pursuing the villains who escaped during last week’s session, the PCs will get on a ship bound for the port city of Tharsis. On their voyage they will spot a derelict. They will board the derelict and discover that one of the villains has transformed into a monster and killed the entire crew… except for one lone survivor. They will fight the monster and rescue the survivor. While they’re fighting the monster, the derelict will have floated into the territorial waters of Tharsis. They will be intercepted by a fleet of Tharsian ships. Once their tale is told, they will be greeted in Tharsis as heroes for their daring rescue of the derelict. Following a clue given by the survivor of the derelict, they will climb Mt. Tharsis and reach the Temple of Olympus. They can then wander around the temple asking questions. This will accomplish nothing, but when they reach the central sanctuary of the temple the villains will attempt to assassinate them. The assassination attempt goes awry, and the magical idol at the center of the temple is destroyed. Unfortunately, this idol is the only thing holding the temple to the side of the mountain — without it the entire temple begins sliding down the mountain as the battle continues to rage between the PCs and villains!”

(This is derived from an actual, published adventure. Names and milieu have been changed to protect the innocent. Bonus points to anyone who can correctly identify the original source.)

A situation, on the other hand, looks like this: “The villains have escaped on two ships heading towards Tarsis. One of the villains transforms during the voyage into a terrible monster and kills the crew, leaving the ship floating as a derelict outside the coastal waters of Tharsis. At such-and-such a time, the ship will be spotted by the Tharsis navy. The other villains have reached the Temple of Olympus atop Mt. Tharsis and assumed cover identities.”

THE DIRTY SECRET

Many people are intimidated by the idea of prepping without a plot. It seems like a lot of work. If the players can do anything, how are you supposed to cope with that?

The dirty secret, though, is that it’s actually a lot more difficult to prep plots than situations.

To understand why, let’s take a closer look at our example of a plotted adventure. It’s a tightly-knit sequence of events that, when broken down, looks like this:

(1) The PCs pursue the villains. (What if they don’t?)

(2) The PCs have to choose to follow them by ship. (What if they decide to ride down the coast? Or teleport?)

(3) The PCs have to spot the derelict. (What if they roll poorly on their Perception check?)

(4) The PCs have to board the derelict. (What if they just sail past it?)

(5) The PCs have to rescue the survivor. (What if they fail? Or choose to flee before realizing the survivor is there?)

(6) The PCs have to question the survivor. (What if they decide not to pressure an injured man?)

(7) The PCs have to go to the central sanctuary of the temple.

(8) The assassination attempt on the PCs has to play out in a very specific way.

What you’re looking at is a chain of potential points of failure. Each of these points is heavily designed with a specific and expected outcome… and if that outcome doesn’t happen the GM is left to railroad the players back onto the tracks he’s laid out.

By contrast, let’s look at what we need to design this same adventure as a situation:

(1) The PCs have to pursue the villains. (This is the hook into the entire scenario. It’s a potential failure point shared by all scenarios. If the PCs aren’t interested in going to the red dragon’s lair, it doesn’t matter how you prep the lair.)

(2) You need to design the city of Tharsis. (Where is it? What’s it like? What can the PCs do there? Et cetera.)

(3) You need to design the derelict ship.

(4) You need to design the Temple of Olympus.

(5) You need to stat up the Tharsis navy, the villains, and (possibly) the survivor.

(6) There needs to be a way for the PCs to know the villains are hiding out in the Temple of Olympus. (In the plot-based design, this is one of the failure points: They either question the survivor or they have no way of knowing where to go next. In situation-based design, you would use the Three Clue Rule and figure out two additional methods by which the PCs could reach this conclusion. This can be as simple as making a Gather Information check in Tharsis and/or questioning the captain/crew of the ship the villains took.)

Here’s the dirty secret: Take a closer look at that list. With the exception of #6, those are all things that you also needed to prep for your plot-based design. (And even #6 is one-third complete.)

Here’s an analogy: Situation-based design is like handing the players a map and then saying “figure out where you’re going”. Plot-based design, on the other hand, is like handing the players a map on which a specific route has been marked with invisible ink… and then requiring them to follow that invisible path.

ROBUST DESIGN

The advantage of situation-based prep is that it’s robust. Surprisingly, however, that robustness doesn’t require a lot of extra work. In fact, as we’ve shown, it usually requires a lot less work. Here are a few things to consider while doing situation-based prep.

THREE CLUE RULE: I’ve already devoted a lengthy essay to the Three Clue Rule. Basically, the Three Clue Rule states: For any conclusion you want the PCs to make, include at least three clues.

The theory is that, even if the players miss two of the clues, you’ve got pretty great odds that they’ll find the third and figure things out.

The Three Clue Rule can also be applied to adventure design in general: For any given problem in an adventure, you should always prep at least one solution and remain open to any potential solutions your players may devise. But for any chokepoint problem (by which I mean “a problem which must be overcome in order for the adventure to continue”), try to include three possible routes to success.

That may sound like a lot of work, but these distinct paths don’t need to be particularly convuluted. (In fact, they shouldn’t be.) For example, a problem might be “Mickey Dee has a piece of information the PCs need”. The solutions can be as simple as (1) knock him out and take it; (2) negotiate with him for it; or (3) sneak into his office and steal it. The actual prep that you do for any one of these solutions takes care of 99% of the prep for the other two.

It should be noted that, just because any given solution is “simple”, it doesn’t mean that the scenario will be (or should be) simple. The convulution of the scenario arises from the way in which a series of problems are overcome. And the nice thing about situation-based prep is that you don’t have to figure out exactly how these problems will be strung together — that arises naturally out of the actions taken by the PCs.

GOAL-ORIENTED OPPONENTS: Instead of trying to second-guess what your PCs will do and then trying to plan out specific reactions to each possibility, simply ask yourself, “What is the bad guy trying to do?”

The most effective way of prepping this material will depend on the particulars of the scenario you’re designing. It might be nothing more than a sequential list of objectives. Or it might be a detailed timeline.

Note that some scenarios won’t be based around the bad guys trying to carry out some specific scheme. They might just be going about business as usual when the PCs decide to show up and make a mess of things. In other words, the “goal” might be nothing more than “maintain the standard guard rotation”.

If you’re interested in seeing this type of prep work in action, I’ve put together a lengthy example of using detailed timelines from my own campaign. (My players should not click that link.)

DON’T PLAN SPECIFIC CONTINGENCIES: Whatever approach you take, the key aspect is that you’ll usually be laying out what would happen if the PCs don’t get involved. If you get some ideas about contingency plans, go ahead and jot them down, but don’t waste too much time on them.

I say “waste your time” because that’s exactly what most contingency planning is. The basic structure of contingency planning is: If the PCs interfere at point X, then the bad guys do X2. If the PCs interfere at point Y, then the bad guys do Y2. If the PCs interfere at point Z, then the bad guys do Z2.

Of course, if the PCs don’t interfere at point X, then all the time you spent prepping contingency X2 is completely wasted. Even more importantly, if the PCs do interfere at point X then point Y and point Z will generally be fundamentally altered or even cease to exist — so all the prep work that went into Y2 and Z2 is also wasted.

This is where situation-based prep usually gets maligned for requiring more work: People think they need to try to prepare themselves for every conceivable action the PCs might take. But, in point of fact, that’s not situation-based prep. That’s plot-based prep juiced up on Choose Your Own Adventure steroids. It’s the type of prep you would need to do if you were programming a computer game.

But you’re not programming a computer game. You’re prepping a scenario for a roleplaying game. When the PCs choose to do X or Y or Z (or A or B or C), you don’t need a pre-programmed reaction. You’re sitting right there at the table with them. You can just react.

KNOW YOUR TOOLKIT: In order to react, you need to know your toolkit. If the PCs start investigating Lord Bane, what resources does he have to thwart them? If they lay siege to the slavers’ compound, what are the defenses?

Typical “tools” include personnel, equipment, physical locations, and information.

For example, if the PCs are investigating a local Mafia leader then you might know that:

(1) He has a couple of goon squads, a trained assassin on staff, and two bodyguards. You might also know that he has an estranged wife and two sons. (These are all types of personnel.)

(2) He lives in a mansion on the east side of town, typically frequents his high-end illegal casino in the secret basement of a downtown skyscraper, and also has a bolt-hole set up in a seedy tavern. (These are all physical locations.)

(3) He has blackmail material on one of the PCs. (This is information.)

(4) He has bribed a local cop. (This is a different type of personnel.)

And just like a real toolbox, you should have some idea what the tools are useful for. You know that a hammer is for nails and a screwdriver is for screws. Similarly, you know that the goon squad can be used to beat-up the PCs as a warning or to guard the bolt-hole. You know that the estranged wife can be used as a source of information on the mansion’s security system. And so forth.

You can think of this as non-specific contingency planning. You aren’t giving yourself a hammer and then planning out exactly which nails you’re going to hit and how hard to hit them: You’re giving yourself a hammer and saying, “Well, if the players give me anything that looks even remotely like a nail, I know what I can hit it with.”

(For example, you know that the estranged wife is familiar with the details of her husband’s operations and the security of the mansion. That’s the hammer. What you don’t have to figure out is how the PCs get that information from her: Maybe they just ask her nicely. Or bribe her. Or offer to protect her. Or they plant a surveillance bug on her. Or tap her phones. Or kidnap her sons and threaten to kill them unless she plants a bomb in her husband’s mansion. These are all nails. The players will provide them.)

The other trick to designing your toolkit is organizing the pertinent resources into usable chunks. Take the goon squads for example: You could try to track the actions of every individual goon while running the adventure, but that quickly becomes incredibly complicated. By organizing them into squads you give yourself a manageable unit that you can keep track of.

On the other hand, don’t let this organization shackle you. If you need an individual goon, just peel ’em off one of the squads and use them. You’re drawing a forest because that’s easier to map — but if the PCs need to chop down some firewood, don’t miss the trees for the forest.

CONCLUDING THOUGHTS

Despite my tongue-in-cheek opening to this essay, there’s nothing inherently wrong with plot-based design. Plenty of great games have been run with tightly or loosely plotted scenarios. And the argument can certainly be made that, “The players don’t care if they’re on a railroad, if the train’s heading to Awesome Town.”

But I’ll admit that, in my experience, Awesome Town is usually a lot more awesome when I let the PCs chart their own course.

Is that because I’m such an amazingly awesome GM that I can always roll with the punches and come up with some awesome improvisation? Maybe. But I think it has more to do with the fact that the players are actually pretty good judges of what they want. And if they come up with a detailed plan for infiltrating the mob boss’ downtown casino as card dealers and gamblers, then they’ll probably have a lot more fun seeing that plan come to fruition than if I artificially quash it so that they can go back to my “awesome” idea of kidnapping the sons of the mob boss and using them to blackmail his wife.

(Which isn’t to say that the PCs should always succeed. Overcoming adversity is awesome as well. But there’s a difference between a plan that doesn’t work because it didn’t work and a plan that doesn’t work because I, as a GM, want them to be doing something else.)

And with that so-called advantage of plot-based design laid to one side, I’m not sure what it’s really supposed to be offering. On the other hand, the advantages of scenario-based design are huge:

(1) It requires significantly less work to prep.

(2) It empowers the players and makes their choices meaningful.

The latter really cannot be emphasized enough. For me, the entire reason to play a roleplaying game is to see what happens when the players make meaningful choices. In my experience, the result is almost always different than anything I could have anticipated or planned for.

If I wanted to tell my players a story (which is what plot-based design really boils down to), then it’s far more efficient and effective to simply write a story. In my opinion, if you’re playing a roleplaying game then you should play to the strengths of the medium: The magical creativity which only happens when people get together.

For examples of what I’m talking about, you can also read about the Unexpected Successes from my own table. The Twin Deaths of Thuren Issek are particularly awesome.

On the other hand, if you have a group that’s used to being shown the Correct Path and then following it, suddenly throwing them into the deep-end of an open-ended scenario may have disastrous results, just like any other sudden shift in the style of play. Others, of course, will immediately take to it like a fish takes to water. But if you’re running into problems, just sit down and talk things over with your players. Explain where the disconnect is happening. Maybe give them a copy of this essay so that they can have a better understanding of what’s going on (and what’s not going on) behind the screen.

I suspect that once they know the shackles have been taken off, they’ll revel in their newfound freedom.

Three Clue Rule

Three Clue Rule

May 8th, 2008

Mystery scenarios for roleplaying games have earned a reputation for turning into unmitigated disasters: The PCs will end up veering wildly off-course or failing to find a particular clue and the entire scenario will grind to a screeching halt or go careening off the nearest cliff. The players will become unsure of what they should be doing. The GM will feel as if they’ve done something wrong. And the whole evening will probably end in either boredom or frustration or both.

Three Clue Rule - Sherlock Holmes

Here’s a typical example: When the PCs approach a murder scene they don’t search outside the house, so they never find the wolf tracks which transform into the tracks of a human. They fail the Search check to find the hidden love letters, so they never realize that both women were being courted by the same man. They find the broken crate reading DANNER’S MEATS, but rather than going back to check on the local butcher they spoke to earlier they decide to go stake out the nearest meat processing plant instead.

As a result of problems like these, many people reach an erroneous conclusion: Mystery scenarios in RPGs are a bad idea. In a typical murder mystery, for example, the protagonist is a brilliant detective. The players are probably not brilliant detectives. Therefore, mysteries are impossible.

Or, as someone else once put it to me: “The players are not Sherlock Holmes.”

Although the conclusion is incorrect, there’s an element of truth in this. For example, in A Study in Scarlet, Sherlock Holmes is investigating the scene of a murder. He discovers a small pile of ashes in the corner of the room. He studies them carefully and is able to conclude that the ashes have come from a Trichinopoly cigar.

Now, let’s analyze how this relatively minor example of Holmesian deduction would play out at the game table:

(1) The players would need to successfully search the room.

(2) They would need to care enough about the ashes to examine them.

(3) They would need to succeed at a skill check to identify them.

(4) They would need to use that knowledge to reach the correct conclusion.

That’s four potential points of failure: The PCs could fail to search the room (either because the players don’t think to do it or because their skill checks were poor). The PCs could fail to examine the ashes (because they don’t think them important). The PCs could fail the skill check to identify them. The PCs could fail to make the correct deduction.

If correctly understanding this clue is, in fact, essential to the adventure proceeding — if, for example, the PCs need to go to the nearest specialty cigar shop and start asking questions — then the clue serves as chokepoint: Either the PCs understand the clue or the PCs slam into a wall.

Chokepoints in adventure design are always a big problem and need to be avoided, but we can see that when it comes to a mystery scenario the problem is much worse: Each clue is not just one chokepoint, it’s actually multiple chokepoints.

So the solution here is simple: Remove the chokepoints.

THE BREAD CRUMB TRAIL

GUMSHOE System - Robin D. Laws

For the GUMSHOE system (used in The Esoterrorists, Fear Itself, and The Trail of Cthulhu), Robin D. Laws decided to get rid of the concept of needing to find clues. In each “scene” of an investigation scenario, there is a “clue”. It’s automatically assumed that the investigators will find this clue.

This removes three of our four chokepoints, leaving only the necessity of using the clue to make the correct deduction (i.e., the deduction which moves you onto the next “scene” where the next clue can be imparted). And, in the case of the GUMSHOE system, even this step can be tackled mechanically (with the players committing points from their character’s skills to receive increasingly accurate “deductions” from the GM).

This is a mechanical solution to the problem. But while it may result in a game session which superficially follows the structure of a mystery story, I think it fails because it doesn’t particularly feel as if you’re playing a mystery.

Laws’ fundamental mistake, I think, is in assuming that a mystery story is fundamentally about following a “bread crumb trail” of clues. Here’s a quote from a design essay on the subject:

I’d argue, first of all, that these fears are misplaced, and arise from a fundamental misperception. The trail of clues, or bread crumb plot, is not the story, and does not constitute a pre-scripted experience. What the PCs choose to do, and how they interact with each other as they solve the mystery, is the story. As mentioned in The Esoterrorist rules, we saw this at work during playtest, as all of the groups had very different experiences of the sample scenario, as each GM and player combo riffed in their own unique ways off the situations it suggested.

But, in point of fact, this type of simplistic “A leads to B leads to C leads to D” plotting is not typical of the mystery genre. For a relatively simplistic counter-example, let’s return to Sherlock Holmes in A Study in Scarlet:

WATSON: “That seems simple enough,” said I; but how about the other man’s height?”

HOLMES: “Why, the height of a man, in nine cases out of ten, can be told from the length of his stride. It is a simple calculation enough, though there is no use my boring you with figures. I had this fellow’s stride both on the clay outside and on the dust within. Then I had a way of checking my calculation. When a man writes on a wall, his instinct leads him to write above the level of his own eyes. Now that writing was just over six feet from the ground. It was child’s play.”

This is just one small deduction in a much larger mystery, but you’ll note that Holmes has in fact gathered several clues, studied them, and then distilled a conclusion out of them. And this is, in fact, the typical structure of the mystery genre: The detective slowly gathers a body of evidence until, finally, a conclusion emerges. In the famous words of Holmes himself, “When you have eliminated the impossible, whatever remains, however improbable, must be the truth.”

What is true, however, is that in many cases it is necessary for many smaller deductions to be made in order for all of the evidence required to solve the mystery to be gathered. However, as the example from A Study in Scarlet demonstrates, even these smaller deductions can be based on a body of evidence and not just one clue in isolation.

This observation leads us, inexorably, to the solution we’ve been looking for.

THE THREE CLUE RULE

Whenever you’re designing a mystery scenario, you should invariably follow the Three Clue Rule:

For any conclusion you want the PCs to make, include at least three clues.

Why three? Because the PCs will probably miss the first; ignore the second; and misinterpret the third before making some incredible leap of logic that gets them where you wanted them to go all along.

I’m kidding, of course. But if you think of each clue as a plan (the PCs will find A, conclude B, and go to C), then when you have three clues you’ve not only got a plan — you’ve also got two backup plans. And when you realize that your plans never survive contact with the players, the need for those backup plans becomes clear.

In a best case scenario, of course, the players will find all three clues. There’s nothing wrong with that. They can use those clues to confirm their suspicions and reinforce their conclusions (just like Sherlock Holmes).

In a worst case scenario, they should be able to use at least one of these clues to reach the right conclusion and keep the adventure moving.

And here’s an important tip: There are no exceptions to the Three Clue Rule.

“But Justin!” I hear you say. “This clue is really obvious. There is no way the players won’t figure it out.”

In my experience, you’re probably wrong. For one thing, you’re the one designing the scenario. You already know what the solution to the mystery is. This makes it very difficult for you to objectively judge whether something is obvious or not.

And even if you’re right, so what? Having extra clues isn’t going to cause any problems. Why not be safe rather than sorry?

EXTENDING THE THREE CLUE RULE

If you think about it in a broader sense, the Three Clue Rule is actually a good idea to keep in mind when you’re designing any scenario.

Richard Garriott, the designer of the Ultima computer games and Tabula Rasa, once said that his job as a game designer was to make sure that at least one solution to a problem was possible without preventing the player from finding other solutions on their own. For example, if you find a locked door in an Ultima game then there will be a key for that door somewhere. But you could also hack your way through it; or pick the lock; or pull a cannon up to it and blow it away.

Deus Ex - Warren Spector

Warren Spector, who started working with Garriott on Ultima VI, would later go on to design Deus Ex. He follows the same design philosophy and speaks glowingly of the thrill he would get watching someone play his game and thinking, “Wait… is that going to work?”

When designing an adventure, I actually try to take this design philosophy one step further: For any given problem, I make sure there’s at least one solution and remain completely open to any solutions the players might come up with on their own.

But, for any chokepoint problem, I make sure there’s at least three solutions.

By a chokepoint, I mean any problem that must be solved in order for the adventure to continue.

For example, let’s say that there’s a secret door behind which is hidden some random but ultimately unimportant treasure. Finding the secret door is a problem, but it’s not a chokepoint, so I only need to come up with one solution. In D&D this solution is easy because it’s built right into the rules: The secret door can be found with a successful Search check.

But let’s say that, instead of some random treasure, there is something of absolutely vital importance behind that door. For the adventure to work, the PCs must find that secret door.

The secret door is now a chokepoint problem and so I’ll try to make sure that there are at least three solutions. The first solution remains the same: A successful Search check. To this we could add a note in a different location where a cultist is instructed to “hide the artifact behind the statue of Ra” (where the secret door is); a badly damaged journal written by the designer of the complex which refers to the door; a second secret door leading to the same location (this counts as a separate solution because it immediately introduces the possibility of a second Search check); a probable scenario in which the main villain will attempt to flee through the secret door; the ability to interrogate captured cultists; and so forth.

Once you identify a chokepoint like this, it actually becomes quite trivial to start adding solutions like this.

I’ve seen some GMs argue that this makes things “too easy”. But the reality is that alternative solutions like this tend to make the scenario more interesting, not less interesting. Look at our secret door, for example: Before we started adding alternative solutions, it was just a dice roll. Now it’s designed by a specific person; used by cultists; and potentially exploited as a get-away.

As you begin layering these Three Clue Rule techniques, you’ll find that your scenarios become even more robust. For example, let’s take a murder mystery in which the killer is a werewolf who seeks out his ex-lovers. We come up with three possible ways to identify the killer:

(1) Patrol the streets of the small town on the night of the full moon.

(2) Identify the victims as all being former lovers of the same man.

(3) Go to the local butcher shop where the killer works and find his confessions of nightmare and sin written in blood on the walls of the back room.

For each of these conclusions (he’s a werewolf; he’s a former lover; we should check out the butcher shop) we’ll need three clues.

HE’S A WEREWOLF: Tracks that turn from wolf paw prints to human footprints. Over-sized claw marks on the victims. One of the victims owned a handgun loaded with silver bullets.

HE’S A FORMER LOVER: Love letters written by the same guy. A diary written by one victim describing how he cheated on her with another victim. Pictures of the same guy either on the victims or kept in their houses somewhere.

CHECK OUT THE BUTCHER SHOP: A broken crate reading DANNER’S MEATS at one of the crime scenes. A note saying “meet me at the butcher shop” crumpled up and thrown in a wastepaper basket. A jotted entry saying “meet P at butcher shop” in the day planner of one of the victims.

And just like that you’ve created a scenario with nine different paths to success. And if you keep your mind open to the idea of “more clues are always better” as you’re designing the adventure, you’ll find even more opportunities. For example, how trivial would it be to drop a reference to the butcher shop into one of those love letters? Or to fill that diary with half-mad charcoal sketches of wolves?

The fun part of all this is, once you’ve given yourself permission to include lots of clues, you’ve given yourself the opportunity to include some really esoteric and subtle clues. If the players figure them out, then they’ll feel pretty awesome for having done so. If they don’t notice them or don’t understand them, that’s OK, too: You’ve got plenty of other clues for them to pursue (and once they do solve the mystery, they’ll really enjoy looking back at those esoteric clues and understanding what they meant).

COROLLARY: PERMISSIVE CLUE-FINDING

The maxim “more clues are always better” is an important one. There is a natural impulse when designing a mystery, I think, to hold back information. This is logical inclination: After all, a mystery is essentially defined by a lack of information. And there’s a difference between having lots of clues and having the murderer write his home address in blood on the wall.

But the desire to hold back information does more harm than good, I think. Whenever you hold back a piece of information, you are essentially closing off a path towards potential success. This goes back to Garriott’s advice: Unless there’s some reason why the door should be cannon-proof, the player should be rewarded for their clever thinking. Or, to put it another way: Just because you shouldn’t leave the key to a locked door laying on the floor in front of the door, it doesn’t mean that there shouldn’t be multiple ways to get past the locked door.

With that in mind, you should consciously open yourself to permissive clue-finding. By this I mean that, if the players come up with a clever approach to their investigation, you should be open to the idea of giving them useful information as a result.

Here’s another way of thinking about it: Don’t treat the list of clues you came up with during your prep time as a straitjacket. Instead, think of that prep work as your safety net.

I used to get really attached to a particularly clever solution when I would design it. I would emotionally invest in the idea of my players discovering this clever solution that I had designed. As a result, I would tend to veto other potential solutions the players came up with — after all, if those other solutions worked they would never discover the clever solution I had come up with.

Over time, I’ve learned that it’s actually a lot more fun when the players surprise me. It’s the same reason I avoid fudging dice rolls to preserve whatever dramatic conceit I came up with. As a result, I now tend to think of my predesigned solution as a worst case scenario — the safety net that snaps into place when my players fail to come up with anything more interesting.

In order to be open to permissive clue-finding you first have to understand the underlying situation. (Who is the werewolf? How did he kill this victim? Why did he kill them? When did he kill them?) Then embrace the unexpected ideas and approaches the PCs will have, and lean on the permissive side when deciding whether or not they can find a clue you had never thought about before.

COROLLARY: PROACTIVE CLUES

A.K.A. Bash Them On the Head With It.

Sometimes, despite your best efforts, the players will work themselves into a dead-end: They don’t know what the clues mean or they’re ignoring the clues or they’ve used the clues to reach an incorrect conclusion and are now heading in completely the wrong direction. (When I’m using the Three Clue Rule, I find this will most often happen when the PCs don’t realize that there’s actually a mystery that needs to be solved — not every mystery is as obvious as a dead body, after all.)

This is when having a backup plan is useful. The problem in this scenario is that the PCs are being too passive — either because they don’t have the information they need or because they’re using the information in the wrong way. The solution, therefore, is to have something active happen to them.

Raymond Chandler’s advice for this kind of impasse was, “Have a guy with a gun walk through the door.”

My typical fallback is in the same vein: The bad guy finds out they’re the ones investigating the crime and sends someone to kill them or bribe them.

Another good one is “somebody else dies”. Or, in a more general sense, “the next part of the bad guy’s plan happens”. This has the effect of proactively creating a new location or event for the PCs to interact with.

The idea with all of these, of course, is not simply “have something happen”. You specifically want to have the event give them a new clue (or, better yet, multiple clues) that they can follow up on.

In a worst case scenario, though, you can design a final “Get Out of Jail Free” card that you can use to bring the scenario to a satisfactory close no matter how badly the PCs get bolloxed up. For example, in our werewolf mystery — if the PCs get completely lost — you could simply have the werewolf show up and try to kill them (because he thinks they’re “getting too close”). This is usually less than satisfactory, but at least it gets you out of a bad situation. It’s the final backup when all other backups have failed.

COROLLARY: RED HERRINGS ARE OVERRATED

Red herrings are a classic element of the mystery genre: All the evidence points towards X, but its a red herring! The real murderer is Y!

When it comes to designing a scenario for an RPG, however, red herrings are overrated. I’m not going to go so far as to say that you should never use them, but I will go so far as to say that you should only use them with extreme caution.

There are two reasons for this:

Red Herring

First, getting the players to make the deductions they’re supposed to make is hard enough. Throwing in a red herring just makes it all the harder. More importantly, however, once the players have reached a conclusion they’ll tend to latch onto it. It can be extremely difficult to convince them to let it go and re-assess the evidence. (One of the ways to make a red herring work is to make sure that there will be an absolutely incontrovertible refutation of it: For example, the murders continue even after the PCs arrest a suspect. Unfortunately, your concept of an “incontrovertible refutation” may hold just as much water as your concept of a “really obvious clue that cannot be missed.)

Second, there’s really no need for you to make up a red herring: The players are almost certainly going to take care of it for you. If you fill your adventure with nothing but clues pointing conclusively and decisively at the real killer, I can virtually guarantee you that the players will become suspicious of at least three other people before they figure out who’s really behind it all. They will become very attached to these suspicions and begin weaving complicated theories explaining how the evidence they have fits the suspect they want.

In other words, the big trick in designing a mystery scenario is to try to avoid a car wreck. Throwing red herrings into the mix is like boozing the players before putting them behind the wheel of the car.

COROLLARY: NOTHING IS FOOLPROOF

You’ve carefully laid out a scenario in which there are multiple paths to the solution with each step along each path supported by dozens of clues. You’ve even got a couple of proactive backup plans designed to get the PCs back on track if things should go awry.

Nothing could possibly go wrong!

… why do you even say things like that?

The truth is that you are either a mouse or a man and, sooner or later, your plans are going to go awry. When that happens, you’re going to want to be prepared for the possibility of spinning out new backup plans on the fly.

Here’s a quote from an excellent essay by Ben Robbins:

Normal weapons can’t kill the zombies. MicroMan doesn’t trust Captain Fury. The lake monster is really Old Man Wiggins in a rubber mask.

These are Revelations. They are things you want the players to find out so that they can make good choices or just understand what is going on in the game. Revelations advance the plot and make the game dramatically interesting. If the players don’t find them out (or don’t find them out at the right time) they can mess up your game.

I recommend this essay highly. It says pretty much everything I was planning to include in my discussion of this final corollary, so I’m not going to waste my time rephrasing something that’s already been written so well. Instead, I’ll satisfy myself by just quoting this piece of advice from it:

Write Your Revelations: Writing out your revelations ahead of time shows you how the game is going to flow. Once play starts things can get a little hectic – you may accidentally have the evil mastermind show up and deliver his ultimatum and stomp off again without remembering to drop that one key hint that leads the heroes to his base. If you’re lucky you recognize the omission and can backtrack. If you’re unlucky you don’t notice it at all, and you spend the rest of the game wondering why the players have such a different idea of what is going on than you do.

As we’ve discussed, one way to avoid this type of problem is to avoid having “one key hint” on which the adventure hinges. But the advice of “writing out your revelations ahead of time” is an excellent one. As Robbins says, this “should be a checklist or a trigger, not the whole explanation”.

What I recommend is listing each conclusion you want the players to reach. Under each conclusion, list every clue that might lead them to that conclusion. (This can also serve as a good design checklist to make sure you’ve got enough clues supporting every conclusion.) As the PCs receive the clues, check them off. (This lets you see, at a glance, if there are areas where the PCs are missing too many clues.)

Finally, listen carefully to what the players are saying to each other. When they’ve actually reached a particular conclusion, you can check the whole conclusion off your list. (Be careful not to check it off as soon as they consider it as a possibility. Only check it off once they’ve actually concluded that it’s true.)

If you see that too many clues for a conclusion are being missed, or that all the clues have been found but the players still haven’t figured it out, then you’ll know it’s probably time to start thinking about new clues that can be worked into the adventure.

THE FINAL WORD

Basically, what all of this boils down to is simple: Plan multiple paths to success. Encourage player ingenuity. Give yourself a failsafe.

And remember the Three Clue Rule: