Node-Based Scenario Design describes an ultra-flexible structure for designing scenarios based primarily around the acquisition and flow of knowledge: When the PCs learn about a node, they can go to that node and, usually, find information that will let them learn about more nodes (which they can then go to and find more information).

The structure is extensible, very robust, and lends itself naturally to mystery scenarios, which are based around the acquisition of knowledge – i.e., the information you gain in a node comes in the form of clues (or leads) that point to other nodes where you can continue the investigation. However, GMs who use node-based scenario design often find its usefulness extends far beyond simply traditional mystery stories, as it turns out that the basic concept of “things which are connected to each other” has a fairly broad application.

The original essay included some simple examples of how node-based scenario design works (most notably the Las Vegas CTU scenario in Part 3 of the series), but those really only scratched the surface of what you can do with the structure. Plus, I’ve spent another ten years learning new tricks and techniques. So now it’s time for a little applied theory as we dive into some examples of how the node-based structure can be used in actual practice.

REALLY PRACTICAL EXAMPLES

If you just want to see full scenarios featuring node-based scenario design, here’s a quick reading list.

The Masks of Nyalathotep is a classic Call of Cthulhu campaign by Larry DiTillio & Lynn Willis. It had a major influence on codifying the Three Clue Rule and is also a great ante-example of node-based scenario design at a campaign-wide level.

Eternal Lies by Will Hindmarch, Jeff Tidball, and Jeremy Keller is a Trail of Cthulhu campaign inspired by The Masks of Nyalarthotep. I did an Alexandrian Remix of the campaign, which is probably one of the most comprehensive examples of how I prep a node-based campaign currently available.

Quantronic Heat is a three-part adventure series for the Infinity Roleplaying Game designed by Nick Bate and myself (mostly Nick). The first adventure, “Conception,” in particular, is a very clean example of scenario-level node-based design.

Here on the Alexandrian, you can check out The Strange: Violet Spiral Gambit. This is another very clean example of scenario-level node-based design, serving as a pretty good Platonic ideal of what a node-based mystery scenario looks like. Other examples on the site include Gamma World: The Egyptian Incursion, Star Wars: Red Peace, and Eclipse Phase: Psi-chosis.

Welcome to the Island is an adventure anthology for Over the Edge that I was lead developer for. The scenario I co-wrote for the book (“Seversen’s Mysterious Estate,” with Jonathan Tweet) isn’t node-based (it uses the party-planning scenario structure), but most of the other scenarios in the book do use node-based design, often adulterated with other scenario structures. For example, Jeremy Tuohy’s “Battle of the Bands” has the PCs trying to reunite a pop-punk band from the mid-2000s, with each band member being a node that they need to track down.

NODES VS. REVELATION LISTS

What is a node?

In Part 9 of Node-Based Scenario Design I list five types of nodes:

• Locations
• Characters
• Organizations
• Events
• Activities

Activities have proven to be exceedingly rare in my scenario design (maybe your mileage will vary). In any case, I tend to think of nodes as things that the PCs can go and interact with.

PROACTIVE NODES

There are also proactive nodes which typically do the opposite: They come to the PCs and interact with them.

Proactive nodes are usually characters. I often think of them as the “response teams” of a scenario. This is frequently literal, with my proactive nodes being the people who are sent to deal with the PCs once the bad guys realize they’re snooping around. But it’s also a useful metaphor: Proactive nodes are the easiest tools I can use as the GM to take action at the table instead of simply reacting.

What about other proactive nodes?

Well, locations tend to be stationary and rarely follow people around… unless you apply sufficiently advanced technology and/or magic. The technology doesn’t really need to be all that advanced, either: An abandoned ghost ship drifting into the town’s harbor can easily be a proactive node.

Organizations can be proactive in their responses, but the response usually takes the form of a specific response team (which would usually be the actual, character-based proactive node).

Events can be proactive if they’re of a sufficiently large scale or if they’re specifically targeted at the PCs: A city-wide festival or a ritual that causes all the trees in the forest to start weeping blood count as the former. A series of enigmatic phone calls that ring up a PC’s cellphone would be an example of the latter.

Almost anything can be a proactive node if it can be framed as information being pushed on the PCs. For example, if the PCs are cops investigating a series of bank robberies, they would be automatically notified if a new bank robbery took place. (Is this an event or a location? Both? Does it matter? Don’t get too obsessed with the categories here.)

In addition to creating a living world where there are both long-term and short-term reactions to the PCs’ choices, proactive nodes also have the practical function of getting a scenario back on track. For example, if the PCs have missed all the clues pointing to a particular revelation, a proactive node can be used to provide a fresh lead.

REVELATION LISTS

On that note, a revelation is any conclusion that the PCs can make or need to make in the scenario (see the Three Clue Rule and Using Revelation Lists for more information).

A revelation can be a node (i.e., “we need to go check out that location / character / organization / event”), but it can also be stuff that isn’t a node (i.e., “the runes are Achaean” or “the rage-wraiths can be kept at bay by the smoke of burning wisteria”).

In my more recent work, I’ve started talking about evidence & leads, where leads point you to places where you can continue investigating (i.e., new nodes) and evidence points to other types of revelations (often the solution to the mystery; e.g., Bob’s the killer). In practice, though, these can often overlap. “Bob’s the killer” is a mystery solution which also points at Bob (who, as a character, might be thought of as a node). Furthermore, for a satisfying mystery you’d probably want to establish Bob before revealing he’s a killer, so there’s a “Bob exists / is here / is involved” revelation that points to Bob-as-a-node and then a “Bob did it” revelation that points to the Bob-as-solution.

I think it’s useful to separate the node-based list of revelations from the list of other revelations. I just find this to be conceptually clearer. (This assumes that there ARE non-node revelations. That won’t always be the case. Pure procedurals and breadcrumb-style mysteries often have a 100% overlap between revelations and nodes. This also tends to be true for non-mystery scenarios.)

In any case, your node list will most often be simply copy-pasted into your revelation list, with a couple notable exceptions:

The initial node that begins a scenario almost never requires a revelation list. The exception are scenarios with multiple points of entry, in which case you may want the investigation from one entry node to potentially lead to other entry nodes. (This is also only true within the context of the scenario itself: The PCs might actually be led to the initial node of a scenario by the revelation list of another scenario. More on that when we discuss fractal nodes and node-based campaigns below.)

Proactive nodes usually don’t have a revelation list, either. These nodes are designed to come looking for the PCs, after all, so they don’t necessarily require a mechanism that will lead the PCs to them. (Many nodes, of course, could be both. I tend to just list those as normal nodes and then opportunistically play them as proactive when or if it comes up.) What I will do for proactive nodes, though, is include a list of them in my prep notes with the likely triggers that will cause them to take action and/or become available for action. These triggers can include stuff like:

• Monitoring Avery Hall [and might therefore spot the PCs investigating Avery]
• Sent to kill Avery Hall [potentially while the PCs are talking to Avery]
• Staking out Node 1, Node 2, or Node 6
• Notified by Avery [if she becomes aware of the PCs]
• Sent by Avery if she learns they know about the jade statue
• Trigger randomly as the PCs are traveling between locations
• Respond to any violence in the neighborhood in 1d6+10 minutes

These triggers aren’t really a binding list. They’re more of a quick personal reminder for how particular tools can be used.

Go to Part 2: Node-Based Campaigns

THE SECRET LIFE OF NODES
Part 1: Secret Life of Nodes
Part 2: Node-Based Campaigns
Part 3: Fractal Nodes
Part 4: Nodes Aren’t Everything
Part 5: Naturalistic Node Design

Many people are familiar with the 5 Room Dungeon. It’s a simple little structure that you can very quickly pour content into, allowing you to create simple dungeon scenarios on the fly. Basically you design a dungeon with 5 rooms, and in those rooms you place:

• Room 1: Entrance And Guardian
• Room 2: Puzzle Or Roleplaying Challenge
• Room 3: Red Herring
• Room 4: Climax, Big Battle Or Conflict
• Room 5: Plot Twist

Depending on the system you’re using and exactly what you stock each room with, this should produce about 2-4 hours of game play.

Personally, I’m not a huge fan of the 5 Room Dungeon: Partially because its structure is too rigid (which results in effective material, but also very predictable material if you use it too frequently). And partially because a remarkable number of people preach it as the one-true-way of dungeon design (which isn’t really the fault of the structure itself, but combines rather horribly with the first problem).

But what the 5 Room Dungeon does a very good job of demonstrating is how valuable it can be to have a simple structure like this in your back pocket. Not only does it let you very quickly (and very effectively) prep simple scenarios, it’s also incredibly useful when you need to start improvising during a session: You can very quickly brainstorm ideas, paste them into the proven scenario structure, and know that the result is, on a basic level, going to work.

I’ve got a similar structure that I default to whenever I’m looking to whip up something simple and quick. I’ve come to call it…

THE 5 NODE MYSTERY

The 5 Node Mystery structure arose pretty much completely independently from the 5 Room Dungeon, but the repetition of the number 5 isn’t really coincidence: Five good, meaty chunks of interactive material is pretty much what you need to fill an evening of gaming. The interaction between five different elements is also roughly the bare minimum complexity required to create something more meaningful than a solitary random encounter. Nothing wrong with a random encounter, of course, but if you’re looking for the next step up — if, for example, you’re interested in what the random encounter might lead to — then this is basically what you’re looking for.

You use the 5 Node Mystery when you want a simple, fairly straight-forward investigation. It uses node-based scenario design and it works like this:

1. Figure out what the mystery is about. Was someone murdered? Was something stolen? Who did it? Why did they do it?

2. What’s the hook? How do the PCs become aware that there’s a mystery to be solved? If it’s a crime, this will usually be the scene of the crime. It could also be “place where weird shit is happening”. Or maybe someone or something comes to the PCs and brings the mystery with them. (Thugs kicking down the door is a classic.)

3. What’s the conclusion? Where do they learn the ultimate answers and/or get into a big fight with the bad guy? (Big fights with bad guys are a really easy way to manufacture a satisfying conclusion.) This will be your Node E.

4. Brainstorm three cool locations or people related to the mystery. Ex-wife of the bad guy? Drug den filled with werewolves? Stone circle that serves as a teleport gate? These will be your Nodes B, C, and D. (Hint: Brainstorm more than three items. Then pick the three coolest ideas. You’ll end up with better stuff. Also: Before you toss the other ideas, see if there’s any way that you can combine them with the three you picked and make them even cooler.)

5. You’ve got five nodes. Connect ’em with clues. The default structure looks like this:

The basic idea here is that Node A points you in three different directions (although, remember, the PCs might find only one of the clues). Then those three locations point to each other and also point towards the big conclusion. Simple.

You’ll also find that the precise structure of the 5 Node Mystery is easy to modify on the fly. In some cases, you’ll find that the nature of the scenario will pretty much dictate the pattern of the clues. (For example, while working on the Violet Spiral Gambit — which was designed in a few hours using this structure — I discovered that it made more sense for the initial node to point to two locations and then have those two locations point to a third. Then I loaded up that third location with a bunch of different clues all pointing to the conclusion.) About the only thing you should avoid as a general rule are clues pointing directly from Node A to your conclusion.

There is a possibility in this structure, of course, for the PCs to go from Node A to Node B to Node E (skipping Nodes C and D). In some cases, the scenario will be modular enough that this just means the conclusion isn’t what you thought it was. (You thought the conclusion was a big showdown with a bad guy in the violet tower at the center of the graveyard. Turns out, it was actually a rooftop chase as the badly injured PCs try to escape the werewolves from the drug den.) In other cases, the nodes left behind the PCs will metastasize into new adventures — either because the werewolves end up causing trouble or because when the PCs go back to mop-up the werewolves they’ll find clues pointing them to other scenarios.

THE 5 x 5 NODE CAMPAIGN

Seasoning your scenario with clues pointing to other scenarios is actually a pretty good way to start expanding from 5 Node Mysteries into designing more interwoven campaigns.

1. Design five 5 Node Mysteries. You might have some idea about how they all relate to each other as you’re designing them, but maybe not. Discovering how seemingly unrelated things are actually connected to each other is a great way to make both things richer and more interesting.

2. Arrange the 5 Mysteries into the same node pattern. In other words, Mystery A will have clues pointing to Mysteries B, C, and D. Mystery B will have clues pointing to Mysteries C, D, and E. And so forth. (If you didn’t already know how the mysteries related to each other, the process of figuring out how clues for Mystery D ended up over in Mystery B is the part where you’re going to figure that out.)

As you’re seeding your clues into each mystery, mix it up a bit. Some clues will be the “pay-off” for solving the first mystery: You’ve taken out El Pajarero, but who was he really working for?! But don’t fall into the trap of always putting the clues in the concluding node. Spread ’em around a bit.

And that’s basically it. It’s a very simple technique for you to use, but you’ll find that (much like the technique of the second track) it creates experiences for your players which are complicated, interesting, and ornate.

FURTHER READING
Game Structures
Node-Based Scenario Design
Gamemastery 101

Go to Part 1

It’s a fairly typical piece of advice for neophyte GMs that they can design scenarios “just like dungeons”: Replace each room with a location or scene; replace each door with a clue.

The logic behind this approach is fairly clear: Most GMs get started by running dungeon scenarios, most GMs are very successful in running dungeon scenarios, and most GMs find it relatively easy to prep dungeon scenarios.

(The reason for this is the dungeon’s clarity of structure, self-controlled pacing, and robust design. But that’s largely a topic for another day.)

But this analogy is problematic from both directions. First, as we discussed previously, doors or hallways in a dungeon are a robust transition:

If you’re standing in a room, the presence of a door or hallway into the next room is generally obvious and its purpose self-evident. Clues, on the other hand, are fragile in isolation: They can be missed, mistaken, or ignored.

Clues also allow for omni-directional relationships. A dungeon room, however, typically can’t have a door to another location on the opposite side of the dungeon. The geography of the dungeon is rigid (and usually reversible). The geography of a mystery can be flexible (and is often one-way).

So, in general, I think – despite its ubiquity – this is actually really bad advice to give to neophyte GMs.

ROBUST STRUCTURES: But there are lessons that can be learned from the analogy.

First, dungeons work because the doors are robust transitions. Ergo, we should try to find equally robust transitions in other scenario structures. The Three Clue Rule, for example, is a way of accomplishing that with a mystery scenario.

Similarly, as we’ve discussed before, it’s possible for the typical robustness of the dungeon geography to mislead us into a false sense of complacency: A mandatory secret door, for example, can create a very fragile dungeon structure. That’s something to be aware of when designing dungeon scenarios.

EPHEMERAL BARRIERS: Consider our simple dungeon example again:

Note that the structure of the dungeon essentially “forces” the players to experience area B: If they could pass directly from area A to their goal in area C, they would. In this sense, area B functions as a “barrier” for the PCs.

Most dungeons are filled with such “barrier content” – content experienced only because the PCs are forced to physically move through those areas in order to reach the areas they want to go to.

But as the PCs gain resources to become proactive, the GM can’t just put barriers in their way. This is why high-level dungeons so often fail: The PCs can simply scry, fly, stoneshape, and/or teleport their way past the old geographical or terrain-based barriers the GM was once able to use to force them into experiencing content.

Some think empowering players like this is a bug. I tend to think of it as a feature. But it does mean that if you want your players to take a journey, you’ll need to make each pit stop interesting. Actually, more than interesting: Each pit stop needs to become a center of gravity, capable of drawing the PCs in for a closer look.

This is where applying some of the lessons you’ve learned from node-based scenario design can be usefully applied to your dungeon scenarios: Effective node-based design, after all, is all about creating centers of gravity for your nodes.

In designing your dungeons, look at each room or major area: Is there a way to make the PCs want to go there and experience that content? Or, alternatively, is there a way to make the content proactive so that it will come and seek out the PCs?

CLUE-BASED DUNGEON NAVIGATION: Consider, too, what happens when you bring clue-based navigation into the dungeon.

For example, the players might find a diary indicating that a “silver throne” can be “pushed aside to reveal a staircase”. Such a clue can easily send them to rooms on the opposite side of the complex, leave them looking for more information about the location of silver thrones, or anything inbetween.

In other words, dungeons can be thought of as a collection of nodes (with each room or area being a separate node). Traditionally we default to thinking of the transition between these dungeon nodes as strictly a geographical affair. Occasionally we may also throw in some randomly-triggered content, but even when we do that, we’re still limiting ourselves. There’s no reason we can’t lace a dungeon scenario with other forms of node navigation: Clues, temporally-triggered events, proactive content, trails, and the like.

The result is a richer and more rewarding dungeon scenario that will keep your players engaged in a multitude of ways.

Go to The Secret Life of Nodes

FURTHER READING
Using Revelation Lists
Game Structures
Hexcrawls
5 Node Mystery
Gamemastery 101

Go to Part 1

I’ve often found it useful to think of mystery-based scenarios as having two “prongs”: First, the clues required to figure out what happened or is happening (the concept solve). Second, the clues that take the PCs to another location or event where more clues can be gathered (the scenario solve).

This is somewhat similar, of course, to the concept of the Second Track, but where a second track presents a secondary set of nodes, here I’m talking about using a single node structure containing two sets of clues.

In practice, of course, you’ll often end up with quite a bit of overlap between the two sets of clues: When the players discover that Altair Electronics is somehow involved with the recent string of cyber-jackings, that tells the players something about what’s going on, but it will also point them in the direction of Altair’s corporate headquarters.

On the other hand, of course, there’s also the exception which proves the Three Clue Rule: In certain mystery structures you can actually be certain that the PCs will know about some locations without needing three clues. (Or any clues.) For example, if they’re police officers tracking bank robbers and another bank gets robbed, they’re going to get called to that location.

In such scenarios, of course, you can simply focus on delivering the clues necessary to reveal the mystery. (With three clues per necessary revelation.) But when faced with a more traditional two-prong approach, the important thing to understand is that you can spread the clues necessary to solve the mystery thinly (as long as you include the necessary density of clues to keep PCs moving from node to node). There may be entire nodes where there are no clues for unraveling the deeper mystery – just clues for moving on to the next node (where, hopefully, answers can be found).

How thin can you go? Well, it depends on what effect you’re trying to achieve. If you’ve got a mystery that’s serving as the metaplot of an entire campaign, for example, you may be spreading those clues very thin indeed.

Another option, of course, is to vary the clue density. Nodes that are difficult to find or difficult to exploit (due to armed resistance, for example) might offer more rewards in terms of mystery-solving clues.

Or perhaps the deeper you move into a conspiracy, the more clues you might discover. For example, the early stages of a layer cake node design might have only sparse or enigmatic clues. The deeper you move into the scenario, however, the thicker and more explicit the clues might become.

Conversely, it’s important to remember not to mistake mystery-solving clues for node-transition clues. What I mean is that including a mystery-solving clue in a node doesn’t actually satisfy the Inverted Three Clue Rule: If it isn’t helping you find another node, then it doesn’t count towards the “necessary” quota of clues for keeping the adventure in motion.

Go to Part 6: Node-Based Dungeons

Go to Part 1

Something I touched on lightly when discussing the organization of your nodes was the difficulty of working with large networks of nodes.

This ties into Delta’s “Magic Number Seven”, which I’ve talked about before. To sum it up:

1. Working memory capacity for most adults is in the range of 7 +/- 2 objects. Short-term memory capacity is also 7 +/- 2 when memorizing strings of random digits.
2. Beyond these limits, mental functioning drops off rapidly.

In other words, we are generally pretty good at holding somewhere between 5 and 9 objects in our mind at a given time. Any more than that and it becomes increasingly difficult (or impossible).

So if you start trying to tackle large networks of nodes, you can quickly reach a point at which you can’t keep the whole network “in your head” at the same time. At this point, the network becomes difficult to design and manage (particularly in real-time at a game table).

Properly organizing your network can make it easier to manage, of course. (The Act I structure I posted, for example, took 15 difficult-to-manage nodes and broke them down into 6 major nodes with a varying number of sub-nodes. I could easily grasp the structure of the 6 major nodes and then “zoom in” to focus on the sub-nodes as necessary.)

But this principle also offers us an opportunity as designers: A quick and easy way to add complexity to a node-based scenario is to simply add a second set of nodes that are largely or entirely disconnected from the first set.

I call this technique the Second Track.

In my experience, it’s particularly easy to run a second track if the tracks use different methods of linking their nodes. For example, you might create a timeline of “backdrop events” combined with a primary network of clue-linked nodes. But this division of methods isn’t strictly necessary.

The reason this works well is that, from your perspective behind the screen, there are just two “chunks” of 4-6 nodes each: Easy to keep track of. Easy to understand. Easy to design. Easy to run.

But for the players – who aren’t privy to that structure – there are 10-12 nodes. This pushes it past the Magic Number Seven and presents them with enough complexity to become enigmatic.

(To put it a different way: The GM can easily handle the reactions of Conspiracy 1 independently from the reactions of Conspiracy 2. Until the players figure out that there are two different conspiracies, however, they can’t even start to unravel what’s happening to them.)

Go to Part 5: The Two Prongs of Mystery Design