The 54 Card Guild: #12
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. It's a fun, casual supplement to this course. If you're interested in joining us, email me at grant [at] hyperbolegames [dot] com.
The timing of this post is impeccable, by which I mean lousy. But, ideas strike when they strike. For this guide, I want to talk about how you can best prepare and take advantage of wonderful events such as Protospiel or Unpub. I've been to local Protospiels and one in Milwaukee, as well as a few tiny Unpubs (though never the main one on the east coast). These events are invaluable for the amount of sustained testing, but also for giving you an opportunity to learn from the community and immerse yourself within it.
This guide will cover two primary topics:
- How to maximize your testing as a designer at a test event.
- How to maximize your testing as a player at a test event.
Topic the First
When you have a room full of people who are ready and eager to play your prototype, you want to maximize that opportunity.
Firstly, practice your pitch and rules explanation. You want to practice it so that you can do it quickly and in the right order. I've been teaching Farmageddon the same way since 2012. I teach Hocus the same way every single demo, complete with choreographed card placement and little jokes.
Here is the basic script for Farmageddon:
"This is a farming game. Whoever has the most money at the end of the game wins. On your turn, you're going to plant Crop cards <place a Sluggo Corn face up> by placing them in front of you like this. Crops have two values <point at them>: required fertilize before they can be harvested, and money earned when harvested. Money is points!
To Fertilize, take any crop card from your hand <show two crop cards and point at backs> and place them face down on the crop <place them down>. You must always fertilize at least once every turn. This Sluggo Corn now has two fertilizer and can be harvested. There's a twist! You cannot harvest it on the turn you plant it. It has to survive until your next turn.
In addition to this, you can play up to two Farmer cards on your turn. These give you bonuses that break the rules. Farmer cards let you protect a crop, steal a crop, destroy a crop, increase its value, give you cards, and other bonuses <slowly place farmer cards one at a time>. Finally, Frankencrops can also be planted and harvested <show one>, but they have bonuses as indicated. If you have any questions, this is a friendly game -- just ask.
I'll take the first turn so you can see how it's played."
Hopefully you can see in my language when I place cards down. You can see how I teach the basics, then layer in exceptions and key moments. You can see how I don't overwhelm them with every detail.
To provide one more example, here is my Hocus teaching script:
"Hocus combines some of the classic elements of poker and mixes them with wizardry and spells.
In Hocus, we play until someone has 25 or more points <here I point at the point pile>, at which point whoever has the most points wins. The game is played in rounds. Each round, you will have a hand of cards <here I fan out a hand>.
There are four suits, <lay out one of each suit> each with a unique illustration and suit icon, a strength, which goes 1-13 and is just like 2-10/Jack through Ace, as well as a point value. <pick up cards>
On your turn, you're going to take ONE action <place a reference card in front of each player>. I'll show you these now.
Firstly, you can place any card from your hand face up in the community. <place one there> Unlike Texas Hold 'Em where these cards are played randomly, we will build it dynamically. This will end with four cards <place 3 more>.
Secondly, you can place one or two cards from your hand into a personal pocket <place them down>. You will mix these with the community to make a 5 card Poker hand <reveal my cards and push them to show the combination. Place a reference card with the hand listing>.
Finally, we need to compete for points. Remember the point value? <show the point value> You can place one card face down in a community's pot and only its point value matters. <place a second card> If I win this hand using my pocket and the community, I'll get 5 points <tally the two now revealed pot cards>.
There is a twist. There are actually two Communities, you can have a pocket for each of them, and each has their own pot. The game is not about having the best hand, but figuring out what hand you need to win the Pot. The round ends when the communities are full, so you must carefully manage your time. A player who spends their entire round building a Full House won't have time to put points in the pot.
Let's play a quick round. I'll go first."
At that point, I always play to the community. I then say to the next player:
"Now, you can add to this community, or play to the next one. You can play to the pot, which is a good way to stall. Or, you can place cards in your pocket if you think you can use this."
The keys to teaching your game:
- Use visual cues to support what you are saying
- Layer things in carefully. Teach the fundamentals, then highlight exceptions
- Leave out values they don't need to know. You can deal the right number of starting cards. You can enforce how many rounds.
- Setup the environment as a learning game, not a competitive game
- Break the ice!
- Repeat key rules when you have opportunities
Secondly, you need to know what you intend to gain from testing. This will alter how you discuss the game, but it will also frame the feedback for your testers. To be blunt, most testers are not designers, and they don't always know how best to help you, even if their intentions are solid. If you just say: "What do you think?" be prepared for them to tell you. If you provide an open ended forum, you will hear feedback from all over the world.
In this situation, you'll have someone telling you your game needs zombies, or they hate that there is any luck at all, or that they wish it had a worker placement element. Not joking! You must frame the discussion from the outset.
Possible testing goals include:
- Balance. Your game is far along and you want to fine tune balance. This means you are stating: the mechanisms are 99% good.
- Layout and presentation. You're less worried about game feedback and more worried about its graphic design and visuals.
- Accessibility: You're not testing deep, elder gameplay, but you want to gauge how simple it is for new players to test so you can smoothen the onramp.
- The Concept: You're stating, hey, it's early, but what do you think about the core idea. Be crystal clear in stating what you hope it becomes! Look to your Vision to answer this!
- Decision Space: You know what you want the game to be, but you aren't sure about the current player actions. Does there need to be a card draw action? Does the scoring work? Here, you want to state your vision, you want to be clear on what you tried, and be prepared to moderate a discussion about where things went and why.
At last year's Protospiel, I was exclusively testing Hocus' spell balance. We were happy with the mechanisms and simply wanted to gauge balance.
The year before, I was testing the concept of Sol Rising. Did it feel cool? Did people like the story objectives?
This year, I'll be testing the strategy and concepts of Gaia and Martian Empire. Are people excited by them? Do they feel rich? I've been hammering on the Gaia Decision Space for months now, so I feel it's ready for the next step. In both cases I'm less concerned with accessibility and more with elder gameplay. I'll try to get players to play two or three games in a row.
In prior years, I was simply testing the accessibility of York. Did players understand my player aids? Did they know how to score and take actions? Were they fighting battles in a sophisticated manner?
Know what you want to get out of your test and push people toward's that.
Thirdly, you want to push the discussion towards identifying the problems, not picking the solution. Now, sometimes you may want to have an open brainstorm. I posit that only you really knows what you want to do for the game, and the brainstorm will render far too many ideas you cannot use or do not want. It's wasting everyone's time.
However, during and after the test, you want to ask questions about mechanisms and balance concepts that have you concerned. You want to clearly identify what your problems are and WHY they are problems. Then, once you have this data, you can solve it.
If you ask for solutions, or try to solve it, it'll become an improv session complete with "Yes, and..." Guide your audience towards the problems.
Fourthly, you want to remember to leverage some simple tools. Show up prepared. It's really simple.
- Bring a notebook to list the number of players, play time, scores, and key notes for each test.
- Prepare a sheet that identifies the Pitch of your game, key information, where it's at in development, and what you want to gain. See below for an example.
- Print a few copies of your rules for people to look at while playing or thinking about the game.
- Bring some tape, scissors, pencils, and markers to update your prototype.
- Bring anything needed to improve against your goal. If you want to test visuals, have a tablet with a Pinterest board showing art.
Pitch Sheet Example
<image of the game> + <image of the game being played>
Martian Empire is a game of drafting and deception set in a feudal science fiction society.
Key Information: 2-4 players, 30 minutes, low to medium complexity
Key Mechanisms: Drafting, hidden information, bluffing, Variable player powers
Development Stage: Early Beta - Mechanisms are solid. Trying to identify if the hook is strong enough, strategy is strong enough, and worrying about balance.
Testing Goals: Does the game excite you? Do you enjoy the strategic decisions?
Fifthly, bring a great attitude. Be passionate and enthusiastic. Be the cheerleader for your game! When people have bad ideas, write them down and discuss things, do not shoot them down. Thank people for their insights and work to take criticism in stride. If someone makes a suggestion you've already tried, feel free to walk them through the process and why that didn't work, but follow up with: how would you do it differently, or why do you think that would make the game better?
People want to help an eager, kind, and receptive designer. Bring a great attitude and it'll pay dividends!
Sixthly, when testing with others, especially at an event, put work into a good looking prototype. Do not bring hand-written cards to a prototype event. At the very least your cards should be typed. But, with Game-Icons.net, The Noun Project, and more, you have all the tools at your disposal to make something that is clean and professional. Seriously, put the time in to make this better.
You remember when some old dude told you to dress for the job you want, not the job you have? That's a little silly for me as a Silicon Valley tech nerd, but it applies to your prototype. You want people to to know you take this, and their time, seriously. Your presentation IS YOUR INTRODUCTION. And, the smile mentioned in the section just above.
Topic the Second
You may think these events are all about you testing your own games, but it is equally important that you play the games of others. You should spend at least a third of your time at someone else's table, and really, you should strive to split your time evenly between personal tests and helping others. Really!
Board gaming is a small, niche hobby. At every opportunity you should be a steward of the community. Help others and the returns will be paid in full, if not immediately, but down the line.
When you are testing, you can help creators by being a better tester. Ask some of the following questions:
- What kind of game is this? How do you want the experience to feel? You ask this so that you don't tell someone making a take-that game for children how to make their game too complex or too strategic.
- Where is the game at in development? From above, this will change your feedback. Balance feedback is premature when the mechanisms don't work.
- What kind of feedback are you looking for? These are all similar questions asked a different way.
When providing feedback, be sure to give feedback not based on your personal desires, but the desires of the designer. Focus primarily on problems, not YOUR solutions. Tell them where you struggled, where you were frustrated, and where you were confused.
Be sure to also provide good notes! Tell them what you liked. Tell them what was exciting. Tell them about the things you think should be more important. They may be focusing entirely on the wrong thing.
Be a good steward! Encourage them, champion them, and support them. Who knows, after you test for them, maybe they'll test for you.
Be honest. But, don't be cruel. There's a difference. You can provide blunt, crisp, tough feedback in a way that is kind, well meaning, and fair. You can also caveat your comments, as needed, with: personally, my preference is for X to be the case. For example, if someone is playing Farmageddon, I'd love to know before they dump their comments on me that they hate any game with aggressive interaction. That's a key thing to know!
In summary, be the tester you wish you could have. It's really the Golden Rule.
What did I miss in this article? How would you improve this?
- Write your teaching pitch
- Practice and perform your teaching pitch for a friend. Or, at the very least, record and watch yourself performing it.
- Identify your testing goal. What would you want to learn right now?
- Write a personal list of problems you want to solve. Get the conversation prepared.
- Prepare an info sheet for your demo table. Share it with someone for feedback.
- Prepare a nicer version of your prototype that is typed.