Two big fears for organisers.
- No-one will show up
- Lots of people will show up and they will hate it
Solution for 1 – not today.
Solution for 2 – test and iterate.
Yes, it’s Learn-Build-Measure, it’s lean, it’s agile, it’s testing assumption – and it’s really tough to do in larp. How do you do the testing, the learning for a one-off event? (Reminded of the story of the development of Inside Hamlet, 2017 edition, and of PD’s Winter Changes.)
The specific case study – a horror larp – using technology to augment/[produce fear.
Assumption: going out into a dark wood is scary, and splitting the party is scarier.
Assumption: power going off is scary, and fixing it is good.
Assumption: it should be obvious why the lights go out, and fixing a generator is fun.
Wireless lamps – range isn’t so good.
IR cameras viewed through tablets – the tablet itself produces so much light the IR didn’t help.
“You can’t test art, can you…”
Larp is usually waterfall. Waterfall is risky. Agile isn’t. But how do agile larp design?
You can test characters with placeholders, testing networks of relationships, then with everyday characters (that might not produce sufficient drama?), then with extreme characters (that might not be relateable?) , then balanced characters as the final delivery.
Adding steps of complexity.
How to test?
Testing specific elements, each in specific ways useful for that elements. With each others and friends. Try it, even if it’s not perfect – every assumption you have tested is of utility.
You know, this is hard.
We ended up designing a test for a meta-technique for communicating the subtext of a conversation at an upstairs/downstairs larp. We’re making the scope of the test as small as possible, so it might actually happen. Test is to use 3 different media for communicating subtext with 5 people we’ve invited round for a bowl of soup before going out for a beer later. And then discussing the options thereafter.
Coda: Try, even if it’s not perfect.
And read the Lean Startup, we’re told…