Rather than a standard design diary, I’m going to begin at the end of Accelemechs vs. Crashotrons‘ development and move toward the beginning. There’s much to say about the start of the process, and I’m eager to get to that. However, there’s more value in emphasizing a point Zach Barash and I have made before: set aside a third of the total project time for polishing, loosely defined here as “getting the project into a finished state someone other than the designer can run.”
As an example of how that played out here, let’s take a look at what went into exactly one page of the rulebook.
This is a pretty simple two-column layout. It has some basic diagrams. A title and footer image frame the text. Yet, despite its simplicity, getting this single page of the rulebook to this point was days of work.
1. Mock up the layout
The first step was to set up two columns and a heading in Scribus. That isn’t hard, but it does forcibly remind one that the statement “set up two columns and a heading” begs a lot of questions:
• How wide should the columns be, to fit enough text to be useful without eliminating the white space that helps readers organize what they see?
• How big should the heading be? It needs to get attention, but it can’t take up too much space–there are rules to write.
• How much of the page, if any, will be devoted to things like page numbers, borders, and other content?
• What fonts will all this be in? I spent quite a while on Font Squirrel and at The League of Movable Type, just looking for title and body fonts.
• Are two columns and a heading all that’s needed? A subheading would allow for explanatory text that helps keep readers oriented.
I ran tests just of that last issue, showing people a version of the layout with and without subheadings to see which they preferred. (I liked the subheadings, but every single tester said they made the page look densely packed and intimidating. Out they went.)
2. Write the rules
Once the layout was settled, I started putting in the rules. This was, as always, tough for a number of reasons.
First, writing down the rules for a game is an exercise in making assumptions explicit. That’s never easy! Assumptions are generally things we don’t think about, so it’s hard even to recognize everything that needs to be on the page.
Second, the rules need to be comprehensible to players without the designer’s pre-existing knowledge of how things “should” work. Accelemechs vs. Crashotrons gave me particular trouble on this point. I’ve been playing tactical games for decades, and I know how these games generally explain themselves. (Oof. Welcome to middle age, me.) AvC is meant for a broader audience of toy owners who want to play with their cool shape-shifting robots, so I needed to get out of my own head and away from wargaming jargon.
Third, the rules must work with the layout to aid comprehension. For example: in the page above, the setup rules begin and end in the left column, because keeping them all in one place is clear for readers. However, that strict space limitation demanded extra rounds of cuts. I would have liked to specify for thematic reasons that one player is the Accelemechs and the other the Crashotrons, but the extra words caused the setup to run into the right column. The danger that players would think they were done at the end of the left column and miss the last step or two outweighed the thematic gain; I removed the line.
3. Make the art
I use Affinity Designer for this purpose. My experience has been that it’s a good middle ground between Adobe Illustrator (powerful, but extremely expensive) and Inkscape (powerful and free, but frustratingly idiosyncratic in the way open-source software sometimes is). I used Designer for the in-text diagrams, the footer images, and the game’s logo.
Much of the game’s art uses icons. I got most of them from game-icons.net, which is an amazing resource. A few I made, trying to fit the game-icons style.
When the art was in place I sent the rulebook out for a round of testing. At this stage I wanted to know if the rules were clear and complete, and where the layout fell down.
4. Rewrite the rules
I got a lot of great feedback about the rulebook. Admittedly, most of it was negative–but as Zach pointed out during our talk, negative feedback is often more actionable.
Much of the problem was in the style of the writing. I had removed wargaming jargon, but the rules were still structured like a wargame’s rules. A long-time wargamer would read them, fit them into a larger understanding of how to parse a wargame rulebook, and be all set to play. Non-wargamers didn’t have that context, and thus felt at sea.
In response, I rewrote significant portions of the rulebook. I also added a “quickstart” page at the beginning, which does double-duty as a sufficient presentation of the rules for those with wargaming intuition and as a necessary introduction to the ideas for those without.
5. Revisit the layout
The incomparable Danny Nanni noted that the layout I was using at the time had poor visual hierarchy. I picked out a new heading font and revised headings to improve each page’s typographic color.
At this point I handed out the rulebook to readers again. I’m still getting feedback, and making last-minute changes.
The final third of the project is polishing
Accelemechs vs. Crashotrons is a summer side project, a labor of love that isn’t expected to pay bills. Hence, time spent on it has to fit around work that does pay bills. Getting the rulebook even to its current state has taken several days, spread out over several weeks–a substantial commitment given my three-month time constraint.
Yet, that investment has been completely worthwhile. I’d even say it was more worthwhile than anything else I could have been doing for the game! All the design and testing that went into every other part of Accelemechs vs. Crashotrons is wasted if the results aren’t communicated well to players.
Polishing is often a slog. At times, writing this rulebook certainly has been! Like so many rock-up-a-hilll experiences, though, if you can get the boulder to balance at the top the view is worth the trip.
The Law of Game Design 