I get asked the game designer equivalent of “Wow, how do I get your job?” about twice a month, and more frequently during convention season.  I usually end up trying to dissuade them.  Writing games is a really bizarre form of technical writing. It’s somewhere on the Venn diagram of writing legal briefs, computer programming and radio plays…and most people think it’s “OK, I explained this game to my friends, now I just need to write it down!”

Coming up with the cool idea for the game is the fun part.  The not-fun parts are, well, not fun.  They’re also what separates the guy who decided to type up his house rules for D&D, Only Betterer from someone who actually wrote a game that other people can play without the designer in the room.  Making a game other people can and will play is what separates the pros from the hobbyists.

First, designing and writing the game is about 20% of the work. This is why every game publisher eye-rolls when someone comes up and says that they’ve got this brilliant idea that they’ll share for 50% of the profits, but they won’t show the idea until you sign the contract.

The next 20% of the work is turning a written first draft into something testable.  This usually involves talking to the author and asking him to codify and clarify terminology. So many game writers hate copy-and-pasting rules text, and end up writing rules that say the same thing in subtly different ways.  Or not so subtly different ways – I’ve seen games early in development (and post-publication…) where nobody went through and built a glossary of terms used in the game – and as a result you get the same concept called three different things with three slightly different ways to do it.

This isn’t editing, per se, it’s development.  Ideally, we’d love authors to do that before they turn the manuscript in, but this is far from the ideal world.  A lot of games don’t make it past this phase, because the author feels the developer is “picking on them” or “trying to smother their genius.”

The middle 20% of the work is sending a draft of the game out to playtesters, and processing feedback. This is where explanatory diagrams are drawn and the first in-text-flow examples get written.  And rewritten.  And re-done. And re-re-done.  The back half of this 20% is taking the feedback from playtesters…most of whom don’t document everything they did to solve a problem.  Or will send you heated emails because the game blew up on them after they played it for two hours, and now their friends don’t want to touch it ever again.  This is the part where the developer feels “picked on” a bit.  Just remember:

Everyone who ever told you your game sucked, but told you what it was about it that sucked, just helped you make it better. You, as a developer, need to figure out how to resolve this issue, and you need to figure out how to differentiate between “The game sucked…” and “The game isn’t one I’m interested in.”

The worst kind of playtesters are the silent ones.  I put playtest material up on the Ad Astra Games Patreon specifically to weed out the silent playtesters.  These are the guys who download the game, and maybe skim it once, and otherwise let it sit on their hard drives.  I would much rather have playtesters tell me the game sucked than download it, decide it sucked, and never tell me so. 🙂

You will want two separate rounds of playtesting in an ideal situation – and you really want to get playtesters who don’t know the author of the game if possible; they’ll come in with things they know from knowing the designer, rather than hit the game up from scratch.  The second group of playtesters gets a draft that incorporates any feedback the first group gave you, and ideally doesn’t have any overlap with the first group.

If you have the time, you want to take any feedback from the second group, incorporate it into the draft and put it in front of the first group and see if the two different revision passes shake out any other “Oh, that’s what that means…” moments.

This 20% of the work can take up most of the time.

The fourth quintile of work starts by setting it aside for a week.  Then opening up the rules draft and editing it with fresh eyes. Up until now, you’ve been at ant’s eye-level in the grass.  Now you need to look at the entire lawn.  Ryan Macklin, designer of Mythender, and the developer who turned FATE into FATE Core, has a truly excellent set of editorial guidelines here.  In is day job, he edits and Paizo.  This is the part of the job where most single-person outfits stall out.  In part, this is because you’ve been living and breathing this project, and interacting with people who’ve been excited about the project for the three prior steps…and now it’s just you, a horribly fucked up draft that’s incoherent, some editorial guidelines, and all the company you could ever want from the Suck Fairies.  Because trust me, at this point of the project, you’re going to see nothing but the warts on it, and everything – including cleaning the cat-box – is going to be more fun.

Power through.  You’re going to make at least three passes on the rules.

The first pass is going to be another nitpicky check on terminology consistency and clarity of explanation.

The second pass is going to be rules flow, grammar and writing quality.  KILL PASSIVE VOICE. Kill it with fire. Your rules are likeliest, as Ryan says, to be presented verbally: One person reading the rules to everyone at the table.  Passive voice makes audio-centric learning suck.

The third pass is going through and checking every single example against not only the text it illustrates, but other texts that may impinge on it. You may find yourself rewriting examples.  You may find yourself writing entirely new examples. You’ll probably never want to write an example again.

The fourth pass is to send it to a copy-editor.  Maybe fiction writers can write without a copy-editor, but game writers and developers can’t. You need someone who fetishizes whatever style manual you use (I use AP, a lot of game companies use Chicago) and will mark up your draft.  Remember that terminology pass?  Make sure you send your copy-editor that draft as well.

While they’re reading the draft with fresh eyeballs, you’re making all the diagrams that need to go in next to the text.  This is also when you’ll start commissioning cover art, and illustration pieces.

The final quintile is production:  You’re doing layout, you’re checking in on art turned in by freelancers, you’re starting the promotional work needed with the cover art you bought in the last phase, and this is where it starts to finalize as a product.  If you have time, and you probably don’t, this is where you start writing a combined Quick Start/Tutorial portion of your product, re-using art assets you already have.  You can’t write the tutorial until the product is written.

During production, you’re also talking to printers, scheduling time to go over proofs (where you’ll find things you missed in editing, copy-editing, and layout) and sending things off to the printer.  When something is off to the printer is when I start taking pre-orders for a game.