Modular Plot Design for LARP Events

What Modular Plot Design Means

Traditional LARP plot design is sequential: Scene A leads to Scene B leads to Scene C leads to the climax. If Scene B fails — the NPC does not show up, the players go elsewhere, the combat goes wrong — the entire chain breaks.

Modular plot design is component-based: the plot is built from self-contained modules that can be deployed, rearranged, or replaced without breaking the overall narrative. Each module is a complete scene with its own setup, content, and outcome. Modules connect to each other through shared narrative elements but do not depend on a specific sequence.

Think of traditional plot design as a train on fixed tracks. Modular plot design is a bus network — multiple routes serving multiple destinations, with the flexibility to reroute when roads are blocked.

Anatomy of a Plot Module

Each module contains:

The Situation — What is happening? A one-paragraph description of the scene's circumstances. "A group of refugees has arrived at the town gates, claiming their village was destroyed by an unknown force. They are desperate, hungry, and frightened."

The Hook — Why should players engage? What draws them in? "The refugees include a child who is carrying a strange artifact. The local healer recognizes the artifact as something mentioned in an ancient prophecy."

Key NPCs — Who is present and what do they want? NPC briefs for each character in the module, including motivations, knowledge, and trigger reactions.

Player Options — What can players do? Two to four likely approaches and their consequences. "Help the refugees (reveals information about the attacking force), interrogate them (reveals the artifact's significance), ignore them (refugees seek help elsewhere, potentially from a rival faction)."

Outcome Categories — Three categories of outcome that determine which modules can follow:

• Positive — Players helped, gained information or allies
• Neutral — Players engaged but no significant change
• Negative — Players refused, made enemies, or caused harm

Connection Points — Which other modules can follow this one, and under what conditions? "If positive outcome: leads to Module 7 (tracking the attacking force) or Module 12 (researching the artifact). If negative outcome: leads to Module 15 (refugees join rival faction)."

Building a Module Library

Instead of designing one linear plot, build a library of modules for each event:

Core modules (must run) — Essential story beats that define the event's narrative. Usually three to five modules that must happen for the event to have a coherent arc. These are scheduled at specific times.

Elective modules (run if appropriate) — Content that enhances the event but is not essential. These are deployed based on player actions, pacing needs, or available crew. Usually five to ten modules ready for deployment.

Reactive modules (run in response to players) — Content designed to respond to specific player actions. "If players investigate the ruins, run Module R3. If players ally with the merchant guild, run Module R7." These are your adaptation tools.

Emergency modules (run if pacing stalls) — Quick-deploy content for when the event hits a dead spot. A wandering monster, an urgent messenger, a social catalyst. These require minimal setup and can be deployed anywhere on the site.

Connecting Modules Into Narratives

Modules become a narrative when they are connected:

Shared NPCs. An NPC who appears in multiple modules creates continuity. The refugee leader who appeared in the arrival module returns in the investigation module with additional information.

Shared objects. The artifact found in Module 3 is needed in Module 8. The letter discovered in Module 5 provides the key to Module 11.

Escalating stakes. Each subsequent module raises the stakes. Module 1: refugees arrive. Module 4: the attacking force approaches. Module 8: the force reaches the town walls. The escalation creates a narrative arc from independent modules.

Outcome chains. The outcome of one module determines which modules become available. This creates branching narratives without requiring you to design every possible permutation — you just need to know which module follows which outcome.

Deploying Modules During the Event

The lead storyteller manages module deployment:

The module board. A tracking board showing:

• Which core modules have been deployed and their outcomes
• Which elective modules are available for deployment
• Which reactive modules have been triggered
• Current pacing assessment (too slow? too fast? on track?)

Deployment decisions. Before deploying a module, the lead storyteller asks:

• Is this the right moment for this content? (pacing)
• Are the required NPCs available? (logistics)
• Are the target players in a position to engage? (player state)
• Does this module's content conflict with anything currently happening? (coherence)

Module handoff. When a module is deployed, the lead storyteller hands it to the responsible line storyteller with context: "Deploy Module 7. The refugees in Module 2 got a positive outcome, so the players have the artifact and are looking for the attacking force. The players who engaged were from Faction A."

Benefits of Modular Design

Adaptability. When players do something unexpected, you can swap modules rather than rewriting the plot in real time.

Scalability. More players? Deploy more modules. Fewer players? Deploy fewer. The narrative scales with attendance.

Reusability. Modules that were not deployed at one event can be modified and used at the next. Elective modules that players never triggered still have value.

Team-friendly. Modules are easier to delegate than sequential plots. A line storyteller can own a set of modules without needing to understand the entire event's plot architecture.

Resilience. If a module fails — the NPC does not show up, the players break it, the weather intervenes — the event continues. The module is skipped and an alternative module is deployed.

Common Modular Design Mistakes

• Modules that are too interdependent — If every module requires a specific previous module, you have a sequential plot disguised as modular. True modules should have multiple valid predecessors.
• Modules without internal closure — Each module should have its own satisfying mini-arc. Players who engage with a module and do not encounter the follow-up should still feel their time was well spent.
• Too many modules, not enough crew — Having fifteen modules ready but only enough crew to run five simultaneously. Match your library size to your deployment capacity.
• Neglecting the connective tissue — Modules with no shared NPCs, objects, or themes feel disconnected. Ensure your library shares narrative elements that create cohesion.

Want to design and deploy modular LARP plots? Join the TransitMap waitlist — map your module library as a transit network with interchangeable routes, connection points, and real-time deployment tracking.