The Bone Orchard – No one expects…

Previous posts in this series

Part 1 / Part 2 / Part 3 / Part 4

We’ve talked about how the graphic design and writing of scenarios can – nay, should! – be better for GMs running them at the table. Now I want to talk about how their structure should be the same.

We’ve all been there: we’re running a scenario – either published or one we’ve written ourselves – that expects a certain train of player behaviour, only – gosh, shock, horror – they don’t do what we expected them to do. This can either be because the players start acting like murder hobos – “I stab the important and friendly NPC in the head for no other reason than I had a bad day at school/college/work!” – or because they choose a reasonable path of action you or the writer failed to consider.

Aside from the many, many remedies for tackling the former¹, dealing with the latter traditionally involves learning how to subtly steer the players back on track while improvising like you’re on Whose Line is it Anyway? There is a better way. Several in fact.

A tale of MURDER!

First, an example. Say you have a scenario where a cult has kidnapped a series of innocent teens to first summon and then placate an otherworldly horror. The traditional scenario might be written with scenes such as:

1. Parents of kidnapped teen asks the investigators to help find their child.
2. The investigators research and discover other teens have also gone missing.
3. The cult realises the investigators are on its tail and send some goons to scare them off.
4. They survive the initial attack, investigate the dead cultists and find a lead to the cult.
5. They research the cult and find its hideout.
6. They battle the cult just as it is summoning the monster.

Fine. A little basic, but you get the idea. It’s the sort of thing you might see in many short scenarios. Unfortunately, even longer scenarios often have the same type of linear pathway. The players don’t have any choice about how the scenario plays out. The only variety between their playthrough and another group’s is what they do within each scene, and the GM will be hoping like crazy they don’t do anything disruptive enough to spill over and affect subsequent ones.

Nah. They wouldn’t do that. Would they?

Instead, let’s consider what happens if the players miss the clue on one of the cultists that attacked them. Now, instead of going to the cult’s hideout they start following up some red herring. Or maybe instead of storming the hideout they stake it out instead while the ritual is taking place, the monster is summoned and starts rampaging. With no written advice on how the players can remedy the situation because the writer assumed they’d interrupt the ceremony, the GM has to start making stuff up on the fly from scattered information from unused scenes. That’s also when you run into the dreaded phrase “By now…”

“By now, the PCs will want revenge on the Big Bad.”

“By now, the PCs will realise the intricacies of the Big Bad’s plan.”

“By now, the PCs will have found the one clue they need to defeat the Big Bad.”

What if they actually sympathise with the Big Bad, failed to understand the intricacies or didn’t find that one clue? It happens ALL THE TIME. Usually, the blame is laid at the feet of the GM for not controlling the players enough or at the feet of the players for not ‘behaving’. What if it’s not their fault at all though, but the fault of the scenario writer?

The Node Star!

The solution that I keep coming back to is Justin Alexander’s node-based scenario design. As described above, traditional scenario design writes a chain of likely scenes, sometimes with some branches just in case, but usually you only use half of them as planned and spend the rest of the scenario madly flicking back and forth trying to find the information you need to make up the situation you actually find yourself in.

Instead, Alexander suggests (as does Scott Dorward of The Good Friends of Jackson Elias podcast) of preparing situations, not plots. Ditch set scenes that assume specific player behaviour and gather all the information about particular NPCs, locations, organisations or events into nodes – toolboxes of all the relevant information and GMing tools you need – then placing them in logical, easy-to-find places.

For example:

• One node for the cult’s hideout, maybe with a map if that’s your bag.
• One for the cult itself with all the NPC stats and motivations together.
• Another for the monster itself, its behaviour, its stats.
• Since they’re probably minor scenes, clump all the kidnap locations into one node, with all the clues that might be found at each.
• Maybe a node for the summoning itself, although depending on how complex it is you might want to just add that into the hideout, cult or monster nodes. Whatever works for you so that each node is manageable to find information quickly at the table.

With all the information now in easy-to-find toolboxes, the GM is instead able to use what they need, when they need them and more easily run a scenario that reflects the players’ actions.

The nodes aren’t completely independent from each other. They’re still connected by clues and leads, but these paths aren’t prescriptive. They only provide the most likely journeys.

Next time, I’ll talk about Alexander’s other innovation: the three-clue rule. And after that I’ll go step by step through writing a scenario that uses everything we’ll have learned. Yay!

¹Have open and honest communication about expectations and if that doesn’t work, game with other people. 99.9% of gamers will never follow this advice.