A hexcrawl is one way of looking at a game world.

Like other scenario and campaign structures, a hexcrawl can be broadly understood as a method for organizing prepped material paired to a complementary procedure of play: A dungeon procedure provides structure for PCs moving between rooms and exploring their contents, and it’s logically paired to a prep structure in which rooms are positioned on a map (to make them easy to reference) and keyed with the information needed to explore them.

A hexcrawl, similarly, creates a map of the world broken down into hexes because those hexes provide a convenient structure for keying content and managing overland exploration.

But one must not mistake the map for the territory.

One way to think about this is to consider the howling wilderness of the typical hex: We generally key no more than a single point of interest in each hex. But whether we’re talking about a 5-mile hex, a 6-mile hex, or the Alexandrian 12-mile hex, if there was really only one point of interest in a hex, it would mean a vast and desolate place.

Lay a hex grid to scale over a map of your local county, shire, or district and you’ll see what I mean. For example, consider Brown County in Minnesota, which I picked by basically clicking randomly on a map. It would consist of roughly eight 12-mile hexes, but it contains seven cities, a couple dozen townships, fifteen major lakes, three major parks and wildlife preserves, multiple scientific outposts, and forty different sites on the National Register of Historic Places. Whichever eight of those you pick, you’re obviously going to be leaving a lot of stuff out of your hex key.

That’s how the real world works. It’s also how your game world works: Whether consciously or otherwise, you’re choosing to key the most important or significant thing in each hex, while overlooking the others. This isn’t a problem, of course, unless you forget the conceit and begin to believe that what you’ve keyed is everything the game world has to offer.

(This is also why the Alexandrian Hexcrawl uses random encounters to procedurally generate new locations — e.g., lairs — on the hexmap. The more time the players spend in a particular region, the more of these “overlooked” details they’ll have a chance to discover precisely in the area of the game world they’re spending the most time in.)

The hexcrawl also has a procedural bias: The material is structured and keyed for the PCs to discover it through geographical exploration (e.g., “We walk north until we see something interesting.”). But this is not, of course, the only way that PCs can explore or interact with an area. It’s also pretty easy to imagine interesting elements of the game world that are largely or entirely inaccessible to simple geographic movement.

What I’ve found useful is to think of different structures as being “layers” of the game world. A hexmap, for example, is one “layer” — one method of keying and describing the game world — and it’s often more than enough to run an entire campaign. But it’s not a complete picture of the game world, and you can add more layers, each describing the world in a different way and each conducive to different types of PC actions.

Furthermore, since these layers are all describing the same world, they will also overlap or intersect with each other in different ways. While the PCs are exploring and interacting with the world in one way, you’ll be able to use the appropriate layer to run the game for them. Then, when they discover something new and/or set a new goal that will lead them to begin exploring the world in a new way, you’ll be able to shift to a new layer — a different scenario or campaign structure — to adjudicate what happens next.

And you can also, as the GM, design your world with these phase shifts in mind!

NODE-BASED LAYER

For example, consider node-based scenario design, in which nodes are linked to each other by clues.

Each node is a person, organization, event, activity, or, crucially, location. This means that each location keyed to your hexmap can also be thought of as a node and linked to other locations on your hexmap (i.e., other nodes) via clues.

For example, the hobgoblin bandits lairing in the ruins of the Black Baron’s Keep may have been sent by the Necromancer to spy on the elves of Silverwood. When keying the Black Baron’s Keep, therefore, it would be perfectly natural to include clues pointing to both the elven village in Silverwood and the Necromancer’s Tower.

If you want to start experimenting with this technique in your own hexcrawls, I recommend getting started with some simple loops:

The Black Baron’s Keep has clues pointing to the Necromancer’s Tower, the Elven Village, and the Hobgoblin Village.

Meanwhile, the Necromancer’s Tower has clues pointing to the Black Baron’s Keep, the Elven Village, and the Hobgoblin Village.

And so forth.

The advantage of this design is that it creates compact little scenarios that can be naturally explored no matter which of the nodes the PCs encounter first: Whether they’re attracted by the strange lights in the Black Baron’s Keep, hear reports of hobgoblin raids from the elves of Silverwood, or stumble across the hobgoblin village, they’ll be able to follow the clues and discover the other nodes.

To add additional complexity to these simple setups, consider linking a single node to multiple loops. For example, spying on the Silverwood may be only one of the Necromancer’s current schemes, with her tower acting as a sort of crossroads between different node-based scenarios.

As you become more comfortable with adding node-based layers to your hexcrawl, you’ll likely end up gravitating towards freeform design in the cloud, with your various hex-keyed locations pointing to each other freely in whatever manner makes the most sense. In doing so, you may also discover that you can use these same techniques without necessarily creating fully robust node-based scenarios.

What I mean is that, with the hexcrawl structure as a backstop, you don’t need to strictly obey the Three Clue Rule or Inverted Three Clue Rule. Or, to put it more simply: You can include a single clue from Hex A to Hex B, and it’s just fine if the PCs don’t find it, because the hexcrawl structure means they can just geographically navigate their way to Hex B with or without the clue.

Note that you can also plant clues into other structures of your hexcrawl campaign:

• Rumor tables, for example, are basically just big lists of free-ranging clues.
• Random encounters can also include clues pointing to hex locations. (This can even be true of procedurally generated clues. Tracks, for example, are inherently clues that point you to the locations that creatures are coming from or going to.)
• Even random treasure can be used to plant clues. (Random treasure maps are a classic example of this.)

All of these links add depth to your campaign. They actually feed back into the hexcrawl structure itself, giving the PCs’ the information they need to set goals that will guide their exploration, allowing them to travel with purpose instead of just wandering around the map aimlessly.

However, we’re still only scratching the surface here, because so far we’ve only been linking locations that also appear in our hex key (and are, therefore, also accessible via the hexcrawl). There’s no reason that we need to limit ourselves like this: Locations discovered through the hexcrawl can link us to nodes — people, events, organizations, activities, and even other locations — that DON’T appear in the hex key and could never be discovered by simply moving around the hex map. They literally exist on a completely separate “layer” of your campaign world.

I frequently find this approach useful for cities located in my hexcrawls. Like Maernath, for example:

Maernath might be the PCs’ homebase for the hexcrawl, or it might be a city they discover while exploring the region. Either way, it’s easy to see how the city itself could be encountered through the hexcrawl structure.

But simply seeing a city on the horizon isn’t going to reveal all of its secrets to you. For example, what if a scion of one of the noble families is collaborating with the Necromancer? They might be just one node in a much larger conspiracy scenario that’s infesting the city, but the PCs are unlikely to stumble onto this conspiracy just because they walked through the city gates.

(What I also like about this is that it connects the urban environment to the surrounding wilderness, and you can obviously do the reverse, too. It weaves your campaign together, not only adding depth, but also making everything feel interconnected.)

Another fun technique is to stock your hexcrawl with rituals, allowing the PCs to piece together the clues and supplies they need to figure out what, where, and possibly when they need to perform the ritual. These rituals, in turn, might unlock unique spells and abilities; empower magic items; summon mystic allies; or even open portals to extradimensional adventuring sites.

The region described by your hexcrawl might also include traveling elements, like a touring carnival, merchant caravan, or mystic phoenix. These are, obviously, not keyed to specific locations. You might include such elements on your random encounter table as one way of integrating them into the hexcrawl structure, but node-based design can provide another path for the PCs to discover them and track them down.

Note: You can also use node-based scenario design to provide links to location nodes far away from the region covered by the hexcrawl (e.g., you’ll need to take a ship south to pursue the political backing of the local privateers; or you’ll need to go to the Imperial City to follow the Cult of the Black Eye). This isn’t quite same thing as thinking of the campaign in terms of “layers,” but it IS an example of how you can use shifts in structure to present or handle different types of scenarios. Your structure should never feel like a straitjacket; it should be a tool that liberates you.

Go to Part 2: Pointcrawl Layers

Back to Hexcrawls

Desert Orange asks:

I’m trying to use node-based scenario design for the first time. I’m designing a Hangover-style scenario on a superyacht: the PCs wake up on the ship surrounded by corpses and with no memory of how they got there.

If I’m using a funnel design, is it possible to only have two nodes before the first funnel? There’d only be two clues per node. That can’t be right. But what bugs me is that I only have two locations for the PCs to explore: the ship they’re on and the island that’s nearby.

I’m not sure if I should use the locations as nodes or the conclusions that the characters have to reach. The funnel would be figuring out how the previous night ended. After this, they’d begin figuring out how it started.

Easy answer first: If you’re designing a node-based mystery, think of each node as a place where you can investigate for clues.

Each node (other than the starting node) is also a revelation/conclusion because the players have to conclude that they can go to the node and investigate. (The three clues pointing to Node X are basically pointing to a conclusion which says, “You can find more clues at Node X.”)

But in a mystery scenario you can also have conclusions that aren’t nodes – i.e., things that the PCs need to learn that aren’t places they can go to investigate for more clues.

In my more recent writing, I’ve started referring to clues that point to places where you can continue your investigation as leads – they lead you somewhere. In node-based design it’s the leads that need to adhere to the Inverse Three Clue Rule:

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

Because as long as the PCs have somewhere to continue investigating the mystery, the adventure keeps working. It’s only if they run out of places to investigate that the adventure breaks.

So in your Hangover cruise adventure, for example, you’ll have a list of revelations which consist of Things That Happened To Us That We’ve Forgotten. And you’ll want clues for each of those (and three clues for any that the PCs need to know about). Those probably aren’t leads.

NOT ALL MYSTERIES HAVE NODES

But here’s the thing: I don’t think your mystery is actually a node-based scenario. At least not at first.

The PCs are not trying to figure out where to look for clues: The clues are on the ship.

So what you actually have is a location-crawl in which they explore the ship room by room, finding clues in each room. You’re still using the Three Clue Rule:

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

And you’ll have a revelation list so that the PCs can piece together what happened to them, but the players aren’t really finding clues in the helm station that tell them they should check out the stern deck for clues. They’re just methodically searching the ship for clues (while also potentially dealing with other crises or conundrums).

(This isn’t to say that a location-crawl can’t have clues in Room A that point the PCs to Room B, for example. That’s a great way to make a location-crawl feel cohesive and, if those clues are revealing hidden secrets that the PCs might have missed in Room B the first time they went, can add a lot of depth to the experience. But that’s not really node-based design and doesn’t structurally function as a node-based adventure.)

Now if there are clues on the ship that point the PCs to another location where they need to continue their investigation, that would suggest a node-based design. (Maybe they need to realize that the superyacht was at a different location at some point last night and they need to go there. Or they discover the ritual that opened a gateway to a dark dimension that they need to go back to in order to continue piecing things together.) But I still wouldn’t try to break the ship up into multiple nodes: The superyacht as a whole would just be one node, with that node basically being a mini-location-crawl inside the larger scenario.

You’d mentioned that you wanted the scenario to start with them figuring out how the previous night ended and then, after that, they’d begin figuring out how it started. You can see how this structure would essentially accomplish that: The superyacht has all the clues that let them figure out how the previous night ended, which allows them to figure out where the night started (i.e., the other node where they can look for the clues to figure out what happened there).

In fact, this node-based scenario might consist of just these two nodes: The superyacht and where the night started.

There’s nothing about node-based design that says you have to get super-complicated about it.

REGARDING FUNNELS

Although I don’t think it necessarily applies to this scenario, let’s talk about your specific question regarding funnel design for a moment: The key thing about the Inverse Three Clue Rule is that the PCs should have access to at least three clues at all time.

(This doesn’t necessarily mean they will FIND all those clues. The whole reason you have redundancy is in case they don’t, after all. But they should have ACCESS to them, by which I mean that in locations which the PCs know about, there should be at least three clues pointing to locations that they don’t already know about. Or, in the final scene(s) of a scenario where they’ve almost finished their investigation, three clues that point to all the conclusion(s) they need to bring the scenario to its conclusion.)

In addition, the Three Clue Rule still applies! You still need three clues for each conclusion the PCs need to reach!

So your current structure is:

• Node 0 ➞ A, B
• Node A ➞ B, C
• Node B ➞ A, C
• Node C

We can immediately see that in Node 0 (the opening scene) they only have access to two clues. That’s a structural problem which violates the Inverse Three Clue Rule.

In addition, you basically have three conclusions:

• You need to investigate Node A.
• You need to investigate Node B.
• You need to investigate Node C.

But for each of those conclusions, there are only two clues, which means you’ve violated the Three Clue Rule.

Adding enough clues to satisfy the Three Clue Rule will, conveniently, also satisfy the Inverse Three Clue Rule. Here’s a symmetrical example:

• Node 0 ➞ A, A, B
• Node A ➞ B, B, C
• Node B ➞ A, C, C
• Node C

You could also saturate the opening scene:

• Node 0 ➞ A, A, B, B
• Node A ➞ B, C
• Node B ➞ A, C, C
• Node C

And other patterns are also possible:

• Node 0 ➞ A, A, A, B
• Node A ➞ B, B, C
• Node B ➞ C, C
• Node C

If you walk through these simple node structures, you can clearly see how the PCs always have access to three clues pointing towards nodes they haven’t investigated yet.

You may also be able to see how different patterns of clues will make certain paths through the adventure more or less likely. For example, in the third arrangement it’s much more likely that the PCs will end up going 0 ➞ A ➞ B ➞ C, but if they DO go from 0 ➞ B, then it becomes likely they’ll never go to Node A.

If you’re dabbling with node-based scenario design for the first time, I recommend doing a couple of symmetric designs first. It will give you more reliable results and a better sense, after running the scenarios, of what node-based scenarios “feel” like.

Go to Ask the Alexandrian #4

Go to Part 1

Once I came to see scenes as an emergent property of game play (rather than something that’s prepared), I began to realize that scenario prep is almost entirely about designing tools. Or, perhaps more accurately, toys. Running an RPG is about picking up these toys and actively playing with them, just like the players are actively playing their PCs.

In creating these tools you’re still thinking about how they’ll be used at the table. But it’s more like designing a hammer (“I know this tool will be useful for hammering nails”) than it is writing an IKEA instruction manual (“here is how the scene with Diego will work”).

At the table, players are going to say things like, “Let’s build a chair!” And the GM will be thinking, “Great! I’ve got a hammer, a bunch of wood, and some… screws? Well, let’s make it work.”

It may only reflect my predilections as a GM, but I’ve found over time that node-based scenario design seems to inherently lend itself to a naturalistic form of prep. I’m not sure if that’s the ethos of active play pushing node-based design in a particular direction or if it’s that node-based design has naturally fostered active play. Or both.

But, in short, the more comfortable I become with node-based scenario design, the more I find that the design arises out of the diegetic organization of the game world itself.

For example, when I’m designing something like the Lytekkas hypercorp, the nodes I design (and how those nodes are organized) overwhelmingly tends to mirror the organization of Lytekkas in the game world. (You can see this in the earlier examples, which were based on things like the geography of the game world or the corporate divisions of Lytekkas.)

When I’m struggling with node-based design, a trick I’ve learned is to pick an NPC and ask, “How would they see this stuff? How would they use it? How would they interact with it?” Whether that’s a hypercorp CEO in an orbital penthouse or a Triad 49er on the rough streets of Hong Kong, the in-game perspective is almost always illuminating.

Of course, this makes sense, doesn’t it?

If node-based scenario design is based on the flow of information – if the structure of a node-based scenario is made up of the paths formed by the information – then it follows logically that node-based scenarios will mirror how that information naturally flows through the game world. And, of course, that flow will be determined by the actual relationships between people, places, organizations, and events in the game world. In how the nodes are related to each other.

Thus, as you design your scenarios, you naturally break the game world apart into discrete chunks. Each chunk (or node) is either a toy or a collection of toys that you can pick up and play with, while the connections between nodes show how those toys are related to other toys, making it easy for them to be endlessly combined and recombined in actual play.

And that’s node-based scenario design.

FURTHER READING
Using Revelation Lists
Game Structures
Hexcrawls
5 Node Mystery
Gamemastery 101

Go to Part 1

NODES & THE CAMPAIGN STATUS DOCUMENT

Campaign status documents are something I discuss in more detail in Part 4 of Smart Prep. The short version is that the campaign status document collects all of your notes on the current, evolving situation of the game. There are a number of cool ways you can use the campaign status document, but the most pertinent one for our discussion here is the scenario updates: Rather than attaching notes like “they killed all the kobolds in Area 3” or “Benny is angry with them” to a bunch of different scenarios, so that they’re scattered hither and yon, you collect all of these notes in the campaign status document for easy reference and upkeep.

The key insight here is that properly organized node-based scenarios make it REALLY easy to assemble and maintain your campaign status document. In the status document for In the Shadow of the Spire, for example, I can just place “NOD6” at the top of a section (remember those alphanumeric codes?) and drop stuff relevant to that scenario into that section. When the PCs go to NOD6, I can just flip to that page in the status document and have it available for easy reference.

We’ve also talked about meta-scenarios. Something I’ll do is pull upcoming or pertinent details from a campaign’s meta-scenarios and drop them into my campaign status document. When the players in my Eternal Lies campaign would go to a new city, for example, I would look at the Act II floating scenes (which operate as a very loose meta-scenario), grab a handful that I thought were likely to be appropriate, and drop a list of them onto the first page of my campaign status document. It gave me a kind of mini-menu that I could quickly consult without trying to process or remember the entirety of the meta-scenario in the middle of a session.

In some cases I’ll also drop “active” revelation lists into the campaign status document to keep track of them, but for these I’ll usually just mark up the master copy in the scenario itself. (That’s what it’s there for after all.)

NODES AREN’T EVERYTHING

With all of this being said, node-based scenario design is not the be-all and end-all of scenario design. Beyond obvious stuff like dungeon crawls and hexcrawls, I’ve already discussed lots of other scenario structures here at the Alexandrian. There are also a lot of tools that will be useful to you as a GM in node-based scenarios which aren’t nodes themselves.

Let’s take another look at my Bangkok prep notes for Eternal Lies and break them down. There’s five nodes in there, but there’s also a bunch of other stuff. What’s it all doing in there?

First, you’ve got the revelation lists and the trigger list for proactive nodes. These are obviously part of node-based scenario design, but they’re also basically the table of contents for the scenario. They show the whole scenario structure and can act as a quick reference for your nodes/tools. So I’ll usually have this in the first couple pages of my prep notes.

And then we come to the tools. One thing to note is that these are usually designed to be picked up in combination with one of the nodes. 95% of the time, this will be stuff that might be used in multiple nodes (like an NPC who could show up in multiple locations).

The other thing to note is that there’s nothing magical about these particular tools. I don’t use them for every scenario I prep and there are a lot of other tools you could potentially include depending on the nature of the scenario and game.

CITY MOOD BEATS: This is a cool tool from the published Eternal Lies campaign. These small beats (e.g., “birdsong drifts out of an open apartment window”) are designed to be dropped into any scene to provide local color/theme.

NPC NAMES: A list of locally appropriate names to be used when improvising NPCs (which could obviously happen almost anywhere in the scenario).

(These two tools usurp the usual place of honor for the revelation lists and are the first page of my prep notes for the city nodes in Eternal Lies. When the PCs went to a city, I would generally grab this sheet out of the binder and place it on the table off to one side for easy use.)

REFERENCE: I use a reference sheet to encode broad background data for the scenario that doesn’t belong to a particular node. In this case, it’s a timeline for the Emporium of Bangkok Antiquities. (This timeline could come up while questioning Daniel Lowman at his townhouse, questioning Savitree at Ko Kruk Island, or while looking at research notes found at the Estate. So it’s really clear how this has cross-node applicability.)

RESEARCH: In Trail of Cthulhu it’s not unusual for the PCs to head to the local library or newspaper morgue and do general research on leads they’ve found. This is material that doesn’t really belong to any of the nodes, so it gets split out.

NPCs: At the back of my prep notes I present major NPCs, including the Universal Roleplaying Template and other key information. Some of these NPCs are treated as nodes (and will be found indexed on the revelation list) while others can be used in multiple nodes, but for practical reasons I’ll usually include any NPC that takes up a lot of space to declutter the individual nodes. I also just generally find that giving each major NPC a full, dedicated sheet is useful. When roleplaying them, I can just grab and focus on the pertinent sheet. If it’s a combat situation, I can also grab the sheets for everyone participating for easier reference.

STAT SHEET FOR BANGKOK: But when a system’s stat blocks are short enough (as in Trail of Cthulhu), I will also drop all the stat blocks for a scenario onto a single sheet to make running combat SUPER EASY (at least when it comes to referencing stats). Some scenarios might require multiple stat sheets, which I will generally organize according to action group or node.

As I say, these tools are not the be-all or end-all of node-enhancing elements you can include in your scenario and campaign design. But they should give you a pretty good sense of the types of tools I’ll develop and use.

Go to Part 5: Naturalistic Node Design

Go to Part 1

An idea we’ve sort of been flirting with here is that node-based design is fundamentally fractal: You can “zoom in” on a node and break it apart into more nodes. Or, conversely, you can “zoom out” of the local collection of nodes you’ve been adventuring in and discover it’s all part of just ONE node in a much larger web.

For example, let’s consider the Lytekkas vampire hypercorp:

• At the highest level, we map their activity across seven cities: Chicago, the Old Angeles arcology, Shanghai, St. Petersburg, Reykjavik, Cheltenham, and the Lytekkas-Auberjonais L1 colony.
• Pick one of those and open it up: Now you’ve got nodes representing all of Lytekkas’ major projects in the Chicago metroplex. (These would also have connections to the other cities.)
• One of these involves the development of experimental blood-nannies (probably derived from the vampiric virus to mass-Renfield the population; or maybe an effort to control the negative side-effects of being a vampire).
• Look inside that node and you find the half dozen or so people and facilities involved in the program.
• The PCs identify and target a Lytekkas warehouse. This node is a heist scenario. There are elements of a heist scenario that are node-like, but it’s really a different structure, so this is the end of the road.
• … or is it? Part of the heist scenario is the opportunity to secure blueprints of the target. We could resolve that with a skill check, but we could also design it as a micro-node-based scenario.

But you can also flip this whole thing around and see that the Lytekkas hypercorp is just one of the immortal corporations which can track their secret history from the 22^nd century back to the Dutch East India Company in the 17^th century, with each one of those immortal corporations being a separate node.

This fractal quality can be seen not just in the nodes themselves, but in the connections between those nodes: There’s functionally no limit to how many leads can be placed in a single node, nor in how many leads can be created that point to a node. There is always an opportunity to increase the complexity and interconnectedness of your node map, particularly if we’re talking about an ongoing campaign which is developing over time (and, thus, features connections being formed and broken over time).

At this point the pedants may point out that this isn’t truly fractal because there is a limit to how far we can take this: At some point we’ll end up with a node which is a person; which is a sole entity that cannot be subdivided.

But it’s more true than you might think: Even individuals can be reconceptualized as a node-based scenario consisting of their job, connections, family, etc. The question is not whether you can do this, but whether it is interesting to do so.

MANIFESTING & MANAGING COMPLEXITY

This fractal nature of node-based scenario design, as we’ve seen, allows us to manifest an almost limitless amount of complexity. That can be quite daunting.

But it also allows us to manage this complexity. One of the functions of node-based design is specifically to chunk information into manageable nodes so that you don’t have to try to juggle or keep the whole thing in your head at once.

If you’re getting overwhelmed by trying to handle all seventy nodes of the Lytekkas hypercorp, figure out how to categorize those nodes into manageable groups: By city of operation. Or secret projects. Or corporate division.

The “right” division is going to depend on your own personal preferences and the details of the specific scenario. You’re looking for the clear conceptual chunks that will allow you to keep on top of incredibly complicated campaigns, while ideally only needing to think about one chunk of the scenario or campaign at a time. (I talk a bit more about what the manageable limits for this are in Advanced Node-Based Design – Part 4: The Second Track.)

For a rough-and-ready example of this, let’s consider the Bangkok node in the Eternal Lies Remix. In my prep notes, you can see that I identified five nodes:

1. Lowman’s Townhouse
2. Phikhat Hwan
3. Ko Kruk Island
4. Sirikhan Estate
5. Savitree Hunts the Investigators

The first two nodes are pretty standard node-based design: They’re distinct locations with (at least) three clues pointing at each.

But Ko Kruk Island is then broken into three separate nodes: The island itself, the Sirikhan Estate (a mansion on the island), and Savitree hunting the investigators (on the island).

Why?

To manage the complexity.

While the Sirikhan Estate is located on Ko Kruk Island, if the PCs are exploring the island (Node 3) I don’t need to think about every individual room inside the Estate (Node 4). And vice versa: if they’re in the mansion, I generally don’t need to worry about the whole island. Just like separating the individual rooms of a dungeon into separate keyed entries, separating this information lets me clearly focus on (and find!) what’s important RIGHT NOW.

(Speaking of fractal prep, of course, the rooms of the Estate are prepped as a location-crawl. So it’s individual rooms within a node (the Estate) within another node (the Island) within another node (Bangkok). You can really see how the prep structure lets me precisely narrow my focus.)

Node 5 was actually a late addition to my prep notes. I was originally trying to include that material in Node 3 — it’s stuff that happens on the island, so logically it should be in the “Island” chunk of information.

But the complexity of that particular event sequence was bloating the material to a point where I was finding it difficult to organize and reference it. If this is happening to your prep, it’s usually a warning sign that you need to break the material apart into more discrete chunks!

On the flip side, if the players become particularly fascinated by some aspect of the scenario or game world, it becomes relatively trivial for you to zoom in on it and explore it in more detail. Keep this in mind even when running the game: Zoom in on the node and/or add connections to it in response to the PCs’ actions. Slap in a simple node-template like the 5-Node Mystery and you’re good to go following the players down their rabbit hole. Who knows where it will take you?

Go to Part 4: Nodes Aren’t Everything