Using ChatGPT to help review freeform larps

The kind of freeform larps that I write can be complicated beasts. Numerous characters, complicated plots, items, abilities, secrets, contingencies. And a timeline that can easily be confused. Even an independent proofreader can miss things.

So when it was suggested that an AI might be able to help check a freeform larp, I thought I’d give it a go.

TL;DR – remarkably effective

The Highgate Club and ChatGPT

I recently re-ran The Highgate Club, a fourteen-player freeform that I co-wrote at Peaky in 2010. This was the third time I had run it, and you would have thought that by now, all the kinks had been ironed out of it.

Certainly, in terms of playing the game, it ran very well (read about it here). There were a few kinks (minor ones) that I needed to address. So I decided to use The Highgate Club as a test case for AI, because I knew the game well and I didn’t think there was much to find. That’s what I thought…  

I used ChatGPT. I have a paid account which lets me upload files into a folder so that ChatGPT can analyse them.

So that’s what I did. I uploaded the files as MS Word documents. 

(For clarity, at no point in this process did ChatGPT change the game materials – I made the edits myself. And ChatGPT doesn’t use the uploaded files for training purposes; at least, that’s what it says.)

The prompts

My first prompt: Read the entire LARP and review it as a professional editor. Produce a prioritised list of issues but don't rewrite anything yet. Classify each issue as Critical, Major or Minor, explain why it's a problem, and suggest a possible solution.

As you can see, I didn’t even introduce The Highgate Club to ChatGPT… In a later prompt, I remembered to tell it that the larp was written in UK English. I will try to remember that in the initial prompt next time.

(Although this review ended up identifying all sorts of (mostly minor) issues with The Highgate Club, it wasn’t very structured. I plan to develop a more structured approach for future games.)

ChatGPT responded to my post by recommending a full editorial pass rather than a quick proofread, which ended up as follows:

Editorial review

ChatGPT completed an editorial review in four passes:

• Pass 1: Core structure, rules and cross-document consistency
• Pass 2: Character consistency & information flow
• Pass 3: Plot dependency & failure analysis
• Pass 4: Continuity audit

I’m not really sure whether all those passes were necessary, but they brought up lots of points to consider. Obviously, ChatGPT was extremely complimentary about everything else, which was a bit tiring…

Character review

Then we moved on to characters. ChatGPT reviewed every character as a separate pass. I didn’t tell ChatGPT which character to do next – I just let it choose. (In future I will probably tell it which ones to do so that I can track progress. I got a bit lost towards the end – if ChatGPT had omitted a character, I might have missed that.)

Hallucinations

About two-thirds of the way through the character reviews, I realised that ChatGPT was starting to hallucinate when it mentioned a character that didn’t exist.

So I pointed out its mistake, and ChatGPT replied that: 

“After reading a large cast with multiple immortals, ancient civilisations, and overlapping mythology, I allowed my internal summary of the characters to drift instead of re-grounding myself in the source documents before writing the review.”

So it then re-read the character and revised its comments. At the end of that, it said.

“From now on, I'll re-read the relevant character sheet immediately before every audit, even if I think I remember it.” (ChatGPT’s emphasis.)

And then it immediately hallucinated again!

So in future, I will remind ChatGPT to re-read the character sheet before every character review.

The output

At the end of the review, I asked ChatGPT to summarise everything in a Word document. (It could also have created an issue log in Excel – I might try that later.)

It created a 15-page report containing 37 different findings which it ranked in order of criticality: Critical, Major, Minor. Each finding has an explanation and a suggested fix.

While I didn’t accept all of the points, I accepted the majority – and every single one has been a valid point worth considering. Examples of the kinds of things it picked up:

• Conflicting instructions
• A character had mistakenly received a handout
• Areas where we had not provided enough information – the sort of thing that we would handwave when running the game, but really should clarify
• Some items had mixed up item numbers
• Character backstory inconsistencies
• Information in the plot summary did not match the characters
• Conflicts in spellings and terminology – Holmes and Homes, for example

So all extremely useful.

One benefit was that ChatGPT doesn’t have my assumptions or biases – so it picks up things that I didn’t even realise were missing.

Other prompts

During the prompting, I also asked it to review the timeline in the game instructions to see if anything was missing. Sure enough, it highlighted a few things. I suspect it could probably assemble a timeline from scratch if I wanted it to.

I also asked ChatGPT: Imagine I've fixed all the consistency errors. Now imagine running this larp with experienced players. Predict the ten most likely problems that will arise during play, and explain why.

It came up with ten examples, all very interesting. I knew about two or three already, and having seen the game in action, I know that others haven’t arisen (and probably wouldn't). But I could see why it had identified each of the ten issues – definitely a good question to ask.

Plus I could ask ChatGPT to suggest other prompts.

Overall

Overall, I found ChatGPT an extremely useful tool in assessing The Highgate Club. You have to treat it with caution and watch for hallucinations, but it produced an extremely useful final report.

I suspect with a little practice (as I improve my prompts and learn how to use it fully), it will become even more effective.

And as for The Highgate Club, the files are now all updated.

GDPR for organisers of chamber larps, parlour larps, and freeforms

(Yes, I know they’re all the same kind of thing. I’m using the term “chamber larp” in this article because that seems to be gaining ground as the most common term right now.)

So, you’re organising a one-shot chamber larp for a convention. If you manage your players’ personal data (email addresses, names, and so on), GDPR may apply to you. And if you are in the EU (including the UK) or have EU/UK players, you are definitely subject to GDPR. (Other territories have their own data laws, obviously.)

Hosting Venice. Photo by Tsijon

Now, I’m not a lawyer or a GDPR expert, but this is my take on the GDPR requirements.

When does GDPR apply?

GDPR protects data belonging to EU/UK citizens and residents, and it applies even if you’re outside the EU/UK. So if you’re organising a convention chamber larp with European players, GDPR applies to you – wherever you are in the world.

GDPR applies to “professional and commercial” activities. So if you are organising a chamber larp for a few friends, GDPR doesn’t apply. But if there's some kind of commercial arrangement (such as a convention, or charging players to cover room hire), then GDPR applies.

Data controller

As the organiser of a chamber larp, you are acting as an independent "data controller" for a small amount of personal data (usually name, email address, perhaps accessibility requirements). GDPR applies, and requires that you handle the data sensibly.

Broadly, the key principles are:

• Collect only what you need
• Be clear about why you’re collecting it
• Don’t expose players to each other unnecessarily
• Have a retention policy

Collect only what you actually need

For most games, you probably need:

• Name (or preferred name)
• Email address
• Character assignment information
• Perhaps a few logistics questions

Information about disabilities or health conditions is considered special-category personal data under GDPR. You may need this information depending on your game, but be aware that it is even more sensitive than other data.

Only collect additional information if there’s a clear purpose (for example, if your game doesn’t care about your players’ ages, don’t ask them!).

Your responsibilities as a data controller begin when you first receive details about your players – normally from the convention organisers.

Be clear about why you’re collecting it

It helps to be clear about why you’re collecting the data. Ideally, when you first collect data (perhaps in a sign-up or casting form, you should include something like:

I will use your contact details to send information about the game you have signed up for, including character materials, scheduling information, and post-game follow-up if necessary.

Don’t unnecessarily expose players’ data

The golden rule when sending emails to a mixed group of strangers is always to use BCC for mass emails.

(This is an easy mistake to make.)

And don’t circulate participant lists containing email addresses. If you want players to communicate before the game, get explicit permission first.

For example: Would you like to be included in a pre-game player discussion group? Your email address will be visible to the other participants.

Be careful with character materials

If you’re like me, you’ll create a spreadsheet to manage your players, with columns for player name, email, and character. This is fine for your own use (and essential if you are using a mailmerge programme).

What’s less fine is accidentally sharing that spreadsheet!

Have a retention policy

The easiest GDPR retention policy is to delete the data you no longer need. (You can’t misuse data you don’t have!)

For convention games, this might look like:

• Keep contact details until the event is over
• Keep them for a short period afterwards (e.g. 1–3 months) in case of follow-up issues
• Then delete them unless the person has separately opted into future contact

(Set a calendar reminder! And if you’re a convention organiser who gave player details to their GMs, please remind your GMs to delete those records!)

I use Gmail, Google Forms and Google Docs, so in practice this means for me:

• Deleting emails about the game to players
• Deleting my contacts
• Deleting email addresses from my casting spreadsheet
• Deleting the responses from my casting questionnaire

(It’s surprising how widely these systems share data…)

What about friends?

Obviously, some of the people who play my games are my friends, and we are regularly in contact. So do I need to delete their details as well?

I think GDPR is a little unclear here, so this is my pragmatic approach:

• I delete all the responses from my casting spreadsheet and questionnaire
• For friends (and this is a judgement), then I delete neither their emails nor their contact details, because I will need them again

In practice, this tends to mean that if you play one of my games and you are new to me, or I don’t know you very well, then I’ll delete your details. If you’re someone I’ve shared drinks with in the bar, then I probably still have your details. (If that’s you and you don’t want me to have your details, just let me know and I’ll delete them.)

And what about photographs?

I often write about my games on my blog and like to use photographs of the games in progress. So as part of my casting questionnaire, I ask: May I use a photograph/screenshot of you playing the game in future publicity? (For example, on my blog, website and social media.)

So I need to record this, which is why I keep the casting spreadsheet (although I delete actual emails from it, just to be sure).

Marketing

For those of us who occasionally organise games privately, it’s important to separate "game administration" from "future marketing."

Just because someone played your game in 2020, they may not want emails about your future games in 2027. So if you want to maintain a mailing list, make it explicit: Would you like to hear about future games I run?

Keep that list separate from event administration records. And when you do send out emails, explain how recipients can remove themselves: Just let me know if you no longer want to receive emails from me.

Or use mailing list software that handles much of this automatically: If you want to hear about future games I run, click here to subscribe to my mailing list.

Use mainstream tools sensibly

Fortunately, we don’t need enterprise-grade infrastructure to satisfy GDPR. Things like Gmail, Google Sheets and so on are fine, provided:

• Your account is secured with a strong password and preferably MFA
• Sharing permissions are controlled
• You don’t make documents publicly accessible

A simple chamber larp organiser policy

So for running chamber larps as a volunteer at conventions, a practical policy might be:

• Collect only names, email addresses, and information necessary to run the game.
• Use contact details only for organising that game.
• BCC group emails unless players have opted into a shared communication channel.
• Keep accessibility or dietary information private and delete it after the event.
• Delete participant lists a few months after the convention.
• Maintain a separate opt-in mailing list for future games.
• On request, tell players what information you hold and delete it if there is no longer a reason to keep it.

That would put you in a much stronger position than most hobby organisers and aligns well with GDPR’s core principles without creating excessive administrative overhead.

Contingencies

This isn't a complete rewrite of the contingencies section of Writing Freeform Larps, but further thoughts on them following discussions on the ukfreeforms mailing list. When I get to a second edition, I will review the section on contingencies in light of this post.

The background to the discussion was that I was writing Aurora Horizon, a game set aboard a spaceship where the crew awakens from cryosleep with somes of their memory missing. The first part of the game would be about them dealing with that.

I wasn't sure how to approach the idea, so I started a discussion on the mailing list.

Player preferences (ie, everyone is different)

It quickly became clear that some players prefer the surprise of in-game reveals, while others prefer to know everything in advance, as it allows them to think about how to play the character and integrate the information into their roleplay. 

So while some may enjoy the rollercoaster of unexpected twists, others prefer to know the key points ahead of time.

(And me? I don’t know – I’ve not done either. I suspect it depends on the game. I’ve written about it before on my blog, though.)

Should I ever create a second edition of Writing Freeform Larps, I will update the section on contingency envelopes to reflect this.

Contingencies

Contingency envelopes can be triggered by in-game events, by other players, or by time. (Or they may simply be handouts from the GM.)

Contingencies are a popular way of dealing with hidden information – I’ve used them.

For many players, opening a contingency is great – it’s like a small reward, and it’s exciting to find out what’s inside.

However, contingencies aren’t perfect:

• Sometimes, the contingency is a disappointment and doesn’t contain anything new.
• Reading lengthy information mid-game can be overwhelming for players with dyslexia or those for whom English is a second language.
• Interrupting roleplay to read an envelope can disrupt the flow of the game.
• Players might forget triggers and miss vital information. (I’ve certainly done this! Backup triggers may help here.)
• If other characters reveal information before a player opens their envelope, it can be deflating.

Full disclosure

Providing all information upfront means putting all of the information in the character sheet in advance and explaining (through GM notes) how I imagine the character might be played.

This approach:

• Allows players to plan their roleplay.
• Enables players to foreshadow and create a richer character experience.
• Reduces the burden on GMs.
• Allows players to role-play their character’s surprise when appropriate.

However, not all players like this approach – especially those who enjoy being surprised by twists and turns.

I often use a full-disclosure approach for minor bits of information. So rather than use a contingency, I will often now write: “GM note: If you see item 25 (a painting), you recognise it as one that your grandfather painted and used to hang in your study. What is it doing here?”

I’ve yet to see a player abuse this, and it simplifies packing character envelopes.

Hybrid approaches

Of course, it is possible to combine both methods.

Players who like full disclosure can open their contingencies in advance. (The opposite isn’t quite so easy, of course.)

I may decide to have some parts of the game as full-disclosure but also have some contingencies for what I think are key secrets. (And if I really don’t want players to open them in advance, I could do them as GM handouts.)

Memory loss specifics

Amnesiac characters require a few special considerations.

• Reveals should enhance a player’s experience, not detract from it. A contingency that completely changes a character’s nature should have some foreshadowing so it doesn’t feel too jarring.
• It’s worth thinking about how the reveal is staged – giving it space and making it memorable. As a result, I am considering adding a psychologist/therapist character who can be the focus for recovering memories to give it a sense of importance.
• Players should know that their character has lost their memory. Otherwise, they may assume that a lack of information indicates a badly written game. (We’ve all been there!)
• Given the nature of memory loss, a single contingency could include too much information for a player to read and absorb while actively playing. So if possible, time “heavy” contingencies to suit any breaks.
• Some players may not like receiving lots of new information during the game – something to consider as part of casting. 

Aurora Horizon

In the end, for those characters in Aurora Horizon who were having memory problems, I wrote the first page of their character sheet (including some goals) from the perspective of having just woken up from cryosleep.

After that, I put the rest of their character information (including more goals) and told them that it was up to them how they wanted to play recovering their memories. If they were enjoying playing an amnesiac, then they could do that for as long as they wanted. If they didn't, then they could get their memories back sooner.

(And for a few specific memories, I used contingency envelopes.)

From what I could tell, the approach seemed to work. Letting the players decide is often best!

Second-edition "romance" rules for freeform larps

Writing Freeform Larps has only been out a year, and I already have changes I want to make. One of those changes is to the romance rules.

Following West End Lullaby (which I wrote about on my blog), I’ve made four changes.

• First, I’ve simplified it. I’ve removed the tracking of “negative behaviours” and changed it so that you simply decide if you want to fall out of love. (In my experience, people rarely do this – it’s fun having your characters fall in love, and why spoil the fun?)
• Second, I’ve explicitly made it more flexible should you fall in love with more than one person. It’s up to you how you resolve that – do what you think is appropriate.
• Third, I’ve made the heart colours more LGTB-friendly.
• Fourth, I’ve changed the emphasis from romance to falling in love, to allow for platonic and romantic relationships. (Thanks to Rei for nudging me in this direction.)

West End Lullaby’s mechanic was actually a relationship mechanic, and you could use it for rivalries and friendships as well as falling in love. I thought about that, but my experience of West End Lullaby is that it didn’t really work as anything other than for falling in love.

For friendships, I prefer the “Pardner” mechanic we created for Tombstone. And rivalries? I don’t know, I’m not sure if they need a mechanic.

So here’s my updated system for falling in love.

An example system for falling in love

This is an example system that could be added to almost any freeform. Feel free to use it in your own games.

Falling in love

These are the optional rules for falling in love, whether romantically or platonically.

Setup

First, decide whether you want your character to fall in love and how flexible you want to be. Get a pen/sticker from the GM desk and mark your name badge as follows:

• No heart: I don't want to fall in love.
• Black heart: I want to fall in love (heterosexual).
• Pink heart: I want to fall in love (queer).
• Gold heart: I want to fall in love (any).

If don't want to fall in love, read no further.

Second, your envelope contains a heart card with several behaviours you would like to see in your partner. Choose the six you like the look of and cross out the rest.

(It’s probably best if you choose these once you have read your character so you choose behaviours that suit how you want to play your character.)

Third, decide how easily you want your character to fall in love (your “Heart Target”). We recommend starting with a Heart Target of three, but if you want to make things easier or harder, that’s great too.

That’s it for setup.

During play

During play, as people play the game, they will (deliberately or accidentally) behave in a way that makes your character feel more attracted to them (heart behaviours). To help you keep track, we’ve formatted the tasks in a grid so you can check them off.

(We expect you will only have half a dozen or so people to track. To track more, you’ll need a separate sheet of paper.)

Add the heart behaviour checks for each character – that’s your heart score. If your heart score equals (or beats) your Heart Target, congratulations, you have fallen in love with that person.

Falling in love

Once you have fallen in love with them. Here’s what you do:

First, tell someone. That might be the person you have fallen for, but it could be anyone.

Second, you have a new goal.

Help the love of your life succeed: You have a new love in your life, and you want them to succeed. Depending on how hard you have fallen, this may involve putting their goals ahead of yours. (You decide – we suggest using your heart score as a guide.)

Falling in love together

If the person you have fallen for also falls for you, that’s fantastic. We look forward to hearing all about it.

Unrequited love

If you’ve fallen in love with someone, but they haven’t fallen for you, well, that’s just how life works sometimes. Deal with it (through roleplaying).

Falling out of love

If the love of your life does something you really don’t agree with (and you can decide what this is), then you are no longer in love with them. Roleplay it! (And again, tell someone.)

Falling in love with someone else

Keep tracking your scores. If another person beats your Heart Target, then you are in love with them as well! Does this mean you have changed your heart and fallen out of love with your original flame? Not necessarily – you decide! Tell people! Roleplay it!

A few guidelines

Respect other players’ boundaries: If a player doesn’t have a heart on their badge, please don’t track their heart behaviours.

Don’t talk about the mechanics: We prefer it if you don’t discuss the specific dos and don’ts needed to win your heart. It’s OK to talk about them generally, but not to be too specific. Try to keep the conversation natural.

“What does a guy need to do you get you to fall for him?”

“A sense of humour is a good start.”

Ignore all these rules if you want: If these rules aren’t giving you the results you want, please ignore them, particularly if it’s more dramatically appropriate.

Example heart tracker

I would tailor behaviours to the specific freeform – accompany me to the county fair, dance with me at the ball, and so on.

Preparing freeform larps for others to run

While Writing Freeform Larps covers writing and running freeform larps, it doesn’t cover turning a freeform from your notes into something that other people can run.

So, assuming that you’ve run your game and incorporated feedback, what else should you do to get your freeform into a state where others can pick it up and run it?

This is what I do. 

Files and formats

I usually publish games as pdfs, and I assume the buyer will print the game at home. If I’m happy for my work to be edited, I’ll give away the MS Word files. (In either case, I embed the fonts I’ve used.)

My game files for All Flesh is Grass

File naming I usually do like this: GameName_XX_Name_of_File. Where:

• GameName is the name of the game – or an abbreviation
• XX is a number, starting at 01 for the instructions
• Name_of_File is the name of a file, such as a character name or “Setting”

The instructions file is file 01 because that’s the first thing I want the GM to read. It introduces the game and explains how everything works. More on instructions below.

The setting and background file is (for me), normally file 02. It contains the overall setting and probably a cast list. It’s the pre-game stuff I will send out when I’m advertising the game.

Individual files for each character. These are individual files so they can be easily emailed to players in advance. If you don’t expect your GMs to do that, you can put all the characters in a single document.

I might have separate files for cards, name badges, contingencies or handouts, depending on how complex the game is. (If the game is relatively straightforward, I will put these in the instructions file.)

At Freeform Games, we have a separate summary file of key things for the host (so the timetable and answers to key questions) that can be used to run the game on the day (rather than the much longer instructions file). But I’ve not done that for other games.

One thing that’s been brought to my attention recently is that if someone is using a print service, it’s worth keeping stuff that needs printing single-sided in different files from anything printed double-sided. (That’s not something I’ve thought about before.)

Fonts and layout

Fonts: I use fonts from https://fonts.google.com/ as they have a good range and don’t have any copyright or licensing issues. I like EB Garamond as a body font, and then I use something suitable for headers.

Justified or ragged right: I find ragged right (ie, text aligned left, like this blog post) easier to read and looks better if you use Word to prepare your files. (If you know what you’re doing, then go for justified text. If you don’t know what I mean by “if you know what you’re doing,” then stick with ragged right.) 

Line length: The ideal line length is 50-70 characters. Long lines are harder to read, as are short ones.

One column or two: That’s personal preference, and you may find the line length and paper size dictate your options. 

Font size: As I age, I usually prefer a larger font that is easier on my eyes. I usually use EB Garamond at 14 points for body text. Or even bigger if I expect character sheets to be printed at two pages to a single sheet.

Page numbers: I put the file name and page number in the footer on each page. (Such as “Instructions page 1 of 12”.)

And use “curly quotes/apostrophes” (like these) rather than straight quotes or apostrophes.

Consistency and proofreading

If several authors contributed to your game, they almost certainly have different writing styles. Some might be verbose, others terse. Maybe someone types two spaces after a full stop, while others don’t. Maybe there are spelling differences, such as realize/realise (and many, many more.) Perhaps one person writes in active tense and others write in the passive tense. These differences all stand out.

I recommend that one person give everything a final polish, and they also arrange for a proofread by someone who hasn’t read the game before.

(Apps can help - I use Wordrake, Grammarly and PerfectIt. They’re not free, and you have to learn how to interpret them rather than follow them blindly, but they’re a great start and highlight things to look at.)

Instructions

What are you including in your instructions file? This is important - if GMs can’t follow it, they can’t run your game. This is how I structure mine:

• Intro: A brief introduction explaining the game in broad principles. This is an elevator pitch, including how long the game is likely to take and how many players and GMs are needed.
• Contents: A list of all the files that come with the game and a brief description of what’s in each. (For example: “AFiG_02_Setting – the setting and cast list for All Flesh is Grass. I also use this as pre-game publicity.”)
• Printing and preparation: What needs printing and preparing for the game.
• Casting: How to cast the game, including optional characters, if any. (This may need its own files or an appendix if you have casting forms or casting is complicated.)
• Venue: notes about the venue or game space – what does the game need?
• Game timetable: The timetable for the game, first in summary (perhaps as a table) and then each section in detail, finishing with how the game ends and debriefing.
• Rules: Talk about any game rules or mechanics - such as contingencies.
• Plots: Talk about specific plots – particularly details the GM needs to know. Give the GM an overview of what’s going on; don’t force them to read through all the characters to figure out what’s going on.

Other points

Try to make things easy for whoever is running your game. Remember, they’ve never seen it before – and they don’t know the game the way you do.

Make things easy to print. Group sections together where possible to make it easier to manage.

If your game has many handouts, make sure they are identified at the top of the page so they are easy to find during play.

A nice cover helps your game stand out. (I’m not an expert at this - I mostly just fumble around a bit.)

Publishing

If you’ve done all that and everything is ready, the next stage is deciding where to host your files. Broadly, four options.

Your own website: This is the easiest, if you have one. If you don’t have server space on your website, you can always link to a shared file on Google Drive or Dropbox or whatever.

Larp libraries: There are a couple of larp libraries keen to host your files. They include larplibrary.org and https://alexandria.dk/en/ 

Itch.io: I find Itch.io easy to use but there’s so much on there that it’s hard to stand out. My Itch.io page is here: https://stevehatherley.itch.io/

DriveThruRPG: The best source for all things RPG online – but there’s so much on it. You can also get your game published in hard copy, but you need to know what you’re doing. DriveThruRPG has stricter rules than Itch.io. I haven’t put any larps onto DriveThruRPG – just some tabletop RPG stuff and my Writing Freeform Larps book. My DriveThruRPG page is here: https://preview.drivethrurpg.com/en/publisher/21683/steve-hatherley 

Getting the word out

Then get the word out. This is something I’m not so good at…

Pardners

For the Once Upon a Time in Tombstone freeform larp, we created a mechanic for non-romantic relationships. We called it Pardners, and this is how it worked.

Pardners

Butch and Sundance. Wyatt Earp and Doc Holliday. The Lone Ranger and Tonto. They’re more than friends – they stick with you through thick and thin. They’re people you can rely on. We call them Pardners.

Pardners help each other out and come to each other’s aid in times of hardship. A Pardner won’t let you down. A Pardner will help you achieve your objectives, as you will help them achieve theirs.

Everyone has at least one Pardner ability card. You can’t use your own Pardner ability – you must exchange it with someone else. You’re now Pardners!

It’s up to you whom you choose as your Pardner, but we recommend waiting for a suitably dramatic moment before offering to become Pardners with someone. Perhaps they have intervened in a fight to help you, loaned you a poker stake, or even just bought you a whisky.

A Pardnership may be broken at any time – just return the Pardner ability and ask for your own back. It must be returned immediately. However, you should only break a Pardnership with good reason, and don’t be surprised if your ex-Pardner holds a grudge.

If you break a Pardnership, you must give your ex-Pardner a reason why. Then, act out the breaking of the pardnership – preferably in front of other people.

Romance between two Pardners automatically supersedes, and breaks, the Pardnership. Return each other’s Pardner ability cards.

Pardner abilities

Each character then had a special ability that they gave to their Pardner. Some examples:

Bill Cobb's Pardner: Bill Cobb's reputation extends to his friends. Whoever has this ability may not be arrested for any reason, provided Bill Cobb is still Sheriff.

Jessica Drummond's Pardner: Jessica Drummond's pardner may use this card instead of tearing up or checking off one of his/her abilities.

Johnny Ringo’s Pardner: Play at the start of combat. If Johnny Ringo is in the gunfight, add +1 to your Accuracy. If Johnny is not present, subtract 1 from all your opponents' Speeds (they need to watch their backs...)

Kit Shelleen’s Pardner: When competing against somebody with a cut of the cards, one use of this ability will make your 'cut' exactly one rank higher than theirs. You cannot use this ability to beat an Ace.

About Once Upon a Time in Tombstone

Once Upon a Time in Tombstone is a weekend-long freeform for 60+ players. It’s based on various Westerns, including Tombstone (of course), Silverado, The Big Country, Maverick, Pale Rider, The Good, the Bad and the Ugly, and many, many more.

I co-wrote Once Upon a Time in Tombstone with Heidi Kaye, Tony Mitton, AJ Smith and Paul Snow. 

I’ve written about it here.