You don’t need to be a great player to be a great designer, but it does help to play your own games reasonably well—if only so that you can participate better in playtesting. To achieve that, ask what you could have done differently after a loss. The answer to that question will be much more useful than grumping about external factors that may have contributed to your defeat.

Admittedly, it’s sometimes very hard to put a loss on your own shoulders! The temptation to blame the dice, or the cards, or your opponent’s cheesy strategy, can be strong. It’s especially so when the dice were objectively lopsided (don’t trust your memory on this! Write rolls down.).

However, saying “the dice got me” doesn’t tell you anything about your game. That feedback merely teaches that sometimes dice come up with unwelcome numbers at inconvenient times, which is hardly new information.

Taking the emphasis off of the dice, and putting it first and foremost on what you could have done, forces you onto a line of thinking that’s much more likely to end in useful design insights. Was there another strategy you could have pursued, one where the rolls you got would have been sufficient? If so, is that a strategy you want players to rely on when the chips are down? If not, does that point to a design problem, or are you willing to accept that sometimes players will lose despite having made good choices? All of those are much more useful things to think about than “dice sure do hate me sometimes.”

Of course, focusing on yourself instead of on random factors is also a great way to build skill in general—and that will further strengthen your testing. As you improve at a game, or at games writ large, you’ll be able to be say with greater confidence that a different strategy would have worked better, or that you really had no alternatives. There’s no faster or more reliable way to get to skill worthy of reliance than to put your own decisions through the wringer.

Ultimately, asking questions about your own play is a kind of quality assurance for the conclusions you’re reaching about your game. It helps guarantee that you’re identifying the right problems. You’ll find that a valuable contribution; after all, you can’t arrive at correct solutions any other way.

Careful note-taking is central to the design process. Overload is inevitable for a busy designer without a systematic approach to keeping thoughts and ideas organized. Even a designer working on a single project will run into trouble without some way to keep track of successful changes and failed experiments

Below are some guidelines I’ve found useful for note-taking. I hope you find them valuable as well.

1. Write everything down.

This might sound obvious, but things are often obvious because they’re important, and this is important. Don’t assume that you’ll remember anything. Any time you make any sort of progress on a design, write your thoughts down.

I didn’t understand how critical this would be until I started really pursuing design seriously. At that point it became clear that game design doesn’t always involve fretting over and polishing one game continuously. Sometimes that was because I had an idea that I wanted to follow up on right away; more often it was because I knew a concept might not pan out, and so I wanted to have another project “on deck.” Whatever the cause, I found that I was usually working on two or three games at once.

Nor do I have the impression that I’m unusual. If anything, I think I have fewer games in progress than many designers!

Working in parallel like this makes it hard to remember where a design is, what you’ve already tried, and what you meant to try next. This is especially true when a game has lain dormant for a while; coming back to it can feel like starting from scratch. If you don’t have good notes, starting from scratch is exactly what you’ll be doing!

Having a written record guarantees that improvements to a game don’t get lost. It’s incredibly frustrating to know that you solved a problem . . . if only you could remember how. Writing everything down guarantees that you never have to repeat your work.

2. Create a rulebook whenever you’re ready to stop.

Given that switching back and forth between projects is part of the job, it’s vital (a) to retain progress made on current game until it’s time to come back to it, and (b) to get up to speed on the next project as quickly as possible. Written notes help enormously with (a), but not so much with (b); figuring a game out from working notes is frustrating and increases the chance that you’ll miss something. It’s therefore extremely valuable to actually write out a rulebook before setting a project down, so that you can easily re-learn the latest and greatest version of the game when you’re ready to start working on it again.

Putting together a rulebook for a project recently saved me a lot of grief. I wanted to try out a change to Lines of Questioning—but LoQ has already undergone many changes, and I couldn’t remember off the top of my head exactly where the rules stood. This was my own game, and I didn’t know how to play! Without a rulebook I would either have had to reassemble the standard version from notes jotted on legal pads—with the concomitant risk of error—or redo the hours of work and many playtests necessary to hammer it out a second time.

Bjarne Stroustroup, creator of C++, says in his introductory programming textbook that properly documenting code isn’t just a kindness to other people who might read it. It’s also a kindness to yourself, since you may well be called on to maintain your code months or years later. The same principle holds true in game design. Document your designs with a rulebook; you’ll be grateful when you resume work on them.

3. Keep your records.

Sometimes it’s useful to be able to see, not just the current state of a design, but how it got there as well. Maybe you’ve decided that some changes aren’t right, and you want to revert a game to a previous version; maybe an idea that didn’t seem useful or important suddenly has new promise. Holding onto notes and old rulebooks ensures that you can turn back the clock.

The easiest way to keep these documents without your workspace (be it a physical desk or a computer desktop) becoming a mess is simply to organize by date. Admittedly, this isn’t much of an organizational method; knowing that a certain set of rules is from 8-11-15, or that some playtest notes are from 12-24-13, doesn’t tell you anything about what they contain. Something is better than nothing, though, and having a system begets putting things in the system. If you intend to store things by date you’re more likely to store them at all, and that’s the most important thing.

A more powerful, albeit more time consuming, method is to organize by topic. Notes on player powers go in one file; notes on mission cards go in a different one; board layout gets a third. If you’re willing to keep this system up, it provides easy, direct access to relevant information. Just make sure to have a comprehensive rulebook so that you don’t end up relearning (or, worse, teaching) from a slew of documents!

Maintaining old notes and rulebooks is the kind of task that seems like unnecessary drudgery until you really need to be able to refer back to them, at which point you’re happy you went to the trouble. Then you forget how relieved you were in that moment, and it goes back to feeling like drudgery. 😉 Try to hold onto the joy of having what you needed a the exact moment when you needed it, and resist the temptation just to recycle your old notes. Sooner or later you’ll be glad to have them.

Carved in stone

I’m always hesitant to say that someone else should work the way I do; there are lots of ways to be productive. Nevertheless, I feel confident in saying that anyone involved in game design who doesn’t have an eidetic memory will benefit from taking lots of notes, maintaining rulebooks for their designs, and holding on to their work documents. The time investment is significant, but the efficiency gains are tremendous.