Well developing a game using a sorta new (a good chunk of it was loosely what I did) framework in 3 days was of course quite a bit. I also wasn’t doing it “full time”, a lot of it was off and on throughout the day or in my head while doing other stuff. The game managed to get to a playable state, although to be fair I only played it by myself as I think the rules still needed a bit of refining before trying to explain them.

Did I learn some things? Definitely.

Will I be doing it again for another 3 days? Again, definitely.

Since this was about experimenting with process, i’ll go over the parts of the process and how they worked out overall. Here’s the overview of the process.

Establish a Core Mechanism (Action/Purpose)

Decide on a Goal Come up with some Supporting Mechanisms related to the Core. Identify how the Mechanisms work together coherently, adjust as necessary. Work up some basic “content”. Establish enough rules to play test. Refine the rules and add more content as needed, dropping anything not coherent before adding things new or back. Play test different solutions to any problems that come up.

Establish a Core Mechanism (Action/Purpose)

At first this seemed pretty easy because I was using a movie theme as a reference, but the more I thought about it, the more I really got to what was essential. Having the Raiders move relative to the Rig instead of a bunch of continuous car movement seemed a little strange at first, but really kept the game simple and playable within a small enough space. It also avoided being overly simulationish and setting player expectations of realism too high.

I don’t want combat to be the core of too many games as it’s pretty played out, but the way manuevering/positioning played in made it a bit more strategic. Avoiding any randomness to combat success and failure, but using hidden information from card hands and action point management proved to add a lot of strategy and lower the certainty of success in attacks. It definitely wasn’t easy, but it was worth the effort.

Decide on a Goal

It was interesting to do such an asymmetrical game as I hadn’t really tried one before. The upside for the goal was allowing quite a few different victory/loss conditions to de-focus min/maxing strategy and making the end a little less predictable. Having the Rig getaway progress act as a turn timer worked out nice to keep turtling to a minimum and guaranteeing a maximum # of turns. The goals also seemed to really set the right kind of pace and vibe for the theme, supporting it without being dictated by it.

Come up with some Supporting Mechanisms



Brainstorming Supporting Mechanisms is always fun, but keeping ideas relevant to the core and goal can sometimes be harder than it seems, especially when working from a theme that may not be totally coherent from a mechanical standpoint. It also helped to establish constraints for the design by this point to help guide ideas a bit without totally fencing them in. Using a simple rule of 3 secondary mechanisms that are well connected directly or through tertiary mechanisms seemed to work well, although some still took up more focus than others.

Identify how the Mechanisms work together coherently



The Support Mechanisms combined with the theme were good at suggesting connections and tertiary mechanisms. Some of them didn’t work as well rule-wise however. Thankfully I wasn’t being a total slave to the theme and was able to come up with some simplifications rather than simulations, but I can see how easily a theme can hinder a design with less discipline. I must admit I also applied certain personal preferences onto the design, but that’s better than just doing what is mechanical and obvious imo.

Work up some basic “content”



This is the part where things just necessarily sticky. Even more than with Supporting Mechanisms, the theme will probably overly influence the design of content. While it’s good to not pre-edit yourself too much, it was very easy to get out of control with content and add tons of rules exceptions and way over-complicate the game. It seems best to stay focused on how the content directly relates to mechanics and adjust the theme “skin” as necessary to make sense instead of the other way around.

This is an area where I probably could have done better, but am still happy with how it turned out after some adjustments. This also took up a lot more time than I expected as it forced me to dive deeper into rules related detail and make decisions about mechanical things like action point cost and up/down sides that I hadn’t had to consider yet. This is a good thing though as it forced me to try and better understand my goals.

Establish enough rules to playtest

It’s easy to get stuck in the trap of needing everything perfect and ready before prototyping and play testing. Luckily I’ve done enough board games in the past to know that sometimes it’s better to come at the prototype without having everything figured out and pay attention to how the game actually plays, handling exceptions on the fly and not being afraid of things playing really wonky. This is of course why you don’t want to play this with someone else until you’re past this stage or it will be really confusing.

It was a little more boring but definitely necessary to playtest with minimal rules and see how those functioned before having too many variables to really see where problems lie. It also helped me realize which additional features were really necessary. This playtest is probably the clunkiest one you’ll have as some things may really not work at all, and some just need real time tweaks.

Refine the rules and add more content as needed



Once i’d had a chance to work out the kinks of the basic mechanics and content, it was time to introduce the larger set of rules, knowing that those would help reflect on the flexibility of what I had already play tested. The content that really worked out best was the ones that slightly altered play, but made the opponent much more difficult to predict and created enough uncertainty to keep it from being a total look-ahead game.

This area is one where it was important to pay attention to feature creep and rules getting more and more complex. I think the game still needs more polish and subtraction to feel smooth and elegantly designed instead of a bit lumpy. Always important to keep in mind how much mileage you get out of any complexity you add, especially in a board game, where the player has to manually manage that complexity. The more weird exceptions and extra rules and ability or mechanic adds, the less its worth compared to how much more interesting it makes the game.

Play test different solutions to any problems that come up



Now of course the iteration process. Iterating can always feel like a 2 steps forward, 1 step back affair as every “fix” can crop up as a problem somewhere else. This is why its always good to take a subtractive approach and look for things you can remove, especially things that would when removed, would also remove the necessity for a lot of rules and exceptions. For a good example of this, see the recent 2nd edition of Pandante by Dave Sirlin, where he removed a lot of small things that certain rules only really existed to handle. As a result the game is much better and easier to teach and play. Just remember that it’s always better to subtract before you add!

Final Verdict

This was a useful learning exercise, and I hope to use future 3 day tests to better refine certain skills and refine the process. I hope this has also served as an example of someone using the process besides the author and instead of it just being an abstract idea. Have fun and never stop pushing game design forward!