Minimum Viability

Or, Design Series Part 2.

Overview: This is the third of several articles on the design of a new board game that I am working on in partnership with Brendan McCaskell and OOMM Games. Throughout these posts, I want to give readers a sense of my design process, as well as some of the ruminations that came out of work I was doing at each stage. Check out the introduction to this series here. Today, we’re delving into the creation of a minimum viable prototype of a board game, and how to avoid doing to much, and what to do when you do too much anyway.

What is a Minimum Viable Prototype?

Pictured: Everything but the kitchen sink, which is behind me.

For board games, I define a minimum viable prototype as the set of the fewest number of components that are needed for a player to have the experience of playing that game. For a minimum viable prototype, I am taking as an assumption that you, the designer, will be at the table, and can act as a living reference guide. This means that only the components that you cannot adequately act to replace on the spot are needed. This is somewhat subjective, and deciding whether an element is superfluous or vital depends on knowing what you want the heart of your game experience to be.

For a concrete example, a minimum viable prototype of chess would likely be a board and differentiated markers with piece names written on them. As the designer could explain each piece’s special rules and the general rules for the game, a rulebook would be superfluous for the minimum viable prototype stage. The designer would have to decide whether or not aesthetics are an integral part of the experience they wanted to create with their new game of “chess,” which would determine whether or not some sort of graphic simulation of the eventual pieces would be needed – but given what we know the experience of chess to be today, I think one could reasonably dispense with them and use just text to differentiate pieces.

For Codename Lithotaph, pictured above, one example of planning to the needs of the minimum viable prototype was laminating the terrain tiles. Suddenly, any token or marker could be replaced by simply writing on the tile with a dry-erase marker, saving me needing to make tons of tokens for the various terrain types, statuses, and other elements the terrain tiles might take on during the game.

As a sidenote, if you’re building a minimum viable prototype on Tabletop Simulator, substitute “digital” for “physical,” but if you intend for your game to be physical in the long run, I personally find it pays to actually go through the arts-and-crafts early, for some reasons I’ll discuss below.

When Is Going the Extra Mile Necessary?

The numbers are because there is a 0% chance I’d have glued the fronts/backs together correctly without them. Know your strengths and weaknesses!

A key objective of the minimum viable prototype is to be… minimal. It is right there in the name, after all. Why is that important? Because if your design process is anything like mine, you’re going to iterate a lot at this stage. The image of a squirrel digging through a dumpster, haphazardly tossing half-intriguing scraps in every direction, springs to mind. So getting each version’s minimum viable prototype to the table quickly is important, and any given element you spend a lot of time on might not be worth keeping.

But sometimes, you need to feel a specific component in your hand to know the experience it’s going to create. That’s where you occasionally need to risk overdesigning a bit because it’s important to the game’s core.

For Project Lithotaph, I knew that I would need a set of board tiles that looked at least decent to get the feel for how the game would come together. Exploring the valley is a huge part of this game, and placing tiles together to form a map is the main way the game draws players into this experience. I am not a (good) graphic artist, but I have basic knowledge of a few image editing programs, so I drew up these tiles.

I then spent a lot of time printing these out, cutting them , and gluing them onto punchboard before realizing the really obvious problem…

Making the Best of Going Too Deep

So you screwed up creating a regular hexagon…

One thing I’ve found is that sometimes I need to overindulge on details at this phase. Or maybe it’s more apt to say I’m going to do it whether I intend to or not. But whatever the case, the experience of the sort of games I make comes alive in the details. What do I do when I’ve made some component, spent two hours cutting, gluing, and cutting again only to find the hexagons don’t fit together?

This is where I had to decide whether the remedy to my screwup was decide it’s good enough for now or reuse what I can but cut my losses.

A lot of the time, good enough is your friend for a minimum viable prototype. When I changed the name of “stamina” to “fatigue” before the first test even happened, I didn’t reprint the components corrected, I just told people “stamina is fatigue” when we played. When I eliminated whole systems from the prototype because I realized they weren’t core at this stage, I just crossed out references to them on components I’d already printed. These issues were nuisances that didn’t interfere with the core experience. Aesthetics are important, but so is getting the prototype to the table.

But the tiles not fitting together was a bit different. I could already see the writing on the wall that that was grit in the machinery of a key system, and it was going to cause real friction that the final game obviously wouldn’t have, distinctly changing the experience of playing the game. Since I was after seeing how well the desired experience I had in my head came out of the game I had drafted, I knew I needed tiles that actually fit together. So I pivoted: what was the least amount of work I could do to make the irregular hexagons work? I initially cut one down to a regular shape (always repurpose when you can!), but that proved to be more effort than remaking them entirely, so I ended up cutting my losses and remaking them and tossing the last set back into the Big Box of Prototyping Components for some future project. Who knows, maybe I’ll even need irregular hexes someday.

What’s Next for the Codename Lithotaph Design Series?

Next article, I’ll be taking a break and fielding some questions! Curious why the Codename is “Lithotaph”? How I organize a my files? Designers and games I find inspiring? Whether I like cake or pie better?

Hit me up at my email, or over on Twitter, with your questions about my game design process, this project, or other topics!