The Alexandrian

Posts tagged ‘node-based scenario design’

Go to Part 1

Up to this point I’ve been fairly vague about exactly what I mean by a “node”. This is largely because there isn’t really a hard-and-fast definition of the term.

In generic terms, you can think of each node as a “point of interest”. It’s the place (either literally or metaphorically) where something interesting can happen and (in most cases) information about other interesting things can be found.

In my experience, nodes are most useful when they’re modular and self-contained. I think of each node as a tool that I can pick up and use to solve a problem. Sometimes the appropriate node is self-evident. (“The PCs are canvassing for information on recent gang activity. And I have a Gather Information table about recent gang activity. Done.”) Sometimes a choice of tool needs to be made. (“The PCs have pissed off Mr. Tyrell. Does he send a goon squad or an assassin?”) But when I look at an adventure, I tend to break it down into discrete, useful chunks.

Chunks that become too large or complex are generally more useful if broken into several smaller nodes. Chunks that are too small or fiddly are generally more useful if grouped together into larger nodes. The “sweet spot” is about identifying the most utilitarian middle-ground.

(To take an extreme example: “All the forestland in the Kingdom of Numbia” is probably too large for a single node. On the other hand, 86,213 separate nodes each labeled “a tree in the Forest of Arden” are almost certainly too fiddly. Is the appropriate node the “Forest of Arden”? Or is it twelve different nodes each depicting a different location in the Forest of Arden? I don’t know. It depends on how you’re using the Forest of Arden.)

Let’s get more specific. Here are the sorts of things I think of as “nodes”:

LOCATIONS: A place that the PCs can physically go. If you think of a clue as being anything that “tells you where to go next”, telling the PCs about a specific place that they’re supposed to go is the most literal interpretation of the concept. Once PCs arrive at the location, they’ll generally find more clues by searching the place.

PEOPLE: A specific individual that the PCs should pay attention to. It may be someone they’ve already met or it may be someone they’ll have to track down. PCs will generally get clues from people by either observing them or interrogating them.

ORGANIZATIONS: Organizations can often be thought of as a collection of locations and people (see Nodes Within Nodes, below), but it’s not unusual for a particular organization to come collectively within the PCs’ sights. Organizations can be both formal and informal; acknowledged and unacknowledged.

EVENTS: Something that happens at a specific time and (generally) a specific place. Although PCs will often be tasked with preventing a particular event from happening, when events are used as nodes (i.e., something from which clues can be gathered), it’s actually more typical for the PCs to actually attend the event. (On the other hand, learning about the plans for an event may lead the PCs to the location it’s supposed to be held; the organization responsible for holding it; or the people attending it.)

ACTIVITY: Something that the PCs are supposed to do. If the PCs are supposed to learn about a cult’s plan to perform a binding ritual, that’s an event. But if the PCs are supposed to perform a magical binding ritual, then that’s an activity. The clues pointing to an activity may tell the PCs exactly what they’re supposed to be doing; or they may tell the PCs that they need to do something; or both.

NODES WITHIN NODES

In other words, at its most basic level a node is a person, a place, or a thing.

As suggested above, however, nodes can actually be fairly complex in their own right. For example, the entire Temple of Elemental Evil (with hundreds of keyed locations) could be thought of as a single node: Clues from the village of Hommlet and the surrounding countryside lead the PCs there, and then they’re free to explore that node/dungeon in any way that they wish.

Similarly, once the PCs start looking at the Tyrell Corporation they might become aware of CEO James Tyrell, the corporate headquarters, their shipping facility, the server farm they rent, and the annual Christmas party being thrown at Tyrell’s house — all of which can be thought of as “sub-nodes”. Whether all of these “sub-nodes” are immediately apparent to anyone looking at the Tyrell Corporation or if they have to be discovered through their own sub-network of clues is largely a question of design.

In short, you can have nodes within nodes. You can plan your campaign at a macro-level (Tyrell Corporation, Project MK-ALTER, the Chicago Sub-City, and the Kronos Detective Agency), look at how those macro-nodes relate to each other, and then develop each node as a separate node-based structure in its own right. Spread a few clues leading to other macro-nodes within each network of sub-nodes and you can achieve highly complex intrigues from simple, easy-to-use building blocks.

Advanced Node-Based Design

Go to Part 1

Everything we’ve been discussing here are basic, systematic designs. But there’s no reason you need to be symmetrical. Maybe node A has two clues pointing to node B while node C is clue-happy for node A.

Node-Based Scenario Design - Asymmetrical Nodes

On a larger scale, you’ll probably find yourself mashing together lop-sided conglomerations of disparate structures.

For example, a good-sized chunk of my current campaign is based around a general layer cake approach: An interconnected web of criminal organizations allow the PCs to generally make their way up the “chain of command”. But this layer cake naturally funnels towards various sub-conclusions, and I’ve also included loops designed to carry the PCs back to points prior to the various funnels.

That approach may seem jargon-filled, but it’s really just a matter of embracing the fundamentally flexible principles of node-based design, strewing clues liberally, and spot-checking to avoid problem areas.

Looking over my notes for this campaign, I’ve come to think of this as the “cloud”: Dozens of nodes all containing clues and linked to by clues. Even if we discount all the different ways in which the PCs can approach each of these nodes, the complex relationships which emerge from the node structure make literally hundreds of potential outcomes possible.

But I didn’t have to think about that emergent complexity as I was designing the campaign-scale scenario: All I needed to do was design the criminal organization, break it into node-sized chunks, and then lay down the clues necessary to navigate to and from each node.

As I write this, my players are about mid-way through this section of the campaign. It’s been filled with countless surprises for all of us, and these surprises lead me to a final point regarding the strengths of node-based design: It’s flexible in play.

Because each node is, effectively, a modular chunk of material, it becomes very easy to rearrange the nodes on-the-fly. For example, when the PCs raided an enemy compound and wiped out half of their personnel before being forced to pull back, it was very easy for me to look around, grab a different node full of bad guys, and plug them in as reinforcements.

In other words, it was as easy for me to call in the reinforcements as it was for the NPCs to pick up the phone. Node-based design gives you, by default, the scenario-based toolkit I talked about in “Don’t Prep Plots”. And the underlying structural function of that node hadn’t changed: The NPCs still had the same clues to provide that they’d been designed to provide at their previous location.

Go to Part 9: Types of Nodes

Go to Part 1

LARGE LAYERS

In case it hasn’t been clear, I’ve been using three-node layers in these examples because it’s a convenient number for showing structure. But there’s nothing magical about the number. Each “layer” in the previous examples constitutes an interlinked environment (either literal or metaphorical) for exploration or investigation, and you can make these environments as large as you’d like.

As long as each node has a minimum of three clues in it and a minimum of three clues pointing to it, the Three Clue Rule and its inversion will be naturally satisfied and guarantee you a sufficiently robust flow through the layer. But as you increase the number of nodes, you also open the possibility for varying clue density: Particularly dense clue locations could have six or ten clues all pointing in different directions.

Obviously, however, the larger each layer is, the more prep work it requires.

DEAD ENDS

Dead ends in a plotted mystery structure are generally disasters. They mean that the PCs have taken a wrong-turn or failed to draw the right conclusions and now the train is going to crash into a wall: There should be a clue here for them to follow, but they’re not seeing it, so there’s nowhere to go, and the whole adventure is going to fall apart.

But handled properly in a node-based structure, dead ends aren’t a problem: This lead may not have panned out, but the PCs will still have other clues to follow.

Node-Based Scenario Design - Dead Ends

In this example, node E is a dead end. Clues at nodes B and C suggest that it should be checked out, but there’s nothing to be found there. Maybe the clues were just wrong; or the bad guys have already cleared out; or it looked like a good idea but it didn’t pan out into usable information; or it’s a trap deliberately laid to catch the PCs off-guard. The possibilities are pretty much limitless.

The trick to implementing a dead end is to think of clues pointing to the dead end as “bonus clues”. They don’t count towards the maxim that each node needs to include three different clues. (Otherwise you risk creating paths through the scenario that could result in the PCs being left with less than three clues. Which may not be disastrous, but, according to the Inverse Three Clue Rule, might be.)

On the other hand, as you can see, you also don’t need to include three clues leading to a dead end: It’s a dead end, so if the PCs don’t see it there’s nothing to worry about.

Of course, if you include less than three clues pointing to the dead end then you’re increasing the chances that you’re prepping content that will never be seen. But this also means that the discovery of the dead end might constitute a special reward: Extra treasure or lost lore or a special weapon attuned to their enemy.

Which leads to a broader point: Dead ends may be logistical blind alleys, but that doesn’t mean they should be boring or meaningless. Quite the opposite, in fact.

In the same vein as dead ends, you can also use “clue light” locations. (In other words, locations with less than three clues in them.) Structurally such locations generally work like dead ends, by which I mean that clues pointing to clue light locations need to be “bonus clues” to make sure that the structure remains robust.

The exception to this guideline is that you can generally have a number of two-clue locations equal to the number of clues accessible in a starting node. (For example, in the layer cake structure diagram you have three nodes in the bottom layer with only two clues each because the starting node contains three clues. If there wasn’t a starting node with three clues in it, the same structure would have potential problems.)

LOOPS

Node-Based Scenario Design - Loops

In this simple loop structure all four nodes contain three clues pointing to the other three nodes. The advantage of this simple structure is that the PCs can enter the scenario at any point and navigate it completely.

Obviously, this is only useful if the PCs have multiple ways to engage the material. In a published product this might be a matter of giving the GM several adventure hooks which can be used (each giving a unique approach to the adventure). In a personal campaign, clues for nodes A, B, C, and D might be scattered around a hexcrawl: Whatever clues the PCs find or pursue first will still lead them into this chunk of content and allow them to explore it completely.

Go to Part 8: Freeform Design in the Cloud

Go to Part 1

On the other hand, there is something to be said for the Big Conclusion. There are plenty of scenarios that don’t lend themselves to a shuffling between nodes of equal importance: Sometimes Dr. No’s laboratory is intrinsically more important than Strangeways’ library. And the Architect’s inner sanctum requires the Keymaker.

So let’s talk about some alternative node structures.

CONCLUSIONS

Node-Based Scenario Design - Conclusions

In this design, each node in the second layer contains a third clue that points to the concluding node D. The function should be fairly self-explanatory: The PCs can chart their own course through nodes A, B, and C while being gently funneled towards the big conclusion located at node D.

(Note: They aren’t being railroaded to D. Rather, D is the place they want to be and the other nodes allow them to figure out how to get there.)

One potential “problem” with this structure is that it allows the PCs to potentially bypass content: They could easily go to node A, find the clue for node D, and finish the adventure without ever visiting nodes B or C.

Although this reintroduces the possibility for creating unused content, I put the word “problem” in quotes here because in many ways this is actually desireable: When the PCs make the choice to avoid something (either because they don’t want to face it or because they don’t want to invest the resources) and figure out a way to bypass it or make do without it, that’s almost always the fodder for an interesting moment at the gaming table in my experience. Nor is that content “wasted” — it is still serving a purpose (although its role in the game may now be out of proportion with the amount of work you spent prepping it).

Therefore, it can also be valuable to incentivize the funneling nodes in order to encourage the PCs to explore them. In designing these incentives you can use a mixture of carrots and sticks: For example, the clue in node A might be a map of node D (useful for planning tactical assaults). The clue in node B might be a snitch who can tell them about a secret entrance that doesn’t appear on the map (another carrot). And node C might include a squad of goons who will reinforce node D if they aren’t mopped up ahead of time (a stick).

(That last example also shows how you can create multi-purpose content. It now becomes a question of how you use the goon squad content you prepped rather than whether you’ll use it.)

FUNNELS

The basic structuring principles of the conclusion can be expanded into the general purpose utility of funneling:

Node-Based Scenario Design - Funnels

Each layer in this design (A, B, C and E, F, G) constitutes a free-form environment for investigation or exploration which gradually leads towards the funnel point (D or H) which contains the seeds leading them to the next free-form environment.

I generally find this structure useful for campaigns where an escalation of stakes or opposition is desirable. For example, the PCs might start out investigating local drug dealers (A, B, C) in an effort to find out who’s supplying drugs to the neighborhood. When they identify the local distributor (D), his contacts lead them into a wider investigation of city-wide gangs (E, F, G). Investigating the gangs takes them to the Tyrell crime family (H), and mopping up the crime family gets them tapped for a national Mafia task force (another layer of free-form investigation), culminating in the discovery that the Mafia are actually being secretly run by the Illuminati (another funnel point).

(The Illuminati, of course, are being run by alien reptoids. The reptoids by Celestials. And the Celestials by the sentient network of blackholes at the center of our galaxy. The blackhole consciousness, meanwhile, has suffered a schizoid bifurcation due to an incursion by the Andromedan Alliance…. wait, where was I?)

In particular, I find this structure well-suited for D&D campaigns. You don’t want 1st-level characters suddenly “skipping ahead” to the mind flayers, so you can use the “chokepoints” or “gateways” of the funnel structure to move them from one power level to the next. And if they hit a gateway that’s too tough for them right now, that’s OK: They’ll simply be forced to back off, gather their resources (level up), and come back when they’re ready.

Another advantage of the funnel structure is that, in terms of prep, it gives you manageable chunks to work on: Since the PCs can’t proceed to the next layer until they reach the funnel point, you only need to prep the current “layer” of the campaign.

LAYER CAKES

Node-Based Scenarios Designs - Layer Cakes

A layer cake design achieves the same general sense of progression that a funnel design gives you, but allows you to use a lighter and looser touch in structuring the scenario.

The most basic structure of the layer cake is that each node in a particular “layer” gives you clues that lead to other nodes on the same layer, but also gives you one clue pointing to a node on the second layer. Although a full exploration of the first layer won’t give the PCs three clues to any single node on the second layer, they will have access to three clues pointing to a node on the second level. Therefore, the Inverted Three Clue Rule means that the players will probably get to at least one node on the second layer. And from there they can begin collecting additional second layer clues.

Whereas PCs in a funnel design are unlikely to backup past the last funnel point (once they reach node E they generally won’t go back to node C since it has nothing to offer them), in a layer cake design such inter-layer movement is common.

Layer cakes have a slightly larger design profile than funnels, but allow the GM to clearly curtail the scope of their prep work (you only need to prep through the next layer) while allowing the PCs to move through a more realistic environment. You’ll often find the underlying structure of the layer cake arising naturally out of the game world.

Go to Part 7: More Alternative Node Designs

 

Go to Part 1

As I noted before, the plotted approach gives control to the designer of the scenario by taking that control away from the players.

For example, if we were to re-design our Las Vegas CTU scenario using the plotted approach, we could carefully control the flow of events:

Node-Based Scenario Design - Plotted Approach

Evidence at the self-storage facility (BLUE NODE) leads the PCs to Yassif Mansoor’s apartment (NODE A) where they have a frenzied gun-fight with the suicide bombers. But Mansoor is missing and there’s evidence of an even bigger bomb somewhere in Vegas! Their only hope is to track down the corrupt cop Frank Nasser (NODE C) and force him to break under questioning. But will they reach the Bellagio in time (NODE B)?

This is obviously an effective way for the scenario to play out: Everything builds naturally up to a satisfying confrontation with the Bad Guy and his Big Bomb. The argument can certainly be made that you would want to enforce this linearity to make sure that the PCs don’t take out Mansoor and the Big Bomb half-way through the scenario and end up with a massive anti-climax.

But in making that argument, I think we’re overlooking some equally viable alternatives.

For example: Following evidence at the self-storage facility the PCs head to the Bellagio. There they capture the internationally infamous terrorist Yassif Mansoor and disarm the Big Bomb. It looks like they’ve wrapped everything up, but then they discover the truth: There are more bombs! The Bellagio bombing was only the tip of the iceberg, and even from behind bars Mansoor is about to turn the Las Vegas Strip into a Boulevard of Terror!

(And in a more reactive scenario, you might even introduce the possibility of the undiscovered Nasser somehow freeing Mansoor from his cell.)

My point here is that when you create individually interesting nodes, you’ll generally find that those nodes can be shuffled into virtually any order and still end up with an interesting result. The PCs might even decide to split up and pursue two leads at the same time (in true CTU style).

As a GM I find these types of scenarios more interesting to run because I’m also being shocked and surprised at how the events play out at the gaming table. And as a player I find them more interesting because I’m being allowed to make meaningful choices.

Of course, the argument can be made that there’s no “meaningful choice” here because there are three nodes in the scenario and the PCs are going to visit all three nodes no matter what they do. In the big picture, the exact order in which they visit those nodes isn’t meaningful.

Or is it?

Even in this small, simple scenario, the choices the PCs make can have a significant impact on how events play out. If they go to the Bellagio after they’ve identified exactly which room Yassif Mansoor is in, for example, they’ll have a much easier time of confronting the terrorists without tipping them off. If they have to perform a major search operation on the hotel, on the other hand, the terrorists may have laid a trap for them; Mansoor might have a chance to escape; or there might have been time to make a phone call and warn the terrorists back at the apartment.

And in more complex scenarios, of course, there will be more meaningful contexts for choices to be made within. For example, something as simple as adding a timeline to our sample scenario can make a big difference: If CIA communication intercepts indicate a high threat of a terrorist attack in Vegas timed for 6:00 pm, then PCs standing in the storage facility with multiple leads to pursue suddenly have a tough choice to make. Do they go to the Bellagio because it’s a high-profile target despite the fact they aren’t sure exactly what they should be looking for there? Do they go to Mansoor’s apartment in the hope that they can find out more information about the Bellagio attack? Do they split up and pursue both leads in tandem? Do they call in the Vegas police to evacuate the Bellagio while they pursue the apartment lead? (Is that even a safe option if they have evidence pointing to a mole inside the department?)

Furthermore, when an individual scenario is placed within the context of a larger campaign it allows the choices made within that scenario to have a wider impact. For example, if they tip off Mansoor and allow him to escape by rushing their investigation, it means that he can return as a future antagonist. Similarly, if they don’t find or follow the leads to Nasser, the continued presence of a terrorist-compromised mole in the Las Vegas police force can create ongoing problems for their investigations.

(And if the Bellagio gets blown up there will obviously be a long-lasting impact on the campaign.)

On a more basic level, in my opinion, the fact that the players are being offered the driver’s seat is meaningful in its own right. Even if the choice doesn’t have any lasting impact on the final conclusion of “good guys win, bad guys lose”, the fact that the players were the ones who decided how the good guys were going to win is important. If for no other reason than that, in my experience, it’s more fun for everybody involved. And more memorable.

Go to Part 6: Alternative Node Design

Archives

Recent Posts


Recent Comments

Copyright © The Alexandrian. All rights reserved.