Design Muscle Memory

This post sponsored by the Hocus Poker PNP! Download it from BGG (and give us a thumb!) or read the rules.

Design should become easier the more you do it. No, conceiving a unique mechanism is never easy. Identifying that killer solution to a terrible problem is never easy. But, there are dozens, even hundreds of tiny steps that you can begin to ignore if you're honing your craft and paying attention. Well, ignore is the wrong word. You won't think about them because they'll be ingrained in how you make every decision.

Today, I wanted to share some basic things I think are a part of my muscle memory. The hope, is that by taking advantage of this muscle memory to quickly move past the basics, you can more easily start work on the hard part - crafting unique mechanisms, experiences, and balancing your game!

Here are a few examples.

Card Design: A great start for new designers is a card game. Everyone has owned a deck of bicycle cards, or played a CCG, or played some form of card game. They are immediately accessible and require few components, which is great for new designers.

There are many subtle things I've learned about cards in my design travels! Some of them include:

  • Use clear 1-2 word card titles. Keep them short and simple. Make sure titles are easy to read and pronounce. If players have difficulty reading or knowing what the title means, they might ignore the card in their hand. Yes, they will!
  • Good titles should reinforce the function of the card. Pesticides, to most people, are connoted as a bad thing. Good titles can act as a bookmark in the player's mental encyclopedia. With repeat plays, they'll see this title and will remember what the card does.
  • Limit the number of functional areas. Let's assume you know to limit the overall amount of information on a card. However, it's easy to squirrel key pieces of information in different parts of the cards. Train players to look in 1 or 2 places max!
  • Key info on the left...usually. Players often fan cards such that the left side of the card is visible. Be careful about tucking key info in the right-hand side. There are exceptions! Magic puts their card cost and creature attack/defense on the right.
  • Think about key terms. Develop a language for each game, being careful to not screw with common terms used in other popular games. Key terms save words, especially when you're explaining key concepts over and over (like Draw, Discard), and constrain you, the designer, with a tool box. How can you be creative with the 5 key terms you've established?
  • Think about icons. If you're going to use a concept often, very often, and it's dead simple to convey in a single icon? Consider incorporating it. Money is a classic example. Everyone understands "Get 4 <Money icon>."
  • Make card text concise. You and a tester are falling off a cliff. I don't know why you're in this position, but make the most of it. How are you going to explain the card? The more words, the more people can misinterpret. Using your key terms, your icons, and concise language, say what you need to say. You can gate yourself by creating prototypes with 12-14 point font. You'll run out of space quickly. It will force you to write better.


In the above mock up, the blue squares represent potential areas for you to place functional information. Pick 2 of them! 

I think Dominion exhibits a "best in class" for good card design and it's never far from my mind when thinking about a first pass layout. You can see a very simple title at the top. Many cards, like Upgrade, Trading Post, and Torturer cue you into the card's function. You have 2 key areas: purchase price at the bottom and function in the middle of the card. Everything else can be ignored. The game uses a handful of key terms, like draw, trash, discard, and action, so you can quickly ascertain a card's function. Finally, they bold simple actions, like "+3 cards" or use the gold icon to quickly communicate "this card gives you money" or "this card gives you cards."

pic496639 Cards from Dominion by Rio Grande Games

Netrunner is a far more complex game that also adheres to many of these principles. You see icons used for Trash, Clicks, or Credits. They use the top left of a card and the middle for most information, with a third piece for Trash or the Strength of Ice. They use a series of key terms to keep text short. Netrunner offers a cliff-like learning curve, but thanks to fantastic use of a few icons and key terms, that cliff is lessened.

Note: For that last comment, I'm referring to terms like Click, Install, Rez. We can debate HQ, Grip, and Archives for hours and that's a topic for another post. 


The above pictures are from Android: Netrunner by Fantasy Flight Games.

Mechanism Design: When designing mechanisms, it's very simple to explain the idea in your head, play a test hand or two, and spend months working on it before you write the rules. But, it's very simple to forget that you will not ship with every copy of your game. Don't kill your creativity or brainstorms, but begin to pair mechanism creation with mechanism explanation.

When I design a new mechanism, I ask myself these questions. Often subconsciously, as it's just a part of my process.

  • How will I explain this in my rules? How many words will this take? Is the weight and importance of the mechanism equivalent to its weight and complexity in my rules?
  • Does this mechanism add sufficient fun for its complexity and weight?
  • Does this mechanism give me something unique, does it increase the fun, or does it solve a problem?
  • Does this require a diagram in the rules?
  • Does this require examples?
  • Does this require a reference card?

One of the most controversial elements of York, before I licensed it to Portal, was the fact that turn order was determined at random. This drives some people batty! I experimented with several alternative solutions, but all of them were too complex and too wordy for what they added. Random turn order was both simpler, more fun, and appropriate for what I needed. I arrived at that conclusion from testing, but also answering my questions.

Note: Portal has come up with an awesome solution that preserves the experience of random, but is cleaner and more compelling.

In the very first version of Hocus, we had an increasing cost mechanism that was created to make less-used spells a more enticing option. It was a subtle mechanism that did the job well. It was also insanely confusing for so many of our testers. We tried literally dozens of ways to explain it, represent it, support it with components, and more. People really struggled with it. Now, we know that, and we'll think twice about similar mechanisms in the future.

Many of those questions above are questions potential publishers will be asking themselves when they are considering your game. They aren't just asking if they can have fun, but whether they can explain this to customers, if the complexity level is right for their target audience, and whether they have the component bandwidth to support your mechanisms. You should have answers for those questions before they arrive at an answer that eventually means the same thing as "Not interested."

As you grow more experienced in your designs, you'll have fewer instances of "I'm doing this mechanism because I can." Instead, because you're doing things with purpose to save time, you'll have more instances of "I have this mechanism to improve balance," or "this mechanism exists to create a story," or "this mechanism is the key decision point for players." And so forth.

Probability: Probability is a wonderful tool and one of the most devious bests facing every designer. Over time, you'll find your handle on probability will greatly expedite the pace at which your prototypes become enjoyable.

For example, dice rolls! If you want you combat to move along quickly, be decisive, and have few wasted rolls, you probably shouldn't go below a 50/50 hit chance (assuming a single die roll). Even with a 50% chance, you will find that things will rarely happen 50% of the time, but might instead work out to be 10% or 20%.

You'll also find that perception of progress has a heavy hand here. If players roll 1 die, and hit on a 50% chance, combat can be maddening. But, if they roll 3 dice and hit on a 50% chance, that's much better. See Memoir '44 when attacking infantry. In Memoir or Summoner wars, which have up to a 50% (for infantry) or 66% chance (per die) to land a hit, you're always making progress. You rarely kill an opponent of substance in a single hit, but you'll steadily plink away and deal damage.

One of the criticisms I think is fairly leveled against Eclipse is that combat can take forever. A large battle towards the end of the game may have 5 or more dice rolling rounds, with over half of them resulting in no change of state. Players want to see progress being made, otherwise the game feels broken.

A good counter-example to my argument of 50% or greater is Space Hulk. In this game, Space Marines kill a Genestealer on a roll of a 6 on a six-sided die. This 1 in 6 probability is balanced by a few things.

  • The Genestealers have 1 health. If you hit them once, they die.
  • Combat is often a series of 2-4 rolls. If you continue firing, you hit on a 5+, which is much better odds.
  • A primary component of the experience is the charge of the Genestealer down a hallway to close to melee distance. A single Genestealer on the board is actually an abstraction of many Genestealers. It isn't that you aren't killing any in the fiction. It's that you didn't stop all of them. Space Hulk is essentially Aliens -- think to the scenes where overwhelming firepower still barely hinders the Xenos.

When designing  a game with dice, I use my muscle memory to support the experience I want. I complement this with tuning on other elements. With Sol Rising, ships can sustain 4-5 hits, which means I want them to take damage often to make progress possible. In a game like Memoir, there are usually just 3-4 Hits per Unit, so it should be a little slower. And so forth. Leverage your experiences to set your initial probability to a level that supports the game you're trying to make.

Conclusion: I fear this post is growing a bit lengthy and hopefully I've made my point. What do you think about muscle memory? What are some examples of YOUR design muscle memory? How do you get to the important stuff in your design more quickly? Share in the comments below!