Go to Part 1

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

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

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

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

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

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

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

I call this technique the Second Track.

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

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

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

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

Go to Part 5: The Two Prongs of Mystery Design

Go to Part 1

One of the challenges a GM faces is in presenting the complex reality of a living world: Players have the luxury of focusing on a single character, but the GM often finds themselves needing to juggle dozens of characters and potentially hundreds of pieces of information.

One of the most important skills for a GM to master, therefore, is better organization.

Take a dungeon, for example. Simple stuff like using a numbered key to describe the dungeon may seem obvious, but take a second to imagine the alternative where that basic level of organization isn’t applied. (And I have, in fact, seen published adventures where it wasn’t applied. It isn’t pretty.)

Now, how could we improve that organization even more? Well, we could start by clearly segregating “information anyone entering the room should immediately know” from “information that can only be gained with further investigation”. (Properly written boxed text is one way of doing that, of course.)

Might it be useful to also distinguish “information characters might notice immediately upon entering the room without taking any particular action”? Probably.

And so forth.

Note that I’m not talking about performing any extra prep work. I’m just talking about organizing your prep work so that it’s easier to use at the table. (I’ve actually found that proper organization can actually reduce the amount of prep you need to do.)

The node-based structure itself, of course, is one way of organizing your prep work. In terms of organizing the actual nodes, though, here are a few tips that I’ve learned—

KEY YOUR NODES: Just like the rooms in a dungeon, it will be easier to reference and use your nodes if you key them. For the most part, I just use numerical codes: Node 1 is First Central Bank. Node 2 is the security guard who didn’t show up for work during the robbery. Node 3 is the stolen car that was used as a get-away vehicle. And so forth.

KEEP A CONNECTION LIST: I’ve talked in the past about the importance that The Masks of Nyarlathotep played in developing the Three Clue Rule and, by extension, node-based scenario design. The concept of a “connection list” is taken directly from that campaign:

It shouldn’t take much imagination to see how much easier such a list will be to design and maintain if you’ve specifically keyed your nodes. I discuss this concept at much greater length in Using Revelation Lists.

KNOW YOUR NODE HIERARCHY: At a basic level, you should have some rough sense of how you want the various nodes of the scenario to hook up. (Bearing in mind that (a) your players will probably find all kinds of ways to connect the nodes that you never intended and (b) you don’t really need to pursue some sort of rigid ideal.

And if you’re dealing with a relatively small number of nodes, that’s probably all you need to know. But as the number of nodes begins to grow, you’ll probably find it useful to break them up into more manageable packets: Can you break one large scenario into multiple smaller scenarios?

Those scenarios, of course, can hook into each other. But by breaking them up into distinct packets, I find it’s easier to keep the overall structure of the campaign manageable and comprehensible.

For my games, I typically maintain a document I refer to as the “Adventure Track” which details the macro-level node structure of the campaign. For my Ptolus campaign, I broke the macro-structure into five acts. And then, within each act, I created clusters of related nodes using a simple outline structure.

For example, here’s Act I:

1. The Awakening
2. The Murderer’s Trail (Ptolus – Adventure #1)

a. Following the Ledger
b. House of Demassac
c. Jirraith and the Pale Dogs

3. The Trouble With Goblins (Ptolus – Interlude #1)

a. Complex of Zombies
b. Laboratory of the Beast
c. Goblin Caverns of the Ooze Lord

4. Smuggler’s Daughter (Ptolus – Adventure #2)

a. The Slavers’ Enclave

5. End of the Trail (Ptolus – Adventure #3)

a. Swords of Ptolus
b. Cloud Theater

6. Shilukar’s Lair (Ptolus – Adventure #4)enture #4)

Each line here is a major scenario, with the various scenarios interconnected as nodes. (Some of these individual scenarios are also designed using node-based techniques.) The indented lines are closely associated with the “major nodes” above them. (In other words, I’m using a basic outline structure to conveniently group the content of Act I into convenient conceptual packages. This outline also keys each node: “The Awakening” is Node 1; “Laboratory of the Beast” is Node 3B; and so forth.)

Act II of the campaign is even more complicated, featuring a total of 42 major scenarios. In order to keep the structure of that act manageable, I broke it down into three semi-independent “chunks”, each of which was then organized in a fashion similar to the outline for Act I you see above.

I’ve found this Adventure Track + Connection List method to be very useful for both preparing and running a node-based campaign. But there’s nothing magical about it. You should find the method that works best for you. My general point, however, is that you should strive to achieve a high-level understanding of your node structure – chunking that node structure into larger and more manageable pieces as necessary.

Go to Part 4: The Second Track

Go to Part 1

Let’s turn our attention now to specifics: What are the exact navigation methods that can be used to guide characters into a node?

CLUES: Clues turn each node into a conclusion. When the PCs put the clues together, they’ll tell them where to go, who to look at, and/or what to do.

Clue-based scenarios are often considered fragile, but by using the Three Clue Rule and the Inverted Three Clue Rule you can make them robust.

One pitfall to watch for: In order to reach the next node, the PCs must know both what they’re looking for and how to find it. If you only give the PCs one clue telling them how to reach the Lost City of Shandrala, your scenario will remain fragile even if you include 20 clues telling them the Lost City of Shandrala is interesting and they should totally check it out.

On the other hand, clue-based node navigation conveniently organizes itself into mystery scenarios which provide over-arching push/pull motivations: Once the PCs are interested in unraveling the mystery, all you need to do is put a node on the bread crumb trails and they’ll follow it.

GEOGRAPHY: In other words, the choice of which way to go. The archetypal example is the dungeon, which generally provides a far more robust structure than a clue-based scenario. For example, consider this simple dungeon:

Moving from A to B to C requires no redundancy because the hallway provides a clear and unmistakable geographic connection.

However, geographical structure can occasionally create a sense of false security. For example, consider this very similar dungeon:

Now you have a potential problem: If the PCs fail to detect the secret door your adventure can easily go off the rails. (Assuming they need to reach C.)

Hexcrawls can be similarly problematic in that there’s no guarantee that any given piece of content will actually be encountered. (When I was 12 years old I remember pouring over a copy of X1 Isle of Dread and never quite figuring out how the PCs were supposed to “know where to go” in order to find all the keyed encounters.) Properly designed hexcrawls, however, employ a mode of redundancy similar to the Three Clue Rule: They don’t require you to encounter any particular piece of interesting content, but rather spread interesting content liberally so that you are almost certain to encounter at least one piece of interesting content even if you’re just exploring randomly. (This, of course, creates a high degree of extraneous prep. But hexcrawls are meant to be used over and over again, utilizing that extra content over the course of several passes.)

In geographical arrangements, obstacles serve as pushes. For example, if the PCs are in Room A and they want to get to Room C, then Room B is encountered only because it’s an obstacle. The PCs are pushed into encountering Room B because the geography of the dungeon requires it.

TEMPORALLY: The phone call that comes at 2 PM. The goblin attacks on the 18th. The festival that lasts for a fortnight.

Although lots of nodes can include time-sensitive components (“if the PCs arrive after the 14th, the Forzi crime family has cleared out the warehouse”), nodes that are triggered temporally are almost always a push: Something or someone comes looking for the PCs, pushing them into engaging with the node.

(Of course, temporal triggers can also be coincidental – like a red dragon attacking the Ghostly Minstrel when the PCs just happen to be dining there or the sun becoming eclipsed – but those are still pushes.)

Temporal triggers can also have some variability built into them. For example, you might decide that the Forzis hire a hitman to kill one of the PCs on the 16th. That doesn’t necessarily mean that the hitman will immediately find them.

RANDOMLY: Wandering monsters are the classic example of a randomly generated node, but they’re far from the only example. The early Dragonlance modules, for example, coded story events into their random encounter tables. Jeff Rients’ table for carousing mishaps offers a different set of possibilities.

Because of their long association with wandering monster checks, the random triggering of a node is often associated with the random generation of a node. Although both can be useful techniques, when we’re talking about navigating between nodes we’re primarily focusing on the random triggering of a node.

For example, in my current hexcrawl campaign the content of each hex has been fully keyed. But I use a set of mechanics to randomly determine whether or not that content is encountered by a group moving through the hex (i.e., triggering the node).

PROACTIVE NODES: A proactive node comes looking for the PCs. These are often triggered temporally or randomly, but this isn’t necessarily the case.

For example, instead of using random encounters I will often run small complexes in “real time” by splitting the enemy NPCs into small squads. I can then track the actual movement of each squad in response to the actions of the PCs.

One could also easily imagine an “Alert Track”: Every time the PCs do something risky or expose their activities in some way, the alertness level of their opponents rises. The rising alertness level could change the content of some nodes in addition to triggering a variety of proactive nodes.

In reading many published adventures, it’s not unusual for the first node to be entirely proactive. (The classic example being “an NPC wants to hire you for a job”.) But then many adventures will suddenly stop being proactive. Neither of these things need to be true.

It can also be tempting to think of proactive nodes as being a railroading technique. While they certainly can be used in that way, there’s no need for that to be true. Examples entirely free of predetermined GM machinations might include NPCs making counter-intelligence checks to discover the PCs’ identities or the PCs being tracked through the wilderness by enemy forces after they escape from the Dread Lord’s Castle.

In general, proactive nodes are useful for creating a living world in which there are both short-term and long-term reactions to the PCs’ choices.

FOLLOWING A TRAIL: I’m not sure if following a trail from node A to node B constitutes navigating by clue, geography, both, or neither, so I’m including it here as a common sort of special-case hybrid.

A trail, of course, doesn’t have to be limited to following tracks in the mud: Tracing data trails through the ‘net; hacking jumpgate logs; a high-speed car chase. There are lots of options.

PLAYER-INITIATED: In their quest to get from A to C, it’s not unusual for players to invent their own B’s without any particular prompting. Sometimes these can be anticipated (like most Gather Information checks, for example), but in many cases the players will find ways of tackling a problem that you never imagined (like the time my players inadvertently started a shipping company in order to find a missing person).

In the same spirit as permissive clue-finding, it’s almost always a good idea to follow the player’s lead: Your prep should be a safety net, not a straitjacket. (That doesn’t mean all their schemes should prove successful, but when in doubt play it as it lies.)

Go to Part 3: Organization

In Node-Based Scenario Design we explored an alternative to the typical plotted approach to scenario design: By designing a situation instead of a plot we create a flexible environment in which the meaningful choices of the players are allowed to flourish. And by organizing the elements of that situation into nodes we retain the clarity of the plotted approach without accepting the limitations of its straitjacket.

Now that we’ve established the basic elements of node-based design, however, I want to explore some of the tips and tricks I’ve learned in working with node-based prep.

Let’s start by taking a closer look at the fundamental structure of node-based design: How do the players move from one node to the next?

In discussing basic node-based design I defaulted to clue-based movement because (a) it’s simple; (b) it’s versatile; and (c) it clearly demonstrates just how powerful and flexible the node-based approach can be. It’s also fairly universal in my experience: Whatever other methods I may be using, the clue-based approach is virtually always part of the mix.

But it’s not the only way.

PUSH vs. PULL

Let’s start with a general principle.

In discussing narrative velocity in computer games, Andrew Doull coined the terms “push” and “pull”. I find Doull’s usage of the terminology a little vague, but nonetheless useful as a basic concept: A “pull” happens when the players want to explore, experience, or discover a node. A “push” happens when the players are forced to do these things.

A pull, by its nature, requires that the players have some sort of knowledge about the node which makes it desirable for them. The appeal of the pull can take the form of a reward, an opportunity, or any other form of benefit. In a typical D&D dungeon, the pull is the promise of treasure. In a mystery scenario, the simple promise that “you might find some clues over there” is often more than enough of a pull.

A push can similarly rely on player knowledge (“rob the bank or your girlfriend dies”), but it doesn’t necessarily require it. For example, the PCs can be pushed into an encounter with the assassin hunting them (by way of ambush) without ever being aware that the assassin was coming. In other cases, the PCs’ ignorance may be the entire difference between a push and a pull. For example, they might have loved to seek out the Hidden Citadel of the Golden Empire if they had ever heard about it. But since they didn’t, it was a complete push when they randomly stumbled across it during a hexcrawl.

In practice, the distinction between a push and a pull can be somewhat muddy. This is particularly true once you start layering motivations. (For example, the PCs might be forced to investigate the recent raids by giant war parties when the duke threatens to execute them if they don’t. But once they’re engaged in the investigation, the pursuit of individual clues might still be pulls. And maybe they’d already been pulled by the giant raids because Patric’s father was killed by frost giants.)

It should also be noted that pushes don’t need to be fait accompli. The duke threatening to kill them if they don’t investigate the giant raids is certainly a push, but it doesn’t necessarily mean they don’t have the option to leave the duchy and seek their fortunes elsewhere. (Or assassinate the duke. Or bribe him to leave them alone. Or kidnap his daughter and hold her hostage until he grants them a pardon. Or any number of other things.) In other words, the game world can push at the PCs without the GM railroading them.

Pulls and pushes also don’t have to be limited to character motivations; they can also act on player motivations. If you’ve ever heard your players say “let’s find some orcs to kill so that we can level up”, then you’ve heard the siren call of the metagame pull. But this can also take the simple form of “let’s explore the Eyrie of the Raven Queen ‘cause it sounds like the most fun”.

Whether pushing or pulling or both, a node still needs to overcome a certain “gravity” in order to be explored. For some groups, this gravity is simple apathy. (You need to make the place sound a lot more interesting or threaten them with a lot more consequences before they’ll drag their sorry asses out of the local tavern.) Sometimes it’s the competition with other active pulls and pushes. (“We’d love to deal with the Temple of Deep Chaos, but first we need to make sure the Pactlords can’t breach the Banewarrens.”) Or it might be the known and suspected costs of going to the node. (“The Tomb of Horrors may contain a ton of treasure and that’s a fantastic pull… but it’s still a bloody death trap and I don’t want to go there.”)

Go to Part 2: Node Navigation

UPDATE: This page is out of date and no longer maintained. I’m leaving it up to keep the comments archived, but for a complete index of all articles related to node-based scenario design, check Part 1 of the series.

Here’s a convenient index of Node-Based Scenario Design for easy access, easy reading, and easy linking.

Part 1: The Plotted Approach
Part 2: Choose Your Own Adventure
Part 3: Inverting the Three Clue Rule
Part 4: Sample Scenario – Las Vegas CTU
Part 5: Plot vs. Node
Part 6: Alternative Node Design
Part 7: More Alternative Node Designs
Part 8: Freeform Design in the Cloud
Part 9: Types of Nodes

The essays on the Three Clue Rule and scenario-based design make for good supplementary reading if you haven’t seen them already.

UPDATE: A a sequel or supplement for Node-Based Scenario Design has been written under the mind-numbingly clever title Advanced Node-Based Design.