Trying to improve my rule writing

Part of the journey of learning to be a better game designer is learning to be a better writer of rules.  This is something that is absolutely critical as, for most game groups, somebody has to learn how to play the game from written rules before teaching it to everyone else.  For many games, the rulebook also needs to be able to answer questions when some issue comes up in play.  This is all a very specific form of technical writing, and it's hard.

[Image stolen from Dan Brady on Flickr]

My experience so far is limited, but I am moving along.  The one tabletop game rulebook I have presented to the world as "finished" (I Know An Old Woman) has already received feedback helping me to locate more places where things are unclear -- and this is a very simple game, which just goes to show how far I have yet to go.  I have also helped with proofreading rules for other designers (helping to build up my ability to spot problems) and am in the process of helping rewrite a translation of the rules of a foreign language game.

I figure that one of the best ways of getting experience and building my skills is to just get out and help people out.  There is only so much time each week, but I can fit some work on other people's projects in between my own.  It isn't hard to find this sort of work on a voluntary basis: the forums on Board Game Geek, for example, regularly have people requesting help with various aspects of their games, including the rules.

It has been nice to see a number of blog posts, videos and the like turning up recently on the Internet with advice of rulebook writing.  The advice doesn't always agree, for example, Matthew Gravelyn wrote on his Designing Cardboard blog about writing concise rules, and then a month later,  Lewis Pulsipher released a short talk entitled "Too-Concise Rules Can Become Incomplete or Incomprehensible".

Of course, these two aren't really disagreeing: Gravelyn is aiming to cut out useless text, while Pulsipher is warning against cutting out too much, as you may impede understanding.  Basically, the acceptable length and complexity of game rules depends on your target audience.  In the end, you need to test the effectiveness of your rules.

A really great resource is a discussion from the Metatopia game design convention, featuring Geoff Engelstein (of Space Cadets and the Ludology podcast) and Gil Hova (of Battle Merchants and the Breaking Into Boardgames podcast).  This is almost an hour of solid gold with a lot of good advice, but I think one of the most interesting parts of the discussion is about how rulebooks need to meet two mutually-encumbering objectives: to provide a tutorial for the game and a reference for once you have learnt the basics.  The big take-away though is that writing rulebooks is hard and even very experienced people get it wrong.

A little more in-your-face is a talk given by Mike Selinker (of... almost everywhere) at  PAX Dev, where he gives 10 rules (well, 11) for writing rules, with examples of a whole heap of traps you can easily fall into and how you can keep out of them.  The talk is based on an essay he wrote in The Kobold Guide to Board Game Design, which is a book full of useful advice from a great many knowledgeable people.  The majority of Selinker's rules can, I think, be summed up by "don't try to be too clever."

From all this stuff along with other sources, plus my own meagre experience, I am starting to build my own principles that I will try to use to guide my rulebook writing.  The top of my list is currently as follows:

• State, in general terms, how to win the game right at the start of the rules. Details can come later, but the general idea needs to be there before anything else is explained in order to give context for everything that follows.
• Closely connected to this, the rulebook needs to convey some level-zero heuristics.  This is a slightly technical term (see Characteristics of Games for plenty of discussion on heuristics), but basically I mean that on reading the rules, the players need to have a general idea about what they need to do to play the game and have a chance of doing OK.  If the players start with no idea of what to do, that is a failure of the rules.
• Keep the language simple and consistent.  It may be necessary to define special terms, but do so sparingly and be really careful to stick to those definitions.  
• Don't be afraid to repeat yourself in the rules in order to make sure that information is in appropriate places, but remember that if a rule is repeated, this adds an overhead for editing as a change in one place means checking everywhere else.
• Proofreading is necessary but not sufficient.  A proofreader may decide that the rules read just fine, but someone trying to learn and play the game from the written rules may still have all manner of problems.  Blind playtesting the rules is essential.

Defence against the horde...

I've been doing this game design thing enough now that I am starting to get the "problem" of unbidden ideas taking over my head for a while.  For the last couple of days it has been for a card game that wouldn't go away until I created a prototype.  What happens next, I don't know.

To step back a bit, some time ago I was thinking about the very enjoyable Sherlock Holmes the Card Game, which I used to play quite regularly and features a nice mechanism where each card specifies what types of card can follow it, allowing a pleasing (though occasionally silly) narrative to develop.  So, while in the country, Holmes may find a clue, which leads to suspicion of one of the players, who has an alibi, after which Holmes is compelled to catch a train back to London.  The rules can be explained quickly (though the end of round scoring can take some work!) 

Alone against the monster horde. Luckily this wandering mystic has come to my aid.

I was trying to think of a way to play with this basic mechanism to come up with a game that built a narrative of a conflict between opposing forces, ideally where players are at least mostly on one side, but possibly with one (or more) of them taking the role of either an adversary or a traitor.  This never really developed very far; I had a very basic attempt, which mostly worked, but wasn't really interesting enough and relied too much on the game that provided the inspiration.

Months passed and then this weekend, for some reason, I started thinking about the concept again.  What got me moving again was some looking at the wonderful website, game-icons.net, which does pretty much what it says on the tin, and deciding that the card types could be labelled with icons representing different parts of the story (characters, events, actions and so on) and each could allow for a small number of other types of card (by icon) to be played next.  So far this just changed the representation of a concept: text in Sherlock Holmes is turned into graphics in my game, which is no change at all, really, but sorting through some candidate icons the ideas started flowing.

The game would be about the players helping to defend a village from an invading army of monsters.  I was trying to come up with victory conditions for a competitive game, but eventually thought that the setting lends itself to being cooperative, and that is a style of game that I haven't yet tried designing (or, for that matter, solitaire).  Eventually I came to the idea of having a "threat level", which would be increased by some cards and reduced by others.  This still didn't seem enough, so I also had a magical "power level", which could be increased to allow magical defences to come into play.

Usually I would rough out a prototype with pens and bits of card, but I was confident enough of the most basic functioning here that I turned to some very basic nanDeck coding plus the icon assets I had downloaded, worked out a basic selection of cards, and soon had printed out a small deck of 36 cards to play with. 

By this point I had thought of a couple of ways for players to lose the game -- if the threat level reaches 10, or the deck of cards run out -- but I hadn't really figured out how to win.  Never mind, start playing anyway...

By half the way through my first solitaire test, I had figured out the main win/lose conditions: if the threat reaches 10 you lose, as previously planned, but to win you need to work through the deck and then get the threat level to 0 with whatever cards are left over, otherwise you lose.  Also, if you are unable to play a card you add a threat and draw an additional card.

This seemed to work. I lost my first three games in a row and found some frustrating points where there were no playable cards for some time, which was largely due to the icons on the cards not meshing with each other properly.  A small change or two with a pen and I won a couple of games.  Yeah, balancing this is going to be difficult, but at least there is the option of having selectable difficulty levels thanks to varying hand size, starting threat level, and so on.

Now the game is out of my head and in a tangible form that makes me think I might like to keep working on this.  I definitely need to think through the card mix carefully if we're going to progress, and one problem I've noticed is that on many turns there are no real choices to make: you just have to play the card that fits.  OK, so every few turns there can be really interesting decisions, but the rest can be scripted.  That seriously needs to change.

Much still to do...

How do you treat playtesters?

I've been thinking recently how to recruit and retain people who are willing to test my games.  I have a handful of people local to me who are willing to help out, and am working on developing this group (see my previous post), and in the long term this will involve making sure I keep the playtest sessions fun for everyone so they remain engaged and willing to pitch in.  This is a big responsibility as people are freely offering their time and I mustn't forget that.  I could probably do with multiple groups, but I think this may prove even more of a challenge given all sorts of life constraints.  In fact, it took me quite an effort of willpower to bring myself to actually ask for help and make arrangements for a playtesting session.  I'm not the sort of person that is very good at this sort of thing.  It is probably a learned skill though and I have taken an early step.

Early playtesters check that they have the rules right.
(Image source: Wikipedia.org)

Alternatively I could recruit playtesters online.  This can be even more tricky: not only do I need to have the game developed further than I might need for a local playtest (it needs to have coherent written rules and components that can either be printed out or plundered from elsewhere), but I am also competing against all the other games they could be playing and it is harder to bring my sunny personality into play in order to persuade them to play.  I am asking people to go quite a long way out of their way to assemble and play my game, so I have some work to do.

But there is a community out there, and it is possible to attract the attention of people who might be willing to try my games for me.

I manage to playtest games for other people less often than I would like, but I have a go from time to time, and it can certainly be fun: often the games are good in their own right, but it is also interesting to see other designers at work, learn something more about the design and testing process and, possibly, to see an early form of a game that might turn up at the local games shop some time down the line.

There was one game I printed out the playtest materials for and tried out with a friend.  The game was essentially pretty solid, but we felt the rules had some holes in them and didn't explain some of the basic principles properly.  I reported back a guarded thumbs-up along with a few points where things felt awkward or we didn't understand the rules properly.  The reply I received back seemed quite blunt and pointed out that we had done something wrong and should have done it differently.  To be honest, feeling that I have been told off for not being clever enough has not disposed me to playtesting other games for this designer.

Another experience involved reporting on a couple of two-player runs of a game and reporting back that we liked the game, along with some basic statistics about the plays and a few other points that we felt were worth raising.  The response from this didn't include the word "thanks", but did include a request that we play the game again with different player counts.  This reply was polite enough, but just left me feeling that I was being taken for granted.

On the other hand, some designers fall over themselves to be appreciative.  I remember one in particular who wrote back, offering warm thanks an addressing each item in a list of points I had made, including one point that was replied to along the lines of, "You misunderstood that rule, it is meant to be XYZ, but I'll make sure I make that much clearer in the next version of the rules."

So the main point of this post is a note to myself to remember that if I want people to test my games I need to treat them like valued and appreciated members of the team, and ensure that they know that I am grateful for their contributions.  If they have been blunt in their feedback, I have to take it all as good information and still stay thanks.  After all, I need to nurture any sources of help I manage to get.

And no, I'm not going to name names.