The Alexandrian

Archive for the ‘Roleplaying Games’ category

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

Go to Part 1

Node-Based Scenario Design - Basic Node Structure

The PCs are playing agents in the Las Vegas branch of CTU. This mini-scenario begins when they receive an inter-agency intelligence report that a monitoring program established on a known terrorist operation’s bank account information has recorded payments being made on a storage unit in Las Vegas. The PCs have been authorized to execute a search warrant on the storage unit.

The scenario starts at the North Las Vegas Self-Storage on Lake Mead Boulevard (the BLUE NODE).

Node-Based Scenario Design - North Las Vegas Self-Storage

The storage space itself is stacked high with empty cardboard boxes. Anyone walking past the storage space when the door was open would see a bunch of boxes labeled “LIVING ROOM”, “DISHES”, and the like – but it’s all just for a show. There’s a large gap towards the back where several boxes have recently been removed: Something was being stored here and now it’s gone.

CLUE 1: Checking the rental records reveals that Yassif Mansoor signed the lease on the storage space. The address given on the lease agreement is a fake, but a routine database search turns up a Yassif Mansoor living in the Broadstone Indigo apartment complex on Azure Avenue (NODE A).

CLUE 2: The storage space contains a bellboy uniform belonging to the Bellagio hotel and casino (NODE B).

CLUE 3: There is also a disposable cell phone in the storage space. Checking the call log reveals several calls being placed to a number that can be traced to Officer Frank Nasser (NODE C).

ANCILLARY CLUE: Two detonation caps can be found behind the metal track of the storage space door. (They rolled back there and were lost.)

NODE A: YASSIF MANSOOR’S APARTMENT

Node-Based Scenario Design - Yassif Mansoor's Apartment

Yassif Mansoor isn’t at his apartment, but there are eight terrorists hanging out. Four of them play cards in the living room; two are watching TV in one of the bedrooms; and two more are on the balcony smoking.

Node-Based Scenario Design - Apartment Floorplan

CLUE 1: A large metal trash can in the storage closet off the balcony contains the charcoaled remnants of a massive amount of documentary evidence (Mansoor was covering his tracks). Sifting through the ashes reveals a few partially preserved scraps of paper, including part of a Radio Shack shipping manifest including an order number. Tracking the order reveals several pieces of electronic equipment that could be useful in building bombs. More importantly, it also gives them a credit card number and one of the fake names Mansoor was using. If they track recent activity on the credit card, they’ll find that it was used to rent a room at the Bellagio (NODE B).

CLUE 2: If the PCs can get one of the terrorists to crack under questioning, they can tell them that Yassif Mansoor was at the apartment yesterday with a cop named Nasser (NODE C).

ANCILLARY CLUE: There are six suicide-bomb vests stored in the walk-in closet. After the big bomb went off at the Bellagio, these suicide bombers were going to deliver a second wave of terror throughout Vegas. (These bombers, however, do not know the actual target of the big bomb. That information was sequestered.)

NODE B: THE BELLAGIO

Node-Based Scenario Design - The Bellagio

If the PCs tracked Mansoor’s credit card activity, then they know exactly which suite he’s rented at the Bellagio. If they only know that something might be happening at the Bellagio then the room can be tracked down in a number of ways: Bomb-sniffing dogs; questioning the staff; surveillance; room-by-room canvassing; reviewing security tapes; and so forth.

Node-Based Scenario Design - Hotel Room

Mansoor and six nervous, heavily armed terrorists are waiting in the suite with the Big Bomb (which they snuck into the room on luggage trolleys using bellboy uniforms).

CLUE 1: Yassif Mansoor probably won’t break under questioning, but merely identifying him should allow the PCs to track down his home address (NODE A).

CLUE 2: Sewn into the lining of Mansoor’s jacket is a small packet of microfilm. These contain records indicating that Frank Nasser of the Las Vegas police department is guilty of embezzling from a fund used for undercover drug buys. Mansoor was using these records to blackmail Nasser. (NODE C)

NODE C: FRANK NASSER

Having been blackmailed by Mansoor, Nasser has been helping the terrorist in a number of different ways. (The C4 for the suicide bombers, for example, was taken from a police lock-up Nasser was responsible for. And Nasser intimidated a beat cop into dropping a speeding ticket issued on one of Mansoor’s men.)

CLUE 1: Nasser is more likely to crack under questioning than Mansoor (particularly if the PCs reveal that they have hard evidence of any of his wrong-doing). But he’s also aware of the consequences: If he can, he’ll try to cut a deal before answering their questions.

CLUE 2: Nasser can also be placed under surveillance. He will check in at both the Bellagio and Mansoor’s apartment before the bombings occur.

Go to Part 5: Plot vs. Node

Go to Part 1

The Three Clue Rule states:

For any conclusion you want the PCs to make, include at least three clues.

The underlying theory behind the rule is that having three distinct options provides sufficient redundancy to create a robust scenario: Even if the PCs miss the first clue and misinterpret the second, the third clue provides a final safety net to keep the scenario on track.

This logic, however, also leads us to the inversion of the Three Clue Rule:

If the PCs have access to ANY three clues, they will reach at least ONE conclusion.

In other words, if you need the PCs to reach three conclusions (A, B, and C) and the PCs have access to three clues (each of which would theoretically allow them to reach one of those conclusions) then it is very likely that they will, in fact, reach at least one of those conclusions.

And understanding this inversion of the Three Clue Rule allows us to embrace the full flexibility of node-based design. Here’s a simple example:

Node-Based Scenario Design - Basic Node Design

The scenario starts in the blue node, which contains three clues – one pointing to node A, one to node B, and one to node C. Following the inverse of the Three Clue Rule, we therefore know that the PCs will be able to conclude that they need to go to at least one of these nodes.

Let’s assume they go to node A. Node A contains two additional clues – one pointing to node B and the other pointing to node C.

At this point the PCs have had access to 5 different clues. One of these has successfully led them to node A and can now be discarded. But this leaves them with four clues (two pointing to node B and two pointing to node C), and the inverse of the Three Clue Rule once again shows us that they have more than enough information to proceed on.

Let’s assume they now go to node C. Here they find clues to nodes A and B. They now have access to a total of seven clues. Four of these clues now point to nodes they have already visited, but that still leaves them with three clues pointing to node B. The Three Clue Rule itself shows that they now have access to enough information to finish the scenario.

(Note that we’re only talking about clue access here. That doesn’t mean that they’re guaranteed to find or correctly interpret every single clue. In fact, we’re assuming that they don’t.)

Now, compare this node-based design to a comparable plotted approach:

Node-Based Scenario Design - Plotted Approach With Clues

Note that the plotted approach can also be broken down into distinct nodes. And in terms of preparation, the plotted approach requires the exact same resources: Four nodes and nine clues. But the non-plotted design is richer, more flexible, and leaves the PCs in the driver’s seat. In other words, even in the simplest examples, node-based design allows you to get more mileage out of the same amount of work.

Of course, this entire discussion has been rather dry and technical. So let’s put some flesh on these bones.

Go to Part 1

Of course, it’s all well and good to say, “Prep Situations.” But one of the reasons people prefer the plotted approach is that it provides a meaningful structure: It tells you where you’re going and it gives you a way to get there.

Without that kind of structure, it’s really easy for a gaming session to derail. It’s certainly not impossible to simply turn the PCs loose, roll with the punches, and end up somewhere interesting. Similarly, it’s quite possible to jump in a car, drive aimlessly for a few hours, and have a really exciting time of it.

But it’s often useful to have a map of the territory.

This line of thought, however, often leads to a false dilemma. The logic goes something like this:

(1) I want my players to have meaningful choice.
(2) I need to have a structure for my adventure.
(3) Therefore, I need to prepare for each choice the players might make.

And the result is an exponentially expanding adventure path:

Node-Based Scenario Design - Exponentiall Expanding Adventure Path

The problem with this design should be self-evident: You’re preparing 5 times as much material to supply the same amount of playing time. And most of the material you’re preparing will never be seen by the players.

In some ways, of course, this is an extreme example. You could simplify your task by collapsing some of these forks into each other:

Node-Based Scenario Design - Collapsed Forks

But even here you’re designing eight steps worth of material in order to provide three steps of actual play. You’re still specifically designing material that you know will never be used.

And in other ways it’s actually not that extreme at all: The original example assumes that there are only two potential choices at any given point on the path. In reality, it’s quite possible for there to be three or four or even more – and each additional choice adds a whole new series of contingencies that you need to account for.

Ultimately, this sort of “Choose Your Own Adventure” prep is a dead end: No matter how much you try to predict ahead of time, your players will still find options you never considered — forcing you back into the position of artificially constraining their choices to keep your prep intact and leaving you with the exact same problem you were trying to solve in the first place. And even if that wasn’t true, you’re still burdening yourself with an overwrought preparation process filled with unnecessary work.

The solution to this problem is node-based scenario design. And the root of that solution lies in the inversion of the Three Clue Rule.

Go to Part 3: Inverting the Three Clue Rule

Archives

Recent Posts

Recent Comments

Copyright © The Alexandrian. All rights reserved.