I designed my first black box larp, “Waiting for GO901” back in 2014 but it was only in 2016 that i finally made the larp script available. A stark contrast from the Fastaval tradition, where you write the game and only run it afterwards, (This is because at Fastaval, the game must be able to be run by other GMs. Also the must not have been run anywhere else before Fastaval except as a playtest).

That is the way I have done it for many years. But where my Fastaval games always felt incomplete after the ultimate taste that Fastaval is, the script i finished for “Waiting for GO901” still holds and is to this day the best larp script I have produced. The reason was, I think, that I didn’t write it down until after i had run it several times in very different conditions.

By then I had the structure, design, workshop, instructions and mechanics down to a point. I knew exactly how the game was to be run and the biggest challenge was putting that to words. It is a clear and concise script and much less rambling than any of my previous scripts.

This has change my way of making games. Where before I got as much done as possible and then maybe, if there was time for it, I would make a playtest to see if it worked. Now I playtest as early as possible and as often as possible. And I don’t really see them as playtests, perhaps except the first one, which really is a proof of concept. Here I test if the mad idea even works. The rest is to run the game again and again to really get af feel for it. What works, what doesn’t, which way is the best way to explain or practice a mechanic. What phrase really gets the point across to the players?

The end result is that my lastest game, “…And that’s it”, got praised for its communication. That has always been my weak point and suddenly it was the strong point.

So how does it work?

Well for the first playtest, the proof of concept, I only write down what I need to run it. A bullet point list of things I need to say and do. A rough descriptions of scenes and whatever text the players need, (characters, handouts, and so on). I do no layout it, I keep it as simple as possible.

They I run the game. Often parts of it don’t work, and I change them on the spot, so that they do work, and make a note of it in the text. Then during the game I add notes of things I did different than what I had written down. I also note where the game isn’t working as I want it to.

Then after the game I talk with the players about the elements I was in doubt about, and how they would feel about changing it this and that way. This is very helpful, as often, something I felt went bad, worked perfect for the players, so it’s good to know, if the worry is only in my head or a real thing.

I also talk to the players about the experience they had. And then in my head match that up to the experience I’m aiming for. Players can have a great experience at a game, but still not have the experience you wanted. Did they manage to find tragedy in your feelgood story, or create an action adventure out of your grimdark superhero story? Do you want to move your idea in that direction or how do you bring it back to the experience you wanted to design?

After this first proof of concept I have a rough short draft of the story and input on what I need to change. From there I run the game again and again each time getting to know the game better and better, changing it, tweaking it.

The actual writing often only happens shortly before the next run, as I hastily add the change and improvements, I have come up with from the previous runs before I have to run it again.

Then after several runs, I don’t see them as playtest more as practice runs, I have enough a feel for the game that I start to write down all the stuff I know how to do, but haven’t written down, because I just do it. This is often prep of the room, a more detailed workshop run through and instructions for the scenes rather than just descriptions of them.

I think this is where the biggest difference lies. This is where I have changed my style the most. Before I had to guess what a GM needed to know before running my game. But now having done it five or four times I know what needs to be said and done to run this game.

Another result of this format is that my games become much more fluid. I can change them a lot more than before. “…And that’s it” went though a lot of changes much, more than I’m use to, and I think this approach is one of the reasons. Because if the playtest come late in the process the game is set in stone in my head, and only small tweaks can be made. But as long as the game is in the fluid state of only a rough draft it costs nothing to make great changes.

None of the changes was to make it a different game, but change that made the game come closer to the experience I was looking for. They made the game more stable more sure to yield the result I wanted.

So this has become my new approach.
What do you think?