Go to Part 1

The Three Clue Rule states:

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

The underlying theory behind the rule is that having three distinct options provides sufficient redundancy to create a robust scenario: Even if the PCs miss the first clue and misinterpret the second, the third clue provides a final safety net to keep the scenario on track.

This logic, however, also leads us to the inversion of the Three Clue Rule:

If the PCs have access to ANY three clues, they will reach at least ONE conclusion.

In other words, if you need the PCs to reach three conclusions (A, B, and C) and the PCs have access to three clues (each of which would theoretically allow them to reach one of those conclusions) then it is very likely that they will, in fact, reach at least one of those conclusions.

And understanding this inversion of the Three Clue Rule allows us to embrace the full flexibility of node-based design. Here’s a simple example:

The scenario starts in the blue node, which contains three clues – one pointing to node A, one to node B, and one to node C. Following the inverse of the Three Clue Rule, we therefore know that the PCs will be able to conclude that they need to go to at least one of these nodes.

Let’s assume they go to node A. Node A contains two additional clues – one pointing to node B and the other pointing to node C.

At this point the PCs have had access to 5 different clues. One of these has successfully led them to node A and can now be discarded. But this leaves them with four clues (two pointing to node B and two pointing to node C), and the inverse of the Three Clue Rule once again shows us that they have more than enough information to proceed on.

Let’s assume they now go to node C. Here they find clues to nodes A and B. They now have access to a total of seven clues. Four of these clues now point to nodes they have already visited, but that still leaves them with three clues pointing to node B. The Three Clue Rule itself shows that they now have access to enough information to finish the scenario.

(Note that we’re only talking about clue access here. That doesn’t mean that they’re guaranteed to find or correctly interpret every single clue. In fact, we’re assuming that they don’t.)

Now, compare this node-based design to a comparable plotted approach:

Note that the plotted approach can also be broken down into distinct nodes. And in terms of preparation, the plotted approach requires the exact same resources: Four nodes and nine clues. But the non-plotted design is richer, more flexible, and leaves the PCs in the driver’s seat. In other words, even in the simplest examples, node-based design allows you to get more mileage out of the same amount of work.

Of course, this entire discussion has been rather dry and technical. So let’s put some flesh on these bones.

Go to Part 1

Of course, it’s all well and good to say, “Prep Situations.” But one of the reasons people prefer the plotted approach is that it provides a meaningful structure: It tells you where you’re going and it gives you a way to get there.

Without that kind of structure, it’s really easy for a gaming session to derail. It’s certainly not impossible to simply turn the PCs loose, roll with the punches, and end up somewhere interesting. Similarly, it’s quite possible to jump in a car, drive aimlessly for a few hours, and have a really exciting time of it.

But it’s often useful to have a map of the territory.

This line of thought, however, often leads to a false dilemma. The logic goes something like this:

(1) I want my players to have meaningful choice.
(2) I need to have a structure for my adventure.
(3) Therefore, I need to prepare for each choice the players might make.

And the result is an exponentially expanding adventure path:

The problem with this design should be self-evident: You’re preparing 5 times as much material to supply the same amount of playing time. And most of the material you’re preparing will never be seen by the players.

In some ways, of course, this is an extreme example. You could simplify your task by collapsing some of these forks into each other:

But even here you’re designing eight steps worth of material in order to provide three steps of actual play. You’re still specifically designing material that you know will never be used.

And in other ways it’s actually not that extreme at all: The original example assumes that there are only two potential choices at any given point on the path. In reality, it’s quite possible for there to be three or four or even more – and each additional choice adds a whole new series of contingencies that you need to account for.

Ultimately, this sort of “Choose Your Own Adventure” prep is a dead end: No matter how much you try to predict ahead of time, your players will still find options you never considered — forcing you back into the position of artificially constraining their choices to keep your prep intact and leaving you with the exact same problem you were trying to solve in the first place. And even if that wasn’t true, you’re still burdening yourself with an overwrought preparation process filled with unnecessary work.

The solution to this problem is node-based scenario design. And the root of that solution lies in the inversion of the Three Clue Rule.

Go to Part 3: Inverting the Three Clue Rule

Most published adventures are designed around a structure that looks like this:

You start at the beginning (Blue), proceed through a series of linear scenes (Yellow), and eventually reach the end (Red).

Occasionally you may see someone get fancy and throw a pseudo-option into things:

But you’re still looking at an essentially linear path. Although the exact form of this linear path may vary depending on the adventure in question, ultimately this form of design is the plotted approach: A happens, then B happens, and then C happens.

The primary advantage of the plotted approach is its simplicity. It’s both easy to understand and easy to control. On the one hand, when you’re preparing the adventure it’s like putting together a scheduled to-do list or laying out the plot for a short story. While you’re running the adventure, on the other hand, you always know exactly where you are and exactly where you’re supposed to be going.

But the plotted approach has two major flaws:

First, it lacks flexibility. Every arrow on the plotted flow-chart is a chokepoint: If the players don’t follow that arrow (because they don’t want to or because they don’t realize they’re supposed to), then the adventure is going to grind to a painful halt.

The risk of this painful train wreck (or the necessity of railroading your players) can be mitigated by means of the Three Clue Rule. But when the Three Clue Rule is applied in a plotted structure, you run the risk of over-kill: Every yellow dot will contain three clues all pointing towards the next dot. If the players miss or misinterpret a couple of the clues, that’s fine. But if they find all of the clues in a smaller scene, they may feel as if you’re trying to spoon-feed them. (Which, ironically, may cause them to rebel against your best laid plans.)

Second, because it lacks flexibility, the plotted approach is inimical to meaningful player choice. In order for the plotted adventure to work, the PCs must follow the arrows. Choices which don’t follow the arrows will break the game.

This is why I say Don’t Prep Plots, Prep Situations.

This, like pretty much everything Google does, is really cool. But either I’m becoming an old fogey, or the fact that Google continues to make us more and more reliant on content that exists only on their servers makes me nervous.

In pondering the implications of the AIs in Greg Egan’s Diaspora immersing themselves so completely in virtual realities that they forgot about the real world, I found a simple saying: “You should never forget where your plug is.” The virtual reality may be indistinguishable from the real world in every way while being filled with endless possibilities far beyond the scope of anything the real world may be able to offer: But if the sun goes supernova in the real world, you’re still going to die, no matter how deeply nestled you’ve become in your artificial life.

In reflecting on cloud computing I think it’s equally important to say: “You should never forget where your data is.”

Because the “cloud” is increasingly becoming a buzz word that means, “If Google ever goes away or chooses to shut down a server or decides to start charging for a service, then you’re all screwed.”

Don’t get me wrong: I use GMail, Google Calendar, and Google Reader. I watch videos on Youtube. I search prices on Froogle. Google Books (along with the Internet Archive) is literally revolutionary in making information widely and rapidly accessible. I’m even convinced that Google Wave has the opportunity to replace e-mail. (Although, notably, one of the reasons I believe that is because Wave is an open protocol and not dependent on Google’s servers.)

But whenever I hear about somebody who has lost their entire blog because their hosting company has gone out of business or failed to back up their servers properly, I’m reminded of the importance of knowing where your data is. The Alexandrian, for example, is actually designed so that the primary copy of every document is kept on my local computer. The website itself is the first of several back-ups. And even though that isn’t an option for many blogs, you should still make a point of making a local back-up on a regular basis.

The same applies to anyone who’s keeping their data exclusively on Google Docs, Flickr, Facebook, or anywhere else on the web. The utility of being able to access and manipulate your data from anywhere is great, but the importance of both knowing and controlling the physical location of your data just cannot be stressed enough.

Which is why, for example, I can’t get excited for Google Chrome OS. In fact, it’s why I can’t figure out why anybody is excited about it. This is an operating system which fails to offer even a single unique feature: Everything it can do, other operating systems already do. In fact, the only thing it can uniquely claim to do is to make your computer completely reliant on the “cloud” — in other words, to force you to give up your control over your own data. For some reason this is supposed to be a “feature”, but I can’t fathom what advantage anyone thinks they’re going to get out of it.

Keep on the Shadowfell was the inaugural introductory product for 4th Edition. When it was released, I shared my initial impressions and eventually ended up writing a lengthy series of essays in which I remixed the entire adventure.

One of the major problems I had at the time was the sheer sloppiness of the module: There were continuity errors in the adventure scenario and numerous self-contradictions in the rules. Ignoring some of the larger creative and structural issues with the adventure, on a very basic level the product was a mess.

In April 2009, Wizards of the Coast released a revised version of the module as a free PDF on their website. I didn’t pay much attention to it because I had already sampled 4th Edition, found it lacking in everything I value in an RPG, and moved on. But I did think it was a rather nice gesture on WotC’s part to make a corrected version of the product available.

Recently, however, I decided to re-visit this material with an eye towards using my remixed version of the module as the basis for an OD&D one-shot. Remembering that the module had been revised, I tracked down the PDF. My plan was to re-read the revised version of the module, see what had been improved, and then adapt my remix notes as necessary if I thought incorporating the changes would be worthwhile.

Unfortunately, I couldn’t even get past the first paragraph of the first encounter before discovering that WotC’s revision was just as sloppy as the original product.

The original module describes the encounter like this (pg. 16): “The player characters are on the King’s Road traveling toward Winterhaven east to west (or right to left on the map).” They are then ambushed by kobolds, as shown on this map:

The obvious problem, as I detailed in my original remix essay, is that the indicated kobolds are all standing in plain sight for characters traveling east to west along the road.

WotC’s keen-eyed revisers noticed the same thing, but they didn’t want to redo the cartography. So they opted to simply change the direction that the PCs are traveling (pg. 6): “The player characters are on the King’s Road traveling toward Winterhaven, west to east (or left to right on the map).”

Problem solved!

… except that’s completely impossible.

Because two pages earlier in the module we can see this map of the local area:

And, as you can clearly see, Winterhaven is at the western end of the King’s Road. You cannot travel west-to-east anywhere on the King’s Road and end up at Winterhaven.

Mistakes, of course, get made. (For example, both the original and revised versions of the module refer multiple times to the Burial Site being southwest of town. You’ll note that it isn’t.) But what you have here is an acknowledgment that there is a problem that needs to be fixed; a decision being made (either deliberately or ignorantly) to not fix the root of the problem; and ending up with a half-assed effort that just creates an entirely different problem.

And it doesn’t even fix the original problem, because there are still kobolds standing in plain sight.

This is symptomatic of WotC’s general culture of not-fixing (or even anti-fixing).