Polish

Welcome to the final part of a 6 part series on Collectible Game Design.  If you are just joining us, here are the other parts:

Part 1: Overview

Part 2: Engine Design

Part 3: Engine Development

Part 4: Component Design

Part 5: Component Development

If you’ve come with us this far, you’ve got a pretty awesome game.  You’ve crafted your vision, defined your parameters, brainstormed countless ideas, prototyped and iterated on them repeatedly.  With each phase of design, your cycles got tighter and tighter, focusing on more minutiae until the entire system hummed.  Now is the time to put the final touches on your game and make it ready for sale.

THEME

basic-product-mockup

This week, our new game You Gotta Be Kitten Me is hitting stores.    The core game mechanics are pretty simple- Players bid on the number of a given symbol or color they think are in everyone’s hands.  Each player must in turn raise the bid or challenge the previous bidder.  If you lose a challenge, you lose a card for the next hand.  The last player with cards left wins.

The game took about 18 months to develop, but the game mechanics were complete within the first 6 months of development.  What took so long was figuring out that final polish – the theme and look for the game.   The game is light, social and quick to play, making it appropriate for families. It also has strategic bluffing and hand-reading elements that appeal to more traditional gamers.  We wanted a theme that could help us reach both audiences.  We went through many iterations before settling on the final design.

Here are some never before seen behind-the-scenes looks at the themes we developed along the way

8-bit-card-mockup-3-a-d bowler-red-2 wild_ideas_1 yeti-card-mockup-3-a-d

The above themes in order: “8-bit Crook”, “Schrodinger’s Hats”, “Liar’s Cards”, “Are We There Yeti?”

As you can see, each has a very different look and feel, potentially appealing to different audiences.  We even took the Shrodinger’s Hat prototype to a convention to get direct feedback from customers before finally deciding on You Gotta Be Kitten Me.  Designing a theme is just like designing a game.  You need to go through the Core Design Loop to brainstorm ideas, prototype, and test them until you find the right one.

ART, NAMES, STORY

Once you’ve decided on a theme, the next step is to commission the art and flesh out each component into a full character in whatever world you’ve created.   This is where the 6 cost creature with 6 attack and 4 health becomes a “Craw Wurm” and where abstract numbers and effects become dragons, spaceships, and kittens.

Much like when building structure during your initial design process, when building a collectible game, try to connect and build structure in your characters, art and background story.

This helps your world come alive and gives players things to discover as they dig deeper into your universe.  Some tips include:

  • Have a bigger story in mind.  Put your characters into context and set expectations that can payoff later.
  • Have key characters recur to reinforce their importance (e.g. in art pieces, names, etc.)
  • Create cycles with names and art that parallel mechanics (e.g. The Apprentice cycle in Ascension are all 1 cost heroes that show a novice training in their respective faction)
  • Seed evocative references in your names and story text.  The players may not know what these mean, but they will be intrigued to learn more. (e.g. Oros, Deepwood’s Chosen; Freyalise, Llanowar’s Fury, etc.)

When building my games, I try to have at least 3 years of story sketched out before the first release. This helps as I design future releases and keeps the world coherent.  Even if you never deliver on the complete story, the structure is valuable to guide your decisions.

GRAPHIC DESIGN AND LAYOUT

Spend time iterating on the specific layout of information for each of your components.  Many designs end up cluttered and confusing.  Here are a few tips to help focus your graphic design process:

1. Priority rank each piece of information in order (e.g. Card cost, attack, health, textbox, name).  Make sure that your design emphasizes the right information

2. Avoid clutter as much as possible. Avoid adding extra flourishes, symbols, and components that don’t serve a purpose to the player. Less is more.

3. Draw the eye to the most important information. Good layout should naturally make the player want to do what they are supposed to do.  

TEMPLATING AND COMPREHENSIVE RULES

For me, building out story, characters, and art is a really fun process.  It reminds me of my old days of playing Dungeons and Dragons.  Creating worlds, characters, and epic plots are some of the things I love most about my job.

The last piece of polish, however, is a bit more of a grind.  When first working on a game, I will use a lot of shorthand for what a card does.  Everyone in my playgroup knows what I mean and if they don’t I can always clarify.

In the real world, players won’t have your same background assumptions and you won’t be in the room to answer their questions.   This is why it is important to have a clear consistent template for your text backed up by comprehensive rules that help avoid confusion.

COMPREHENSIVE RULES

Comprehensive rules are read by only a small part of your player base, but they provide the foundation for resolving disputes and making sure the whole game “works” even after hundreds or thousands of cards or components get created.  This article doesn’t have time to go too in depth on comprehensive rules writing (let me know if you want to see an article on that). For now, think of comprehensive rules as the underlying code upon which your game “program” runs.   

TEMPLATING

The beauty of a collectible game is that each card and component is able to change the rules and thus create an ever-changing play experience.  But, when each card can change the rules, it is more important than ever to be clear and precise when describing each card’s effect.  Being precise with your templating helps players access your game and understand what is going on.

For physical games, precision of language is about answering four basic questions:

Target: Who does the effect apply to?

Timing: When does the effect happen?

Script: What does the effect do?

Source: Who/what is the originator of the effect and what traits does he/it have?

Answering these questions thoroughly can lead to some long and cumbersome text boxes and you will often have to make difficult trade-offs when deciding how to template your effects and rules.  Here are some considerations to keep in mind

Concision vs. Clarity- Answering the above questions in detail and with precision can be cumbersome.  Consider the following example of two templates of the same effect:

TEMPLATE 1- Deal 3, Draw 3

TEMPLATE 2- First, this card deals 3 damage to target creature or player of your choice.  Then, you draw 3 cards from your deck.

The second text is 5 times as long, but more clear.  Which template is better?  That depends a lot on your audience and the nature of your game.  How relevant is each piece of information? How likely are your players to infer information you don’t want to spell out?  Can you imagine game scenarios where this template would be confusing?

Wrestling with these questions has lead to many heated debates around the office because, as silly as the distinction may seem, your early decisions in templating will have long-reaching effects on the types of cards you can create and how your audience relates to them.  If you choose to never identify Source, for example, it will be harder to create future mechanics that reference it.

Keywords and Text Compression– A common tactic in collectible games that introduce a mechanic used multiple times is to compress the rules text into a keyword.  Keywords are special game jargon that stand in place of a bunch of regular text.  The best keywords compress a lot of text into a word that is evocative of the effect.

A great example of this is the keyword “Flying” in Magic: the Gathering.  Here are the comprehensive rules for Flying:

702.9. Flying

  • 702.9a Flying is an evasion ability.
  • 702.9b A creature with flying can’t be blocked except by creatures with flying and/or reach. A creature with flying can block a creature with or without flying. (See rule 509, “Declare Blockers Step,” and rule 702.17, “Reach.”)
  • 702.9c Multiple instances of flying on the same creature are redundant.

That is a mouthful!  For most players, however, they will simply intuit what flying means- creatures with flying can fly over creatures without flying.  That one word compresses a lot of text in a way that doesn’t confuse the player.  Try whenever possible to use keywords that evoke the feeling of the effects you are trying to describe.

Physical vs. Digital Game-  Because digital games enforce the rules for you, the importance of consistency and clarity in templating is reduced (though not eliminated).  In digital games, it is generally preferable to use less precise but more readable language.  Players will learn the ins and outs of the game by playing.

Ship it!

ship-84139_1920

One of the biggest challenges with any game design process is deciding when your game is “done.”  There is always more time that can be spent refining, polishing, and improving your design.  It is worth spending time to make your game as good as it can be, but be careful not to let the perfect be the enemy of the good.  A good, completed game is infinitely better than a theoretical “perfect” game that never gets published.

The most powerful way to ensure your game gets completed is to set a deadline.  When you have a boss or a design contract, this is often done for you.  If you are working on your own, set one for yourself.  Work towards that date as though you were delivering it to a client or your boss and you’ll be amazed at how quickly you can get things done.  If you have a game you are working on, post a note in the comments with your committed date to get it ready!  I’ll follow up with anyone who commits and offer some support.  Good luck and have fun!

Leave a Reply

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