If you’re using node-based design, does that mean you’re prepping a plot?

No.

We’re talking about “plot” in the sense of Don’t Prep Plots:

Don’t prep plots, prep situations.

Plot, in this case, means the sequence of events that happens in a story. Prepping a plot in an RPG means you’re predetermining what the PCs will do: A will happen, then B will happen, then C will happen. If by “plot” you mean something else — a villain’s scheme, a ground plan, etc. — then the answer might veer closer to “maybe,” but it’s also outside the scope of this discussion.

If you’re familiar with node-based design, then it’s likely you’re scratching your head right now: Obviously node-based design isn’t about prepping a plot, so why is this even a question?

But it’s actually a question I get asked several times a year. This is sometimes because people are using some other definition of “plot,” but, based on conversations that I’ve had, it’s frequently that they’re so deeply entrenched in plot-based prep (including railroading) that they have difficulty comprehending any other paradigm. Even when they look at alternatives, they subconsciously think to themselves, basically, “Well, obviously I would use this to prep a plot.” And then sometimes they go farther and say, “Why is this guy lying when he says he doesn’t prep plots?” Strangely, this even seems to happen with people who are virulently opposed to prepping plots.

This isn’t limited to node-based design, either. I’ve seen the same attitude applied to everything from clocks to hexcrawls to faction turns. No matter what the structure is, the GMs trapped in this way of thinking start by trying to guess what their players will do and/or figuring what they want to force their players to do, and only then do they try to figure out how the structure can help them do that.

This, of course, is really unfortunate. It’s a massive blindspot. And I’ve seen this enough — and been asked this enough — that I think it’s worth taking the time to take a closer look at these misapprehensions.

THE MANDATED MYSTERY

The first argument I often see is that:

1. Node-based scenario design is used to design mysteries (e.g., figuring out who’s selling red opium).
2. A mystery scenario means that the GM is dictating the scenario concept to the players. (“Thou shalt figure out who’s selling red opium.”)
3. This is a plot.
4. Therefore, using node-based scenario design means that you’re prepping a plot, not a situation.

To start, let’s accept as a given that node-based scenario design means that you’re designing a mystery. (I’d actually quibble with that a bit, but it’s not important here.)

Next, I think we need to define what a sandbox campaign is: This is a campaign where the players can either choose or define what the next scenario is going to be. The second premise being asserted here is that if the GM is the one assigning scenario concepts (as they might in an episodic campaign where the PCs are cops being assigned cases to solve, for example), then this is not a sandbox campaign.

This is, of course, true. I actually describe this as the “lightest form of railroading” in Part 3 of The Railroading Manifesto. (Which is not to say that there’s anything inherently wrong with this sort of campaign structure. Quite the opposite. There all kinds of diegetic and non-diegetic reasons for running an episodic campaign and, as I point out in the manifesto, lots of people wouldn’t consider it to be railroading at all.)

But is this, in fact, a plot? Is the GM prepping a predetermined sequence of events? Well, if you squint hard enough and are sufficiently liberal with your definition of “sequence of events,” you can make a case for this being true. (For reasons pretty similar to why I refer to it as “the lightest form of railroading.”) Personally, I think what you’re actually discussing here is campaign structure rather than the scenario structure, and I think putting this much weight on the nature and presentation of the scenario hook is more deceptive than revealing when it comes to the overall design of the scenario, but there’s certainly a semantics debate to be had.

Ultimately, though, none of that is really relevant, because nothing about mystery scenarios or node-based design requires the GM to dictate scenario concepts to the PCs.

If you’ve never experienced a player saying, “I want to do X,” and then the GM designs the scenario that results from them wanting to do X, then you might find this confusing. But I do this all the time.

The type of scenario you design, of course, will depend on what X is and how the PCs are planning to do it: If they want to steal the Ruby of Omarrat, then I’m probably prepping a heist. If they want to travel from Neverwinter to Waterdeep, then I’m prepping a travel route. If they want to attend Burning Man, I might prep a festival. And if they want to figure out where their rival gang is sourcing red opium from, I’d probably use node-based scenario design.

So even if we believed that scenario hooks are plots, once we realize that mysteries do not require GM-mandated scenario hooks, we can easily see how this entire line of argument collapses.

CLUES = PLOT

This brings us to the second common argument, which is that by designing clues and placing them in a scene you are prepping a plot. For example, by saying that Rachel works for Bobby (and, therefore, the PCs can discover this connection and follow it to Bobby), you are predetermining events.

This is, again, certainly something that you CAN do: The breadcrumb trail of clues, each of which can only be found in one specific way and used in one specific way.

I suspect, though, that most people reading this are already sensing that something doesn’t quite feel right here. How is stating “Rachel works for Bobby” a plot? Is that not clearly a situation — a description of the world state?

Imagine that I created a room in the game world and I said, “This room has a door and two windows.”

And then Bob said, “THAT’S A PLOT! You are predetermining that the PCs will enter the room through the door or the windows!”

I’m very hopeful that you can understand that Bob’s not making any sense here.

First, the players could easily enter the room in other ways: They could chop a hole in the wall. They could teleport in.

Or they might choose NOT to enter that room. Either because they simply choose to go somewhere else, or because they figure out some way of accomplishing their goals in that room without entering it. (They could scry on the room. Hire someone to search the room for them. Burn the house down and force the threat inside the room to come running outside.)

The leads in node-based scenarios work just like the doors and windows of that room, and stuff like permissive clue-finding is analogous to chopping holes in the wall. Node-based design is a way of thinking about how different parts of the game world are connected to each other — Rachel works for Bobby; Mathieu has a treasure map revealing the location of Shandrala; the street dealers get their red opium from a house on Oak Street — and prepping scenarios in which the PCs use information (i.e., leads) to navigate the game world.

You can hypothetically use node-based scenario design to force a plot, the same way that you could build a room with adamantine walls and endless GM fiat to force the players to solve the riddle that will unlock the door. But that’s something you’re choosing to do.

CONCLUSION

I’m mostly writing this essay because, when I get these questions in the future, I want to be able to just point people here. But I’m also hoping that it might help some people break out of a paradigm that’s limiting them as both GMs and players.

If you see a GM create a tree and your first thought is, “There’s no other explanation for this than that the GM is going to force me to climb that tree,” it’s important to understand that this is a warped perception. Even if that’s been your experience with one GM, you should know that there are other GMs running their games in very different ways.

And if you’re a GM who either (a) can’t create a tree unless you’re planning to force your players to climb it or (b) are paralyzed at the thought of creating a tree because you’re afraid it means you’re railroading your players into climbing it, then I truly believe your games will be better if you can jettison that way of thinking and, instead, embrace the simple maxim:

Don’t prep plots, prep situations.

A hexcrawl is one way of looking at a game world.

Like other scenario and campaign structures, a hexcrawl can be broadly understood as a method for organizing prepped material paired to a complementary procedure of play: A dungeon procedure provides structure for PCs moving between rooms and exploring their contents, and it’s logically paired to a prep structure in which rooms are positioned on a map (to make them easy to reference) and keyed with the information needed to explore them.

A hexcrawl, similarly, creates a map of the world broken down into hexes because those hexes provide a convenient structure for keying content and managing overland exploration.

But one must not mistake the map for the territory.

One way to think about this is to consider the howling wilderness of the typical hex: We generally key no more than a single point of interest in each hex. But whether we’re talking about a 5-mile hex, a 6-mile hex, or the Alexandrian 12-mile hex, if there was really only one point of interest in a hex, it would mean a vast and desolate place.

Lay a hex grid to scale over a map of your local county, shire, or district and you’ll see what I mean. For example, consider Brown County in Minnesota, which I picked by basically clicking randomly on a map. It would consist of roughly eight 12-mile hexes, but it contains seven cities, a couple dozen townships, fifteen major lakes, three major parks and wildlife preserves, multiple scientific outposts, and forty different sites on the National Register of Historic Places. Whichever eight of those you pick, you’re obviously going to be leaving a lot of stuff out of your hex key.

That’s how the real world works. It’s also how your game world works: Whether consciously or otherwise, you’re choosing to key the most important or significant thing in each hex, while overlooking the others. This isn’t a problem, of course, unless you forget the conceit and begin to believe that what you’ve keyed is everything the game world has to offer.

(This is also why the Alexandrian Hexcrawl uses random encounters to procedurally generate new locations — e.g., lairs — on the hexmap. The more time the players spend in a particular region, the more of these “overlooked” details they’ll have a chance to discover precisely in the area of the game world they’re spending the most time in.)

The hexcrawl also has a procedural bias: The material is structured and keyed for the PCs to discover it through geographical exploration (e.g., “We walk north until we see something interesting.”). But this is not, of course, the only way that PCs can explore or interact with an area. It’s also pretty easy to imagine interesting elements of the game world that are largely or entirely inaccessible to simple geographic movement.

What I’ve found useful is to think of different structures as being “layers” of the game world. A hexmap, for example, is one “layer” — one method of keying and describing the game world — and it’s often more than enough to run an entire campaign. But it’s not a complete picture of the game world, and you can add more layers, each describing the world in a different way and each conducive to different types of PC actions.

Furthermore, since these layers are all describing the same world, they will also overlap or intersect with each other in different ways. While the PCs are exploring and interacting with the world in one way, you’ll be able to use the appropriate layer to run the game for them. Then, when they discover something new and/or set a new goal that will lead them to begin exploring the world in a new way, you’ll be able to shift to a new layer — a different scenario or campaign structure — to adjudicate what happens next.

And you can also, as the GM, design your world with these phase shifts in mind!

NODE-BASED LAYER

For example, consider node-based scenario design, in which nodes are linked to each other by clues.

Each node is a person, organization, event, activity, or, crucially, location. This means that each location keyed to your hexmap can also be thought of as a node and linked to other locations on your hexmap (i.e., other nodes) via clues.

For example, the hobgoblin bandits lairing in the ruins of the Black Baron’s Keep may have been sent by the Necromancer to spy on the elves of Silverwood. When keying the Black Baron’s Keep, therefore, it would be perfectly natural to include clues pointing to both the elven village in Silverwood and the Necromancer’s Tower.

If you want to start experimenting with this technique in your own hexcrawls, I recommend getting started with some simple loops:

The Black Baron’s Keep has clues pointing to the Necromancer’s Tower, the Elven Village, and the Hobgoblin Village.

Meanwhile, the Necromancer’s Tower has clues pointing to the Black Baron’s Keep, the Elven Village, and the Hobgoblin Village.

And so forth.

The advantage of this design is that it creates compact little scenarios that can be naturally explored no matter which of the nodes the PCs encounter first: Whether they’re attracted by the strange lights in the Black Baron’s Keep, hear reports of hobgoblin raids from the elves of Silverwood, or stumble across the hobgoblin village, they’ll be able to follow the clues and discover the other nodes.

To add additional complexity to these simple setups, consider linking a single node to multiple loops. For example, spying on the Silverwood may be only one of the Necromancer’s current schemes, with her tower acting as a sort of crossroads between different node-based scenarios.

As you become more comfortable with adding node-based layers to your hexcrawl, you’ll likely end up gravitating towards freeform design in the cloud, with your various hex-keyed locations pointing to each other freely in whatever manner makes the most sense. In doing so, you may also discover that you can use these same techniques without necessarily creating fully robust node-based scenarios.

What I mean is that, with the hexcrawl structure as a backstop, you don’t need to strictly obey the Three Clue Rule or Inverted Three Clue Rule. Or, to put it more simply: You can include a single clue from Hex A to Hex B, and it’s just fine if the PCs don’t find it, because the hexcrawl structure means they can just geographically navigate their way to Hex B with or without the clue.

Note that you can also plant clues into other structures of your hexcrawl campaign:

• Rumor tables, for example, are basically just big lists of free-ranging clues.
• Random encounters can also include clues pointing to hex locations. (This can even be true of procedurally generated clues. Tracks, for example, are inherently clues that point you to the locations that creatures are coming from or going to.)
• Even random treasure can be used to plant clues. (Random treasure maps are a classic example of this.)

All of these links add depth to your campaign. They actually feed back into the hexcrawl structure itself, giving the PCs’ the information they need to set goals that will guide their exploration, allowing them to travel with purpose instead of just wandering around the map aimlessly.

However, we’re still only scratching the surface here, because so far we’ve only been linking locations that also appear in our hex key (and are, therefore, also accessible via the hexcrawl). There’s no reason that we need to limit ourselves like this: Locations discovered through the hexcrawl can link us to nodes — people, events, organizations, activities, and even other locations — that DON’T appear in the hex key and could never be discovered by simply moving around the hex map. They literally exist on a completely separate “layer” of your campaign world.

I frequently find this approach useful for cities located in my hexcrawls. Like Maernath, for example:

Maernath might be the PCs’ homebase for the hexcrawl, or it might be a city they discover while exploring the region. Either way, it’s easy to see how the city itself could be encountered through the hexcrawl structure.

But simply seeing a city on the horizon isn’t going to reveal all of its secrets to you. For example, what if a scion of one of the noble families is collaborating with the Necromancer? They might be just one node in a much larger conspiracy scenario that’s infesting the city, but the PCs are unlikely to stumble onto this conspiracy just because they walked through the city gates.

(What I also like about this is that it connects the urban environment to the surrounding wilderness, and you can obviously do the reverse, too. It weaves your campaign together, not only adding depth, but also making everything feel interconnected.)

Another fun technique is to stock your hexcrawl with rituals, allowing the PCs to piece together the clues and supplies they need to figure out what, where, and possibly when they need to perform the ritual. These rituals, in turn, might unlock unique spells and abilities; empower magic items; summon mystic allies; or even open portals to extradimensional adventuring sites.

The region described by your hexcrawl might also include traveling elements, like a touring carnival, merchant caravan, or mystic phoenix. These are, obviously, not keyed to specific locations. You might include such elements on your random encounter table as one way of integrating them into the hexcrawl structure, but node-based design can provide another path for the PCs to discover them and track them down.

Note: You can also use node-based scenario design to provide links to location nodes far away from the region covered by the hexcrawl (e.g., you’ll need to take a ship south to pursue the political backing of the local privateers; or you’ll need to go to the Imperial City to follow the Cult of the Black Eye). This isn’t quite same thing as thinking of the campaign in terms of “layers,” but it IS an example of how you can use shifts in structure to present or handle different types of scenarios. Your structure should never feel like a straitjacket; it should be a tool that liberates you.

Go to Part 2: Pointcrawl Layers

Back to Hexcrawls

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

Go to Part 1

Once I came to see scenes as an emergent property of game play (rather than something that’s prepared), I began to realize that scenario prep is almost entirely about designing tools. Or, perhaps more accurately, toys. Running an RPG is about picking up these toys and actively playing with them, just like the players are actively playing their PCs.

In creating these tools you’re still thinking about how they’ll be used at the table. But it’s more like designing a hammer (“I know this tool will be useful for hammering nails”) than it is writing an IKEA instruction manual (“here is how the scene with Diego will work”).

At the table, players are going to say things like, “Let’s build a chair!” And the GM will be thinking, “Great! I’ve got a hammer, a bunch of wood, and some… screws? Well, let’s make it work.”

It may only reflect my predilections as a GM, but I’ve found over time that node-based scenario design seems to inherently lend itself to a naturalistic form of prep. I’m not sure if that’s the ethos of active play pushing node-based design in a particular direction or if it’s that node-based design has naturally fostered active play. Or both.

But, in short, the more comfortable I become with node-based scenario design, the more I find that the design arises out of the diegetic organization of the game world itself.

For example, when I’m designing something like the Lytekkas hypercorp, the nodes I design (and how those nodes are organized) overwhelmingly tends to mirror the organization of Lytekkas in the game world. (You can see this in the earlier examples, which were based on things like the geography of the game world or the corporate divisions of Lytekkas.)

When I’m struggling with node-based design, a trick I’ve learned is to pick an NPC and ask, “How would they see this stuff? How would they use it? How would they interact with it?” Whether that’s a hypercorp CEO in an orbital penthouse or a Triad 49er on the rough streets of Hong Kong, the in-game perspective is almost always illuminating.

Of course, this makes sense, doesn’t it?

If node-based scenario design is based on the flow of information – if the structure of a node-based scenario is made up of the paths formed by the information – then it follows logically that node-based scenarios will mirror how that information naturally flows through the game world. And, of course, that flow will be determined by the actual relationships between people, places, organizations, and events in the game world. In how the nodes are related to each other.

Thus, as you design your scenarios, you naturally break the game world apart into discrete chunks. Each chunk (or node) is either a toy or a collection of toys that you can pick up and play with, while the connections between nodes show how those toys are related to other toys, making it easy for them to be endlessly combined and recombined in actual play.

And that’s node-based scenario design.

FURTHER READING
Using Revelation Lists
Game Structures
Hexcrawls
5 Node Mystery
Is Node-Based Design Prepping a Plot?
Gamemastery 101

Go to Part 1

NODES & THE CAMPAIGN STATUS DOCUMENT

Campaign status documents are something I discuss in more detail in Part 4 of Smart Prep. The short version is that the campaign status document collects all of your notes on the current, evolving situation of the game. There are a number of cool ways you can use the campaign status document, but the most pertinent one for our discussion here is the scenario updates: Rather than attaching notes like “they killed all the kobolds in Area 3” or “Benny is angry with them” to a bunch of different scenarios, so that they’re scattered hither and yon, you collect all of these notes in the campaign status document for easy reference and upkeep.

The key insight here is that properly organized node-based scenarios make it REALLY easy to assemble and maintain your campaign status document. In the status document for In the Shadow of the Spire, for example, I can just place “NOD6” at the top of a section (remember those alphanumeric codes?) and drop stuff relevant to that scenario into that section. When the PCs go to NOD6, I can just flip to that page in the status document and have it available for easy reference.

We’ve also talked about meta-scenarios. Something I’ll do is pull upcoming or pertinent details from a campaign’s meta-scenarios and drop them into my campaign status document. When the players in my Eternal Lies campaign would go to a new city, for example, I would look at the Act II floating scenes (which operate as a very loose meta-scenario), grab a handful that I thought were likely to be appropriate, and drop a list of them onto the first page of my campaign status document. It gave me a kind of mini-menu that I could quickly consult without trying to process or remember the entirety of the meta-scenario in the middle of a session.

In some cases I’ll also drop “active” revelation lists into the campaign status document to keep track of them, but for these I’ll usually just mark up the master copy in the scenario itself. (That’s what it’s there for after all.)

NODES AREN’T EVERYTHING

With all of this being said, node-based scenario design is not the be-all and end-all of scenario design. Beyond obvious stuff like dungeon crawls and hexcrawls, I’ve already discussed lots of other scenario structures here at the Alexandrian. There are also a lot of tools that will be useful to you as a GM in node-based scenarios which aren’t nodes themselves.

Let’s take another look at my Bangkok prep notes for Eternal Lies and break them down. There’s five nodes in there, but there’s also a bunch of other stuff. What’s it all doing in there?

First, you’ve got the revelation lists and the trigger list for proactive nodes. These are obviously part of node-based scenario design, but they’re also basically the table of contents for the scenario. They show the whole scenario structure and can act as a quick reference for your nodes/tools. So I’ll usually have this in the first couple pages of my prep notes.

And then we come to the tools. One thing to note is that these are usually designed to be picked up in combination with one of the nodes. 95% of the time, this will be stuff that might be used in multiple nodes (like an NPC who could show up in multiple locations).

The other thing to note is that there’s nothing magical about these particular tools. I don’t use them for every scenario I prep and there are a lot of other tools you could potentially include depending on the nature of the scenario and game.

CITY MOOD BEATS: This is a cool tool from the published Eternal Lies campaign. These small beats (e.g., “birdsong drifts out of an open apartment window”) are designed to be dropped into any scene to provide local color/theme. (Check out Trinity Toolkits for a wider discussion of this sort of thing.)

NPC NAMES: A list of locally appropriate names to be used when improvising NPCs (which could obviously happen almost anywhere in the scenario).

(These two tools usurp the usual place of honor for the revelation lists and are the first page of my prep notes for the city nodes in Eternal Lies. When the PCs went to a city, I would generally grab this sheet out of the binder and place it on the table off to one side for easy use.)

REFERENCE: I use a reference sheet to encode broad background data for the scenario that doesn’t belong to a particular node. In this case, it’s a timeline for the Emporium of Bangkok Antiquities. (This timeline could come up while questioning Daniel Lowman at his townhouse, questioning Savitree at Ko Kruk Island, or while looking at research notes found at the Estate. So it’s really clear how this has cross-node applicability.)

RESEARCH: In Trail of Cthulhu it’s not unusual for the PCs to head to the local library or newspaper morgue and do general research on leads they’ve found. This is material that doesn’t really belong to any of the nodes, so it gets split out.

NPCs: At the back of my prep notes I present major NPCs, including the Universal Roleplaying Template and other key information. Some of these NPCs are treated as nodes (and will be found indexed on the revelation list) while others can be used in multiple nodes, but for practical reasons I’ll usually include any NPC that takes up a lot of space to declutter the individual nodes. I also just generally find that giving each major NPC a full, dedicated sheet is useful. When roleplaying them, I can just grab and focus on the pertinent sheet. If it’s a combat situation, I can also grab the sheets for everyone participating for easier reference.

STAT SHEET FOR BANGKOK: But when a system’s stat blocks are short enough (as in Trail of Cthulhu), I will also drop all the stat blocks for a scenario onto a single sheet to make running combat SUPER EASY (at least when it comes to referencing stats). Some scenarios might require multiple stat sheets, which I will generally organize according to action group or node.

As I say, these tools are not the be-all or end-all of node-enhancing elements you can include in your scenario and campaign design. But they should give you a pretty good sense of the types of tools I’ll develop and use.

Go to Part 5: Naturalistic Node Design