Coherency - part 3

The things that happen in the world you create have to make sense. Maybe not to the players, but you have to understand why things happen and what the likely repercussions of your players actions are.

 You can change things after the time as long as you’re careful. I generally work to the following rules in most cases:

• Death should be final - even if you made a mistake. Once players are dead they are dead. Unless you had a built in mechanism that all players knew about it’s not worth the damage that undoing death will do. If necessary, admit you made a mistake, but apologise and move on.
• Acknowledge your players actions. There should be results for their actions. They don’t have to be the results that they wanted, but acknowledge their effort.
• It’s your game. Decide what’s important to you, lay it out clearly and stick to it. Accommodate players ideas, but within your structure. It helps you to stay keen, and it helps the game to have an identity. It’s fine to say no to people.  

A good backstory gives you options that the players need never see if they make the right choices. This can be an unpopular option as it requires having kit around for things that may never happen. It can take money for something the players never see, and money is a major limiting factor in most games. We have a lot of kit, and will often bring things we're not anticipating using. This both allows us to use them if we find we need them, and also means that players who see the monster kit on site don't actually know what we're going to throw at them. 

A good backstory enables you to react smoothly to the players actions without messing things up or over complicating things. We ran the entire Alone arc based on the month (possibly two month) long journey of one ship. The players were interacting with the space ship at points along its journey and the Alone events were the result of that. We weren't just throwing Aliens at them. We were throwing Aliens at them because of where they were. I'd link you to the Main timeline, but we've been talking about running another one, so that would be doing you a disservice - you clearly all want to play.

Each game has things that will happen and things that happen depending on what the players do. We tend to work with both. If they turned up to an Aliens game and there were only Aliens if they turn on the Alien tap they might go home disappointed (especially if they're a group that hole up and don't go out and poke things). We might have the Alien tap turned off when they arrive, but we're likely to build in an autostart if the players haven't found it and turned it on before a certain point. 

Slender are good at this. Their Alien tap doesn't have to be turned on until late on Saturday. Sometimes it's their from the start. Sometimes you've almost given up on it when you suddenly find yourself dying at the hands of an ink-soaked child... It builds suspense to withhold something your players are expecting. Especially if you've built in something else in its place. 

You also need to know how your npcs and other plot elements will interact with each other. Ideally you want this to be something the players can influence and have to deal with (unless you don't, which is also okay, but think about it and then decide). With Alone we had daytime and nighttime npcs/aliens (they mostly come at night - mostly) except for Alone 4 where we locked the players in the day and felt no need to stop throwing Aliens at them. We told them not to bring watches and hence removing any other way of telling the time was also beneficial for them to lose all sense of what was going on. 

Our back stories form from moments. We'll be talking about what we want at events. Someone will say 'I want to see the players waist deep in water being attacked by giant tentacle creatures.' And we'll move on to both discussing how we're going to get them waist deep in water and how we're going to phys rep the giant underwater tentacle creatures and how likely we are to drown them, and to discussing why the players would be there. For example, it could be that the main control panel for the power plant for the base is in this room so they've sent the engineers in to turn it on. It's underwater because the power is off and this bit of the base flooded when it was abandoned. Which is a stupid design for a base. It could have been part of a fail safe to completely flood the power control panel so the base couldn't be reactivated which failed part way through because the AI stopped it. We'll look at that, see how well it fits into what we've got and put it in if it works. Then we'll spend the next four months talking about it and it will look utterly different when we've finished. We might just make Humpo stand in a sci fi paddling pool throwing things at people (I believe it's traditional...). 

Ideas are cheap. Have hundreds, get rid of the ones that don't work, and work out what needs to happen before things can occur. Work out why things are happening. 

Then put Humpo in a paddling pool. 

I have also written you an entry about the LRP Awards

Although John Haynes says it better than I do