Posts tagged ‘node-based scenario design’

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

Room 1: Entrance And Guardian

Room 2: Puzzle Or Roleplaying Challenge

Room 3: Red Herring

Room 4: Climax, Big Battle Or Conflict

Room 5: Plot Twist

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

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

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

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

THE 5 NODE MYSTERY

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

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

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

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

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

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

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

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

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

THE 5 x 5 NODE CAMPAIGN

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

EPHEMERAL BARRIERS: Consider our simple dungeon example again:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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

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 node-based design itself, 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.

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 current 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)

(I’ve rendered this as white text because it has minor spoilers for my current players. If you’re not one of my players, just highlight the text to read it.)

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.