Maintaining Continuity Across an RPG Module Series

The Series Continuity Challenge

A standalone module has internal continuity only — the events within the adventure must be consistent with each other. A module series has cross-module continuity — events, characters, and consequences must be consistent across multiple published adventures, potentially written months or years apart.

This is significantly harder than internal continuity for several reasons:

Time gaps. Modules in a series may be published months apart. Details that were fresh during the first module's writing may be forgotten by the second.

Writer changes. Series may involve multiple writers. Each writer interprets the shared world differently, introducing subtle inconsistencies.

Player variation. Each table's version of earlier modules is different because of player choices. Module two must account for multiple possible states from module one.

Retcon pressure. Later story developments may make earlier published material awkward or contradictory. Unlike digital media, print modules cannot be patched.

The Series Bible

Every module series needs a series bible — a living document that tracks all continuity-relevant information:

World state. The current state of the world as affected by published modules. Which factions are active, which locations have been destroyed or changed, and what the political landscape looks like.

Character registry. Every named NPC across all modules, with their current status, location, and relationships. When introducing an NPC in a new module, check the registry first.

Event timeline. A chronological record of events across all modules. This catches timeline contradictions before they are published.

Item registry. Significant items introduced in any module — artifacts, quest items, important equipment. Track where they were introduced, where they can be found, and what they do.

Rule and lore precedents. Any established rules about how the world works — magic limitations, political structures, cultural norms. These precedents constrain future modules and must be respected or explicitly overridden.

Unresolved threads. Plot threads introduced but not yet resolved. Each thread should note the module that introduced it, the current state, and the intended module for resolution.

Handling Variable Player History

The biggest challenge in module series design is that different tables have different histories:

State variables. Define the key decisions from each module that affect subsequent modules. Keep these to a minimum — three to five major state variables per module. More than that creates unmanageable variation.

State summary sheet. At the start of each new module, include a state summary sheet that the GM fills in based on their group's history: "Did the party save the village? Did the party ally with the merchant guild? Is the antagonist alive or dead?"

Default states. For tables starting mid-series or groups that did not play the previous module, define default states for all variables. "If the party did not play Module 1, assume the village was saved but the merchant guild was disbanded."

Conditional content. Each state variable should produce specific, documented changes in the new module. "If the village was saved: the village elder greets the party warmly and provides supplies. If the village was not saved: the ruins are inhabited by bandits."

Cross-Module NPC Management

NPCs who appear across multiple modules need careful management:

Consistent characterization. An NPC's personality, speech patterns, and core values should be consistent across modules. If the gruff sergeant was gruff in Module 1, he should be gruff in Module 3 — unless the events between explain a change.

Character development. NPCs should evolve based on the series' events. A fearful NPC might become brave after being inspired by the party. A trusting NPC might become suspicious after being betrayed. Document these changes in the series bible.

State-dependent NPCs. NPCs whose status depends on player choices from previous modules. The ally who might have been killed, the villain who might have been captured, the neutral party who might have been won over. Each state must be accounted for.

Replacement NPCs. When an NPC might be dead based on previous module choices, prepare a replacement NPC who can fill the same narrative role. The replacement should not be a clone — they should have their own personality while serving the same story function.

Connecting Modules Narratively

Bridging scenes. Each module should include a scene at the beginning that connects to the previous module's conclusion: a summary of what has happened, a scene showing consequences of prior events, a message from a familiar NPC.

Escalating stakes. Each module in the series should raise the stakes. The first module threatens a village. The second threatens a region. The third threatens the world. Escalation provides narrative momentum across the series.

Recurring elements. Motifs, symbols, phrases, or themes that appear across modules create a sense of continuity even when specific events vary. The recurring raven. The mysterious symbol. The prophecy that gains new meaning in each module.

Foreshadowing. Each module should plant seeds for future modules. These seeds are discovered by players who will appreciate the callback and overlooked by players who will be surprised by the future development.

Series Production Planning

Outline the entire series before writing Module 1. You do not need detailed content for every module, but you need the overall arc: the series' central conflict, the major beats of each module, the planned resolution. This prevents painting yourself into corners.

Lock state variables early. Decide which player choices from each module will carry forward before writing the module. This prevents the inclusion of choices whose consequences are impossible to track.

Maintain the bible. Update the series bible after completing each module. This is not optional — it is the foundation of series continuity.

Managing continuity across a module series? Join the TransitMap waitlist — map your entire series as a connected transit network, track state variables between modules, manage NPC histories, and maintain your series bible visually across every published adventure.