Lessons From Tombstone

Steve Hatherley

We’ve just finished running Once Upon a Time in Tombstone, a weekend-long freeform that has been some years in the writing. My head is still spinning, and although the game was a great success (as far as I can tell from chatting to the players afterwards), we could have done a few things better. In fact, the things we could have done better were almost all on the GM’s side.
What we really didn’t do very well is make it easy for ourselves to run.

(There’s some irony in this. I write freeforms as a business – selling them as murder mystery games for absolutely anyone to run. When doing those, we have to make the systems easy to run. So why did we forget all that when it came to Tombstone? I wish I knew.)

Anyway, here are the kinds of things we did to make it difficult for ourselves, and how to sort them out for next time. (The one pleasing thing is that having reviewed my notes of the last weekend-long freeform I was involved in running is that we generally didn’t make those mistakes. So although we made mistakes, at least they were new ones…)

Interesting Places

We had a few interesting locations where things were happening – the Big Muddy, various mines, a sacred site or two, even a fort and some ranches. Unfortunately, we didn’t really have much way of coordinating what was going on at those locations and we didn’t really think about it earlier.

So, what tended to happen is that when someone wanted to visit (say) the hydraulic mines, I had to check with a couple of GMs to find out what the current situation was first.

We could have solved this with radios, or phones – or just a piece of paper. A piece of paper (a record sheet) that described the location at the start (maybe with some roleplaying hints for key characters) and then lots of space to describe the changes as the game went on. Then, if someone wanted to visit somewhere all we would need to do is just check that location’s record sheet and we’d know the current state of play.

Timber

Part of the game involves expanding Tombstone – building churches and schools and whatever. (This is part of an overall "taming the West" theme to the is timber – we deliberately restricted timber in two ways. First, you had to order it the game period before, and second, we limited it to 10 wagonloads of timber per game period. (Plus there were other sources tucked about here and there.)

The two restrictions caused different problems.

The delay in delivery caused problems as it required us to record who had ordered timber and make sure that it was available at the right time. (It would have been much simpler to create timber receipt slips – give the receipt to the player with a time on it and they can then collect the timber after that.)

Restricting the limit to 10 lots of timber per game period is fine, except that we didn’t have a satisfactory way of recording what had already been ordered. A way around this would be either to have an order book, or have a dedicated "timber GM".

Or easiest perhaps would be to have a pre-set number of timber receipts available – and once they’re run out, they’re run out.

Banking

Running the bank was a mess…

The basic problem was that the sheets containing the details of the bank accounts didn’t easily lend themselves to being changed. That’s a fundamental problem given that players will want to pay money in, take money out, open new accounts and maybe even take out a loan. Next time we’ll set the banking system up so that it can cater for moving money around.

(Incidentally, both the problems with Timber and Banking would have been fine if there had been one person responsible. Unfortunately, that’s not the way it worked. Originally it was planned that the Town GM would do both of these from the Town Desk – and they’d be there pretty much the whole time. However, that GM ended up heavily involved in running the newspaper, which meant that the Town GM post was occupied intermittently by the floating GMs who didn’t know the Timber and Banking systems. Of course, that’s really no excuse when you’ve got a queue of players…)

Telegrams

We provided a facility for players to telegram their contacts "back East" (or wherever) – unfortunately we didn’t work out in advance how we were going to manage the process.

So what happened was that the players would just come up to us and ask to send a message to their contacts. We then gave them a piece of paper, which they handed in. Those pieces of paper were then just left on the desk until one of the GMs had time to answer them, at which point the answers were also then left on the desk. (Can you see where this is going?) Then, when the player turned up to find out the response, we had to search around through all the bits of paper and try and work out what they should have received…

What we should have done is created some pre-prepared telegram forms – with space at the top for the telegram and space below for the response. We should also have set up a system for checking them in and then keeping them for collection. We have discussed the need for a duplicate book so that we knew what information we had issued, but personally I’m not sure of the worth of that as it didn’t seem to matter during the game. (I can’t recall an incident where we needed to review what information we had issued.)

The other problem with telegrams was only really experienced by the GMs who didn’t really know the game in great detail (that was Adam, who hadn’t written it, and me, who hadn’t been heavily involved in the writing for over two years and whose knowledge was dangerously out of date).

The problem was that every now and again a player would want to know some information about another character, or NPC. Unfortunately, Adam and I rarely knew the answer and that meant either we had to ask another GM (which we didn’t want to do – if we were answering those queries it meant that the other GMs were also busy) or go and look up what we needed. Often we could just look up the information in a character sheet, but it got really tricky when it came to NPCs – luckily we had a PC on hand to search with, but if I was writing a new game I’d create an "NPC Bible".

(The NPC Bible would work as follows: next time the writers create an NPC for a plot, they also write a few words for the NPC Bible. That way, should any information about the NPC be needed during the game, you can consult the Bible and find out everything you need to know. And while the NPC Bible is really easy to create as you write the game, it’s much more work at the end so I’m not expecting one for the next time we run Tombstone.)

Staking Claims and Ranching

I’ve lumped Staking Claims and Ranching together because that’s how it worked in the game - both systems were managed by one GM (the "Big Country" GM). The reason for them both being managed by the one GM – nobody else understood those rules. Although there were different problems with both, fundamentally the problem came down to all the players queuing up for the same GM.

If we had created rules that used "turn sheets" and "default orders" we would have reduced the queuing dramatically.

We should also have created simpler rules that other GMs could run, just to help the Big Country GM and let him take the occasional break.

Abilities

Is it possible to have too many abilities? Oh yes…

I like ability cards – all my games use ability cards and I even use them sometimes for tabletop games. In fact, all the writers like ability cards – so it was inevitable that Tombstone would have abilities. Lots of them.

Unfortunately, we left writing abilities until about a month before showdown, and as a result we didn’t really get the quality of abilities that the game deserved. Instead we tried for quantity over quality – and I’m not convinced we did the right thing. (I must own up to some direct responsibility for this one – I ended up writing the bulk of the abilities, about 800 of them in total.) In the event, each character ended up with a mass of little cards that they had to pick through. And while some of the abilities were pretty good, quite a lot of them weren’t…

So overall, I’d far rather have a small number of good abilities over a large number of mediocre ones.

A Date with Destiny

But it wasn’t all bad. Here are a couple of things that seemed to work really well, starting with something we created on the fly – A Date with Destiny.

Late on the Saturday night it became clear that that there was a chance that our villains (the Cowboy gang lead by Curly Bill and Johnny Ringo) were in danger of being pounced on by lots of well-armed lawmen at 9am on Sunday morning. We’d implemented a "no deaths until Sunday" rule, but our villains had been so successfully played that they well and truly annoyed almost everyone – which meant that there was a high probability of an early bloodbath on Sunday morning.

Our villains didn’t want that. We didn’t want that – so we and the players concerned did some thinking on our feet and came up with a cinematic solution.

We created new "A Date with Destiny" abilities - that basically meant that provided they had called someone out and had arranged a showdown at High Noon, then any gunfight they were involved in was subject to the non-lethal rules. (And they also could escape jail and other inconveniences just so that they make their date with destiny.)

As well as ensuring our villain’s survival to the final reel, this also did a couple of other things. First, they had to go and find someone who would duel them at High Noon – plenty of roleplaying opportunities for calling each other out.

Second, on the Sunday it meant that the Cowboys could be as mean and despicable as before, safe in the knowledge that they could be thrown in jail and still have their moment of glory.

Which brings me to the showdowns at High Noon.

Staging Gunfights

I’m not normally a fan of the “stand around and watch other people hog the limelight” style of freeforming, but this seemed to work really well for Tombstone.

Although it looked much more planned than it really was, what we basically did is told each of the gunfighter pairs to work out between themselves who won and who lost their “date with destiny”. We trusted them to do what was dramatically right - and gave them the opportunity for their moment in the spotlight. I sorted out a running order, and then we just let them get on with it - with the odd break to allow people to react (and continue gaming) to the events as they unfolded.
And then, as the last staged event drew to a close, we announced that the game was over and the credits were rolling.

For me, it was a really satisfying way for the game to end, and it seemed to suit our players as well. I can think of several reasons why it worked well this time:

  • We’d built the villains up over the course of the game and it was the right time to see them go down in flames.
  • We had lots of short scenes that actually involved a fair percentage of our cast. That’s much better than one long scene involving 5 or 6 characters.
  • Several of our players have become very experienced at ad-libbing and improvising, so it was joy to watch some of them.

I don’t advocate this style of ending for every game, but it certainly suited Tombstone.

Summary

My overall learning experience from Once Upon a Time in Tombstone is that we needed to spend a little longer thinking about how we were going to run the game, and prepare ourselves accordingly. Some of this was down to inexperience (some of the other GMs hadn’t run a game quite like this before), but in my case it was inexcusable!

Article by Steve Hatherley.

Comments

Add a New Comment
Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-Share Alike 2.5 License.