The Alexandrian

Posts tagged ‘node-based scenario design’

Go to Part 1

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:

Advanced Node-Based Design 3

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:

Advanced Node-Based Design 3

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.

Go to Part 1

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. Second, the clues that take the PCs to another location or event where more clues can be gathered.

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.

To  be continued…

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

To be continued…

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

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:

Advanced Node-Based Design 5

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.

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

To be continued…

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:

Advanced Node-Design 3

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:

Advanced Node-Based Design 4

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

To be continued…

Archives

Pages


Recent Posts

Recent Comments

Proudly powered by WordPress. Theme developed with WordPress Theme Generator.
Copyright © The Alexandrian. All rights reserved.