Go to Campaign Status Documents
As I mentioned in my original article describing the use of campaign status documents, every campaign is unique and that means that the campaign status document for every campaign will be a little different. This series will be taking a closer look at some of the very specific tools I’ve developed and used for campaign status documents over the years, including examples drawn from actual play, and it will certainly make more sense if you’re familiar with campaign status documents.
I’m going to refer to these as campaign status modules. And, as I say, there’s nothing sacrosanct about them. The whole point is to take this stuff and adapt it, molding it to whatever the immediate needs of your current campaign are.
Also, importantly, I’ve never had a campaign status document that featured ALL of the modules we’ll be talking about. You really want to identify the stuff that you need and use that. (And only that.) Including stuff that you don’t need actually creates a negative value, filling your status document with a bunch of cruft that makes it harder to maintain the vital material and use it during play.
TRACKING DUNGEONS
I’d like to start by taking a peek at how I track dungeon status. This is a form of scenario update, and I did take a look at quite a few of the techniques I use in the original article.
- adversary rosters
- updated room keys
- scenario timelines
- return to the status quo
What I’d like to do here is look at some specific examples of this in practice.
The first thing is that, as with everything else on the campaign status document, you can and should keep it simple: Just because you have all of these tools available for tracking dungeon status, it doesn’t follow that you need to use them all. For example, here’s what the dungeon status for the Kolat Towers in my Dragon Heist campaign looked like in the Session 13 status document:
5.4 ZHENTARIM – KOLAT TOWERS
• Mimic killed.
• K12: Two destroyed staffs.
This was all that was needed given the changes that the PCs had affected at that point.
As more details are needed, the tools I most commonly invoke are the adversary roster and updated room key.
Prepping a dungeon around an adversary roster not only makes it much, much easier to run the dungeon as a dynamic environment, it also makes updating the dungeon incredibly easy: The things most likely to change about a dungeon, after all, are its denizens. During play you can easily update the roster as necessary (e.g., crossing off casualties). Then, between sessions, you can simply update the roster, put the current version in your status document, and ignore the original.
The flipside of this coin are the physical fixtures of the dungeon. The updated room key is a simple “diff file” that reminds you of any changes that have been made because of the PCs’ actions. (For example, if they rip a door off its hinges, then I should try to remember that next time they pass through that room.) I generally find that I don’t need more then one or two sentences to jog my memory for this kind of stuff.
Here’s an example update sheet for a dungeon from Monte Cook’s Banewarrens campaign:
CURRENT ENTOURAGE (10/20/790)
| 2 Undead Knights (Wights) | Area 1 |
|---|---|
| Glyptodon | Area 3 |
| 2 Undead Knights (Wights) | Area 7 |
| Golden One + Emperor Cobra | Area 7 |
| Slaadi (x2) | Area 12 |
| Vallacor + Dire Boar | Area 18 |
BW08 – LOCATION STATUS
• AREA 12: Great white shark corpse on edge of Conflagration (partially eaten by slaadi).
• AREA 12 – CAVE: Bison carcass.
• AREA 21: Xorn refuses to make alliance with the Golden One.
(The xorn here is listed in the key rather than the adversary roster because it won’t leave Area 21 under most circumstances.)
Design Note: In these notes, “BW08” is an alphanumeric code I use to refer to this specific adventure. (In the Dragon Heist example, “5.4” fulfills the same function.) These codes help me organize my notes and, as you can see here, make it easy to cross-reference the scenario (either in my campaign status document or another scenario).
The final piece of the puzzle, scenario timelines, are tied to the concept of status quo design: The dungeon exists in a literal or effective state of status quo (i.e., how it is described in your initial adventure notes) until it is perturbed by the PCs. For example:
- 10/05/790: Tee attacks Temple of Deep Chaos.
- 10/06/790: Tee unleashes nightmare on Arveth, leaving her fatigued next day.
- 10/07/790: Arveth hits Tee with Dais of Vengeance.
- 10/08/790: Tee unleashes nightmare on Arveth, leaving her fatigued next day.
- 10/09/790: Arveth switches sleeping pattern so that she won’t be asleep at night.
- 10/10/790 (4 AM): Arveth hits Tee with Dais of Vengeance (forced to watch her friends’ eyes ripped out).
- 10/10/790 (11 PM): Rissien and Santiel are kidnapped from Narred and taken to Temple of Deep Chaos.
- 10/13/790: Santiel is blinded.
- 10/14/790: Santiel’s eyes delivered to Tee.
- 10/15/790: Santiel is killed.
- 10/16/790: Rissien suspended in Kaleidoscope Temple.
- 10/21/790: Rissien is killed. (Possibly rescued by Dark Leaf.)
I use strikeout text to indicate events that have already happened. In some cases I’ll simply delete these entries, but I’ve too often found that it can be essential to easily reference this past continuity during play. In fact, for many types of actions, it’s far more efficient to simply list what happened (and then describing things accordingly) rather than trying to account for every individual change in the key.
It follows, of course, that the items which have not been struck out are stuff that hasn’t happened yet. They may, in fact, never happen. (If, for example, Tee catches up with Arveth before she can kidnap Rissien and Santiel.) Such events are generally based on the intentions and plans of the NPCs, and prepping them can be smart if (a) they’re sufficiently complex or convoluted that it will be valuable to puzzle them out between sessions, (b) juggling all the off-screen actions of the NPCs would be too difficult to handle during play, and/or (c) they would involve some form of additional prep (new stat blocks, physical props, etc.) that can’t be improvised during the session.
Once I start rolling out timelines, there are two key questions I ask:
- When is it likely that the PCs will re-engage with this dungeon? I won’t prep timelines much beyond that point because the likelihood of wasted prep becomes high.
- If the PCs don’t further interact with this dungeon, what will the new status quo be?
The latter question can be easy to overlook, but is a really essential component of efficient, smart prep. Some situations will just continue to spiral out of control (spinning their chaos out into the rest of the campaign), but a lot of scenarios will instead settle down into a status quo (e.g., the mafiosos bring in new muscle to guard their drug operation and then… that’s it, they’ve taken the precautions they think they need to take). You can simply prep up to that new status quo, file it in the appropriate section of your campaign notes, and then stop thinking about it until it becomes relevant again.
