Card Design Commandments

Post by: Grant Rodiek

I have a thing for card games. I like playing them and I like designing them. Every time I try to veer away from cards to tackle another component like dice, I always end up right back with a box full of index cards and penciled scribbles.

As I design card games, play card games, and give advice to other designers about their card games, I see a few patterns emerging. There are key design mistakes that many of us commit repeatedly, so often that I thought it’d be good to compile a list of guidelines. Obviously, rules can and should be broken, but if the following rules are used as a base line, I believe your games will become more fun more quickly.

Text should be easy to read: Two smart individuals, Chris Farrell and Daniel Solis, have already written about this (and many topics in this post) at length. Honestly, you should read both of their pieces and then return to this one.

Bottom line, it should be incredibly easy for people of all ages to read the text on your cards. Pick a sufficiently large size for your text and stick to it. If you run out of room, I suggest the first change you make is simplifying the rule of the card, NOT decreasing the size of the text.

Use icons where possible: If you’re using a term or rule often, create an icon. While designing Poor Abby Farnsworth, I created a spreadsheet where I listed all terms I used more than once. From there, I condensed them further and created a list of approximately 10 icons to convey these terms.

Good iconography saves space on cards and immediately gives the player an idea of the card’s purpose at a glance. Not everything needs an icon, but it’s a good exercise to determine what you can convey with a small, simple icon. If you’re not a graphic designer (I’m not!), use Google Drawings. They have a small collection of symbols that you can layer and change colors. You can begin testing your iconography even with the ugliest prototype.

Sample Poor Abby proto card

Sample icons I made for my prototype

One game that uses icons fairly effectively in my opinion is Eminent Domain, designed by Seth Jaffe and published by Tasty Minstrel Games. Observe the amount of information conveyed purely through iconography: the cost, requirements, victory points, and card bonus type.

That’s a great amount of information to process, but luckily this is an advanced card. Another good example is Elder Sign, published by Fantasy Flight Games. Notice that there isn’t a single piece of gameplay information conveyed with text on the top card.

Brass is an excellent game with two types of cards: One with a type of improvement allowed and one with a city specified (shown below). These cards provide a huge array of choices, yet are painfully simple when viewed.

Limit each card to 1-2 rules per card: This is an easy and often necessary rule to violate. However, it is potentially the worst rule to violate based on the audience for your game.

Here is a scenario: Each player has a hand of 5 cards. Each card can be played in 1-3 ways, as defined by their rules. There are 3 cards already in play, each with a unique piece of information. Players now need to track 5-15 Rules based on the cards in their hands AND the information from the cards on the table.

Overwhelming! Complex! Unnecessarily complicated! Obviously, you can point to Race for the Galaxy, ranked #13 on Board Game Geek, and tell me I’m wrong. However, this is a polarizing game (for some) because of multiple ways each card can be played and I’ve heard from many people that the game is really difficult to learn.

I’ll propose a more vague compromise: Be aware of the amount of information you’re asking your players to process and understand. Make sure you’re not asking your players to take on more complexity than the game is due. The worst place you can be with your design is High Complexity, Low Depth.

Stick to established terminology: This is one of the most common mistakes I see amateur and new game designers make.

Many designers change established terms for the sake of innovation (Note: This isn’t innovation) or for the sake of flavor. Don’t! Your game doesn’t need flavor when it comes to learning the game.

What are the established terms? For me, I look to the most popular games. If you’re designing a card game, I suggest you read Dominion‘s rule book. If you’re making a war game, take a look at Memoir ’44. Notice that the Flash Point rulebook is very similar to Pandemic‘s — GOOD. The rule book or terms are not where to innovate. Differentiate your game through mechanics and experience.

I played a game recently where the rules used Discard, Destroy, and Trash completely differently than Dominion. Three of the five players at the table were immediately confused and we had to stop the game to look it up. As a result, we had less fun.

Don’t force players to track card actions: This is a mistake I make constantly in prototypes. You should design your game and each card such that the player can take the action indicated on the card immediately. In the initial implementation of Farmageddon‘s Foul Manure card, players had to track the card for 2 turns. Fiddly! Another example is that in Poor Abby I created a card that said something along the lines of “If during your turn this thing happens, then do this thing.” You’re now forcing the player to potentially keep track of something.

Here’s the better implementation: “If this condition is the case, take this action.” Or, “When this card is played, take this action.”

Dominion actually violates this rule constantly with cards that add Actions or Buys. It’s not really a problem (obviously, as the game is flying off shelves and is awesome), but there are times when keeping track of my Actions is lame. This is a refinement I really appreciate with Ascension.

Clearly separate flavor text from rule text: I think some designers are really just storytellers. They create a card, write pages of flavor text, then remember they are making a game. It’s important that you take pains to clearly differentiate your rule text from flavor text so there is little confusion.

Gubs, designed by Cole Medeiros, does a great job of this. Notice the flavor text is tiny and at the top of each card. The functional rule text is boldly called out at the bottom. Players know to always look down to learn how to play a card.

Epic Spell Wars of the Battle Wizards: Duel at Mt. Skullzfyre takes it a step further. They let their outstanding art act as the flavor text. Why read when I can look and let my imagination create a richer story?

Each card’s purpose should be relatively apparent: This rule can be read in a variety of ways. I’m not telling you to make your game’s strategy brain dead obvious. I am telling you to not be so subtle or “clever” that your players cannot figure out why they’d use the card.

The other day we were playing a card game in which two of the five players could not understand the purpose of most of the cards in their hands. “Why would I ever play this card?” was uttered multiple times. Three rounds into the game, one of the players finally understood the cards.

This is another rule where you want to properly align the complexity and depth of each card within the acceptable realm for your target audience. I think the design sweet spot is to design your rules and card such that players draw the card and immediately say “Ah, I use this to do X.” But, as they play the game multiple times and really learn your design, they begin to see that it can be used in a variety of ways that subtly change things.

I think the Foul Manure card in Farmageddon is one of the best cards I’ve designed because of this. The first time you read it you think it’s a shield, which it is. Then you realize you can play it alongside Dust Bowl or pair it with Genetic Superworm to maximize its effectiveness. Or, you can play it offensively to hinder an opponent. The card has one rule, but multiple uses.

Maximize players’ chances of having interesting choices: If you’re designing a game with cards, you’re designing a game that’s a slave to probability. There are no guarantees with probability, but you can maximize the chances of desired outputs occurring.

You never want a player to take their turn, look at their hand of cards, and say “I guess I’ll play this.” Every turn should present the player with interesting choices. What to play? How to play it? Who to target? And so forth.

Make sure the allocation of cards in your deck is such that players have a high number of attack cards (if your game features such a thing), or defensive cards, or preparation cards. Furthermore, make sure the allocation is such that everyone has a fair chance of winning regardless of the cards drawn. People will quickly tire of your game if the perception is such that players believe a particular card grants the victory.

Which rules did I miss? Which rules did I present incorrectly? Which ones do you think are most important?

4 thoughts on “Card Design Commandments

  1. Grant, I think you nailed this, but as we say in editing, “Good writing is knowing when to break the rules.” But as we say in the grammar world, “You have to know the rules to know when it’s okay to break them.” These are a great start.

    To your icon point: I’ve found that icons are harder to teach but ultimately make for much smoother gameplay. 7 Wonders is a beast to teach the first game, but moves like clockwork the second.

  2. While I understand how icons can be helpful, I seem to have a hard time picking up on them at first (as FarmerLenny stated nicely). Of course, a small-target visual identifier will allow your brain to fly once trained … but the training can sometimes be frustrating.

    There are 2 things that seem to work best for me when first learning a game: (1) A single-word identifier next to the icon, such as “Cost” or “Energy” … and I do understand that can be an issue for a multi-lingual game … and (2) Having the shape of the icon resemble what it is representing, such as a stack of coins, or a particular resource.

    As I work on more complex designs, I am hoping to get better at these types of things.

    Thanks for the interesting read, Grant.

    -Matt

  3. Pingback: Game Design Theory: Play Mechanics | Pearltrees

  4. Pingback: Game Design Heuristics | Pearltrees

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>