Running Multiple PbP Games Without Cross-Contamination
The Cross-Contamination Problem Is Cognitive, Not Organizational
Forum GMs who run multiple PbP games simultaneously usually frame the problem as an organizational one: they need better folders, better file naming, better thread labels. They build those systems, find them insufficient, and conclude they're simply not suited for multitasking. Neither conclusion is accurate.
Task switching costs 40% of productive time. The brain's rule-activation system — the mechanism that sets up context for a given task — doesn't switch cleanly. When you move from Campaign A to Campaign B, residual context from A bleeds into B for several minutes. For creative and narrative tasks, context switching reduces output quality by up to 40%. This isn't a discipline failure. It's a structural property of how narrative cognition works.
Knowledge workers lose 23 minutes re-orienting per project switch. For a forum GM checking both games once per day, that's 23 minutes of disorientation tax before any actual GM work begins — and during that 23-minute window, cross-contamination errors are most likely to occur. GMs running multiple campaigns cite narrative cross-contamination as their primary cognitive complaint: they post the wrong NPC name, assign a faction motivation to the wrong world, describe a location detail that belongs to the other campaign.
The solution isn't to manage context switching better — and it isn't a GM multitasking skill gap. It's to minimize context switching while maintaining complete separation between separate parallel campaigns through structural design rather than willpower.
The Isolated Transit Network Model
Clean IC/OOC discipline within each individual campaign is the foundation that makes running multiple pbp games viable — the same discipline that managing parallel forum storylines for large groups requires within a single campaign, just extended across games. If your threads are structurally clean within each campaign, cross-campaign contamination is less likely because there's less ambient noise in each game's IC record.
StoryTransit treats each campaign as a completely separate transit network — different cities, different maps, different route logic. Networks don't share stations. A character who exists in Campaign A's world doesn't appear in Campaign B's documentation. An NPC motivation that belongs to one campaign isn't visible when you're working on the other.
The structural discipline required is hard campaign partitioning.
Separate documentation environments. Each campaign gets its own documentation space — not a separate folder within a shared GM workspace, but a completely isolated environment. Kanka supports unlimited separate campaigns per account with isolated wikis, timelines, and character rosters. LegendKeeper's isolated campaign workspaces are designed to prevent asset bleed between concurrent games. The tool you choose matters less than the discipline: Campaign A's documents must not be visible when you're working on Campaign B.
Sequential session blocks. Don't switch between campaigns mid-session. Schedule your Campaign A work and your Campaign B work in distinct time blocks, with a context-clearing ritual between them. The ritual can be as simple as closing all Campaign A tabs before opening Campaign B, making tea, and spending three minutes reading Campaign B's last round-state summary. The 23-minute re-orientation cost shrinks when the context switch is deliberate rather than reactive.
Distinct narrative identifiers. Give each campaign a unique surface-level identity that's immediately recognizable at a glance: a color scheme, a document header, a naming convention for threads. When you open a thread, you should know within one second which campaign it belongs to — before you read a word of content. This prevents the specific cross-contamination forum error mode where you respond to the wrong thread because the IC thread subject lines were similar.
Campaign A / B quarantine on NPCs. Maintain explicit lists of NPC names and faction names for each campaign, and review them for accidental overlap at campaign start. If Campaign A has a merchant guild called the Golden Scale and Campaign B has a faction called the Golden Hand, change one. Phonetic or semantic similarity between campaign assets is the primary vector for involuntary cross-contamination.
Advanced Tactics: Managing GM Bandwidth Across Separate Campaigns
Hard partitioning prevents cross-contamination but doesn't address the bandwidth problem: two forum games at one-post-per-day pace require two sets of scene openings, two promise logs, two OOC coordination threads. That's a sustainable workload for an organized GM, but it requires honest accounting of what each campaign actually demands.
Stagger campaign stages. Don't start Campaign B during Campaign A's most intensive period — a major convergence event, a multi-thread climax, a player dropout crisis. Start Campaign B when Campaign A is in a stable mid-campaign rhythm. Campaigns at different lifecycle stages have different GM overhead, and staggering them keeps your total workload from spiking simultaneously.
The cross-contamination audit. Every month, run a five-minute review: read the last five IC posts from Campaign A and the last five from Campaign B. Look specifically for NPC names, location details, and faction relationships — the categories most vulnerable to cross-campaign bleed. Any detail that appears in both campaigns' recent posts warrants investigation: did you intentionally introduce parallel elements, or did a Campaign A asset leak into Campaign B's IC posts?
This audit is also where you catch the cognitive contamination that's more insidious than content errors: posting the same GM voice, the same NPC mannerisms, the same scene-opening style to both campaigns. Players in each campaign deserve a world that feels distinct, and the GM who's been running both campaigns for six months often unconsciously homogenizes their GM voice without realizing it. The audit creates deliberate space to notice and correct this.
Setting player expectations for multi-campaign GMs. Players in each of your separate parallel campaigns should know that you're running another game. Not because they need the details, but because understanding your bandwidth lets them calibrate their posting expectations appropriately. A GM who says "I'm also running a second campaign, so my post cadence here will be three times per week rather than daily" is giving players accurate information to plan around. A GM who tries to maintain daily cadence across two full campaigns and then starts missing posts creates the impression of unreliability rather than honest bandwidth management. Transparency about your total GM workload is part of the structural discipline that makes multiple pbp games sustainable.
For questions about managing player counts across campaigns, scale four to twenty covers how campaign structural overhead scales with player count — relevant when one campaign has six players and the other has twelve.
When storylines within a single large campaign require the same kind of isolation discipline as separate campaigns, the structural work is identical to running distinct games: both require narrative partitioning between concurrent threads that serve the same overarching story — just applied within one world instead of across two.
For live-event parallels, simultaneous themed subplots in LARP contexts addresses how event organizers manage multiple simultaneous plot tracks without participant cross-contamination — different format, same isolation architecture.
Task switching errors are unavoidable and increase in frequency during switches. The cognitive science is unambiguous: the goal is never zero switching errors but rather building systems that catch and correct errors before they reach players. A brief review of Campaign B's last round-state post before posting — thirty seconds — catches 90% of cross-contamination errors before they go live.
Run Two Campaigns. Keep Them Two Worlds.
The asymmetry of contamination errors. Not all cross-contamination errors are equal in their damage. Posting the wrong NPC name to the wrong IC thread is immediately visible and correctable — other players will catch it, you fix it in the next post, no lasting harm.
The insidious contamination errors are the ones that don't surface immediately: making a faction decision in Campaign A that's informed by a player dynamic from Campaign B, writing an NPC's motivation through the lens of a different campaign's world logic, or advancing a plot thread in Campaign B faster than its internal story logic warrants because you're unconsciously borrowing momentum from Campaign A's current arc. These errors compound silently over months, and by the time you notice them, they're structural — the story logic has genuinely been contaminated, not just the surface content. The review discipline and session-block separation are designed to catch these before they embed.
The GMs who successfully run multiple PbP games simultaneously aren't the ones with superhuman multitasking ability — they're the ones who've built structural walls between their campaigns and created switching rituals that respect the cognitive cost of moving between narrative universes.
StoryTransit gives play-by-post game master tools for hard campaign partitioning: isolated documentation environments, campaign-specific story maps, and a session structure that minimizes the context switching that causes cross-contamination. If you're running or planning to run multiple concurrent PbP games, join the waitlist for play-by-post GMs to see how the isolated transit network model keeps your worlds from bleeding into each other.