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
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.

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

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

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