Now Available: Accelemechs vs. Crashotrons

Accelemechs vs. Crashotrons is a silly game about playing with toys, which is also a robust strategy game about playing with toys. It’s now available on Itch.io.

Tactical maneuvers. Strategic thinking. Throwing socks.

To take a look at AvC‘s development, check out my posts on testing the rulebook, using real physics for wargaming, and who I made the game for, as well as other posts over the last two weeks.

I’ve released Accelemechs vs. Crashotrons on a pay-what-you-want basis. Give it a try, let me know how it goes, and I hope you enjoy!

Accelemechs vs. Crashotrons: Primary Verb as a Source for Names

This design diary, which is already running backwards, is about to get even stranger: I’m going to jump back to near the very end of the process. Today, let’s talk about how, and more importantly when, I chose Accelemechs vs. Crashotrons as the game’s title.

At this point I think it’s fair to say that there’s broad agreement that your game’s advertisingincluding its name–must reflect how it plays. People go into a game with expectations based on how they were convinced to try it, and if those expectations aren’t met they’ll be disappointed. This is true even if what they end up playing is “good,” by the metrics that should be applied to it; farm-fresh, delicious apples aren’t a substitute for rigatoni. Since disappointed people give bad reviews and spread negative word of mouth, it’s important to set the right expectations at the outset.

Names take on special significance when talking about small games released on digital storefronts. A tabletop game might get its entire front cover displayed, and be able to set the mood that way. At the very least it will have a spine showing, with room for an artistic presentation of the game’s title, an environment or a character, and some basic data like who made it and play time. A digital storefront compacts all that: you get your game’s name presented in plain text, a tiny image, and a summary of less than a full sentence, if there’s room for a summary at all. In that latter environment, the name has to carry extra weight.

So, keeping in mind the critical role that the title would play, I adopted my wife’s early preference: Robot Sock Ball.

In a funny way, Robot Sock Ball works. Highlighting the robots is useful, as is that the game involves doing something with socks. Lots of people really enjoy that part!

Unfortunately, Robot Sock Ball also sets the wrong expectations. It sounds like a sport, and Accelemechs vs. Crashotrons doesn’t play that way. One doesn’t score goals or pass a ball around; I don’t want people to open the PDF expecting rules for doing so.

My first serious effort at a name landed me for a while on Some Shall Stand, Some Shall Fall. This had a couple of things going for it:

  • It’s a recognizable reference for at least some of my target audience, “people who own toy robots that turn into vehicles.”
  • This sounds like a game where you eliminate your opponent’s pieces, which sets the right expectations.

At the same time, there were quite a few weaknesses. Among those I considered most troubling were:

  • The reference is strong only for those old enough to remember it.
  • If one doesn’t get the reference, there’s little hint as to what’s going on. An ill-defined “some” will “fall,” whatever that means in an unknown context.
  • This is an intimidating, serious name. When I hear it I’m put in the mind of Waterloo or Sekigahara. I knew from the beginning that I wanted my game to be engaging for wargamers, but it’s played with toys; it’s a beer-and-pretzels wargame, and the title should sound like it.

I spent a long time stuck with Some Shall Stand, Some Shall Fall. I knew it was wrong, but wasn’t able to find anything better. There were so many things to capture: toys, robots, socks, tactics, on and on.

Mercifully, Zach Barash was willing to help me out of the slump. At the risk of oversimplifying, the insight Zach shared was: the name should hint at how players will actually win the game, because that’s what they’ll spend most of their time doing.

By this point in the process I had a lot of test data, and it had revealed something interesting: throwing stuff at the opponent’s toys wasn’t all that strong, and players realized it. Throwing a sock was fun, sure, but folks didn’t anticipate winning that way. Overwhelmingly, their plan was to get a toy up close to an opponent’s toy, turn into a vehicle, and knock the opposing toy over by ramming it.

Seen in that light, naming suddenly became a lot easier. The central verb of the game is crash or ram, and that’s what the title had to convey. I didn’t need to talk about throwing stuff; that was cool, and players would enjoy trying it, but it shouldn’t be sold to them as a primary activity. Nor was it important to specify that the game is played with toys, since crash and ram imply more kinetic action than is found in a hex-and-counter wargame.

With that in mind I went back to brainstorming–but now with much more focus. Accelemechs vs. Crashotrons won out because:

  • It explicitly calls out the idea of crashing.
  • “[M]echs” and “trons” are robot-sounding.
  • The idea of competition between groups is clearly conveyed.
  • Each word is easy to say, even if the overall name is a mouthful. That leads into the next point . . .
  • AvC as an acronym doesn’t, to my knowledge, mean anything bad. It also doesn’t, again to my knowledge, suggest any similar game.
  • Accelerating and crashing sound like arcade-y, silly things for robots to do, which suits this arcade-y wargame.
  • There’s no immediate reference to tactics or wargaming, but I considered that an acceptable loss in light of the positives.

And with that, the lesson was learned: name your game after you understand it, and know what the primary verb is. Even if that word doesn’t show up in the title, you’ll at least be able to judge whether you’re giving the right impression.

(If you want to keep calling AvC Robot Sock Ball, though, you’ll be in good company.)

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.

Announcing: Accelemechs vs. Crashotrons!

Accelemechs vs. Crashotrons is the most rigorous game of flinging socks at toys you’ll ever play, and the silliest deep tactical challenge you’ll ever face. Your Accelemechs and your opponent’s Crashotrons will maneuver across a battlefield set up on your dinner table, knocking each other over with speed, daring, and the occasional thrown object. If you own some robots that turn into vehicles, you can be playing inside of five minutes.

Over the next few weeks I’ll be talking about the game’s inspirations and design objectives. I’ll get into how it plays, and why it works the way it does. Perhaps more importantly, we’ll talk about all the reasons it doesn’t work like many wargames do.

Accelemechs vs. Crashotrons releases as a pay-what-you-want tabletop wargame on itch.io on August 24th. Check back every Tuesday and Thursday evening between now and then for new posts about the game. (EDIT: an index of these posts is below.)

Get your toy robots out of storage, clear the kitchen table, and roll up a sock. We’ve got battles to win!

Accelemechs vs. Crashotrons design posts

Writing the Rulebook