Desert Orange asks:

I’m trying to use node-based scenario design for the first time. I’m designing a Hangover-style scenario on a superyacht: the PCs wake up on the ship surrounded by corpses and with no memory of how they got there.

If I’m using a funnel design, is it possible to only have two nodes before the first funnel? There’d only be two clues per node. That can’t be right. But what bugs me is that I only have two locations for the PCs to explore: the ship they’re on and the island that’s nearby.

I’m not sure if I should use the locations as nodes or the conclusions that the characters have to reach. The funnel would be figuring out how the previous night ended. After this, they’d begin figuring out how it started.

Easy answer first: If you’re designing a node-based mystery, think of each node as a place where you can investigate for clues.

Each node (other than the starting node) is also a revelation/conclusion because the players have to conclude that they can go to the node and investigate. (The three clues pointing to Node X are basically pointing to a conclusion which says, “You can find more clues at Node X.”)

But in a mystery scenario you can also have conclusions that aren’t nodes – i.e., things that the PCs need to learn that aren’t places they can go to investigate for more clues.

In my more recent writing, I’ve started referring to clues that point to places where you can continue your investigation as leads – they lead you somewhere. In node-based design it’s the leads that need to adhere to the Inverse Three Clue Rule:

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

Because as long as the PCs have somewhere to continue investigating the mystery, the adventure keeps working. It’s only if they run out of places to investigate that the adventure breaks.

So in your Hangover cruise adventure, for example, you’ll have a list of revelations which consist of Things That Happened To Us That We’ve Forgotten. And you’ll want clues for each of those (and three clues for any that the PCs need to know about). Those probably aren’t leads.

NOT ALL MYSTERIES HAVE NODES

But here’s the thing: I don’t think your mystery is actually a node-based scenario. At least not at first.

The PCs are not trying to figure out where to look for clues: The clues are on the ship.

So what you actually have is a location-crawl in which they explore the ship room by room, finding clues in each room. You’re still using the Three Clue Rule:

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

And you’ll have a revelation list so that the PCs can piece together what happened to them, but the players aren’t really finding clues in the helm station that tell them they should check out the stern deck for clues. They’re just methodically searching the ship for clues (while also potentially dealing with other crises or conundrums).

(This isn’t to say that a location-crawl can’t have clues in Room A that point the PCs to Room B, for example. That’s a great way to make a location-crawl feel cohesive and, if those clues are revealing hidden secrets that the PCs might have missed in Room B the first time they went, can add a lot of depth to the experience. But that’s not really node-based design and doesn’t structurally function as a node-based adventure.)

Now if there are clues on the ship that point the PCs to another location where they need to continue their investigation, that would suggest a node-based design. (Maybe they need to realize that the superyacht was at a different location at some point last night and they need to go there. Or they discover the ritual that opened a gateway to a dark dimension that they need to go back to in order to continue piecing things together.) But I still wouldn’t try to break the ship up into multiple nodes: The superyacht as a whole would just be one node, with that node basically being a mini-location-crawl inside the larger scenario.

You’d mentioned that you wanted the scenario to start with them figuring out how the previous night ended and then, after that, they’d begin figuring out how it started. You can see how this structure would essentially accomplish that: The superyacht has all the clues that let them figure out how the previous night ended, which allows them to figure out where the night started (i.e., the other node where they can look for the clues to figure out what happened there).

In fact, this node-based scenario might consist of just these two nodes: The superyacht and where the night started.

There’s nothing about node-based design that says you have to get super-complicated about it.

REGARDING FUNNELS

Although I don’t think it necessarily applies to this scenario, let’s talk about your specific question regarding funnel design for a moment: The key thing about the Inverse Three Clue Rule is that the PCs should have access to at least three clues at all time.

(This doesn’t necessarily mean they will FIND all those clues. The whole reason you have redundancy is in case they don’t, after all. But they should have ACCESS to them, by which I mean that in locations which the PCs know about, there should be at least three clues pointing to locations that they don’t already know about. Or, in the final scene(s) of a scenario where they’ve almost finished their investigation, three clues that point to all the conclusion(s) they need to bring the scenario to its conclusion.)

In addition, the Three Clue Rule still applies! You still need three clues for each conclusion the PCs need to reach!

So your current structure is:

• Node 0 ➞ A, B
• Node A ➞ B, C
• Node B ➞ A, C
• Node C

We can immediately see that in Node 0 (the opening scene) they only have access to two clues. That’s a structural problem which violates the Inverse Three Clue Rule.

In addition, you basically have three conclusions:

• You need to investigate Node A.
• You need to investigate Node B.
• You need to investigate Node C.

But for each of those conclusions, there are only two clues, which means you’ve violated the Three Clue Rule.

Adding enough clues to satisfy the Three Clue Rule will, conveniently, also satisfy the Inverse Three Clue Rule. Here’s a symmetrical example:

• Node 0 ➞ A, A, B
• Node A ➞ B, B, C
• Node B ➞ A, C, C
• Node C

You could also saturate the opening scene:

• Node 0 ➞ A, A, B, B
• Node A ➞ B, C
• Node B ➞ A, C, C
• Node C

And other patterns are also possible:

• Node 0 ➞ A, A, A, B
• Node A ➞ B, B, C
• Node B ➞ C, C
• Node C

If you walk through these simple node structures, you can clearly see how the PCs always have access to three clues pointing towards nodes they haven’t investigated yet.

You may also be able to see how different patterns of clues will make certain paths through the adventure more or less likely. For example, in the third arrangement it’s much more likely that the PCs will end up going 0 ➞ A ➞ B ➞ C, but if they DO go from 0 ➞ B, then it becomes likely they’ll never go to Node A.

If you’re dabbling with node-based scenario design for the first time, I recommend doing a couple of symmetric designs first. It will give you more reliable results and a better sense, after running the scenarios, of what node-based scenarios “feel” like.

Go to Ask the Alexandrian #4