Go to Campaign Status Documents

If you’re running a sandbox campaign with ‘crawl-type scenarios (dungeoncrawls, hexcrawls, urbancrawls, etc.), you’ll most likely want to restock those scenarios.

For example, let’s say that there’s a ruined keep west of the village in Hex F6. As the campaign begins, this dungeon is filled with rausling bandits who have been staging raids on the merchant caravans and other travelers passing through the area. At some point, the PCs decide that they’re tired of being harassed by rauslings, so they track the bandits back to the keep and wipe out them out.

The keep now stands empty. That’s a really easy form of status quo, and it could persist for any length of time. But do you want the keep to stand empty forever?

Quite possibly not! In fact, it can be very interesting to have someone else move into a dungeon the PCs have already cleared out once. Going into a dungeoncrawl when you already know the layout of the dungeon is a distinct experience and a very different strategic challenge. Plus, the changes made by the new inhabitants can provide cool surprises!

So what I’ll do when running a hexcrawl sandbox is simply list all of the locations that are currently empty. After each session, I’ll go down the list and make a restocking check for each location on the list (usually 1 in 6 or 1 in 8). If the check succeeds, I’ll figure out who’s moved in (more on that below), create a new version of the adventure notes, and remove the location form the restocking list.

Updating the scenario notes is actually quite similar to doing a dungeon status update, with most of the work being done by simply swapping in a new adversary roster. Rather than doing a “diff file” for the updated room key, though, I’ll take the time to briefly modify my original adventure notes, print up a new copy, and file it in the appropriate spot. (There’s no way to be certain when the PCs will actually re-engage with the dungeon, after all.)

Tip: Even in non-sandbox campaigns, it can be fun to restock and revisit old dungeons. For example, in my Ptolus campaign the PCs cleared out the Temple of the Ebon Hand. Later they hit another cultist stronghold, but some of the cultists escaped. These cultist refugees ended up taking refuge in the abandoned Temple of the Ebon Hand, where the PCs eventually tracked them down.

RESTOCKING MEGADUNGEONS

The same methodology can also be applied to megadungeons. Basically you want to split the megadungeon into sectors and then make restocking checks for each applicable sector.

There are a couple different approaches I’ve used for defining sectors. In my Castle Blackmoor campaign, I followed Dave Arneson’s lead and split each dungeon level roughly into quarters. In other megadungeons, I’ve typically taken a more bespoke approach of looking for the “natural” break points in the dungeon. (For example, if you’ve got two chokepoints in the dungeon, all the rooms between those chokepoints are a natural “sector” that’s likely to be occupied by a particular faction.) The most important thing, I think, is for the sectors to make sense to you. As long as that’s true, it will be much easier for you to keep track of them and also to interpret the “meaning” of your restocking checks.

There are two types of restocking checks you can use in the megadungeon: empty sectors and disturbed sectors.

Empty sectors work more or less like cleared hexes, checking each empty sector once per prep period. (Although I’ve found that 1 in 4 or 1 in 6 seem to have better results as intervals.)

Disturbed sectors, on the other hand, involve tracking each sector the PCs enter during an expedition into the megadungeon, and then checking each one during the next prep period. After checking the disturbed sectors from the previous session, you clear that list.

Of course, both techniques can also be used in tandem (checking both empty and disturbed sectors during each prep period).

Tip: These techniques can also be used with medium-sized lairs and other dungeons that don’t quite aspire to “mega.”

OTHER RESTOCKING CHECKLISTS

You can use similar techniques with other scenario types, too.

For example, if you’re running a heist scenario and the PCs get made during onsite surveillance. How long does it take for the target to figure out that something is wrong and increase their security? Obviously you could just make that decision, but you could also drop this onto your campaign status document and make daily “restocking” checks to see when the reinforcements get installed.

(This can become quite interesting in a more complicated campaign where the heist is only one of several things that the PCs are juggling at the same time.)

RESTOCKING PROCEDURES

The actual process of restocking can be considerably easier if you’re using a game system that comes packaged with procedural content generators. For example, you just have to flip through the 1974 D&D manuals to find detailed dungeon stocking tables and treasure generators. On the other hand, these tools are largely or completely absent from 5^th Edition D&D. (And most other RPGs.)

When these tools are absent, I’ll often make the effort to create them. There are also a few universal techniques you can use to fake it until you make it. For example, the AD&D 1^st Edition Monster Manual conveniently has almost exactly one hundred pages of monsters. I’ve done a whole bunch of ad hoc stocking over the years by just rolling percentile dice, flipping to the appropriate page, and then randomly picking a monster on that page.

Also think about how you can use tools you’ve already created. For example, if you’re running a hexcrawl or megadungeon you’ve probably created a random encounter table. You can use this same table to determine creature type(s) for your restocking. (This can be limiting, though, as it means you won’t be injecting anything new into your campaign. On the other hand, that may actually be desirable in many cases.)

Next: Event Fallout

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)

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.

Next: Restocking Checklists

Go to Part 1

Conceptually, I think of most campaigns as being collections of scenarios. The ways in which those scenarios are organized can radically differ, but at least nine times out of ten everything still breaks down into very distinct scenarios. Ptolus: In the Shadow of the Spire is a node-based campaign, with each interconnected node being a separate scenario. In my OD&D hexcrawl each hex is basically a separate scenario. Even in my Castle Blackmoor megadungeon campaign, the castle dungeons and the tunnels surrounding those dungeons are studded with sub-levels that are designed and managed as separate scenarios.

None of these are necessarily distinctions that will be recognized by my players at the table, but they nonetheless exist in how I organize, prep, and think about the material. As a GM, I think you have to be able to compartmentalize the campaign world into these sorts of manageable chunks; in its totality, the campaign world would overwhelm you.

(For example, in my series on Hexcrawls I talk about how hexes are an abstraction for my convenience as a GM, but that they’re a player-unknown structure that’s inherently invisible to the players. This is true in other campaign structures, too: In Dragon Heist, for example, the players can obviously distinguish the difference between the Eyecatcher and the Zhentarim interrogation house, but they probably won’t see the Outpost / Response Team / Lair structure I’ve used to organize my notes.)

Once the game begins and the campaign world is set into motion, however, this can become a lot trickier. You separated the headquarters of the Black Lotus gang from Benny Hu’s mansion from the third eye dealers in Kowloon so that you could manage each of them conveniently, but if all of those separate scenarios are active simultaneously, how do you keep track of them? Each individual ball was easy to get a grip on, but now you’ve taken a dozen balls, tossed them into the air, and you’re trying to keep them all up at the same time.

How do you keep it all straight in your head?

The tool I use is a campaign status document.

Rather than keeping notes attached to a dozen different scenarios, I rope all the active elements of the campaign into this single document. In some ways you can think of this as a change log or diff file: The original scenario notes, by and large, remain untouched. Instead, the campaign status document records how those scenarios have changed. When the PCs re-engage with those scenarios, I can use my original scenario notes in combination with the campaign status document to run the updated version.

But the campaign status document is more than that. It’s a compilation of ALL the active components of the campaign (not just those arising from scenarios which have been ejected from the status quo). It’s the default repository for the evolving canon of the campaign. It’s arguably the single most important document I have at the table during play. It is always kept close to hand, and is ultimately the guide I use to keep the campaign on track.

It’s also kind of my secret weapon as a GM. How do I manage to run these huge, sprawling, complicated campaigns without getting lost? I have a road map. I use the campaign status document as a cheat sheet, offloading the mental load to my downtime so that at the actual table I can stay focused on execution and active play, rather than the logistics of continuity.

The campaign status document, however, is not a one-size-fits-all tool. Every single campaign is unique, and I’ve found that to be reflected in each campaign’s status document. It often takes me three or four sessions with a new campaign before I can really start grokking what the status document for that campaign is going to look like.

With that being said, there are three elements which form the core of my campaign status sheets: The timeline of bangs, the list of background events, and the scenario updates.

TIMELINE OF BANGS

“Bang” is a term of art from the Art of Pacing. Bangs are the explosive moments that you use to start a new scene. Stripping the jargon out of it, the timeline of bangs is basically a list of events that are going to happen to the PCs in the future; the places where the active campaign world is going to actively seek them out instead of waiting to react to them.

For example, here’s the timeline from one of the campaign status documents from my first Eternal Lies campaign:

• Wini receives a letter stating that Monte Jr. is getting sicker.
• Trigger Floating Scene 5: Bomb on Board.
• Waterlogged tome washes up next time they’re on a beach. (Particularly creepy if it’s a lake. Or the pond behind Allaghmore House.)
• Ulysses finds the mango he was given in Bangkok buried in one of his bags. Rotten and forgotten.

For Eternal Lies, my timeline of bangs was usually not tied to specific dates, but rather triggered by certain actions or as the result of reaching particular milestones. This worked well for Eternal Lies because often a globe-hopping character’s ability to receive a letter, for example, was tied more to them arriving at a place where the letter could reach them rather than some specific date.

In my Ptolus campaign, on the other hand, the timeline was tied to specific dates (and often times). Here’s an example from the Session 41 campaign status document:

• 09/22/790: Dominic scheduled to denounce Rehobath. (Backdrop 2)
• 09/22/790 (Evening): Chaos cultists identify Tee as being “Laurea.” They attack the Ghostly Minstrel. (Laurea’s Doom)
• 09/23/790: Tor’s Training.
• 09/23/790: Jevicca’s Briefing on the Pactlords.
• 09/23/790: Receive invitation from House Abanar for a cruise on the Vanished Dream. (Interlude 2)
• 09/24/790: Ranthir’s headband of intellect delivered.

The entries in parentheses indicate where the bang is coming from: Backdrop 2 and Interlude 2 were two specific scenarios. “Laurea’s Doom” referred to a later page of the campaign status document where I had summarized the retaliatory attacks aimed at Tee and the rest of the group as a result of their previous actions.

You can see from these entries that the nature of these bangs can vary wildly: Some are simple appointments the PCs have made. Others are ambushes. But, as I wrote in The Art of Pacing: Prepping Bangs, every single one of them is a bang waiting to happen: When the clock reaches that moment, we’re going to frame a new scene, set an agenda, and bang our way into it.

One other thing to note about these timeline entries, is that they generally aren’t fully-formed bangs. They’re more like bullets waiting to be fired. When the moment arrives, the actual bang will be customized to the circumstances of the PCs. These bangs will often act as interruptions or obstacles to other intentions: The PCs are trying to accomplish one thing, when the active campaign world interjects something else.

When these timeline bangs emerge from a scenario in motion, they’re also scenario hooks. And that’s true even if they’re for scenarios that the PCs have already engaged with.

BACKGROUND EVENTS

Background events are a second timeline of future events running in parallel with the timeline of bangs. These are the events which DON’T directly affect the PCs, but which are nevertheless taking place and moving the campaign world forward.

In my earliest campaign status documents, I didn’t separate these two timelines from each other: Stuff that would be directly experienced by the PCs and background headlines in the local newspapers would be freely mixed together in a single timeline of dates. This worked up to a certain point, but I eventually realized that:

• The two lists are actually used in distinct ways and at distinct times during play, so having them directly juxtaposed didn’t provide any meaningful utility.
• The timeline of bangs is, in many ways, a list of “things I don’t want to forget to have happen.” The background events, on the other hand, are factoids that the PCs usually have to seek out. Mixing them together on the same list sometimes resulted in the essential bangs getting lost amidst the reactive background events, thus degrading the utility of the list.

So although they’re superficially similar (insofar as both are a list of ongoing events that are likely to happen as the campaign world moves forward through time), they actually serve distinct purposes and work better when split apart.

For my Blades in the Dark campaign, I referred to this section of the sheet as “Word on the Street.” In the Ptolus campaign, it was “Newssheets” (i.e., what you might read about in the local papers) and would also include what was being publicly reported about the PCs. Here’s a sample from the Session 41 campaign status:

• 09/22/790: Sir Tor and his companions have rescued three of the most recently kidnapped children and freed more than a dozen slaves. Rehobath is proud of what the Church’s knights are accomplishing for the common citizens of Ptolus. “Let none doubt that the Gods will be true to those who keep faith with the True Church of Ptolus!”
• 09/23/790: What a Whopper! Stranded Jellyfish as Big as a House!
• 09/23/790: A priest was killed on the Columned Row in Oldtown. His head was ripped open, like the woman who was killed the night before on Flamemoth Way. (Thought Stalker)
• 09/24/790: It turns out that children have been disappearing from the Warrens for weeks, but no one has been reporting on it.
• 09/24/790: Three more people were killed in the middle of the night on the Columned Row. Their heads were ripped open. The murders are now referred to as the work of the “Columned Row Killer.” (Thought Stalker)

DEDICATED PAGES: Once again, the parenthetical reference to the “Thought Stalker” points to a dedicated page found later in the campaign status document that details the entire Thought Stalker situation (including its stat block). Dedicated pages serve as a singular reference point for ongoing threads in the campaign and make it easier to revise these sequences if the PCs intervene and cause them to take a different direction (which they absolutely will), allowing you to see all of the sequence’s events at once instead of digging through the larger timelines where they’ve been interwoven with other sequences.

Previous events can also remain archived on these dedicated pages, allowing you to reference them for context if you need to without clogging up the primary reference timelines.

BACKDROP FILES: As the complexity of the evolving world grew in my Ptolus campaign, I eventually expanded on the concept of the dedicated pages with separate Backdrop files: For example, Backdrop 2: Novarch in Exile is a very lengthy, sequential breakdown of the evolving religious conflict in the city. Backdrop 4: Cult Activities, on the other hand, lays out ten separate sequences of cult activity taking place in the city and then weaves them together to form a comprehensive timeline of cult activities.

These separate Backdrop files also allow me to offload some of this prep work so that the campaign status document can remain slimmer and more easily referenced during play. As time passes, I can periodically seed the campaign status document with material from the Backdrop files. For example, my current version of the Ptolus campaign status document reads:

NEWSSHEETS (Backdrops updated thru 10/27)

Which is a reminder to myself that, when we get close to the 27^th of Nocturdei in the campaign, I should go through my Backdrop files, pull out another 5-10 days of material from those timelines, and add it to the campaign status document.

DESIGNING BACKGROUND EVENTS: You want to make sure to include stuff evolving out of what the PCs have done AND foreshadow elements that you know are coming in future scenarios. You also want to spice the background events with entries that AREN’T directly related to the PCs’ activities or the scenarios of the campaign.

That can be purely random local color like the giant jellyfish. But it can also be whole “storylines” of unrelated events happening in the background of your campaign world, adding depth and verisimilitude to the world the PCs are living in.

(And you never know when those purely background elements may suddenly stop being background elements: The Novarch in Exile stuff in Ptolus, for example, was originally meant to just be a juicy story of local intrigue and conflict. But then two of the PCs independently pursued courses of action that thrust the whole group right into the middle of the religious schism and completely changed the course of the campaign. Great stuff.)

DIGGING IN: I also use a system of top-line summaries as bullet points combined with sub-bullets for additional details that the PCs can find out if they decide to dig deeper into a particular topic. (For example, the top-line might mention that a woman was found murdered in the Guildsman District. But the PCs will only discover that her body was covered in rat bites if they follow up on the story they read in the newssheets.) This is a hierarchy of reference, just like those described in the Art of the Key.

I use this technique sparingly. (It’s often just as easy to improvise the details on those occasions when the PCs decide to dig into a background event, and overthinking them isn’t smart prep.) But in specific circumstances, I sometimes find it useful, particularly if it’s additional information that has already been established as canon elsewhere in my notes.

SCENARIO UPDATES

The final core function of the campaign status document is the actual change logs for each individual scenario.

What you generally want to avoid doing is rewriting the entire scenario. There may be times when that is, in fact, necessary, but the entire goal of the campaign status document is basically to avoid doing that as often as possible. What you want is a set of tightly organized lists of updates/differences that you can combine with your original scenario notes on-the-fly.

I’m going to use location-based scenarios for my examples here, but these same basic principles can be used for any scenario type.

ADVERSARY ROSTERS: If you’re designing your scenarios with adversary rosters (which you should be doing anyway), they’ll help to streamline this process. During actual play you’ll have printed off a copy of the original adversary roster, and you’re likely annotating that adversary roster as you go. (The PCs killed these bad guys, etc.) When the session is over, simply copy-paste the adversary roster into your campaign status document and update it to reflect your annotations.

Adversary rosters also make it easy to handle situations like, “The bad guys have reorganized their defenses, or, “They’ve brought in reinforcements.” Modifying the roster is quick and easy.

UPDATED ROOM KEYS: As events evolve in a scenario, it’s likely that physical changes will be wrought in the complex. Some of these changes will be inflicted by the PCs themselves; others may be done by the NPCs. Once again your approach should be to keep your notes tight and confined to the changes that need to be made to the original key entries. Another example from my Ptolus campaign status sheet:

• Area 7: Emptied.
• Area 12: Alarm spell on throne. Door is arcane locked.
• Area 14: Emptied.
• Area 15: Emptied.
• Area 18: Huge pools of blood, streaked back all the way to the inner chamber (where it looks like the bodies were dragged down the wall to Level 3).
• Area 20: Frozen ash (left from immolated body).
• Area 23: 3 dead (partially eaten) Commissar’s Men. (These bodies remain unlooted.)

Often these changes are the result of things that happened during actual play. You don’t need to go into exhaustive detail; just provide a reminder to jog your memory.

TIMELINE OF CONTINUED EVENTS: If the disrupted scenario is in a highly agitated state, but you’re not sure exactly when the PCs will re-engage with that scenario, you may want to develop a timeline of how events develop within that scenario. I discuss this process at length in Don’t Prep Plots: Prepping Scenario Timelines.

The short version is basically indicating that at such-and-such a time the adversary roster and/or room key will be updated in this way. A simple example is when the bad guys have summoned reinforcements, but they won’t arrive for a little while and it’s possible the PCs will come back for a second assault before they get there. So you create an adversary roster without the reinforcements, and then use the timeline to indicate when they should be added to the adversary roster. If the PCs don’t come back, then the next time you’re updating your campaign status document, you can add the reinforcements and remove the timeline entry.

As you’re doing these timelines, an important skill to cultivate is identifying how far in advance you need to anticipate trajectories. Basically, this boils down to judgment call: How long is it before the PCs are likely to interact with this scenario again? Prepping a timeline for the next three weeks is a waste of time if the PCs are likely to be coming back within 48-72 hours. If the PCs are coming back to the scenario at the beginning of the next session, then you probably don’t need a timeline of future updates at all.

On the other hand, you don’t want to necessarily undershoot: Prepping only the next 6 hours of events and then being left to scramble when the PCs don’t come back for three days (but still arrive in the middle of next session) isn’t ideal, either.

CONTINUITY OF PAST EVENTS: In some cases I will leave prior entries in the timeline after I’ve executed the necessary change and only mark them with strikethrough text. Such entries can be useful as continuity notes, helping you to accurately describe how the scenario has altered over time without necessarily doing a fully updated room key for every small difference. For example, if the NPCs have dragged the temporal generator from Area 8 to Area 19, you don’t necessarily need to add an entry describing the drag tracks to every room in between; you just need to know the dragging occurred.

DON’T FEAR THE ENDING: As you begin embracing this “world in motion” concept and begin keeping multiple scenarios active simultaneously through your campaign status document, you may actually find yourself overcompensating in the opposite direction so that nothing is ever actually allowed to finish.

If the PCs have authoritatively completed a scenario (killing all the cultists in the Temple of the Ebon Hand, for example), scratch out that scenario and remove it from your campaign status document. You might still come back to that cult or that location and reincorporate those elements later, but let the moment of conclusion land first and give those elements some breathing room while giving other aspects of the campaign room to grow.

In other cases, you may discover that aspects of the campaign that weren’t definitively concluded are instead simply no longer in focus: The PCs didn’t wipe out all the goblins in Hex A9, but they don’t seem interested in going back there, either. It may make sense to “archive” that material: Advance that scenario to a new status quo, create an updated copy of your original scenario notes reflecting that status quo, and file it with the other scenarios that aren’t being actively engaged.

Your campaign status document will be most useful if you keep it short, focused, and easily referenced.

ADDING MORE TOOLS

Beyond these three core elements, my campaign status documents frequently feature other toolkits that facilitate running the campaign (and particularly running the active, evolving aspects of the campaign). As I mentioned above, every campaign status document is a special snowflake that’s customized for the needs of that specific campaign, and you’ll find that tools which were absolutely essential for one campaign are worthless for another (and vice versa).

In the future, I am likely to add addendums to this series discussing some of the tools I’ve developed for specific campaigns over the years.

MAINTAINING YOUR STATUS DOCUMENT

I used to just maintain a single file on my computer called “Campaign Status” and I would simply overwrite the information in that file between sessions as it got updated. What I quickly realized, however, is that I would sometimes make mistakes about what information I no longer needed to reference, and would regret having deleted the older information. So now I do a couple of things.

First, when it’s time to update the campaign status document I save it as a new copy of the file (“Campaign Status – Session 12”) and drop the previous version into an archival directory.

Second, I file the printed copy of the old campaign status document into a cheap accordion folder. (The Ptolus folder with 100+ campaign status documents is bulging.) I keep this nearby while actually running the game: I rarely need to reference the older documents, but if I do then I have them right there.

Over time you’ll get more skilled with figuring out what should and should not be removed from the campaign status document. But you just never know when the players are going to suddenly want to engage with minutia from 30 sessions ago.

All of this emphasizes the fact that the campaign status document is, above all, a living document. One which reflects not only where your campaign is, but where it’s been and where it’s going.

CAMPAIGN STATUS MODULES
Dungeon Status
Restocking Checklists
Event Fallout
Correspondence
Trackers
Continuity Notes
Supporting Cast

ADDITIONAL READING
Smart Prep: The Exposition Drip