Tom used to be a lawyer. Now he's a game designer. The two have more in common than you think.
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.
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!
Fights are not “resolved” in Accelemechs vs. Crashotrons. You never roll dice or calculate a result. Instead, fights happen through the physical action of the toys and the players. That is not a concession or a compromise; it is not “dumbing the game down” for the sake of fast play. To the contrary, playing in the physical world allows you to access, manipulate, and exploit the most complete and detailed physics engine around–actual physics.
Here are some things that I’ve seen happen in AvC playtests:
These are all things that could happen in the real world, but that even complex wargames generally don’t try to simulate. It would be agonizing to work out the ricochet angle for every miss. No one wants stop play while establishing whether a wall fell over in such a way as to create useful cover.
When playing in the physical world, though, you get all of that stuff for free. If your pieces can take cover behind the fallen wall, you’ll see that it’s so. If a ricochet would hit something, it will. Issues that usually have to be abstracted away become a natural part of the game.
The bigger gain in my mind, though, is how much easier things that are included in wargames become. Issues like the effects of difficult terrain are so clearly important that every wargame has to take them up. Normally this means either jarring abstractions or fiddliness–all of which goes away instantly when actually moving across a real surface.
For example, we all know that it’s difficult for a car to drive on surfaces other than pavement. How far, then, can a general’s staff car in World War II go when moving across the broken ground of Normandy after D-Day?
Perhaps the most common rule is that vehicles move at half speed when not on a paved surface. Thus, if the car normally moves six hexes, or 6″, it would move 3 hexes or 3″ when taken off-road.
That works well enough so long as we only care about cars, and the only surfaces are paved roads and dirt. Infantry, though, requires more detail than “dirt;” people might still make good time over dry, packed soil, but get much slower moving through mud or a thickly-planted field of high corn. Tanks may go right through the corn, but be slowed by the mud (how much?). And we haven’t considered the possibility that “dirt” could include ditches that a car might get stuck in.
Or, instead, of all of that, try this: put a toy car on some dirt, choose a destination, and give it a push in the right direction. Did it make it where you meant it to go? Did it get stuck? Did it get slowed down by the dirt, and not quite go all the way? Did it hit a rock, and flip over? All the issues one normally needs rules for–all the possibilities that the rules would need to address (or, more likely, not be able to address)–are handled for you, right there in the moment with no die-rolling or table lookups required.
If this sounds like a sales pitch, it’s because I really am selling. Not just Accelemechs vs. Crashotrons–though of course, I certainly hope you buy my game–but the experience of real-physics wargaming in general. People have been doing this at least since H.G. Wells’ Little Wars, and it’s amazing! It’s something I really, really think you should try–and if you want to have a go, AvC releases on Saturday!
If you study entrepreneurship, you’ll hear the same mantra over and over: focus on the customer. As part of that focus, you’ll be told to narrow your idea of “the customer” as much as possible. The goal is to find a limited number of customers–a small market–and then design precisely what they want.
Accelemechs vs. Crashotrons was built on that principle.
From the broadest perspective, AvC is a miniatures wargame. In play, miniatures wargames can look like this:
That’s pretty amazing! Narratively, I can pick out heroes (gold armor and wings help us find them even in a small picture) and villains (the people in the lower-right are wearing skulls and spikes, which has to be a clue). From a tactical perspective, there’s infantry and some fantasy cavalry: winged troopers for the heroes, roaring monsters for the villains. Whether I’m looking for a story, a simulation, or both, it’s clearly here.
Of course, miniatures wargames don’t start out looking like that. Instead, they arrive like this:
It’s a long way from here to the winged, heroic leader in the first picture.
For some players, this is A-OK. For some it’s even great! Building the toy soldiers, modifying them, combining pieces from different kits to make new characters, painting them–these “hobby” elements are selling points for many.
To those who don’t enjoy the hobby aspect, though, building and painting is a huge barrier to entry. Across the decades, this was dealt with through a never-ending series of advice columns, podcasts, and other resources meant to get players up to speed with minimum effort. The theme of all of these was “we know you hate this, so here’s how to get through it relatively quickly.”
Does it sound like there’s an unsatisfied part of the market to you? If so, you’re thinking like an entrepreneur.
Companies spotted this division among players, and focused in on the segment of the wargaming market that wanted to play toy soldier games but didn’t like the preliminaries. Miniatures wargames started to appear with pre-built, pre-painted toy soldiers that were ready right out of the box. A decade ago we saw early efforts, like AT-43 and Confrontation 3rd ed. The big hit, though, was FFG’s X-Wing, which has become a top-selling line.
That was one hurdle cleared. However, there was another one waiting: the ready-to-play miniatures are quite expensive. Games Workshop will sell you 10 Age of Sigmar skeletons for $30. A single TIE Fighter for X-Wing retails for $20.
Admittedly, one needs fewer TIE Fighters than one needs skeletons, and the X-Wing miniatures can double as nice models for a display shelf. The sales figures demonstrate that the price is acceptable to many. Still, the question had to be asked: what if I could have good, fast, and cheap?
Gaslands is the major attempt I’m aware of to segment the market again. It’s played with Hot Wheels cars, which cost about $1 at grocery stores. What’s more, it’s great! It’s a serious miniatures wargame, played with pieces that are inexpensive, look good on the table, and are intrinsically fun to push around.
Accelemechs vs. Crashotrons tries to segment the market still one more time. Gaslands is cool, but it uses the Hot Wheels cars largely representationally. You, as a player, aren’t expected to zoom them around, and combat is resolved using dice like in most wargames. The Hot Wheels cars are cheap, fast, and good, but they’re not important.
When I play Gaslands, though, I really want the cars to be important. My personal favorite moment in the game is when they don’t sit quite where they’re supposed to because they’re on wheels rather than a static base. I’m playing with toys, and I want that playfulness to come through more strongly.
That’s what AvC is all about. It’s a game for those who want to play a miniatures wargame, are open to using toys as the miniatures because they’re good representations that don’t require preparation, and who–since we’re playing with toys anyway–want the toys themselves to matter.
I’m in that category. If you are, too, Accelemechs vs. Crashotrons releases on Itch.io this Saturday.
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 advertising—including 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:
At the same time, there were quite a few weaknesses. Among those I considered most troubling were:
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:
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.)
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 protect 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:
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 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.
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.
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.)
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.
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.
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.
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.
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.
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!
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!
Much of my work these days is in making games for education–mostly for use in classes I’m teaching. Thus, I was very interested in this article on getting paid for that kind of work.
In many ways, the article echoes frustrating aspects of my own experience, and the experience of others I’ve talked to in this area. There’s tremendous demand, but no organized way to connect designers to the specific people looking for something at any given time. Money is out there, but it is often caught up in systems meant for other kinds of products and services. It is hard to build a reliable income stream.
On the flip side, there really are–as the article makes clear–paying customers out there. It is possible to do this kind of work, make some money, and finish your day feeling like you put your skills toward making the world a little bit better. If that sounds good to you, I hope you’ll join me in making games for the classroom, and that the article gives you some ideas for how to get paid doing so.
The Law of Game Design 