The concept of an RPG sandbox campaign often gets mixed up with a lot of other things. Some of these are common structures used for sandboxes (like hexcrawls). Others are just misnomers (like sandboxes being the opposite of a railroad).

(Quick definition: A sandbox campaign is one in which the players are empowered to either choose or define what their next scenario is going to be. Hexcrawls are a common sandbox structure because geographical navigation becomes a default method for choosing scenarios, which are keyed to the hexes you’re navigating between.)

Other conflations are subtler. A particularly common one is to conflate simulationism with the sandbox structure. One major appeal of the sandbox can be that it allows players to feel as if they’re “living in the world” because they’re free to do “anything,” which has a fairly large overlap with what people enjoy about simulationism.

But simulationism is not required for sandbox play.

A good example of this is the chardalyn dragon from Icewind Dale: Rime of the Frostmaiden.

SPOILER WARNING!

When the PCs approach a particular location on the map (Xardorok’s fortress), this triggers an event in which the dragon flies away to cause some havoc. In discussing this as part of a sandbox scenario, I was challenged: How could it be a sandbox if it was dramatically triggered by the PCs’ approach?

(Note: I’m just talking about triggering the dragon flight here. Shortly thereafter Rime of the Frostmaiden ALSO has an NPC show up to trigger a linear plot that ends the sandbox. I’m not talking about her. Just the dragon.)

The confusion here is due to the conflation of the sandbox structure and simulationism. A simulationist wouldn’t trigger the dragon based on the PCs’ approach. They’d probably do something like have Xardorok’s construction of the dragon be on a schedule with the dragon being released when Xardorok completes it, regardless of whether or not the PCs have found Xardorok’s fortress yet. (There are also other simulationist techniques that could be used here.)

But a sandbox isn’t dependent on simulationism. There’s nothing about dramatically triggering an event which is incompatible with the players remaining empowered to choose and define their scenario.

Go to Icewind Dale Index

Go to Part 1

An idea we’ve sort of been flirting with here is that node-based design is fundamentally fractal: You can “zoom in” on a node and break it apart into more nodes. Or, conversely, you can “zoom out” of the local collection of nodes you’ve been adventuring in and discover it’s all part of just ONE node in a much larger web.

For example, let’s consider the Lytekkas vampire hypercorp:

• At the highest level, we map their activity across seven cities: Chicago, the Old Angeles arcology, Shanghai, St. Petersburg, Reykjavik, Cheltenham, and the Lytekkas-Auberjonais L1 colony.
• Pick one of those and open it up: Now you’ve got nodes representing all of Lytekkas’ major projects in the Chicago metroplex. (These would also have connections to the other cities.)
• One of these involves the development of experimental blood-nannies (probably derived from the vampiric virus to mass-Renfield the population; or maybe an effort to control the negative side-effects of being a vampire).
• Look inside that node and you find the half dozen or so people and facilities involved in the program.
• The PCs identify and target a Lytekkas warehouse. This node is a heist scenario. There are elements of a heist scenario that are node-like, but it’s really a different structure, so this is the end of the road.
• … or is it? Part of the heist scenario is the opportunity to secure blueprints of the target. We could resolve that with a skill check, but we could also design it as a micro-node-based scenario.

But you can also flip this whole thing around and see that the Lytekkas hypercorp is just one of the immortal corporations which can track their secret history from the 22^nd century back to the Dutch East India Company in the 17^th century, with each one of those immortal corporations being a separate node.

This fractal quality can be seen not just in the nodes themselves, but in the connections between those nodes: There’s functionally no limit to how many leads can be placed in a single node, nor in how many leads can be created that point to a node. There is always an opportunity to increase the complexity and interconnectedness of your node map, particularly if we’re talking about an ongoing campaign which is developing over time (and, thus, features connections being formed and broken over time).

At this point the pedants may point out that this isn’t truly fractal because there is a limit to how far we can take this: At some point we’ll end up with a node which is a person; which is a sole entity that cannot be subdivided.

But it’s more true than you might think: Even individuals can be reconceptualized as a node-based scenario consisting of their job, connections, family, etc. The question is not whether you can do this, but whether it is interesting to do so.

MANIFESTING & MANAGING COMPLEXITY

This fractal nature of node-based scenario design, as we’ve seen, allows us to manifest an almost limitless amount of complexity. That can be quite daunting.

But it also allows us to manage this complexity. One of the functions of node-based design is specifically to chunk information into manageable nodes so that you don’t have to try to juggle or keep the whole thing in your head at once.

If you’re getting overwhelmed by trying to handle all seventy nodes of the Lytekkas hypercorp, figure out how to categorize those nodes into manageable groups: By city of operation. Or secret projects. Or corporate division.

The “right” division is going to depend on your own personal preferences and the details of the specific scenario. You’re looking for the clear conceptual chunks that will allow you to keep on top of incredibly complicated campaigns, while ideally only needing to think about one chunk of the scenario or campaign at a time. (I talk a bit more about what the manageable limits for this are in Advanced Node-Based Design – Part 4: The Second Track.)

For a rough-and-ready example of this, let’s consider the Bangkok node in the Eternal Lies Remix. In my prep notes, you can see that I identified five nodes:

1. Lowman’s Townhouse
2. Phikhat Hwan
3. Ko Kruk Island
4. Sirikhan Estate
5. Savitree Hunts the Investigators

The first two nodes are pretty standard node-based design: They’re distinct locations with (at least) three clues pointing at each.

But Ko Kruk Island is then broken into three separate nodes: The island itself, the Sirikhan Estate (a mansion on the island), and Savitree hunting the investigators (on the island).

Why?

To manage the complexity.

While the Sirikhan Estate is located on Ko Kruk Island, if the PCs are exploring the island (Node 3) I don’t need to think about every individual room inside the Estate (Node 4). And vice versa: if they’re in the mansion, I generally don’t need to worry about the whole island. Just like separating the individual rooms of a dungeon into separate keyed entries, separating this information lets me clearly focus on (and find!) what’s important RIGHT NOW.

(Speaking of fractal prep, of course, the rooms of the Estate are prepped as a location-crawl. So it’s individual rooms within a node (the Estate) within another node (the Island) within another node (Bangkok). You can really see how the prep structure lets me precisely narrow my focus.)

Node 5 was actually a late addition to my prep notes. I was originally trying to include that material in Node 3 — it’s stuff that happens on the island, so logically it should be in the “Island” chunk of information.

But the complexity of that particular event sequence was bloating the material to a point where I was finding it difficult to organize and reference it. If this is happening to your prep, it’s usually a warning sign that you need to break the material apart into more discrete chunks!

On the flip side, if the players become particularly fascinated by some aspect of the scenario or game world, it becomes relatively trivial for you to zoom in on it and explore it in more detail. Keep this in mind even when running the game: Zoom in on the node and/or add connections to it in response to the PCs’ actions. Slap in a simple node-template like the 5-Node Mystery and you’re good to go following the players down their rabbit hole. Who knows where it will take you?

Go to Part 4: Nodes Aren’t Everything

The PCs kick in a dungeon door.

Description #1:

With the sharp crack of splintering wood, the door smashes open, revealing a room about forty feet across. The high, curved walls are lined with built-in shelves of cherry wood filled with books and warmly lit by a crystal chandelier that hangs from the middle of the domed ceiling. Five goblins are ripping books off the shelves, but their heads whip in your direction.

Description #2:

With the sharp crack of splintering wood, the door smashes open, revealing five goblins who whip their heads in your direction. The room is about forty feet across. The high, curved walls are lined with built-in shelves of cherry wood filled with books and warmly lit by a crystal chandelier that hangs from the middle of the domed ceiling. The goblins have been ripping books off the shelves.

Which description is more effective?

What we’re broadly looking at is whether it’s better to describe the monsters in a room FIRST or LAST.

(Disclaimer: Descriptions are an artistic expression and the given circumstances of any particular moment at the game table are limitless. So there will be a bajillion-and-one hypothetical exceptions to any general principles we might discuss. Think of anything I advocate here in the same way you’d interpret “don’t cross the line when shooting reverse angles” in film or “sentence fragments are bad” when writing fiction. Know the rules so you can break the rules.)

The argument for Monsters First is that it mirrors the crisis perception of the characters: If you opened a door and saw a slavering beast, all of your attention would be immediately focused on the monster. You wouldn’t take your time inspecting the rest of the environment and only THEN look at the monster!

It seems like a logical argument. The problem is that it ignores the actual experience of the characters: If you opened a door and saw a slavering beast, you would immediately want to REACT to that slavering beast. That’s the adrenaline-pumping crisis response (fight or flight!), and it’s why Monster Last is the correct technique. You want the player to be able to immediately react to the monster just like their character would. You don’t want to blunt that reaction by forcing them to wait until you’ve finished the rest of the description.

Note that this isn’t just a matter of associating the experience of character and player. It’s also about effective dramatic presentation: A director of a horror film, for example, wouldn’t follow up on a jump scare with an establishing shot that slowly pans across the scenery before showing the main character’s reaction to the monster!

Okay, but can’t we resolve this dilemma by just not describing the room? The character’s focus would be entirely on the slavering monster. If they’re not focused on the rest of the room, we just won’t describe it to them!

Description #3:

With the sharp crack of splintering wood, the door smashes open, revealing five goblins! Their heads whip in your direction.

Unfortunately, this approach ignores the limited bandwidth by which information about the game world is transmitted to the players (i.e., the GM’s voice).

Although the character may be fixated on the monster, their peripheral vision is immediately processing the environment: Where are the exits? Where can they hide? What are the defensible position? How can they attack? Not only can they take in the totality of their sensorium, they’re also capable of taking action while simultaneously continuing to observe their environment.

The player can’t do that: When they communicate their intended action to the GM, they’re monopolizing the same channel that would be used to give them a description of their character’s environment.

Two outcomes become likely:

First, the player will recognize the problem and ask clarifying questions to obtain the understanding of setting they’re lacking. (“Are there any obstacles that would stop me from charging them? Do I see anything I can dive behind?”)

Second, without understanding the environment, the players will take nonsensical actions. (You didn’t mention the giant chasm that runs across the room between them and the rabid mammoth, so now they’re charging straight into it even though that would be a ridiculous thing for their character to do? Whoops.) This, of course, will force you to stop and correct them, explaining the important context they didn’t know (even though their characters would have).

In either case, you’ve reverted to interjecting an environmental description between the revelation of the monster and the reaction (Monster First). Only it’s actually gotten worse because the presentation is now awkward and frustrating.

WHAT ABOUT A BATTLEMAP?

If you’re using a detailed battle map couldn’t you just reveal it to the players to provide essential environmental information? And then just verbally announce the five goblins in the room?

Sure thing! You could also use other visual references. Pictures are worth a thousand words. In terms of technique, though, this is still Monster Last: You’re use using the visual presentation to handle the room description.

(Or, at least, to make that presentation more efficient: I’ve found that even the best visual aids usually benefit from additional verbal details. The great thing is that you can multitask, usually delivering the additional details at the same time that you’re drawing or revealing the visual reference. The usual single channel of information at the game table briefly becomes multi-channel, which is great!)

WHAT ABOUT INITIATIVE?

Wait a minute. What about initiative?

We’ve been talking about that moment of instantaneous response as if it looked like this:

GM: Five goblins are ripping books off the shelves, but their heads whip in your direction. What do you do?!

Player: I yell, “Fire in the hole!” and throw a fireball in the room.

But doesn’t it actually look like this?

GM: Five goblins are ripping books off the shelves, but their heads whip in your direction. Roll initiative.

(rolling dice)

Player: 14.

Player: 8

Player: 21!

Player: 15.

Player: 16.

GM: (also rolls dice and does math) … okay. Looks like Bob is first. What are you doing, Bob?

This is actually something I addressed in the very first Random GM Tip I posted to the Alexandrian:

Have your players roll their initiatives at the end of combat. Use this initiative for the next combat. (Initiative modifiers essentially never change, so it doesn’t really matter when you roll the check.) When it looks like the PCs are about to encounter something, roll for its initiative and slot it into the order. If they don’t encounter it for some reason, no big deal.

Using this method, by the time combat starts, initiative is already completely resolved. As a result, there’s no delay while you ask for initiative, the dice are rolled, your players tell you their results, and then you sort the results into order. This allows you to start combat off with a bang and keep the ball rolling with that same high intensity. It means that when the players are ambushed, you can maintain that adrenaline rush of surprise instead of immediately undermining it with the mundane task of collecting initiative.

This method also means that initiative results are generally being collected at a time when other bookkeeping chores are being done anyway: After the heat of battle, wounds are being healed; corpses are being looted; equipment lists are being updated; and options are being discussed. Juggling a few extra numbers does not detract from that moment.

And you’ll notice that the reason for moving the resolution of initiative is the same reason for using Monster Last scene description: To capitalize on the moment of reaction to drive the players’ excitement into launching the new scene.

THE REACTION POINT

I’ve been talking about the initiation of combat, but there’s a general principle here:

1. Identify the reaction point (the point at which your players WANT to react);
2. Focus your description to that point; and
3. Clear away any detritus that gets in the way of the players immediately reacting.

The stronger the players’ desire to react, the more important this becomes.

You can also think of the reaction point as being literally the point where you’re asking the players for a response: You want that point to be as interesting as possible because you want to provoke a strong response from the players. Because that’s what will drive the action forward in interesting ways, which will let you easily frame the next reaction point to be as interesting as possible.

Examples outside of combat might include:

• Even though you just rolled the random wilderness encounter, make sure to set up the terrain first before describing the merchant’s wagon coming over the hill.
• Noticing that the eyes of the painting in the haunted house are following you should probably be the last thing described in the room.
• A beautiful, blue-haired man blows you a kiss from across the tavern’s common room.
• They notice someone following them.
• The Federales warchief demands the ship’s instant surrender.

Now, here’s the dirty secret that sort of inverts the idea of putting the most interesting thing at the reaction point: If you instead want the players to preferentially react to something in an otherwise undifferentiated list, put it at the reaction point. Psychologically this is due to recency effect. (The other strong position is to mention something first due to primacy effect. But for immediate choices – i.e., a direct response to a described scene – Miller & Campbell, 1959 identifies the last position as the stronger preference.)

For example, if there’s a pit trap under the fancy tabaxi rug in the middle room, drop the description of the rug in the middle of the room’s description and mention the shelves covered in knick-knacks on the far side of the room last: You increase the odds that a curious PC will cross the room (and the rug) to check out the shelves first.

Go to Part 1

When talking about node-based design, I’ve generally used examples of single scenarios (and usually quite simple scenarios). This has the advantage of keeping the examples relatively uncluttered, but can also be inadvertently deceptive by masking the true power of node-based design.

For example, nodes can be locations, characters, organizations, and so forth. But conceptually they can also be entire scenarios.

This is usually how I design campaigns: I start by brainstorming the major scenarios that are part of the campaign. I think of each scenario as a node and I connect these nodes with clues, following the standard Three Clue Rule, Inverted Three Clue Rule, and all of that. For the sake of argument, let’s call these campaign nodes.

Once I’ve sketched out that broad plan, I can look at each individual scenario and work it up in detail. Many of these scenarios will also be node-based (featuring scenario nodes), although it’s easy enough to mix in other scenario structures (like dungeons or raids or parties or whatever) as appropriate.

The 5-Node Mystery essay has an example of this process. The 5-Node Mystery itself is a basic node template for creating a simple mystery scenario with five nodes – an initial node, three locations/people, and a finale arranged into a simple pattern. You can whip up five of these simple mystery scenarios and then arrange them in the exact same pattern as campaign nodes to form a full campaign.

You can also invert this process, starting with a single scenario, linking it to other scenarios, then linking those scenarios to still more scenarios, organically building up a node-based campaign. (This can obviously work well as a way of building an active campaign week-to-week as you play.)

Note: Not every campaign node necessarily needs to be a full scenario. You might have a bunch of campaign nodes that are full scenarios (unfolding into much greater specificity) connected to another node that’s simply “Admiral Dawson” (a single NPC).

THE CAMPAIGN BINDER

My campaign notes generally live in a binder. The first section of this binder contains all the campaign-wide details — lists of campaign nodes, revelation lists, etc. Then each additional section is an individual scenario or similar chunk of information.

To keep the individual scenarios / campaign nodes organized, I’ll frequently number them. They’re usually also sorted into conceptual bundles. You can see an example of this in Part 7 of the Dragon Heist Remix:

0.0 Campaign Overview
1.0 Finding Floon
2.0 Trollskull
3.0 Nimblewright Investigation
3.1 Gralhund Villa
4.1 Faction Response Teams
4.2 Faction Outposts
5.0 Heist Overview
5.1 Bregan D’Aerthe – Sea Maidens Faire
5.2 Cassalanter Estate
5.3 Xanathar’s Lair
5.4 Zhentarim – Kolat Towers
6.0 Brandath Crypts
6.1 The Vault

To briefly summarize:

• The 0.0 document is the campaign-wide material.
• Node-based design mostly kicks in with Part 3.0, which is a node-based mystery in which the solution is going to Part 3.1 (which is a raid scenario).
• The 3.1 raid contains a bunch of leads pointing to other scenarios. I’ve broadly organized these into Part 4 (faction-related stuff built as a sort of node campaign inside the node campaign), Part 5 (the major heists, which the PCs are pointed to by leads in Part 4), and Part 6 (the final scenario, which is built as a dungeon crawl and further broken into two parts for convenience).

Sometimes this conceptual structure is literally just the nodes themselves in a simple list. Masks of Nyarlathotep and Eternal Lies use a globetrotting structure to similar effect: Each major city visited by the players is treated as a separate scenario (i.e., a campaign node) with links between them.

Act II of my Ptolus: In the Shadow of the Spire campaign has forty-two different scenarios. In addition to conceptually breaking the campaign into acts, I have further divided this act of the campaign into three sections, using prefixes to distinguish them. (So this campaign features adventures with organizing codes like NOD4, CC3, and BW09. Which may sound confusing, but is perfectly clear in context.)

My big point here is that there’s not necessarily a “one true way” here. It’s what works for you and it’s what works for a specific campaign.

USING NODES TO MANAGE PREP

The conceptual separation of a campaign into separate nodes is also a great way to manage prep and, in accord with the principles of smart prep, minimize wasted prep.

Basically, you can set up the essential elements of a campaign node (in terms of how it connects and interacts with other campaign nodes) without fully prepping the scenario that lies “behind” that campaign node. Therefore, you don’t actually need to prep that scenario until the PCs move to engage it.

For example, when I originally laid out Act I of Ptolus: In the Shadow of the Spire, it featured thirteen scenarios. Because of the choices my players made, however, I ended up only needing to prep seven of those scenarios.

The high-level view of the campaign gives enough detail to have a complicated web of interrelated content, while also conceptually firewalling the campaign in a way that prevents you from pouring a bunch of extra detail into areas where it turns out you don’t need it.

Note: As you design and expand individual campaign nodes, you’ll often find new opportunities to link the node to other nodes arising naturally out of the material. Do so. As a corollary of the Three Clue Rule suggests: More clues are always better. (Make sure to list these new connections in your campaign-wide documentation, too.)

ADDING NODES

The modular nature of node-based design, however, also makes it easy to integrate new nodes into your campaign structure.

In fact, it’s not unusual in the slightest for the actions of the PCs to generate new nodes by either creating leads out of whole cloth (by pursuing methods of investigation or a strategy of action that I hadn’t anticipated) or following leads that I didn’t realize were leads when I made them. I discussed one example of this in Ptolus: In the Shadow of the Spire here, as the unexpected actions of the PCs added two completely new nodes to Act I (even while they were, as noted above, ignoring six other nodes I had planned).

Something similar happened in the Eternal Lies Remix, with the players choosing to go to the Severn Valley by following information that wasn’t explicitly designed as a lead, but which they nevertheless interpreted as such.

As the GM, you may also find yourself proactively creating new nodes that arise logically out of the evolving circumstances of the game. The Shipwrights’ Ball in my Dragon Heist campaign is an example of that.

As you’re adding these nodes to your campaign, don’t forget to link them to other campaign nodes just like you would with any other node. You don’t need to worry about making sure to include three clues pointing to the new node (you’re designing the node because the PCs are heading there; you don’t need redundancy to make sure they do the thing they’re already doing), but seize the opportunity to add new leads pointing to other nodes. (For example, when adding the Laboratory of the Beast to In the Shadow of the Spire, I added several new links to Act II of the campaign.)

These connections will often arise naturalistically in any case. If the PCs become interested in a mobster’s yacht or lawyer or ex-wife because of their connection to the mobster, it just makes sense that those things could be potentially connected to the mobster’s other affairs (i.e., the other nodes connected to the mobster in the campaign).

Note: There are plenty of exceptions to prove this “rule.” If the PCs go haring off on a wild goose chase, it’s perfectly fine for them to discover that it’s a dead-end in terms of their wider investigation. (Of course, this doesn’t mean that they won’t find something interesting there. The Manse of the Red Dragon sounds pretty exciting even if it doesn’t have any connection to the conspiracy of Elf Lords.)

In some cases, you may find that the PCs have blasted open a whole new multi-node section of the campaign. That’s great! Just remember not to prep more of those nodes than you immediately need to.

META-SCENARIOS

I spoke earlier about the two prongs of mystery design: That there are leads which point to other nodes where you can continue investigating things and clues that point to other types of revelations (like the solution to a mystery). Furthermore, the latter can be spread out over the course of an entire scenario, with the PCs slowly accumulating the clues they need to piece things together.

This same principle can hold at the campaign level: You can take a big mystery, break it down into separate revelations, and then spread the clues for those revelations out over the entire campaign (perhaps dropping only one or two in a given scenario).

This is a meta-mystery, and it’s an example of what I call a meta-scenario.

Although the design principles here, like much of what we’ve been talking about, are the same as they would be for an individual scenario, in some cases a difference in scale is a difference of kind. Largely, this is a matter of organization: I usually find that meta-scenarios require their own section of the binder. I find them easiest to both design and manage if I think of them as a distinct entity that’s kind of being “draped” over the top of the campaign’s primary structure.

Meta-mysteries are not the only sort of campaign-spanning meta-scenario. Other examples might include:

• Collecting the specialized components for performing a ritual.
• Making allies for the Prophecy War.
• Being hunted by an intergalactic cabal of assassins.
• A countdown to the apocalypse as the Stars Come Right.

Go to Part 3: The Fractal Node

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