What makes a mystery scenario work is, ultimately, the structural revelations: The PCs need to find a lead that will take them to the SS Brittany and they need to find the clues that reveal how to defeat the ento-parasites from Planet X.
Using the Three Clue Rule, node-based design, and similar scenario-building tools, therefore, we make these structural revelations robust and distribute them throughout the mystery in interesting and effective ways. Ideally, the result is a mystery scenario that’s more likely to succeed than to fail, and is also compelling for the players from beginning to end.
But not every possible revelation in a mystery scenario is load-bearing.
For example, while investigating strange murders in the Welsh countryside, it might be really cool for the PCs to discover that the coven of witches responsible for the killings is descended from a cult of Isis worshipers who escaped from Egypt during the final days of the Ptolemeic Pharaohs. And it’s probably even cooler if they realize the goal of the multi-generational ritual killings is to bring Cleopatra herself back from the dead!
Such revelations might even feel essential for the players to fully appreciate the scenario. Strictly speaking, however, these background revelations aren’t required. The PCs can follow their leads and find the subterranean passages which serve as the coven’s base of operations, and even puzzle over the Egyptian-style murals painted on the walls there, without ever truly realizing the coven’s long history. They might even fight (and defeat!) the lich-pharaoh without ever realizing that she’s Cleopatra!
Understanding and being able to recognize the difference between structural revelations (the PCs must know where the coven’s HQ is to finish the scenario!) and background revelations (it would be really cool if they knew who the lich-pharaoh was!) offers a lot of practical advantages when it comes to both designing and running mystery scenarios.
First, I recommend keeping your background revelations on a completely separate revelation list from your structural revelations.
Having a revelation list for background revelations is useful for design: Since you do, in fact, want the PCs to learn that the lich-pharaoh is Cleopatra, you’ll want to use the Three Clue Rule and make sure the clues pointing to that revelation are positioned for maximum effect.
On the other hand, since these background revelations are nonessential structurally-speaking, you don’t actually need to track them during play: If something goes wrong, it only means that the identity of the lich-pharaoh becomes a source of enigma. That may or may not be ideal, but it’s a perfectly cromulent outcome.
Note: As discussed in the article on Enigma, the fact these background revelations are structurally nonessential may also mean that you don’t care about them being robust, either! You can use the Three Clue Rule to make background revelations robust, but technically the rule only applies to structural revelations.
Conversely, by removing these nonessential revelations from your main revelation list, you effectively declutter your list of structural revelations: These are the revelations you DO need to keep track of during play so that you can troubleshoot them if something goes wrong, and getting rid of the clutter will make that mid-session tracking much easier to do!
THE PURPOSE OF A BACKGROUND REVELATION
If background revelations aren’t required for the success of a scenario, though, why include them at all? Wouldn’t it simplify everything and declutter the entire experience if you got rid of them entirely?
The short answer is that man does not live on bread alone.
Structural revelations may be how the PCs navigate their way to the scenario’s conclusion, but it’s background revelations that give the scenario meaning. Background revelations are also how you “show, not tell” when it comes to historical research and worldbuilding.
This isn’t just about delivering memorable “oh wow, that’s cool!” moments for the players rather than generic lich fights that will be forgotten before the next session (although it is that, too!).
Plus, from a purely practical standpoint, you often WANT a little clutter in your mystery scenarios: Remember that when the players first discover a strange clue, they’re likely going to be trying to figure out how it fits into the overall pattern of clues (and other strange things) they’ve discovered so far. The clues and details associated with background revelations help to fill up your scenes with cool stuff that can be uncovered via investigation.
Along these same lines, background revelations can also be very good at delivering small victories even while the big questions remain elusive to them: They may not know where the cult is located, but figuring out that they’re Isis worshipers feels like a win! Wins like that are what will keep the group motivated and moving forward in their investigation.
In other words, just because they’re structurally nonessential, it doesn’t mean that background revelations are meaningless. To the contrary: They’re packed full of meaning! Their entire existence is to provide meaning!
“What makes a mystery scenario work is, ultimately, the structural revelations: The PCs need to find a lead that will take them to the SS Brittany and they need to find the clues that reveal how to defeat the ento-parasites from Planet X.”
Man, you really are on a Mothership kick, aren’t you?
Reading this series, it strikes me that Ghostbusters is a pretty neat and simple example of this. Dana provides a location and a name, Zuul. That then introduces the three clues:
– “Zuul was the minion of Gozer” -> Spengler looks Gozer up in Tobin’s Spirit Guide, which both provides the background revelations about The Destructor and the name Ivor Shandor
– Ray gets the blueprints for Dana’s building and observes that it’s a PKE antenna, designed by, wait for it, Ivor Shandor (cross-linked clue for player satisfaction)
– The Gatekeeper and Keymaster are proactive nodes which also both point back to Dana’s apartment
And the desired conclusion is “The building has a Kaiju-summoning temple in it”.
Because the heroes are too late to stop the Gatekeeper and Keymaster and prevent them getting together, they only find out just after the summoning has occurred. But you can imagine other scenarios:
– they find out early, and try to wreck the antenna (if I know my RPG-ers, by trying to demolish the building, but hey…)
– they find out early enough to stake out the apartment; when the Keymaster and Gatekeeper appear they’re ready to trap them before they can possess anyone.
– they find out too late, and arrive after someone else has chosen the Destructor’s form, and end up having to fight the kaiju first before realising the temple is the important thing…
Great advice for how to make the world deep and interesting without obstructing the actual plot.
I like to think of “background revelations” as similar to one of those board games where you have to get someone to guess a word without saying it directly. It’s difficult for me to not spill the beans early, so I have to make it a little “game” with myself. I want the players to figure this out, but I can’t tell them what the answer is…
This technique is great for getting players more invested in worldbuilding details. If you *tell* your players a piece of info, it will bounce right off. If you make them feel like they *discovered* or *guessed* a piece of info, they’re much more likely to remember and value it. For your big concepts, it’s way better to lay a bunch of clues and let your players come to the conclusion themselves.