Post by: Grant Rodiek

I haven’t written many theoretical/philosophical posts lately, but I realized that I’ve modified my design habits in the past few months and therein lay a topic worthy of discussion. Note: I fear I committed a grammatical atrocity in the previous sentence. 

Between Battle for York and Blockade I shifted my approach and outlook. Regarding the outlook, I cast aside my desires to self-publish and instead decided to focus on getting published. With Farmageddon and York I produced and pitched mature games. Not final or without need for refinement, but I developed them extensively, tried to smooth out a million issues, and pitched them as such.

I found this method exhausting. I put a great deal of pressure on myself to get the game across the finish line (or a potential finish line) based on my own goals and instincts. This is difficult! I fear this also wasn’t aligned with my target audience’s desires, namely, publishers. (Many) publishers are looking for:

• A game. They need to see the loop, the strategy, the foundation. They do not want a mere idea (Unless you’re awesome and established). The game can be a small percentage of the final product. You see that distinction?
• A hook. They need to see why it’s unique and what is going to move the game off shelves. This can be thematic, mechanical, or presentation-based, but ideally, a little bit of all 3.

If you think about it, that’s all you can really discuss in a 15 minute pitch. The more details and junk you add to this foundation, the more you detract from the hook. You’re also creating more opportunities for them to not like your game. It’s like winning a (hypothetical sitcom) girl’s heart with your pickup line, and losing her as she learns more about you. Shut your mouth and dance already!

Therefore, for Blockade and Flipped and Draftaria, my goals are simpler: Build what I need to demonstrate the game. Build what I need to demonstrate the hook. Sprinkle in a spice or two to demonstrate where the game can go. But don’t cement these spices such that, if a publisher doesn’t like that direction, it’s a hindrance to obtaining a publication deal.

Let’s look at an example from Blockade to show you what I could have developed, but haven’t yet. These are the the things I haven’t yet done:

• Ship equipment variations. There is no ECM, Shielding, Afterburners. Just guns.
• Fleet Building. Without the above bullet, there’s no fleet and squadron building.
• Sandbox Campaign mode.
• Advanced firing mechanics, like focused fire.
• Mid-scenario reinforcements.

All of that sounds really neat, and I desperately want to mess with them. But, I demonstrated restraint and focused. Instead, here are the things I HAVE built:

• Turn taking/activation mechanic. This has gone through about 5 big iterations and I’m very happy with the current mechanic. 
• Board design. About three iterations.
• How to attack. Mostly minor tweaks.
• How to maneuver. About three iterations.
• How to change formations. About three iterations.
• Action cards. Constant iteration.

This looks like a sad, underwhelming list, but it has helped me bring the game to speed rather quickly.

So far, the results have been very promising. I’m doing this now for Flipped. As my core is solid, I’m able to completely extricate mechanics and replace them with others. Why? Because everything is simpler. Tonight as we speak I’m re-designing my scoring model with something a bit crazier. Why? Because I’m able to do so and the game needs it.

Let’s use another game as an example. If you’re familiar with Memoir ’44, imagine if Richard Borg created a version of the game with:

• Basic cards that indicated how many Units to activate and from what flank.
• How to move.
• How to attack with infantry.
• One terrain type (let’s say forests).

You could see the game there, at least enough to say “let’s publish this.” You actually wouldn’t need any of the following features that shipped with the game to demonstrate the structure and hook of Memoir:

• All terrain types.
• All Unit types (Infantry/Artillery/Armor or any of the expansion one-offs).
• Special movement cards that interrupt or do things other than indicate Units to activate.
• Star-related ability cards and dice rolls.
• Scenarios.

The hook of Memoir ’44 is that it’s a highly distilled game of maneuver and focusing fire by best utilizing cards that indicate the number of Units you can activate from the three flanks (left, center, right).

The result of this process has been really delightful for me. I’m getting my games “stood up” more quickly. I’m able to iterate on core, fundamental elements without having to balance within a highly complicated structure. If you need to re-size a cog and you have 15 cogs, that has cascading implications. If you have 3 cogs, it’s much easier.

One of the reasons tweaking the battle mechanic in York has always been so difficult is that it needed to be factored into things like turn order, number of actions, available general actions, available faction actions, scoring phases, and more. By reducing the number of variables, I’ve been able to make better improvements more easily.

My games are also easier to explain now, both to playtesters and publishers. If I’m emailing a contact, I can share a few images that provide the gist of the experience and save them the effort of combing through my lengthy rules document.  If you check out my picture walkthrough of Flipped, you’ll see what I mean. Or, maybe you’ll look at it and think I’m full of poorly designed stuffing.

This also means my games take less time to build. I don’t know about you, but laziness is sometimes a factor in my designs. Flipped was a very easy game to prototype, so I built it. Drafty Dungeon was a painful game to prototype, so I set it aside. By focusing on the core and foundation, you’ll set yourself up for less work. I know the real version of Draftaria will need a metric pile of cards. But, I can demonstrate the game’s core with a very small number. This isn’t how I made York or even Farmageddon and as a result, they took much longer to craft.

Here’s the takeaway. It’s not unique to me or this post, but it bears repeating.

• Build the simplest implementation of your game.
• Build with a focus to your hook.
• Build with a focus to fun.
• Don’t get caught up in the potential. Get caught up quickly in what’s real.

As you prove these small mechanics, you can layer on additional content, factor in more complexity, add asymmetry, and worry about replayability.

Think big, build small.

Thoughts?