There’s an article in the Knudepunkt 2015 Companion Book which I think is worth further discussion: “The Blockbuster Formula: Brute Force Design in The Monitor Celestra and College of Wizardry” by Eirik Fatland & Markus Montola. The article is about how combining an old (and implicitly deprecated) design method - “brute force design” - with newer Nordic techniques (360 degree illusion, play to lose) made “Monitor Celestra” and “College of Wizardry” a success.
(I am assuming here that you know what “Monitor Celestra” and “College of Wizardry” are. If not, google them and squee).
The interesting concept for us here is “brute force design” - which in Nordic land used to be called “organising larp”. And it looks very familiar to us. Fatland and Montola characterise the brute force method like this:
- Characters are split into groups with conflicting agendas (orcs want to kill elves)
- There are subgroups inside groups (the elvish general wants to attack head-first to show bravery, while the king favors a stealthy approach)
- There are power hierarchies (the general commands the officers who command the soldiers)
- There are secrets, which players can discover, hoard, and trade (the general is a traitor plotting to kill the king)
- There are puzzles that can be solved (assemble a torn-up treasure map)
- Runtime game mastering is conducted by triggering events, introducing surprises, and inserting messenger characters (an NPC scout enters the tent of the king, informing that a horde of undead is approaching the camp)
The design principles:
- “more is more”: the organiser throws enough plot at the game to ensure that something happens. “The results of that are unpredictable and chaotic, but seldom boring”.
- Colliding power hierarchies: games are implicitly zero-sum, with winners and losers. There’s easy dramatic tension from the possibility of rebellion, usurpation and succession.
- Hidden narrative: secrets and puzzles combine to provide backstory
- Play to win: players will try to achieve their character’s goals. Which they sneer at as gamism rather than a shortcut to drama.
So, the first discussion point is what do we do differently here? I can spot a couple of things. We’re not so big on power hierarchies, for a start. We have kings and things, but there’s not a great deal of ordering people about in-game. We do have conflicting groups/factions, and subgroups within them though, because its often an wasy way to write.
We’re not that big on run-time GMing. There are games which do, but there’s also a strong tendency to eschew it entirely, stepping back to a pure facilitation role (“does this thing on my character sheet mean what I think it means?”; “yes”). Personally, my goal as a GM is to be able to spend the entire game in a corner cackling to myself at the fun the players are having. The entire game should be on the character sheet, and I shouldn’t have to do anything after game start except refill the water jugs.
And I’m not so sure we’re that serious about “play to win” either. Yes, the GMs expect people to (at least initially) pursue the explicit or implicit goals on their character sheets - if only as an initial character motivation. But we also recognise that there’s a gap between character goals (I want to get away with murder) and player goals (I want to be taken down dramatically), and so we frequently have explicit advice to players that a “secret” on their character sheet is something you want to tell to everyone you possibly can within the bounds of dramatic plausibility (which requires steering). We also write goals to encourage action rather than inaction (“don’t get caught as the murderer” becomes “pin the murder on character X”), and write intentionally open goals to encourage introspection (“decide how you feel about Y”; “decide what to do about Z”).
The article has a good discussion of both the strengths and weaknesses of this design method. Strengths: easy mapping to common fictional types, produces good scenes for players, resilient (because plot is redundant). Weaknesses: players disabling each other’s plots, potential for monopolization, tension between “play to win” and “playing in-character”, non-functional characters. Most of which we would categorise as consequences of poor design. Monopolization is a sign that there is not enough plot, so everybody fights over it. Tension between IC and OOC goals is a sign of poorly written character motivations or poor goal specification; either write your characters so that they want to win (thus removing tension over strategic choice), or write them explicitly doubtful and turn that tension into a virtue. Non-functional characters are a sign of poor plot design, which we solve by making them relevant or by writing piles of soap opera (and we love our larp soap opera).
(Unmentioned weakness: Aristotelian curse. Still not sure what to do about that one in a short game yet, though the Czechs have suggested a partial solution for long games).
Second obvious discussion point (which I’ve addressed some of above): how do we avoid those weaknesses?
In Nordicland, these weaknesses (or, alternatively, a culture of poorly-designed larps) encouraged criticism, and a series of manifestoes which highlighted them and suggested alternatives. So we got Dogme which outlawed backstory, secrets, “main plot”, supporting characters and action (defined as “superficial”; fun is bad, m’kay?), targeting monopolization, non-functional characters and colliding power hierarchies. And we got Turku which outlawed props, mechanics and acting, and advocated immersion - targeting play to win and hierarchies. They threw away Brute Force Design and created a new larp subculture focused on minimalist and transparent design, producing games which were about IC introspection and bleed.
In New Zealand, we responded to those weaknesses by designing better larps.
Seriously. The larps we write now are on average better than the ones we wrote ten years ago, which were better in turn than the abortions I helped write ten years before that (which fortunately are lost to history). While we have hits and misses, we’ve learned more about what works and what doesn’t, and we’re better at avoiding the obvious pitfalls.
I don’t know how to end this post. But people might want to think about what problems we’ve missed, and how we might design around / to solve them.