Articles Analysis Knowledge Transfer
 

Knowledge Transfer Knowledge Transfer Hot

Image_0_Cool_Hand_LukeOne evening last month I sat down to a first session with a game I had been really been looking forward to. My goal: get two turns in. I wasn't planning to play a whole game; I wasn't even planning for two correct turns. I was planning for two turns with a bunch of take-backs and oopsies and lessons learned so I could beat my understanding of the game into shape. That way when I sat down to it the second time, I'd be all ready to go. I love this part of gaming.

I'll revise that -- I often love this part of gaming.

In the past I've had some magical moments.  Valor & Victory, Arkham Horror, Warriors of God, Ghost Stories . . . when things are working I slow my reading down to extend the fun.  Discovering a new game is like undressing a new girlfriend for the first time.  There's no sense hurrying.

But it became apparent that I wasn't going to get lucky.  The rulebook was a mess.  I tried to skip over the vague and confusing parts, hoping that material that followed would provide context, but it didn't . . . three pages forward, two pages back, no clear core concepts . . . after an hour I dropped the instructions onto the board and assessed: I wasn't trying to figure out the game anymore.  I was trying to figure out the rulebook.  Then I assessed if it was worth the hassle at all. Because that's what it was, a hassle.  I hate this part of gaming.

I know I know, I sound like a petulant child that didn't get his cookie.  But I do this for a living.  I write (and read) software manuals that manage excruciating levels of detail.  In theory I'm a software engineer but in reality I spend the bulk of my work hours communicating with customers and technical staff, acting as a translator between the two.  As the primary architect my writing needs to do two things well -- inform, and persuade.  The "inform" part is pretty obvious since that's what design documents are for.  But the "persuade" part is often more important, because if someone isn't on board with the fundamental concepts being described they're going to balk, and the project is going to fail.  So that is the soul of my job. I explain; I enable; I comfort.  I persuade.  That's my job.

So petulant child is pretty apt.  I'm a short-tempered SOB when I sit down with a game rulebook because it's likely the fourth or fifth technical doc I've dealt with that day and I'm not getting paid to read it this time.  It's not my job to figure out a game from cryptic clues.  If it's a hassle I may as well spend the next two hours billing a customer for reading their doc instead.

This is the baggage I bring to the table when I open a rule book for the first time.  I want to figure out gameplay not documentation.  I'm not alone -- whether you realize it or not each of you feels this way to one degree or another.  What I've learned from writing tech docs for the last nineteen years is this -- nobody wants to figure out my doc.  If I can't get their head off of the text and into the concepts, I'm gonna pay for it.

With that in mind, let's talk about your rulebook.

(Ok, the complaining part is done.  From here on in it's recommendation and observation, so if you don't want to hear me lecture this is a good place to stop.)

Let's pretend you've written a game.  THE game. The next Settlers, the next Imperium, the next Hannibal is on the table in all its glory, ready to be packaged up and sent away for a big ol' production run.  I'm going to boil its contents into these four basic categories -- bits, box, board, and knowledge.  Guess which one I think matters most.

The bits to your game can be replaced in five minutes with an old playing card and a ball-point pen.  With scissors you can make it to stand up on its own.  The box -- helps to sell the thing but after that it's useless.  The board has some artistic merit but it too could be replicated with a slice of cardboard and crayons in a pinch.  In fact I'd wager most of you have have futzed a missing part on short notice, caring little at the loss of authenticity or aesthetic value.  Because what you desired most was the knowledge part, the game . . . in this case your game.

The piece that matters most is the knowledge.  This is the conclusion you need to reach before it's too late: the child of your efforts, the true intellectual product born out of your hours of hard work is encapsulated in its rules. That's what your customers come for. If you can't deliver them, the prettiest package in the world isn't going to fix it.

Oh I know -- you're filing the last two sentences in the no-shit-sherlock category, but from what I can tell this is a profound concept to a lot of publishers.  There's plenty of crap rulebooks out there. They come out with spelling errors, typos (including some really glaring ones), examples and images that don't adhere to the rules they're supposed to describe, confusing terminology, the works, all printed on super-gloss paper in custom font with kick-ass art wrapped around it.  This isn't printing error.  This is mental error.  This is lazy error.  This is labor-cutting in the last 3% of the development cycle.  This is not touching third base after hitting the ball out of the frikkin' park.

But there's gold out there too, and a quarter-century of engineer training has taught me this important lesson: if something works really well, rip it apart to look at the pieces.  That's what I do when I read rule books.  I evaluate how well they enable my learning and manage my confidence.  When they work it's magic, and I read them again to figure out why.  I get better at my job by reading layman-accessible docs.

So what follows is my advice on how to write a decent technical document.  Take it with a grain of salt -- I write software manuals and architecture descriptions not game instructions, so some of this won't be a perfect fit.  But with any luck discussion will follow and voices with better suited experience will chime in, and one or two of the ideas generated will work their way in before you send your game off to the printer.  That's your deadline and remember, you'll only get one shot at this.  That's rule #1.

 

Rule #1 You Get One Shot At This.

There's a period of time between the shrink wrap tightening and the customer opening your game for the first time.  During this interval you're helpless.  The game is what it is, and once it's out the door it's going to have to get along on its own.  The heart of your game, the printed rules, may as well be cast in stone.  So they have be right the first time.

Look at this from your customer's perspective: they've met you halfway.  They've invested money and are coming to you genuinely eager to learn, ready to dedicate time and energy to establish a working relationship with you.  Notice the language -- I'm not saying a relationship with your game, I'm saying a relationship with you.  The box they bought is an inanimate object.  But that rulebook inside speaks with your voice, so it's your good name on the line.  That customer has extended their hand and come to this moment thinking, "I get to learn this game today!" because in their heart they want a happy experience.  They want this relationship to work.  They've invested money, now they're investing time, and the last thing they want is to look like a chump.  You customer wants your game to work -- that's why they bought it.  First impressions matter, so don't blow this.

The moment your customer finds themself rereading a passage out loud, the moment they wonder why the example on the page doesn't seem to match the paragraph next to it or start paging back and forth to see if there's something they missed, their confidence in you and your game (and often themselves) begins to waver.  They stop trusting your product.  That's a hard error to recover from, so the rules have to be clear and they have to be correct.  Mistakes aren't minor things.  They sow worry and doubt.  Mistakes turn "I get to learn this game today!" into "I gotta manage these issues today" and that is the kiss of death.  The moment worry or doubt appears you've entered into a failure cycle.  Everything that follows will have to work harder.

And don't talk to me about living rules.  Living rules are bullshit.  Don't talk to me about forums or chat groups or player aids that "fix" problems after the product has been delivered, because this isn't just about managing a broken rule.  This is about managing the customer's perception of your product.  If they start thinking they can't depend on the rulebook to be a dependable source of knowledge it's over.  Nobody wants to reprint your corrected rulebook or look up that latest clarification.  Spend the time necessary to get every bit of the rules as clear and as correct and as complete as humanly possible before you publish, because when you boil it all down, that rulebook IS the game.

 

Rule #2 The Rulebook IS The Game.

Bits and cover art sex up a game, but fundamentally board games are about the play, and you need to get "the play" across to end-users.  This isn't just about getting the rules correct, it's about getting the rules right.  There's a difference -- "correct" means not wrong.  "Right" is harder. Right means effective.  Right means successful.  Right means that knowledge transfer dependably occurs between you and the player. "Knowledge transfer" is the fundamental goal of all technical documentation.  Regardless of how well designed your game is in your mind, you're the only person that will get that view of it.  The rest of us will use the rulebook.  It's the last word, the ultimate source of knowledge.  In rule 1 I focused on getting the rules "as clear and as correct and as complete as humanly possible" and if you ignore everything that follows I'll consider it a fair compromise.  But you need approach this effort fully aware that the person reading your document doesn't have the same background you do.  Look at the following excerpt from the rulebook for High Frontier.  This passage hits first-time readers at the top of page one, when they have fifteen seconds of game knowledge under their belt:

Image_1_High_Frontier

The first paragraph contains four metadata definitions.  In theory they make things clearer later in the text.  Phhlt.  In these four sentences brain power that should be focusing on understanding the game is being directed to understanding document structure.  Honestly, if the user can't figure out that easily overlooked rules have a black backdrop, telling them isn't going to help.  That italics thing -- telling them that something is defined elsewhere in the doc but not telling them where -- thanks for the help bud!

What follows right after that is an introductory paragraph that forward-references eight different game concepts! I'm in a unique position to appreciate this because it has the distinct aroma of MIL-STD-498, a technical documentation standard used by the United States Department of Defense to manage complex engineering processes.  I have no doubt the author's employment in the aerospace industry puts him in contact with dozens of documents that look like this or any one of a hundred similar standards, and he has my sympathy.  I'd wager he's structuring his rulebook this way because he sees these concepts everyday -- it's our nature to work to our toolset.  That may not be the case -- he may actually enjoy MIL-STD-498 and if so we should start up a fund, but here's two questions that raise an important issue with this approach:

1. Who's the only person who has any real interest in reading a paragraph entitled "High Frontier Summary"?

Answer -- someone reading the rules for the first time.

 

2. Who's the one person you never ever ever want to bamboozle with metadata, obscure lingo and forward references?

Answer -- someone reading the rules for the first time.

 

All that mumbo-jumbo makes sense if you already know the game, but experienced players will never read that summary again.  A new player will, and when they do the'll say, "holy shit I can't even understand the damn summary" and that's not the frame of mind you want them in when they read what follows.  What I said about "confidence" in rule 1 matters -- you need your reader to be on board.  Rule books need to be precise, but this is introductory material, and at this early point in the text the single most important task is to create a solid foundation for the reader.  Foundation is critical to knowledge transfer, especially in a game with as many conceptually unique features as this one.  Visual cues that tell the reader they're not understanding 40% of the meaning in the game summary isn't just counter-productive, it's . . . well . . . kind of rude.  I'm sure that wasn't the author's intention, but nobody gives a damn about intention.  Rule books are about results.  The purpose of summary passages is to clear complexity out of the way in order to focus on fundamental concepts in the game. An introduction's gross generalizations serve a purpose -- at this point in the rules technical precision needs to take a back seat to establishing foundational concepts in order to grow the new reader's understanding.

Image_2_Twilight_Imperium

Two sentences.  If I had been on tech review for Twilight Imperium I'd have removed the TI acronym definition in the first line (and likely the acronym from the entire rulebook) as well as the "see later" at the end.  "See later" serves no purpose here -- it's the beginning of the rulebook; everything is later.  That said, this summary provides enough technical detail for foundational concepts without bowling over a first-time reader.  Two friends I asked to read this did it without speaking the words out loud or rereading.  Neither lifted nor lowered their eyebrows.  At the end one responded, "ok" and the other "alright", each keeping their eyes on the page as they did so.  They were tuned in.  This passage worked for them.  The two sentences from Twilight Imperium's summary are correct, but they're also right.  They've provided information that effectively moves the reader down the path to understanding.  Details can follow now that core concepts are in place.

(Edit -- Ok, on second proof-read of this article I changed my mind. "See later" is a cue to the first-time reader not to worry about what the term "game-ending condition" means and in that aspect it aids in their confidence.  "Described later" might have been a better choice, but I'll concede that "see later" is a solid addition to the text.  I'm still learning too.)

I'm not talking about compromising correctness; never mislead the reader.  This is about level of detail.  Invite the user into your game by setting the firehose on low for a few minutes.  Later on there will be plenty of opportunity to go into details and no one will complain about having to skip over material they found useful their first time out.  At times you need to specify details with precision, and at times, whether you like it or not, you need to set them aside to focus on basic exposition.  In short, your rulebook needs to speak in two voices.

 

Rule #3 Rulebooks Need to Speak in Two Voices.

Well written rulebooks shift between summary and detail throughout their text.  You might think that readers would find this jarring, but in reality they use less detailed passages as islands of safety, relatively soft patches where they can come up for air and consider the game from a big-picture perspective.  Summary passages simultaneously provide comfort and an understanding of how the smaller pieces fit into the larger whole of your game.  Well written manuals do this throughout the text, using cues to indicate which voice they're speaking in.  It could be a background color, a font, even a simple convention like first paragraph of each section.  But it doesn't even need to be that overt.  Readers figure it out by tone and word-selection only, and for good reason.  It's a natural language concept.  In real life people speak differently when they're providing contextual background.  Their word choice, their voice, their gestures, even their posture, these all change when someone pauses mid-topic to bring an uninformed or confused listener back into understanding.  The next time somebody walks up and continues a discussion you've had previously, interrupt them and ask, "what are we talking about here?" then listen for the change.

Your rulebook, though a static document, needs to be aware of this fundamental knowledge transfer question: are you understanding me? When you presented your game to playtesters or interested buyers you got visual and verbal feedback from them and you reacted to it.  That's not going to be possible from a thousand miles or fifty years away.  Here's something that is possible -- you know the parts of your rules where people have struggled in the past when you've explained the game verbally.  You also know how you fixed the miscommunication.  Figure out how you provided background context to get the user up to speed and get that into the doc.  That change of verbiage worked for you in real life so there's no reason to abandon it in text.

Generally I'll throw crap up onto a page when I'm describing a complex portion of screen or data flow just to get the creative process started.  Then I'll refine it, refine again, but even after that I'll get a twinge on passages that don't seem to have proper footing.  A gut feel, I'm suspicious these passages will fail so I speak them out loud.  That usually tells the tale for me.  I envision stupid looks and I go off script (still verbally here) to try to dig my way out of the box.  That off-script material, the hang-on-let's-back-up-a-minute verbiage that comes out of your mouth when you're explaining your game is important stuff.  It's your second voice.  Don't lose it.  Get it onto the page as you speak.  That's your summary material.

The process of getting your second voice into the rules is important because on its most basic level, your rulebook is you.  It's your voice explaining the game just like you would in person.  For all intents and purposes your rulebook is a carefully worded speech.

 

Rule #4 Rulebooks Are Like A Carefully Worded Speech.

I said it above, your rulebook is your voice.  It's your opportunity to sit down in the living room of a person that's giving your game a chance.  You need to explain.  You need to find a way to reach them.  Remember -- they're not you, so be sure to cover the stuff you take for granted.  Basics, detail, review.

The most common (and remarkably cutesy) recommendation you'll hear from speech teachers is this: tell them what you're going to tell them, tell them, then tell them what you told them. This tell-them-three-times strategy is sage advice whenever even small amounts of complexity come into the picture.

Image_3_Warriors_Of_God_5In section 5 of the Warriors of God rulebook the title and first three sentences set the stage for the overall concept of "initiative" in the game.  They announce the concept being discussed, describe the action, then summarize the result of it.  That's the first tell.  Initiative in WofG has a little complication, so those details are described in the five simple sentences that follow, each getting its own moment in the sun.  Those are tell #2.  Following that (and closing out the Initiative section of the rules) is an example describing how the rules play out for one particular implementation, tell #3.  Each of these three tells is key to understanding, and each provides a different service to the reader.

The first is the anchor -- it's the piece that provides a preparatory foundation of the concept for first-time readers, and also serves to quickly describe the section so it can be found when flipping through the rules for clarification mid-game.

The second part is lawyerville.  While the first part is intentionally vague so as to not contradict what follows, part two is designed to carefully paint all the corners of the initiative space in clear detail.  It handles the general case, it handles the exceptional cases, it handles all the potential initiative use-cases presented by gameplay and does so in unambiguous, pocket-sized sentences.  In this particular example it breaks the case of "a tie" apart from "a tie on turn one" because they're different.  They could have been combined and I personally would have been tempted to do so, but each having a separate sentence makes it very clear when to apply each, and cleanly separates them in case someone tries to get picky.  Experienced players will key on this middle part where the detail lies.

The third part is sanity check.  The example in the last sentence comes back again to speak to the first-time reader, building their confidence and providing a check-bit to the concepts that have been presented.  This isn't just about clarity -- you're managing the readers comfort level and confidence.  This is the question and answer period that you'd provide if you were there in person.  Since you're not, you need to play both roles, asking a question that's likely to reinforce understanding and allowing the end-user to see their interpretation of parts 1 and 2 come up with the same answer as yours.  That "got it" moment allows them to move on with confidence.

In Warriors of God's case the tell-them-three-times strategy is utilized in three different ways.  The second can be seen in the opening sentences of Section 6.0, the section that follows the Initiative rules displayed above:

Image_4_Warriors_Of_God_6

 

Section five focused on Initiative but made reference to action impulses.  In this section that follows the concept of Initiative is reinforced by indicating what it's used for, and the concept of action impulses takes center stage.  Each section is providing support for the section on either side of it, building the concepts into the unified package.

 

This unity is supported further by a more global use of the tell-them-three-times concept: an overall order of operations early in the rules that offers the grand scheme of play, the broad brush stokes that reveal the overall narrative:

Image_5_Warriors_Of_God_Seq_Of_Play

This is tell #1 for the entire rule book.  Each phase listed has a corresponding section in the rules (tell #2) and examples follow.  This "Abbreviated Sequence of Play" serves no useful purpose from a technical perspective.  There's nothing there, no rules.  No one is going to look to it for clarification of a situation during play, but that's alright.  It's groundwork, tell-them-what-you're-going-to-tell-them.  It's foundational material that provides a roadmap to the players.

Wargamers are going to look at this and yawn.  They've seen it a hundred times.  In that part of the industry managing a complex ruleset has been critical for forty years, and the cultural tools they've developed to address it seem natural to their user base.  But modern eurogame publishers seem obsessed with minimizing rule book length.  Is this out of fear that long rules may scare new people away?  If you want to scare someone away write short, precise, "orthogonal" rules in curt sentences.  Length presented in layers that gradually ramps into the complexity is comforting, and everyone understands how skipping ahead works.

Let's look at Ingenious.  There's about three rules to this game.  Is a long rulebook needed for something this simple?  There aren't enough rules to make it long.  But in comparison to the number of core concepts in the game, the rulebook is verbose . . .

Image_6_Ingenious_Page_1

 

 

 

 

 

 

 

 

 

. . . and utilizes tell-them-three-times pretty well.  The overview section you see on page one is a bit dense for my tastes but approachable, and provides a grand review of virtually the entire play with relatively simple language.

 

Image_7_Ingenious_Page_2

 

Ingenious has a problem with its core concept (i.e., an exceptional game state requiring a special rule) which is addressed in a section that follows the other rules in detail, and finally play examples show how both the board and scoring tracks function.  (The rule set is available in its full-size glory on the publisher's website here -- http://new.fantasyflightgames.com/ffg_content/Ingenious/ingenious.pdf)  Are the rules long?  No, but comparatively yes, and I don't think anyone is balking a game of Ingenious because you have to turn the page over.  Most simple games can get away with two or three full-sized pages provided they present the material in a comfortable way.  If a reader is drawn in by the first three sentences he'll continue into the nitty gritty.  Though it may look inviting to condense everything onto one side of a piece of paper, that mindset is asking for trouble.  When you start making writing decisions based on the space you want to fit into you've set inappropriate goals.  You'll likely achieve them.

More complex titles will be less forgiving, but no one is stepping into a big game looking for "short".  They're looking for "good" and more than a few guys I've played take perverse joy in the size of a ruleset.  Though newbies may be intimidated by size hobby gamers are only interested in the text's ability to teach and confirm, not its ability to get done quickly.  If someone has spent $50+ for a game they're going to read slowly to get their money's worth.  Give them their money's worth.  This isn't an elevator pitch.  Take the time to really tell your story.

 

Rule #5 Rulebooks Are Like A Story.

At 24 pages Arkham Horror's rule book is big for good reason -- it has a big job to do.  As much story as game, "Arkham" needs to have a lot of moving parts in order to keep interest in the story it weaves.  The rulebook is along for the ride.  Story indeed -- that "sequence of play" concept we saw for Warriors of God above exists in Arkham's rulebook as well, but it has so many steps that the writers chose not to present it in one go -- there's no master action summary in the rules.  Instead they nested steps within steps to reduce complexity for early readers.  Yes boys and girls, there's only five phases in Arkham Horror.  But -- each phase has multiple sub-phases.

Five is a magic number.  Psychologists tell us we're generally capable of handling about five conceptual items simultaneously, and the general rule in technical writing (and architectural design for that matter) is 5 plus or minus 2.  That is, when breaking a concept into parts it's best to use somewhere between three and seven pieces so that the reader can wrap their head around all of them simultaneously.  Any more than seven and pieces start getting dropped on the floor.

A lot of games push that limit including Warriors of God above.  They invariably depend on quick-refs or markers on board tracks to assist the user's memory.  Arkham's sequence of play is WAY bigger than that, and the rulebook has to manage all the complexity that goes with it.

But oh what a rulebook it is, and I'll tell you the secret to its success: "just turn the page". After your first read through you can play the overwhelming majority of the game with three turns of the page -- three turns of the page describe one turn of the game.

Image_8_Arkham_8-9

FFG's decision to three-column their text on wide pages means that virtually the entire sequence of play fits on seven story-telling pages, giving new players a personal assistant to manage complexity in their early turns.  In spite of a LOT going on I had pieces on the board before I had finished reading the rule book for the first time.

There's complexity, but there's also story arc, and I'm not just talking about the game.  Arkham's rules tell their own story, doing it with structure and continuity that give the player footing in the game's current state and minimize the need to search.  Rules appear as they are needed, so new players can follow along with their finger as they proceed through the turn.  Seasoned players can locate rules easily because their understanding of the game narrative gives them understanding of the rule book.  Arkham lends itself well to this concept better than most but even games with a more unstructured thread of play do well when they use a substantial section of their ruleset to describe action sequence and an example turn.

The idea of having just-in-time-rules (i.e., rules that proceed in the same order as the gameplay) may seem an obvious choice, but it's often ignored.  Recent reading brought me to a Sequence of Play (in section 4) that instructed me to move my piece (section 6) then perform an action (section 5).  The ordering meant I had to keep back-paging.  Others place charts and tables on the back cover of the rule book and then cross-reference them on other pages, forcing new users to break mental focus as they locate the table in question.  That's the issue here -- mental focus.  When we finish a page and turn to the top of the next we do it without blinking.  Our mind stays focused on the content because the transition requires no thought.  But the moment we have to pick something out in a non-linear fashion (i.e., undertake a new mental task to search) we lose frame of reference.  We come up for air at a moment that may be detrimental to learning.  Keeping text in a single flow lets the reader keep their head in the game.  This applies to widgets too -- a summary page of all the tables and charts is nice . . . for seasoned players.  But printing those tables inline next to their associated rules is better for new players, and both reader types need to be taken care of.  Remember -- two voices.  Don't break story to save fourteen cents on the publish price -- if your action is complicated, include tables and charts mid-text AND provide a quick-reference page showing all of them in one place.  Too much?  When in doubt, inline. To this day I can tell you the pages where to-hit charts and saving throws were located in the original Dungeon Master's Guide, a book I haven't opened since 1985.  Hell, I could find them in a copy today by riffling the pages.  They were summarized in the back as well, but I never used them there.  I first learned them embedded in the text and that's where I've permanently filed them in my intellectual concept of the game.

Arkham Horror's rules manage more than play sequence.  They also manage state -- the current condition of each spot on the board has an effect on the actions taken each turn.  If this is sounding like it might be complicated you're right.  Arkham's nesting of action and state generally goes two levels deep, sometimes four levels deep and often needs to manage exceptions within that four-level stack. This game shouldn't exist.  But Arkham's verbose rulebook takes the time to break everything into bite-size pieces and presents them in a just-in-time fashion.  When you get to the point in the game where a rule comes into play it's likely on the page already opened in front of you, maybe under your index finger.

Image_9_Arkham_Phase_V

Image_10_Arkham_Phase_V_Part_C

"The Doom Track Advances" section shown above is nested within a state, which is nested within an action, which is nested within a phase.  Four levels deeps sounds unmanageable, but when seen within the greater story arc of the rulebook it has context.  It works, especially since all the material needed for each part of the play is nested in the text and on a single page.  The only cross-reference appearing here refers to "The Ancient One Awakens!" -- the cataclysmic event that triggers end-game and signals an exit from the story told on pages 6-12.

Arkham Horror manages complexity by walking you through the game in the same way you play it, and by using all the explanation and examples it needs to get the job done.  The rulebook obeys rule 4's tell-them-three times rule with phase summaries, detailed descriptions and good, clear examples to reinforce learning.  Is it long?  Yep.  Is it hard to read?  Not a bit.  The fundamental requirement for rulebooks -- knowledge transfer -- is in full bloom and, considering the amount of complexity required for the game, it's designed to be open on the table for your first dozen plays.  Arkham is a pleasure for new players.  They may not like the game, but they understand it.  When someone asks a question the guy with the book can generally read the passage from the page that's currently open and quote a matching example if need be.

(Edit -- my recollections of my introduction to Arkham Horror, a solo session with pieces on the board as I proceeded through my first read, include an issue with the description of the portals action.  Passage through portals was not firmly embedded in my core understanding on first play -- two turns or three to pass through?  One in each spot and one to step out, or hit the two spots and you're done?  To this day it's the rule that "sticks out" to me and doesn't feel a part of the whole.  I still look it up.  Given the size of the ruleset this is a very minor quibble, but an indication of what happens when someone is less sure of one aspect of your game.  It becomes a liability to them, a point of misconfidence, and in my case something I still think about years later.  That doesn't do your game any favors.)

When rulebooks are a pleasure, people want to give the game a fair shot, maybe two.  They want to give it the time it needs to come alive.  They want to get on the Internet and talk about playing not ask about how to.

 

Rule #6 Your Rulebook Controls the Message.

Twenty-five years ago an incomplete or poorly worded rule book meant each purchaser had no choice but to grit their teeth and make a decision on how to play.  They would figure out what they thought was the most straightforward interpretation that would match the spirit of the game.  The acronym COWTRA -- "concentrate on what the rules allow" was an admonishment not to interpret a game away from its core concept, not to read things into the play that weren't written on the page.  These days that isolation is gone.  Players contact the developer directly by email to complain about inconsistent verb tense.  It's not uncommon to see someone open an Internet thread with the phrase "I'm playing right now . . ." hoping for an answer before they continue their game.  And you know what?  They get one, and often it's from a complete screwball.  "Gee Tom, nothing in the rules says you can't float your Panzers across the Volga, so technically I don't see why you need to use the bridge."

Image_11_Memoir

You want to inspire confidence in the quality of your game?  Take the time to get the part of the package your players will reach for first right.  I didn't say correct, correct is easy.  I said right. Don't just get the wording smithed up -- get the framing right, get the numbering right, get the examples right, get the figures right.  Cover the little details.  Provide a way for rules lawyers to clearly cite passages that answer stupid questions, because stupid questions are going to come.  There's plenty of stupid people out there and most are loudmouths to boot.  That's ok -- what matters is that someone can respond to them with an unambiguous answer and cite where they found the information.  The information for that response has to come from an authoritative source (preferably one you control) and if a copy of it is available to the person asking all the better.  That means it has to be in the box; it has to be the rules.  The day someone replies to a rules question with, "I heard an interview with the designer and he said . . . " you're toast.  The ultimate authoritative source is the copy of the rules that came in the box.  Taking the time to get it right controls your game's message and gives it the chance it deserves to succeed in spite of the damn Internet.  Build success into the package from day one.

Unfortunately technical writers cost money and pretty much no one wants to pay them anymore.  This is what our more productive world has brought us to.  Text is embedded in visually stunning artwork but content is lacking, incoherent or wrong.  I don't have an answer for that one.  It's likely you'll need to develop writing skills yourself or pretend to be friends with someone who has them already.  Short of a big publisher (i.e., Hasbro size) I'd wager you're on your own for getting the job done.  Get lots of eyes on your drafts and ask for questions.  They'll want to give comments, but tell them to ask questions too.  Questions hold the key.  And remember two voices -- you need both kinds of users to review.  People new to the game will provide very different feedback from comfortable players.

 

Rule #7 Usage Failure Is Product Failure.

In my job I watch people use data screens with the manual open beside them.  It's pretty remarkable how often they misread or misuse something that appears to me to be very straightforward.  When I say I watch them I don't mean I watch what they're doing, I mean I watch them.  I look for the struggle.  I look for the miscue.  I look for the moment when their perception changes from excitement to concern.  THAT is when I look at where they are and what they're doing.  If one person stumbles on a screen it's notable.  If two people stumble, it's wrong.  The screen is wrong.  It may not be broken, but that doesn't mean it's right and if it's not right someone is going to use it incorrectly and the system is going to go into an error state.  Error states suck.  Error states cost money.  Error states occur when two parts of the product aren't working together properly, and the end-users are part of my system every bit as much as the hardware and software I've put on the desk in front of them.

Your end-users are an important part of your game, and I have some bad news for you.  Whether you like it or not the success of your effort is largely going to be measured by whether they succeed, not whether you succeed.  Every piece you deliver needs to work for them.  This one isn't limited to the rulebook.  But they'll complain if a piece is hard to handle or text is too small to read.  Those errors are obvious to them.  Rules are a different story.  Testers will tell you about misspellings and typos, but "usage failure" is harder.  Most users don't even know what it is.  They think they don't understand because the game is really different, or more complex than they're used to, or maybe they think they're just stupid.  People don't like admitting they're stupid.  They keep their mouths shut and continue reading, hoping you don't notice.

You need to notice.  You need to watch people read your rulebook.  You need to bring someone to the table that's never played a hobby game before and see if they can get it right.  You need to count page turns.  You need to see if they read passages out loud or not.  You need to set a radio next to them and notice what page they're on when they turn it off.  That's the page that's too complex.

I appreciate that everyone wants to produce quality.  I also appreciate that parts shipped from China, and price pressures, and deadlines, and a million other bullshit details are pressing on your project from all directions.  Much of that may be beyond your control.  The one piece you may still have ownership of is the rulebook.  That's ok -- the rulebook IS the game.  Spend the time and take some pride.  This is important.  Your grandson may use it to teach his kids someday.

S.

Powered by JReviews
Comments (48)
  • avatarSka_baron

    Look, I swear I'm gonna read this whole thing, but I had to be the first to praise this:

    Quote:
    Discovering a new game is like undressing a new girlfriend for the first time. There's no sense hurrying.

    Barnes, for those ragging on you joining the cult of the new, *this* is your new go-to rejoinder.

    Thanks for the line Sag! Now on to the rest of this beast of an article!

  • avatarChapel

    Does this article have a summary statement?

  • avatarscissors

    There's no sense hurrying.

    Really? First time with a new girlfriend you're gonna take your time undressing her???!! Bo-ring.

    A game, yeah, that makes sense, but new girlfirend? You want to BOTH be throwing off your clothes fast as can be and kicking them into the corner, man. Plenty of time to go slow later. :)

    But yeah, of course I get the point, and now I'll go read the article.


  • avatarehanuise

    That, dear Sagrilarus, is a great article you just wrote!
    If only more publishers could read it, we'd get a lot of better written games rules.
    (And if game authors could read it, publishers would weep* less poring over their prototype rulesbooks.)

    * be it from despair or laugh :P

  • avatarSuperflyTNT

    I read the whole thing, and I wholeheartedly agree, especially from the perspective of a person who at one time wrote technical documentation for engineers in the same vein as you apparently do.

    Now onto my point: You, if you wanted to truly make your mark on the gaming world, should take up the reins as Headless Hollow has done and start creating EASY, ALL-INCLUSIVE rewrites and/or quick references for complex games.

    The last line is the most important: THE RULEBOOK IS THE GAME. For some reason, a lot of publishers don't seem to understand this and think that the shit in the box is the game. In fact, you are correct that without the rules, all that shit in the box is no more than a 2.99 Dollar Store "green army men" playset.

  • avatarSka_baron

    Great, informative article - this is what FAT is for.

  • avatarThirstyMan

    Yes, great article. I agree whole heartedly after slogging through Magic Realm rules. It's maybe one of the only games where the effort is really worth it in terms of the variety of game play.

  • avatarubarose

    I wish we had someone like you at my work. Translating what I do/am doing/have done to management is such a chore. Translating it into "business terms" always requires that I simplify, and when you simplify you always need to lie a little bit, and then that comes back and bites you in the butt.

    And forget about Knowedge Transfer between IT specialists once non-techs get involved and start imposing their requirements on us. We jump through their hoops, and fill out their templates, and then afterwards ignore the useless documents created and just pass sticky notes to each other.

  • avatarKen B.

    Nice f'n work, Sag. Brilliant stuff. Publishers and designers, please read this and take it to heart.

  • avatarSka_baron

    Sagrilarus: The Dad/Boss/SO? you only *wish* you had

  • avatarclockwirk

    Brilliant article, Sag. Personally, I always found the AH rulebook to be kind of frustrating. It is nice that the phases of a turn are laid out simply over the span of a couple pages, but I find it difficult to find any kind of details or exceptions in there. If I need to look up details about a rule, there's potentially like 3 places in the rulebook where it might be. I have the same problem with a lot of Vlaada Chivatl games, but that's mostly because they always try to teach the game in steps of progressive complexity (Simple game -> more complex game -> full game) and it's difficult to find specific rules even if they're explained well once you find them.

  • avatarBullwinkle

    I still haven't learned to play Fields of Fire.

  • avatarDair

    Very good article Sag. I wholeheartedly agree with you. I do think clockwirk makes a good point. AH is great to learn the game from, but mediocre as a reference after that. I think games should include a fantastic reference sheet ala Merchants & Marauders. It has most of the detailed rules you would want to reference mid-game.

  • avatarGary Sax

    Nice post!

  • avatarDr. Mabuse

    Excellent article Sag as usual. It's interesting because I have felt it was my "duty" as a gamer to "fight through" difficult rules. It can't be the game designer's fault, it must be mine for not getting it.

    The game RAN made me seriously question that.

  • avatarJoelCFC25

    Great article. There are some wargame publishers that should literally suspend their operations today and not go back to work until they and all their developers and designers read this and spend a few days reflecting on it.

  • avatarubarose

    The point made about "trust" is very important. Once you find one incorrect sentence in a rule book, it makes you doubt every other sentence in the book. You start wondering if this rule or that rule is actually what is printed, or if maybe they actually meant something else. You can't even "concentrate on what the rules allow," because you wonder if maybe something was left out.

  • avatarNotahandle

    Bet this is going to be about High Frontier.

    "Living rules are bullshit."
    Absolutely. They're a poor excuse. What? Now] they're worried about checking rules errors? Too late.

    "Invite the user into your game by setting the firehose on low for a few minutes."
    When writing rulebooks I think Phil has his permanently set to 'tsunami'.

    Where you talk about rulebooks speaking in two voices, and where people struggled when the designer played the game, isn't this where blindtesting fits in? You know, the part of the process that most boardgame companies do not do. The part that should give the feedback so you know where the rulebook needs work.

    "The acronym COWTRA -- "concentrate on what the rules allow" was an admonishment not to interpret a game away from its core concept, not to read things into the play that weren't written on the page."
    This is exactly what has not happened with High Frontier and the Retooling rule. Someone added a decommission to their interpretation, posted about it, and almost a dozen threads were spawned arguing about it. Apparently it was just as bad on the Yahoo(?) group as well. Now the Living Rules have been changed because of a few vocal TOSsers (and I'm certainly using the word in both senses here), and the game is poorer for it. The original design intent, as confirmed by several posts by Phil and his son, should have been kept. But such is the power of a vocal minority on the dominant game website. But I digress, the COWTRA concept seems long dead and buried, except in the hearts of crusty old wargamers. Though you went on to mention "There's plenty of stupid people out there and most are loudmouths to boot." so maybe I didn't digress so much after all.

    "The day someone replies to a rules question with, "I heard an interview with the designer and he said . . . " you're toast. The ultimate authoritative source is the copy of the rules that came in the box. "
    I tried arguing this with the guy who brings High Frontier to the club. Didn't work, he pulled the 'I'm right' card. Coincidentally, the game didn't get played that night.

    Absolutely a great article, I don't know if it's possible but this one needs to be stickied, it's required reading. You covered the important stuff, and it reminded me of an email conversation that I had with a game designer about rulebooks and usability. He was the author of this game. :)

    I'd like to see more comments about what is it in a rulebook that causes problems, as opposed to the reader. Why did Last Night On Earth get a reputation for a bad rulebook? When it came out I was answering rules queries, and 95% of the time my answer to point to a section in the rulebook. Again, Ghost Stories, I bought the first edition and learnt it from what was included in the box. I didn't feel there was a problem with the rulebook. And thirdly, High Frontier; I learnt it entirely from the rulebook. I didn't read the walkthrough until much later and thought it sucked because of the idiotic jokes. So. Why do I not have the same problems as many others report? I have an excellent memory and view the rulebook as a whole, referring back and forth a lot. I wonder whether that's part of it. And I agree wholeheartedly with mjl1783 in that I think many, many players simply do not RTFM accurately. I mean, if someone tackling High Frontier can read in a decomission step that certainly is NOT mentioned in the rule, what hope is there for accurately reading the rulebooks of shorter games. Throw in the internet making players lazy: why think about COWTRA when they can lazily post a quick question and feel they're entitled to an immediate answer from the designer. Or any answer from someone that appears knowledgeable and authoritative when they say "nothing in the rules says you can't float your Panzers across the Volga".

  • avatardaveroswell

    Excellent article about the writing process Sag.

    I know designers do not always have creative control regarding components; is this also true about written rules? What would a designer do to change a typo in rules he/or she had previously written correctly?

    I would think those types of issues may be part of the reason some designers go to PnP...

  • avatarscissors

    I enjoyed this article and agree one hundred percent. On an off-note, it was your ratings comment on TOS that made me decide not to ever buy High Frontier. This article explains in greater detail good reason - in my book - to avoid it. The more games I play countered with the less time I have as a parent means I as a gamer I am no longer nearly as willing to do all or most of the heavy lifting to learn a game. The rules have to be at least a little reasonable, and if the author doesnt not get it right on the page, in a way that helps, not hinders, its not hitting the table or better yet I wont make the mistake of buying it in the first place.

  • avatarSGT Dave

    I have a handful of games I've never played because I fall asleep everytime I try to read the rulebook. The FFG Marvel Heroes comes to mind. I think every big publisher should start posting demo videos on their site. There are other games I never bought just because there a too many rules to keep track of. There is a certain point for me when the game stops being fun and starts being work. I love it when the rules can be printed on the inside of the box lid.

  • avatarZMan

    Dave:

    I've had experiences where the designer did not catch a rule he/she wrote poorly - sometimes they are too close to a design that they can't fix the rules properly or catch it when the rules are not right.

    Zev

  • avatarHatchling

    Really interesting stuff, Sag.

    I'm glad you used the Warriors of God rulebook as an example of how rules can be well written. Strangely, I've read quite a few gripes about that rulebook on BGG, but I found it a joy to read and my first game was quite fun as a result. I really got a sense that the writer wanted me to understand everything as a first time reader. It felt like the writer was hanging with me, making the odd joke to lighten the mood and provide some encouragement.

    I find it particularly helpful when there is some repetition -- I like your term "sanity check" -- in rulebooks and in difficult texts generally. Circling back to concepts introduced earlier makes them sink in.

    I also very much value streamlined writing in rulebooks. I don't mean cramped, over-dense writing, but writing that has been edited to the point where the sentences are crisp, punchy and maximally effective. There are simple ways to do this (eg having the main clause in the beginning of the sentence rather than buried at the end of a string of subordinate clauses). I find that when writers try to be precise they sometimes end up being overly wordy (an example here is FFG), which replaces one problem with another. The virtue of crisp and punchy writing is that it is memorable. It's also easier to find what you are looking for when you need to look something up.

    Which reminds me: another virtue of good rulebooks is useability during play. Ease of reference is key. Quick reference glossaries, and streamlined player aids, can have a huge impact on the enjoyment of a game. It sure would be great if I didn't have to make player aids all the time -- I've made one for almost every game I own. Good rules-writing is a serious weakness in our hobby.

  • avatarNeonPeon

    Doc, you're almost making me regret my RAN purchase...Ha!

    Sag, awesome article and if I ever actually write up a game rulebook I'll definitely have to look at this again.

    It's a pity so many bad rulebooks get published. Some of the errors you see make you wonder if any blind playtesting was done at all. I recall seeing in some old RPG books numerous times - "see page xx"!

  • avatarubarose
    Quote:
    Why did Last Night On Earth get a reputation for a bad rulebook?

    I wonder if part of that was a trust and confidence issue. Fairly close to the beginning of the LNoE rule book it says something like, if you encounter a situation in the game for which there is no rule, just play in the spirit of the game. I know some people who stopped right there. They felt that this indicated that LNoE was underdeveloped and the publisher/designer was being lazy, and that all the rules needed weren't in the manual.

  • avatarMr. White
    Quote:
    'm glad you used the Warriors of God rulebook as an example of how rules can be well written. Strangely, I've read quite a few gripes about that rulebook on BGG, but I found it a joy to read and my first game was quite fun as a result. I really got a sense that the writer wanted me to understand everything as a first time reader. It felt like the writer was hanging with me, making the odd joke to lighten the mood and provide some encouragement.

    I'm glad this rulebook has been brought up as well. The voice the author uses is fine, but I would have preferred a little history to go along with it. I don't need my wargames to serve as a history class, but give me a little something to put me in the frame of mind of the 100 Years War. It doesn't have to be a chapter, maybe a page or two like Britannia or some side bar stuff like the Columbia Games. I dunno, when I finished reading the WoG rulebook I wasn't inspired to play. Perhaps I'm that shallow, but to me the game felt like an abstract because of this.

  • avatarhotseatgames

    Great and insightful article. I modeled my last rule book after Arkham Horror, listing sections as it did. I felt that it was well laid out, doing its best to organize a hefty ruleset.

  • avatarAncient_of_MuMu
    Quote:

    Sagrilarus: The Dad/Boss/SO? you only *wish* you had


    Now I wish Tom Bosley was my dad (and then Sag is he wasn't available). And Doc Brown was my mad uncle, Jimmy Smits was my partner when I work as a cop, Pat Morita was the weird guy who works in my apartment block ...

  • avatarhotseatgames

    Incidentally, if anyone is bored and would like to proofread the rules for my latest game, send me a message with your email. I'll send you a pdf. And people in the industry have seen it, so don't even think of stealing it. ;)

  • avatarjeb

    I think different players will respond to different rule books in different ways. I don't mean this in a small way, I mean it in a big way. Some people do not learn well from narrative and others learn extremely well from it. For example, I was taught Calculus via narrative (Calculus in Context). It was a living nightmare for me. Others in the class did very well and learned concepts like derivatives and power series in a novel way, while I was adrift. And so with game rules. Some players can deal well with the MIL STD format and others need a sample game laid out before them on page 2, or plenty of historical tidbits woven into the fabric of the rules, as mentioned above.

    The best rules, for me, strike a balance that allows either extreme of learner succeed. I think the Columbia block games do a nice job by having the rules on the inner two columns of the page and the narrative notes on the outside column.

    I also think that really knowing the game is what makes for really well written rules. You don't want to bring in a technical writer in the last week of the dev cycle, you want them breathing in that game for weeks by that point. This brings me to the problems I have with Universal Head's player aids. They are usually as wrong as the original rules, except he manages to cram all the errors onto a single page PDF. I see them as geek gold grabs rather then helpful summaries at times. Compare his player aid for ARKHAM HORROR to Skelly's flowchart. Skelly knows AH. He internalized the rules and put out, for me, the ultimate way to learn the game--a detailed flowchart. The narrative has been totally stripped, perhaps to some folks dismay. The UH player aid is just a wall of text with no meaningful navigation. Heresalltherulesonagreenbackground. It is not helpful, and compared to the oriental rules, much harder to actually try to learn the game from.

    I, also, work in a regulated industry and have a hand in writing SOPs and MANs for complicated processes. It's an art, and it's one that is unappreciated by game publishers at times. Great article, Sag, very thought provoking.

  • avatarclockwirk

    I view the Universal Head stuff as a cheat sheet for when you already know the game. I would never try to learn the game from one of those docs. I don't think that's what they're for.

  • crumbb

    I agree with clockwirk.

    UniversalHead has said that the reason he started doing his rule summaries was for when a game hadn't hit the table in a while. That way he wouldn't have to wade into the rules, he could just get a quick refresher off the card. In other words, they are designed as quick reference for experienced players, not shortcuts to learning the rules.

  • avatarwkover

    The best rules, for me, strike a balance that allows either extreme of learner succeed. I think the Columbia block games do a nice job by having the rules on the inner two columns of the page and the narrative notes on the outside column.

    There aren't always narrative notes in the sidebar to Columbia rulesets, though. There are also rules clarifications - and even NEW rules - in the side column. That can make it tough to hunt down a particular rule, since you don't know whether it's in the main text or the sidebar.

    Also, I'm not sure that Columbia should ever be held up as an example of a model rulebook. Their rulebooks are notoriously vague and incomplete. Key phrases are never defined, core rules concepts aren't properly highlighted (and are often assumed to be understood from previous block games!), extended play examples are never included, etc.

    There's a reason why every Columbia game has a long FAQ - mostly because I wanted to know how to properly play the games that I'd purchased!

  • avatarNotahandle

    ubarose wrote:
    I wonder if part of that was a trust and confidence issue. Fairly close to the beginning of the LNoE rule book it says something like, if you encounter a situation in the game for which there is no rule, just play in the spirit of the game. I know some people who stopped right there. They felt that this indicated that LNoE was underdeveloped and the publisher/designer was being lazy, and that all the rules needed weren't in the manual."
    Were they seasoned gamers? I'd've thought most would see it as an expression of COWTRA. Seems to me that the type of people more likely to stop would be the more casual gamers. But I can see trust and confidence being an issue as this was FFP's first game. Regardless, putting such a comment at the beginning seems a daft move. I think they had a Q&A FAQ at the end, that is where they should have put it.

    Put me in the same camp as clockwirk and crumbb, I always thought the UH playaids were, you know, memory aids, not for learning.

  • avatarMr. White
    Quote:
    There aren't always narrative notes in the sidebar to Columbia rulesets, though. There are also rules clarifications - and even NEW rules - in the side column. That can make it tough to hunt down a particular rule, since you don't know whether it's in the main text or the sidebar.

    Sure, but you know movement rules will all be in the movement section, etc. All rule formats are prone to having ambiguities, but going back to Jeb's post, the structure of Columbia's rules are clear to me in so far as where to find the rules. Their rule sets are very brief and to the point. Almost like an outline. I much prefer this than having to sift through paragraphs to find the rule statements.

  • avatarjeb

    wkover said:

    Quote:
    There aren't always narrative notes in the sidebar to Columbia rulesets, though. There are also rules clarifications - and even NEW rules - in the side column. That can make it tough to hunt down a particular rule, since you don't know whether it's in the main text or the sidebar.

    I have only read the rule for CRUSADER REX and HAMMER OF THE SCOTS. There are rules over there, but they are fleshed out examples, background, corner cases, &c. The rules are on the inside, the niggly shit is in the designer notes column. That satisfies me. A bunch of folks said:

    Quote:
    UH aids are not rules.

    I wasn't saying try to learn the rules of a game from UH player aids--I was saying I don't even find them valuable as player aids. He crams every rule in a 12 page book onto a single sheet of paper, usually without clarifying anything; and often removing the rules from their original context. That's not an aid, it's an obfuscation. I also wanted to call attention to the transformation Skelly wrought with the AH rules. As noted in the blog post, the rules are crafted as a narrative, with inline boxes for examples and clarification. Skelly flipped it around and broke the narrative into the flow of decisions and outcomes from them laid out spatially.

  • avatarInfinityMax

    I'm bookmarking this. It's fucking brilliant.

  • avatarubarose

    It really is brilliant isn't it. I've read it three times already.

  • avatariguanaDitty

    Just as a counterpoint, I find Skelly's flowcharts crazy confusing, and UH's summaries very useful. But then, flowcharts of any kind usually give me a headache.

  • avatarclockwirk

    Jeb-

    Quote:
    I wasn't saying try to learn the rules of a game from UH player aids

    Jeb-

    Quote:
    It is not helpful, and compared to the oriental rules, much harder to actually try to learn the game from.

    Sure sounds like it. Okay, I'll stop being shallow and pedantic now. :)

  • avatardaveroswell

    Jeb mentions Columbia block games writing good rules; does anyone know of a designer known for very clear and concise rulebooks?

  • avatarSagrilarus


    Thank you all for the kind words.

    S.

  • avatarSagrilarus


    Alright, generally I like to stay out of the conversation for the first 48 hours or so to give people a chance to have their say. In theory if I wrote in complete sentences the text should stand on its own fairly well and I think this time, in spite of a very broad topic, it did. Some articles need to be stretched, some just don't want to be written at all, this one was five threads of consciousness all tumbling onto the page at once. There's just so much going on in this subject and in a lot of ways I see this as an extension of my previous article The Optimal Life where I spoke to how gaming concepts are part of our daily lives whether we choose to recognize them or not.

    Technical writing is about managing relationships, and when done correctly can save you a tremendous amount of heartache and pain. In the case of something like a boardgame rulebook it's more critical than in my line of work -- no one is compelled to read your doc. Getting it "right" is fundamentally a business success strategy when viewed from the publisher's side of the equation.

    I do want to respond to some of your comments, and they follow.

    S.


  • avatarSagrilarus
    Quote:
    You, if you wanted to truly make your mark on the gaming world, should take up the reins as Headless Hollow has done and start creating EASY, ALL-INCLUSIVE rewrites and/or quick references for complex games.

    There's a problem with that concept. A second set of rules no matter how similar to the first is going to introduce inconsistencies. One of the points that I tried to make early on is that there needs to be a single point of reference that all agree to play by in order for the ruleset to have stability. This isn't merely an issue with rewrites and clarifications -- often different printings of the exact same game will have changes to the rules in an attempt to correct problems. For good reason -- no product is perfect. Publishers try to refine the product as it proceeds through lifecycle. But when a disagreement occurs, my personal call is that you use the printed copy of the rules that are sitting on the table in front of you right now. I don't see any other way to fairly adjudicate because anyone can quote some joker on the Internet, and generally the jokers don't agree. If all agree to a different interpretation that's fine, but when in doubt the copy on the table calls the tune.

    Those rewrites you refer to need to be prewrites. The doc needs to be examined prior to first printing to get it 99% right on the first release. I love Warriors of God's rulebook but it has an issue with a particular part of the play that was overlooked prior to release. It's very minor, and to his credit Adam Starkweather has soft-touched the clarifications and essentially let the text stand as is. In one way that's a positive -- the ruleset remains consistent and players simply make a solid interpretation in the odd event that the "Aggressor Marker" issue occurs. In another it's a negative because the issue wasn't uncovered during initial development. Mistakes are going get through and if this was the size of problems I have in other rulebooks I'd be happy as a clam at high tide.

    S.

  • avatarSagrilarus
    Quote:

    I always found the AH rulebook to be kind of frustrating. It is nice that the phases of a turn are laid out simply over the span of a couple pages, but I find it difficult to find any kind of details or exceptions in there.

    and

    Quote:

    I think different players will respond to different rule books in different ways.

    You're both wrong. The way I like rulebooks is the right way so shut up.

    Arkham needs a "nitty-gritty" passage in each piece of the rules. That lawyerville part I mentioned earlier in the text is where you almost add a third voice into the mix, the one where you talk low with your head down and give the dirt on the details. Arkham could use a little more of that, though the doc would grow even longer. A companion doc that followed the exact same structure (and matched numbered paragraphs) could provide that level of detail for seasoned players. I don't think "concordance" is the right word but that kind of thing -- the only issue is that the writer would need to take exceptional care to make sure nothing contradicts the original ruleset. I suppose that's the case in a single doc as well . . .

    To some extent "two voices" stretches the spectrum of how many users will find your writing appealing. But there's a whole bunch of folks out there and you can't make all of them happy simultaneously. I took courses in college because of the Prof teaching them -- I liked their lecture style.

    Something that is generally missing from rulebooks (which makes no sense to me) is an index. Why can't a three page rulebook have an index? It's only going to add half a page. For bigger rulebooks it's almost inexcusable to not have a table of contents and an index. I'm more of an index guy. My buddy Paul is a ToC guy. More often than not these two additions bring a lot more people into the fold and don't seem to be very challenging to add. I don't know why they aren't more common, and often when they exist they aren't very complete.

    S.


  • avatarSagrilarus
    Quote:

    I have the same problem with a lot of Vlaada Chivatl games, but that's mostly because they always try to teach the game in steps of progressive complexity (Simple game -> more complex game -> full game) and it's difficult to find specific rules even if they're explained well once you find them.

    BAD idea. As far as I'm concerned you should never mix two rule sets in the same stream of focus. At a minimum, publish basic as a contiguous set, and then add additional rules via a separate doc. Even better -- Rush 'n Crush implements two games with the same pieces, but two wholly separate rulebooks, each complete. You're using one or the other, never both. Added printing costs, but absolute clarity.

    I damn near used "absolute clarity" and "Rush 'n Crush" in the same sentence which of course is absurd, but for the concept we're discussing it's a pretty solid example of good design.

    S.

  • avatarSagrilarus
    Quote:

    I've had experiences where the designer did not catch a rule he/she wrote poorly - sometimes they are too close to a design that they can't fix the rules properly or catch it when the rules are not right.

    Zev

    A prior discussion of Mansions of Madness raised the issue of an independent technical writer. Expositional writing isn't a skill that most game designers have, and frankly, the job sucks. Technical writers piss people off for a living -- they show up at your desk and point out your flaws. Nobody likes them. Unfortunately someone with this skillset needs to be involved in the publishing process relatively early on. The ruleset needs to be elaborated on paper as the game is being tested (if for no other reason) to make sure that everyone on the design team has a common view of the design decisions that have been made.

    In software it's very common for someone on one side of an interface to declare "you're supposed to send me the record number, not the account number!" during formal test when the integrated product fails to produce the result that unit testing indicated would occur. I'd be curious to know how often people at Z-Man review the printed product and say, "huh, I thought we had decided to work that rule the other way."

    If you're smart, you won't answer that question.

    Some people can write their own docs. Others have no skills in it, and if that's the case it's not good use of their time to have them do it. Find a chump.

    S.


  • avatarJape

    After reading that, I feel the violent urge to rip up every rulebook I've ever written. Or at least give them a very stern look the next time I open them.

    Thanks. (and yeah, I did just join to leave that comment)

    +JP

Only registered users can write comments!
Text Size

Top