Accelemechs vs. Crashotrons: The Right Test

In this strange backwards design diary we began by finalizing the rulebook. Then we reviewed why I chose to move toward release when there was still testing that could have been done. Now the clock is reversing still further, and we are firmly in the production phase, refining ideas. At this stage, what questions are suitable for testing?

The answer, of course, is: any of them, so long as you develop the right test.

What makes for the right test? Zach explains here. In summary, a good test is the smallest thing that will answer the specific question you have.

As an example, let’s take a look at how I worked through one of the fundamental actions in Accelemechs vs. Crashotrons: attacking at range. In fiction battling robots fight with lasers, missiles, and all sorts of sci-fi armaments. That meant there needed to be some way for robots to knock each other over at a distance in the game as well.

I also wanted everything about Accelemechs vs. Crashotrons to focus on the toys it’s played with as much as possible. Hence, I wanted the results of one robot blasting another to be established using the toys, and not through dice, cards, etc.

Early on, it became clear that the best way to accomplish those goals was for the players to throw something. Now, kids know two facts about throwing: (1) it’s fun, and (2) it’s more fun when you’re doing it indoors. Those facts, it turns out, hold throughout life. People love throwing things at toy robots. Throwing things is, for some players, the best part of the game.

Based on that positive feedback, I came out of the ideation phase absolutely certain that players were going to simulate ranged attacks by throwing something at their opponent’s toys. In production I needed to answer the question I was begging: what, exactly, should players throw?

As silly as it might sound, that was a huge issue. I wanted ranged attacks to meet four key standards:

Be effective, but not very effective: through some combination of weirdly bad aim and mechanical toughness, fictional robots generally don’t suffer much harm in long-range battles. Decisive confrontations happen up close. Whatever the players threw needed to be able to knock a toy over, but to product the theme it couldn’t do so reliably.

Reflect differing fictional capabilities: some robots are tougher than others. Even without a canonical storyline, toys can be bigger or just look like they’re meant to take a hit. The effects of the thrown object needed to affect toys in ways that made sense based on the perceived toughness of the toy.

Cheap and commonly available: to the greatest extent feasible, I wanted people who find some old toys in their attic to be playing Accelemechs vs. Crashotrons the same day. This vital game component should be something they have, not something they’ll need to go out and buy.

Limit collateral effects: throwing things indoors always involves a certain amount of judgement. One must have the good sense not to play when heirloom glassware is on the table. My goal here was to build mechanisms that would serve as reminders and helpers in using reasonable care.

With my question, and these intended outcomes, I was able to design this very silly—but very effective—test:

OK, yes, the video is staged—but this is what I really did. I got several toys, of differing heights, weights, and numbers of appendages, and I threw a bunch of stuff at them. That was the smallest thing that answered the specific question I had.

After doing so, I knew all of the following:

  • A well-thrown toddler sock is moderately likely to knock down an average-sized robot toy (about 5”). It’s mostly useless against anything bigger than about 6.5”, unless that toy is standing on a surface with some traction, such as a rug. In that case, if you hit the target high enough the drag on the feet enables you to overbalance the figure.
  • I went into this test thinking bouncy balls would be great. They’re cheap, they’re available everywhere, any home that’s ever had kids live in it probably already has a couple, and they have some—but not too much—mass.
    • As the second clip in the video shows, though, they’re much too bouncy. Hit or miss, they go everywhere. Even if you don’t break something, you have to find the ball in whatever distant corner it rolled into every time, which is annoying.
  • Adult tube socks are comically powerful at this scale. Even big toys are quite vulnerable to tube socks.
  • Other kinds of socks end up somewhere between toddler socks and adult tube socks in terms of their knocking-toys-over potential.

With that test complete I had the grist for the final rules. Players would use rolled-up toddler socks, unless the game surpasses a critical mass of larger toys, in which case it’s tube socks all around. To constrain both striking power and collateral damage potential, players are required to throw with an elbow on the table, and to bounce the sock into the target rather than throwing directly. Add some technical cleaning up, and you have what’s in the rulebook now.

This isn’t the kind of playtest that’s often discussed on Boardgamegeek, or what you’re likely to see at a public playtest session. That’s fine! I didn’t need other people to get the data I needed, or to play the game all the way through. In fact, I didn’t need to play the game at all; setting up a battlefield and moving toys around wouldn’t contribute to answering my narrow question.

Finding that narrow question, and setting up a limited test to answer it, are the keys. If you try to address every issue by playing your game all the way through repeatedly, hoping to develop the broadest possible understanding of the problem, you’ll never finish. Build and run the smallest thing that answers the specific question so that you can get what you need and move on.

Accelemechs vs. Crashotrons: Accepting Imperfection

Accelemechs vs. Crashotrons is not perfect. It will not be perfect upon release. Post-release errata, should there be any, will not make it perfect. Nevertheless, AvC will release, because—in the words of Zach Barash—“done is better than perfect.”

(For the record, though Zach kindly attributed that amazing phrase to me during our talk, it’s his!)

There are lots of things I would like to do before sending Accelemechs vs. Crashotrons out the door. Miniatures wargamers will be surprised not to see a point-buy balancing system; those are always flawed, but I could make one and it would be a selling point. The quickstart page was meant to have a more playful, comic strip-inspired presentation. I’d like to revisit the footer images. AvC’s Itch.io page has weird layout issues that need fixing. (Now that I know what to look for, many Itch pages have weird layout issues, which they fix via awkward workarounds).

Nevertheless, Accelemechs vs. Crashotrons will be available on the 24th.

Making AvC perfect would mean delaying it indefinitely. After all, more could always be done. Every fix will reveal other avenues for refinement. That point-buy system could be tweaked for better balance, the comic strip made funnier, the images replaced with something entirely different, the Itch page layout copied to new storefronts. All making the game better—but with no end in sight.

The simple fact is that games are never perfected. They can only be finished. One must make the hard choice to close the book and move on.

And that’s a good thing! “Done is better than perfect,” for all the reasons Zach and I talked about. Others can play, and enjoy, released games. You can look back on and learn from finished projects; the critical distance helps you be objective and grow as a designer. Maybe, just maybe, you’ll even make money from a release!

(It’s not likely, if we’re being honest, but the possibility’s there.)

I would like to release a perfected Accelemechs vs. Crashotrons. Instead, I will do as every game designer must: release the best version I can. Accepting its flaws is the price of letting others have fun with it.

Accelemechs vs. Crashotrons: Writing the Rulebook

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.

Starting–and Finishing–Your First Game

I recently had the great good fortune to give a talk at PAX East with Zach Barash, a good friend whose accomplishments are too numerous to easily list here. (Designer for Kingdom Death, Magic: the Gathering columnist, improv actor–seriously, we’ll be here all day and into the night!) Our talk, Starting–and Finishing–Your First Game, teaches a process that will reliably take you from an idea for a game to a finished product that you’re proud to show off. It also highlights some common pitfalls that derail projects, and explains how to avoid them.

You can find our slides here. Be sure to turn on presenter’s notes, which include our discussion for many of the slides.

Thanks to all who attended, to all those who asked questions (they were really good questions!), and to all who reached out afterward!

Theory: Randomness and Responsibility

In the past, I’ve argued against employing control difficulty as a gate for player power. Sam Von Ehren offered an alternative perspective today, one that deserves more thought and time than I’m able to give it as the NYU Game Center End-of-Year Show approaches. For the future, then, a summary:

Randomness built into a game system can be frustrating. If players have to do something difficult, on the other hand, one gets much of the benefit of randomness–even experienced players will trip up sometimes, and will be concerned about it still more–while putting the burden on the players instead of on the game. When their errors introduce uncertainty into a match, they will see themselves as the cause, and want to improve. That’s much more palatable than feeling as though the game is out to get them.

Theory: the Dark Side of Computer Assists

Computers can help during the ideation phase of design, and can also point out new strategies to players of what might otherwise be considered a game past the point of innovation.

On the other hand, they can also enable a rate of play that forces a major design firm, with testing resources most can only dream of, to ban a card 48 hours after release.

I suppose we have to take the bad with the good.

Theory: Q’s without A’s

Fantasy Flight Games’ reboot of the classic CCG Legend of the Five Rings raises a number of intriguing issues. In fact, I’d say there’s almost nothing about it that isn’t interesting:

The license itself. The received wisdom is that licensing a fictional world is only worthwhile when the world is a major draw; otherwise, one might as well start from scratch, and forego the expense. Was Legend of the Five Rings worth the cost?

On the positive side of the ledger, it’s a long-standing name in the tabletop market, albeit not perhaps as strong a brand as it was in the past. FFG also received at least some existing art assets–we can see them in the cards displayed on the new website–which avoids the cost of recreating card art.

On the other hand, a game two decades old comes with a lot of baggage. There’s an existing base to be placated, if you’re not simply going to accept their ire. Old data floating around the internet might confuse customers. Your product has expectations out of the gate that otherwise wouldn’t burden it.

I’m not certain whether it will be possible to determine from the outside how the license works out, but it will be interesting to consider.

The gameplay. For all its mechanical warts, old Legend of the Five Rings did one thing right: it was a game about acquisition. Over the course of a winning game you got more honor, more cards, more stats, more abilities, more of just about everything. That acquisition felt good.

New Legend of the Five Rings is, in some sense, a game about losing your resources. Honor and cards are both naturally given away during a game. I can see how those negative feedback loops resolve a runaway-leader problem that bedeviled old Legend of the Five Rings, and can also imagine that they lead to interesting decisions. Yet, the fun of a game isn’t solely in whether it’s mechanically balanced. Will players see the game as punishing them for engaging with it, and move on to something else?

The theme. In the 1990s Legend of the Five Rings’s mashup of dynastic China and Shogunate Japan was seen as forward-thinking and progressive. Today, it might be seen in a different light. Will the theme and fictional history be a help, or a lightning rod for criticism? How will Fantasy Flight handle issues of portrayal going forward?

. . . and so on. Legend of the Five Rings is a venerable brand, and that throws the changes it’s undergoing into especially sharp relief. I’ll be extremely interested to see how the new release plays out.