The larp you play in, the larp you run, isn’t safe. That’s a fact.
Further, if you’re relying on people’s behavior to make your larp safer, you’re practicing bad design. That’s an opinion.
If you’re still reading, let’s prove that fact and justify that opinion, shall we?
There’s No Such Thing As A Safe Larp
Your larp isn’t safe because a “safe larp” doesn’t exist.
When we say “safe,” we’re using a word that means a lot of things to a lot of people. We’re not going to presume to define what the word means to everyone. Regardless of how you use it, it’s an all-or-nothing quality: the larp is either “safe” or it’s “unsafe.” And larps don’t work like that. No matter how well you design it, someone can get hurt at your larp, emotionally or physically. Due to the nature of larp, they can get hurt in unique ways (rollercoasters and rock concerts don’t typically cause bleed). There’s a saying in aviation: the only safe airplane is the one on the ground… it applies here, too - the only safe larp is the one no one actually plays.
However, there’s not really such a thing as a completely unsafe larp: we’re not actually using real weapons or participating in the Stanford Prison Experiment. These two extremes don’t exist. But because the words “safe” and “unsafe” have such powerful meanings (“safe” = “good”, “unsafe” = “bad”), we try to apply these labels to larps consistently. When what we should be saying is “more safe” or “less safe.”
The idea that “safety” is a dial, not a switch, is essential to larp design. At Sinking Ship Creations, we try to avoid the term “safety” and instead use the term “risk management.” Risk management is a practice in which we try to reduce harm by identifying hazards that cause harm, assessing the risk they pose to participants, using controls to reduce that risk, and finally by communicating that risk to players so that they can make a risk-aware consent decision. We can’t tell you what a “safe” larp looks like, but we’ve done the work to quantify what a “low risk” larp looks like, and how to communicate that risk to players.
So when we say “your larp isn’t safe,” it’s not a knock against the larp you play in or the larp you run: no larp is safe. But we can, and should, reduce risk at our larps… and there are ways to do so.
Some Risk Controls Are Better Than Others
When you use risk management to make your larp safer, a key step is implementing controls. A control is anything that reduces the probability, severity, or frequency of a risk. While there are many ways to do this, we use six categories of controls:
Elimination: This is the ideal control, where we remove the hazard associated with the risk completely. For example, if we’re indoors, we eliminate many of the hazards associated with the outdoors.
Design: Also called engineering, we structure the larp to minimize the risk. We saw a lot of these controls after Covid: making sure spaces were ventilated, removing chairs to force physical distancing, limiting attendance, etc.
Equipment: Anything that protects against a hazard. Again, we saw these after Covid, as vaccinations and masks would be considered equipment (the key difference between equipment and design is that people have to use the equipment, which requires verification that they’re using it properly).
Training: Teaching people how to avoid hazards.
Regulation: Making rules that tell people not to do something hazardous.
Information: Telling people about hazards.
You might notice we went into more detail on the first three, which we call independent controls. This is just a term we use internally to describe controls that exist without the interaction of individual players (although equipment kind of straddles both categories). The last three are dependent controls… they require a person to use them. There’s a huge difference between these types of controls, due to a very simple reason.
People Make Mistakes
If you have “safety mechanics,” here are a couple of facts you have to accept:
Sometimes, players won’t use them.
Sometimes, players will fail while using them.
Sometimes, players will use them the wrong way.
There’s an entire field of engineering that deals with reducing human error, because the one sure thing about a human is, if you give them a task to do, they’ll eventually mess it up. People make wrong turns, they trip over curbs, and they will mess up your safety mechanics. That’s why some controls are better than others. Let’s take the risk of tick bites. If you’re indoors, you can’t get bit by a tick (elimination). If you’re only outside for fifteen minutes and the grass is cut, you probably won’t be exposed to ticks (design). And if you’re wearing repellent and long pants, you’re less likely to get bit (equipment). These are far different from instructions such as “check yourself for ticks” and “don’t go into the woods.” Someone is going to go into the woods and then fail to check themselves for ticks. This is a mistake… it doesn’t mean they deserve to get Lyme disease.
If you’re teaching players a mechanic in a workshop, you’re teaching them a human factors-based mechanic, and given time, this mechanic will fail during your larp. When we identify the need for a safety mechanic, we should be developing independent controls - elimination, design and equipment - to address that need. Ideally, we wouldn’t need any safety mechanics, because we’d have managed risk to an acceptable level using those controls. The ideal larp, from a risk management perspective, is the one anyone can play with no safety mechanics, because then we don’t have to worry about when they mess up the safety mechanics.
Of course, we don’t live in an ideal world. So what do we do?
Threat and Error Management
Quick history lesson on risk management: a lot of this comes from aviation, where pilots were taught all kinds of skills to reduce risk… they would learn ORM (Operational Risk Management), CRM (Crew Resource Management), and a whole bunch of TLAs (Three Letter Acronyms). Eventually, aviation experts realized they didn’t need pilots to deal with a lot of risk management, because aviation uses a lot of independent controls. Instead, they just had to be properly trained, and because training is a dependent control, they had to learn to manage their mistakes.
A safer larp is kind of like an airplane: it relies on independent controls to the maximum extent possible, and when it has to, it trains its participants to use safety mechanics to reduce risks further. However, the participants are going to screw up those safety mechanics. So how do we manage those errors to prevent harm? One solution is Threat and Error Management (TEM), which allows us to trap errors and prevent them from causing harm. We’ve applied the TEM philosophy to larp, by identifying the three steps of a mistake:
Step 1: Threat
A mistake begins with a threat, which is any condition that makes things more difficult than they normally are. If your safety mechanics are good, players will use them… when they remember to. But if they’re tired or angry, or if another player is raising their voice, or there’s loud music, it’s harder to remember the mechanic and use it properly. Step one of preventing a mistake is identifying the threats that lead to them.
Step 2: Error
An error is when someone does something, typically due to a threat, that makes the situation less safe (i.e. increases risk). Remember, people make mistakes all the time, but they don’t always have consequences. Just because a player messes up a calibration mechanic doesn’t mean another player bursts into tears, but that error increases the likelihood of emotional harm.
Step 3: Harm
This is the bad stuff that comes from an error… the actual emotional distress, physical injury, or other negative consequence of someone making a mistake.
By looking at a mistake as a process, we can prevent a threat from becoming an error, and an error from causing harm. This means that we should be aware of threats and point them out: the most effective way to counter a threat is just by making people aware of them. They will then pay more attention and make fewer errors. Countering mistakes is more tricky. We’ll talk more about mistakes, and how to manage them, in Part II.
Comments