By Jason Morningstar

There’s a larp modality that looks like this:

You design a large, intricate live action game called Legacy of the Witch-Nuns. Characters are richly detailed and have complex interrelationships with other people and groups. Elements of plot and action hinge on these connections. The characters themselves are each unique and critical to the functioning of the larp as a whole. You’ve created a beautiful tapestry of drama and intrigue that will proceed like a finely-tuned clock.

And this modality inevitably leads to announcements like this:

“URGENT! We’ve had two players drop at the last minute from Legacy of the Witch-Nuns! We desperately need these roles filled or the game won’t run! Free tickets, just show up at our remote location with no preparation! If we can’t find one witch and one nun we’re in big trouble.”

There’s a panicked search for replacements, and perhaps some hurried rewrites, and overall the larp suffers. All the down-to-the-wire changes take their toll, and the poor replacement witch-nuns are dropped in cold. It’s a recipe for stress, confusion, lost revenue, and lackluster play – and it happens all the time. In the age of COVID it is basically a given that this will occur.

Coming from a background in information science and user experience, the persistence of this approach has always surprised me. Nobody wants to repeat this pattern, but it is predictable and will be repeated unless you design your way around it. I thought about ways to build fault-tolerance – the ability of a game’s design to gracefully handle the loss of one or more players – into the design. As a larp designer and larp-runner, I absolutely don’t want to beg for last minute players or make last-minute changes. I want the design to tolerate faults, thereby reducing my stress and maintaining a standard of quality for all the participants. 

There are lots of ways to approach this problem.

A few ground rules, based on my own experience running and playing larps, guided my thinking. If these rules don’t mesh well with your own aesthetics, or social dynamics, or the affordances of play you need to address, obviously my thoughts here aren’t going to be as useful. 

• The default player count can be fixed or variable but but should fall in the 10-20 range. 
• All roles should be roughly equal in responsibility, weight, and potential for interaction and fun. If the game requires pre-casting, that should be straightforward.
• A character should be actively connected to three or four other characters. More than this may be overwhelming and fewer than this may lead to boring or overly-focused play, particularly in the event of a dropped role.
• A character should belong to a cohort of other characters that are easy to identify. If a player’s direct connections aren’t working out for any reason, they should still have a group of characters to interact with. Six to eight people seems ideal for this cohort – enough to form a tangible team but not so many that you can’t identify them all. 
• Some asymmetry should be included, at various scales, because asymmetry is dramatic and fun.
• Whatever model accommodates all these ground rules should also be extensible into larger sizes. Ideally, it will just get more robust as it grows. 

The traditional model likely privileges certain roles. Character connections are fiction-dependent and may be few or many. Cohorts probably exist as in-play factions. Asymmetry is highly likely, but the game cannot scale. 

A better model, suggested by Trey Alsup, is to build a small larp and then instantiate it. If each instance is 4-6 people, you can expand indefinitely, with each group playing a game within a larger game. By adding hooks to connect groups, and perhaps providing distinct color for each, you create both redundancy and fault tolerance. Based on my ground rules, this model’s weaknesses are a lack of cohorts (although I can imagine building them in) and a concrete lack of asymmetry. If those aren’t important to your design, the efficiency of writing a single small larp is very appealing. 

I set out to make a model that could accommodate all my ground rules. The relationship map is built around three asymmetrical teams, each of which has two subgroups. The two subgroups within each team are also asymmetrical – a large group with five characters and a smaller group with three. Around the “edge” is a composite team with one member of each of the six formal groups.

Every character is thematically connected to two groups and four other characters, a manageable and fault-tolerant number. There are many outward-facing connections and allegiances – four out of seven on each team have a direct connection to another team. A number of characters can drop out without impacting connectivity and relationship depth and richness.

Three teams are balanced but inherently unstable, which is nice. You can strip out layers at different known player counts (like A-F can disappear for a 9 player game without breaking any communication channel). 30 players? Two per node, done. Player K doesn’t show up? No problem, all connected players still have three relationships and D/E handle the missing communication channel between the guests and staff. 

This also feels like a nice design tool, because it corners you into questions like (for I) “what is Lawton’s connection to the staff?”, (for A-F) “What’s the deal with this weird council of plutocrats that also includes, quite mysteriously, the cook and the valet?”, or (for K-O) “What sort of relationship do a local forester and an anarchist sculptor have?” Exciting stuff that leaps out and demands explanation. Willem and Annette are estranged and have no romantic connection. With the butler between them, perhaps they don’t even speak to one another any more. May is engaged to Lawton, but they hate each other. Both have a romantic – or at least hopeful – connection to another. The valet and the lady’s maid are in love, and the butler does not approve. In a different set-up, you could invite players to create characters based on their map node, in collaboration. 

Although not unique to this model, a relationship map is also a great tool for assessing things like gender ratios and the availability of non-gendered roles, overly-predictable family relationships, and potentially problematic connections. The Nordmore Estate game has many roles that can be gender-swapped or de-gendered entirely, for example. 

Going through this design according to my ground rules, everything checks out.

• The default player count can be fixed or variable but but should fall in the 10-20 range. 

This model has 15 player roles and can probably lose as many as six and still function.

• All roles should be roughly equal in responsibility, weight, and potential for interaction and fun. If the game requires pre-casting, that should be straightforward.

The model doesn’t really solve for this, but it can easily illustrate areas that seem light on drama. The Nordmore Estate example is primed for family drama among the related staff, with some red hot romance between guests and family. Characters whose roles seem a little ambiguous include Twyla Lamb-Pace and Congressman Culbreth. Graves relies on others to motivate him.

• A character should be actively connected to three or four other characters. More than this may be overwhelming and fewer than this may lead to boring or overly-focused play, particularly in the event of a dropped role.

Each character is explicitly tied to four others. There is obvious room for expanding connections in play, but for a player who can only handle a handful of relationships, the default will provide lots of interaction.

• A character should belong to a cohort of other characters that are easy to identify. If a player’s direct connections aren’t working out for any reason, they should still have a group of characters to interact with. Six to eight people seems ideal for this cohort – enough to form a tangible team but not so many that you can’t identify them all. 

There are three seven-person factions (Family, staff and guests), and within each there are two smaller groupings. Most connect in some way to another cohort. Three (Sarah Bell, India Jansen, and Amalia Rothenberg) are only tied to others in their own cohort.

• Some asymmetry should be included, at various scales, because asymmetry is dramatic and fun.

There are three seven-person factions, and each of these is further divided into a larger (five person) and smaller (three person) group. So if you call a “family meeting”, all the Jansens and all the Van Nordens will show up. If you call a “Van Norden family meeting”, Ernest and India will be left in the cold. 

• Whatever model accommodates all these ground rules should also be extensible into larger sizes. Ideally, it will just get more robust as it grows. 

The defined roles cannot simply be doubled, but the entire relationship map can be. At each node, a second character is introduced – Amalia’s dodgy anarchist dinner plus one, for example – who shares her fundamental connections with some additional twist. This example is suboptimal for such expansion, but other genres and topics would handle it well. The same map, with two cohorts of rival gangsters and a third of corrupt city police, would be an easy-to-scale example.

I hope this model is interesting and useful to you. It arose from my desire to address a specific problem, but I feel like it offers greater insight into building live action games generally. If you use it, or improve upon it, please let me know!