The 54 Card Guild: #6
If this is the first time you're seeing The 54 Card Guild, I recommend you begin with Guide #1. It will explain everything. All of the posts are tagged with 54 Card Guild. There is an active Slack group, which exists to brainstorm, pitch, and discuss games. There are over 25 people in it. It's a fun, casual supplement to this course. If you're interested in joining us, email me at grant [at] hyperbolegames [dot] com.
Welcome to Guide #6 of the 54 Card Guild! Do you remember back on Guide #5 when I said this post would quickly follow? Yeah, well, I grew busy yet again and it didn't happen. I'm the worst. But, Guide #6 is here now and we can dig in to one of my favorite topics, which is development and iteration.
Step One: THE VISION
I've been listening to Mark Rosewater's Drive to Work podcast and it has been quite inspirational for me. Who is Mark Rosewater? Only a 20 year designer veteran of Magic: The Gathering and the current Head of Design. You know, a design nobody.
In one of the podcasts I recently listened to, Rosewater said the following: "Development is optimization of the vision." That is an incredibly succinct and quite frankly perfect definition. If you take nothing else from this guide, remember those 6 words.
Well, what is our vision? We've been beating around this issue with the Outline, discussed in Guide #2 and the elevator pitch in Guide #5. It is difficult to define the Vision in a Webster's like sense, so I'll do so in a historical one: the Vision is your Alamo. If you're not from Texas like me, I'll explain further. The Vision is the point from which you won't retreat. It is the line you will not cross. It is your "not one step back." The vision is that which is sacred for your design, or the most important special sauce element.
Why do you need a Vision? It focuses you. It will help you make a call between Option A and Option B, because one of those will better preserve the Vision and the other might not. Frederick the Great said "He who defends everything defends nothing." Choose your battles carefully and win those you need to win.
Examples will help clarify this exercise.
In York, which is now Cry Havoc, to be published by Portal Games in 2016, my Vision was a 2-4 player war game that played in an hour, didn't include dice, is asymmetric, and is very aggressive and battle focused. How did that Vision steer decision making?
- When determining a turn order mechanism, I opted for the simplest version. This removed complexity from a non-essential part of the game (not battles), and added unpredictability to the game. You needed to conquer with the knowledge that your opponents might take a turn before you.
- Incentives are greatly skewed towards aggression, and the clock is ticking. You cannot win by sitting in Australia the entire game.
- Abilities are tuned to favor the attacker versus the defender.
- It is relatively easy to recover from attrition, so players shouldn't be overly cautious when it comes time to fight.
- Players are rewarded with bonuses for taking territory. The first player on the scene reaps the rewards.
For Hocus, our Vision was Poker plus Spells. We sought a game with its foundation rooted in poker, but surrounded with asymmetric and unique spells that rewarded skillful play.
- We had to remove mechanisms that overly rewarded players for being lucky.
- The clock is ticking and actions are limited. Players need to play decisively and cannot simply sit back and wait to cash in.
- Spells that were too similar to previous spells, or were obvious choices were balanced to require more decisions and thoughtful play.
If you've been following all of the Guides, you know that Project Gaia is my 54 card design that I've been designing and using as my example. Therefore, it's only fitting I define the vision for Gaia here.
Gaia is intended to be a self-contained game about pre-constructed decks. It is crucial to the vision that the game provide a huge amount of variety in deckbuilding, not just in what's possible, but that the decks are compelling, competitive, and intuitive. It must also feel distinct from existing CCGs, else players will simply play those instead!
You'll notice I tend to design my Vision around an experience. Where possible and appropriate I inject theme (York, yes, Hocus, no) and flavor, and I strive to have interesting mechanisms. But, I'm focused on how my players feel and how my game will be experienced differently than other games. I'm less an inventor, more a director. That approach works for me, but you might find a different origin orientation the superior choice for you!
Assignment #1: Define your Vision for your game. Try to do so succinctly. Can your Vision fit in a single Tweet? Your Vision needs to have as few parameters as possible so that it acts as a tool to narrow your efforts and aid you in development.
Step Two: DEVELOPING the VISION
If you're following the design diet I've been slowly laying out, you should be testing with other players at this point. You have a Vision and testing feedback, but now you need to leverage those two items in a way that leads to a better game.
Speaking at a very high level, development tends to have different priorities at different phases. This will vary for different designers and even games, but I'm going to propose some priorities for you now. In the future, I'll try to craft more specific Guides against these ideas.
Here are some good phases to develop against.
- Find the Fun
- Balance the Complexity
- Write them Rules
- Accessibility Testing
- Balance the Game
Find the Fun: This is the first phase of development and often one of the most difficult. In this phase, you're trying to see your vision expressed in game without a mountain of caveats and frustrations in a play session. You want to see an inkling of that idea that's been in your head for so long. This phase might take a very long time. It took us about 10-11 months to find the fun for Hocus. It took about 3 tests for Farmageddon. Your mileage may vary!
During this phase, feel free to experiment and take wild swings. Introduce vastly different methods of beginning or ending the game, different score conditions, and introduce and remove new cards with abandon. Don't create any sacred cows. The only thing sacred is the vision, which isn't tangible or expressed in any single mechanism. You should try branching ideas and see if Option A or Option B solves a problem better.
While you're experimenting wildly, you should still do so within the framework of the scientific method.
- Create a goal (hypothesis) for a specific test. What do you want to occur?
- Identify problems during the test. Take notes, ask questions, and find out why or why not that goal was satisfied.
- Try to isolate your problems and until you grow more comfortable, work against them one at a time. Some mechanisms are more difficult to isolate as they are core to the experience. But, where possible, try to isolate your issues.
- Re-examine your goals. Are they the right ones? Will they meet the vision?
- Ponder solutions to these problems. Then, implement them.
What I'm trying to get at is for you to test with purpose. Experiment with purpose. Branch with purpose. Don't throw spaghetti at the wall and expect Agricola to emerge. Know what you want, why you want it, and focus intently on reproducing that result.
Once the game is fun, you're ready to move on. How do you know it's fun? People are laughing, smiling, asking to play again. People don't cringe when you ask them to test. This doesn't mean the game is finished or perfect, but it's fun. It demonstrates your vision.
Balance the Complexity: This is a difficult phase and one that is learned, not taught. This is something you'll improve at as you make more games. It's something that'll become apparent after years, not individual tests, and is a true reward to the persistent.
The elements and mechanisms in your game do not hold the same weight or importance. As mentioned above, the battle mechanism in York was incredibly important. Turn order and scoring, less so. When I developed the battle mechanism, I never shied from complexity, exceptions, and new hooks. The battle was the most important part of the game and it was crucial to be awesome. But, I can only fill the "cup" so much! The cost to adding complexity to one item was that I needed to remove it elsewhere.
You'll frequently hear experienced designers recommend you have a single innovation in a game. More than this, and players will be too lost and unable to play. Make one new thing, then surround it with familiar things.
Always look to your vision. What is the single most important element in your game? What is the one thing you want your players to take away from their play? What is the thing that sets your game apart? Once you have your answers, you can make the right and appropriate calls.
A good way to gauge the appropriate level of complexity is to compare your design to similar games. Always be playing new games! Examine games that have similar mechanisms, play length, and price points. Why? One could argue that the same people who bought and enjoy those games might buy and enjoy yours! If you have a 16 page rule book when another 30 minute competitor has a 2 page rule book, you might be too complex. Not always, but maybe! If you're making an epic 2 hour game that is as light as Ticket to Ride, it might not be very successful. That's a long time to spin around so little complexity.
As you can tell, this is difficult to express. It really comes down to a gut feeling, an understanding of the competitive landscape, and watching how new people learn your game. If you find them still stumbling 20 minutes into a 30 minute game, you need to re-examine your complexity. Maybe. The obvious exceptions to this are Netrunner and Magic: The Gathering.
A key takeaway: do not be afraid of complexity. Do not be afraid of exceptions. There seems to be this movement that the best designs are the simplest, that there should be no exceptions, that elegance is to be prized above all things. I disagree. Exceptions are a tool and like all things, can and should be used in moderation. I often find that a game is good because of those 1 or 2 exceptions the designer introduced for a really good reason. It's okay for your game to be complex and to have a learning curve. If it's good, people will return. It's really about finding the right level of complexity. If you plant a mountain on someone's table, be darn sure there's a payoff.
This is why we return to the Vision. What is the game you're making? For whom? Why? If you know that, you can use it to guide your mechanical complexity.
Write them Rules: At this point, you really need to think about your game in a more final product sense. How will people learn your game? By reading the rules. That means you need to be able to explain your game in a written format.
Mark Rosewater (that guy!) noted that as an interview challenge, they have people write the rules to Rock, Paper, Scissors. You might roll your eyes, so I challenge you to take a minute to write the rules for Rock, Paper, Scissors. Once you're finished, read them and see what you missed. See how you explained the complexities of orienting one's hands, dealing with tiebreakers, or deciding how and when to display your hand.
- One-Two-Three-Shoot (show on shoot)
- One-Two-Three (show on three)
By the way, option 1 is correct. Oh, and does somebody count aloud? Who? How is that decided?
I have changed mechanisms in the past because I was unable to explain them succinctly and clearly. I tend to write rules earlier, but not everyone does that. If you wait too long to write them, however, you'll miss a very crucial examination of your game -- how it is taught to others.
Write your rules and examine your design through the lens of instruction. Can it be taught to others? When others read your rules, do they play appropriately?
Accessibility Testing: At this stage you have a mature design. Your game is fun, it has the right level of complexity, and you have some rules. Here is when I start testing with non-gamers or novices to see just how difficult things are. This is where I see what impediments exist to learning the game and having fun.
Sometimes this changes my mechanisms, sometimes it simply varies the starts, and other times it just affects the graphic design. Accessibility testing is a great way to snick off the rough barbs of your design. Unless an item is incredibly crucial, you might find you've been holding onto something unnecessary.
This is a great time to test:
- The layout of your cards. Is the information presented with the correct hierarchy?
- Colorblind friendliness. Can the colorblind play your game? Can you introduce symbols and vary your color palette to make it more accessible?
- Diagrams in your rules. A picture is worth a thousand words, especially when learning a game.
- Reference cards and player aids. How can you best remind your players of crucial, but oft overlooked cards?
- Scoring and end conditions. It is painfully obvious how to win and when the game will end?
- What to do at the beginning? Some games are so broad and lack mid-point goals. Give your players something obvious to work towards to drive them in the first few games.
On this last point, a few games do a good job of this. In Clash of Cultures, the expansion provides civilizations with bonus technologies. These essentially broadcast "You are good at these four things!" and give you a very early direction in which to head. Some may disagree with this, but family feeding in Caverna is an excellent early goal. It tells you that you need food and need to spend some time obtaining it. You can do this by buying it with Gems, Adventuring, Farming, or Ranching. It's up to you, and all of those things will help you win. But, the feeding tax gives you a nice mid-point goal to focus you in an otherwise vast game.
Find some people you don't know who may not be as familiar with games. Throw them off the deep end into your design and see how they fare. If you pay attention, you may identify simple methods to improve your accessibility and encourage players to return for a second test.
Balance the Game: This will definitely need its own post. This post itself is growing quite long, so we'll focus on the essentials.
If your game has asymmetry, the different powers and factions need to be balanced such that they have an equal chance of winning if played well. If your game has multiple paths to victory, those paths need to have a chance to win in relation to their difficulty.
Various options, like actions, need to be compelling at different times, and ideally, many actions will have non-obvious moments of opportunity. If the best decision is obvious at every turn, players will quickly grow bored. The game is playing itself!
If random events occur in your game, they need to play out such that players tend to be affected equally, or they present opportunities for different players. Or, their effect on the game needs to be such that a single player cannot claim victory from them. If one player is hit by every event and that cause them to win, that won't be terribly compelling.
Generally speaking, the player who plays the best should tend to win your game. I think luck should factor into games. It should tip the scales from time to time, such that someone can get lucky. In that sense, it acts as a wonderful probabilistic rubber band, like in Mario Kart. But, if player skill doesn't really factor into your game, you may turn off many players who want to invest themselves in your experience. Balance your game accordingly.
Assignment #2: We're all trying to Find the Fun. Write down 3 problems you've encountered so far. Identify why they are problems and/or why they hinder the vision, and propose solutions to solve them.
Here are some examples for Gaia.
Problem 1: Players aren't sure why they should have creatures. What is the value?
Solution 1: Creatures can destroy an opponent's Lands (which give Actions) and other Creatures. I've also modified the score conditions to reward players for having Creatures. Thirdly, Creatures lower the cost of other cards, acting as living mana. It should be very valuable to have creatures now.
Problem 2: Too many options to consider at once, especially at the start of the game.
Solution 2: I removed the 9 unique gods. It was tough to balance them and they created one more thing to look at. I also made it such that players randomly remove 4 cards at the start of the game, which means their initial hand is only 6 cards, not 9. I made it such that the 7 Score conditions are the same in every game, so players can build decks against those and not have to guess. I added a reference card for players to see their possible actions. Finally, I have taken several passes to simplify card text and remove conditional statements. The hope is that cards are potent and obvious.
Problem 3: The game's pace is plodding. It seems to take too long to do things.
Solution 3: I've made it so that you draw 1 card at the start of every turn so that you can always have new cards. I've also given an option to draw all of your cards if you use your entire turn, which lets you quickly get back in the game. Previously, players took one Action on their turn. Now, players take two Actions. As mentioned above, Creatures reduce the cost of other cards, which means fewer cards are discarded. When activating creatures, you activate all creatures (as opposed to one at a time), which should greatly expedite Combat and creature strategies. Players start with fewer cards in hand and should tend to have around 5 cards in hand, which provides fewer options to consider. Finally, I've reduced the cost of all cards, so that the curve is now 0-3, not 1-4. This means players tend to have more cards and can play more often.
I hope this Guide was useful. Until next time!