One 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:
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.
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.
In 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:
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:
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 . . .
. . . 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.
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.
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.
"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."
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.