Undercoding and Overcoding Your Game's Visual Language


Yesterday I wrote a long post on the value and methods of double- or triple-coding your game's visual language. Now here are some pitfalls to watch out for, using some real world examples.

Above is an example of undercoding. Apples to Apples uses only two types of cards in play, each one is a different color: Green and red. Like apples, get it? Makes sense for the theme, but it's also the most common type of color blindness. Take a look at the same image on the right and see if you could distinguish the types of cards at a glance.

Solutions: These cards could have been doublecoded by using a unique illustration for each deck or rotating the layout on one of the decks so it's horizontal.


And here's an example of overcoding. Megan and I really tried to learn Race for the Galaxy from the rules document. We eventually figured out how to make it through a few sessions, but each time we spent a lot of energy just deciphering the numerous symbols and icons. In the end, we spent more time learning the game than actually playing it, which is a shame because I know a lot of folks who swear by RftG.

Solutions: Hard to say, really. There is a LOT of information to get across on a tiny card, so simply writing it all out in plain language may not be efficient. Still, constantly referencing the visual glossary is a huge stumbling block to fluent play. If I were designing Race for the Galaxy from scratch, using all the same rules, I'd probably make it a big box board game. Freed from the constraints of a deck of cards, we could use a board, tokens, pawns, trackers and other implements to help make the learning curve a bit more shallow.

That brings up a final point. Doublecoding can't solve everything. If your game is so complex that it requires a vast visual language, look at the game's design first and see if it needs to be playtested more. If you're satisfied by the game's rules and still need that large language, then look at other format for your game. You may be surprised to find that you're actually making a video game!

Next, I'll talk about how I used coding in Belle of the Ball, taking lessons from all examples.
Daniel Solis
Art Director by Day. Game Designer by Night.