This post has been updated and posted on steemit!
Testing your early game prototypes is simultaneously one of the most exciting and most terrifying experiences of being a designer. There is an inherent vulnerability that comes from taking your creation and opening it up to the criticism of others. To get the most out of your testing sessions, you must learn to love criticism.
Your design is a personal creation and an extension of yourself. You were inspired by a *great* idea. You spent the time to set parameters, brainstorm and prototype a game because you believe in your vision. There is a part of you that *knows* this design is genius and when you show it to others they are without a doubt going to give you some kind of award and attempt to buy your game on the spot. Your design is your baby, and you love it unconditionally. This article is about learning to kill your babies.
Every game can be improved. There is always another variant that can be tested, a component that can be tweaked, or a strategy that can be better developed. I have many games I’ve published (even popular ones) that I now look back on and cringe, but at the time I thought they were the bees knees. Humility comes with experience, and all of the greatest game designers have learned this lesson (usually more times than they care to admit). Go into your testing session with the certain knowledge that your game is flawed and embrace the opportunity to improve.
The secret to loving criticism is to remove your ego from the equation. Imagine when testing a game that you are not the designer at all. In fact, you are not even friends with the designer. Furthermore, you are pretty sure the designer is an alien creature that is only just now trying to understand the human concept of “games.” Feedback from testing is not about the game being good or bad, just about helping educate this alien designer. By removing your attachment to the game being “good” or “bad” you can be far more effective in taking in and processing the reality in front of you.
When testing a game, keep in mind the core mechanic you are trying to test. Watch players interact with that mechanic and observe as much detail as you can. You can elicit feedback from your players about what they like and what they don’t like, but there is no substitute for your own observations. Players will often be more kind in their reviews than they would be if they didn’t know you. In addition, they will often complain about things that aren’t a part of the core mechanic you are trying to test. If you are testing the basics of a collectible card game resource mechanic, then don’t worry about the exact numbers on the cards or complaints that your game isn’t “balanced.” But do worry if players get confused about how the resource system works or find themselves unable to follow the game’s progress. Look for facial expressions, mistaken actions, and uncertainty of movement. Do your best to allow players to make “mistakes” by doing what feels natural to them. When in doubt, the correct action in a game should almost always be the one players naturally gravitate towards.
As an example, in my deckbuilding game, Ascension, we originally had a mechanic that would remove a card from the center row each turn. The center row moved like a conveyor belt with a new card showing up on one side and “pushing” all the other cards down the line, eliminating the last card in the row. This mechanic seemed really cool to me and I had a bunch of designs that manipulated the functioning of this conveyor belt, creating a lot of interesting choices and texture to the decisions (e.g. the cards closest to the end of the conveyor belt were more precious because they would disappear soon). I found in playtesting, however, that players regularly forgot to move the conveyor belt and I noticed that it was fairly awkward to physically move all the cards each turn. Though many players explicitly said they liked the mechanic, I decided based on my implicit observations to remove it, and the game played much smoother.
Key Questions To Ask
After a playtest session, it can sometimes be helpful to have your players fill out questionnaires to give feedback. Again, this will depend on your audience, but you can often elicit more detailed and honest feedback with a questionnaire. Some key general questions include:
What were the 3 things you liked most about the game?
What were the 3 things you liked least about the game?
In your own words, what would you say this game was about?
Was there anything you found confusing?
If you could change one thing about the game, what would you change?
If you could preserve one element of the game, what would you preserve?
In later phases, you can ask more general questions about the game (these aren’t as useful in early stages).
On a scale of 1-5, How likely are you to recommend this game to a friend?
On a scale of 1-5, How easy was this game to learn?
On a scale of 1-5, How much did you like the theme of the game?
On a scale of 1-5, How did you feel about the length of the game?
On a scale of 1-5, How did you feel about the depth of strategy of the game
Whether you use a questionnaire or just receive direct feedback from your players, remember that the most important feedback is often that which is unspoken. Players don’t always know what they want and will often identify the wrong issues as problems. This is not to say that you as a designer “know better” than your players. Your job as a designer is to engineer an experience through your game. In a fundamental way, player perception is reality. The key distinction is that players often don’t know what will really make them feel a certain way. For example, players of collectible card games will often complain about “randmness” or “variance” ruining games when in reality some amount of variance is critical to making those games fun.[note] for a great design article on variance, see Mark Rosewater’s piece here [/note]
Your players are the ultimate arbiters of whether your game is fun or not, but the skill of a designer is discovering the specific mechanics and triggers that engineer the player experience you want. You will refine your skills of observation as you look behind the things players say and address the way the game makes players feel. This can be intimidating at first, but becomes easier and easier as you design and test more. When possible, run your playtest session with a few different groups to get a wider range of feedback. Sometimes one player’s reaction can be dismissed, but any recurring comments from players is almost always something that needs to be addressed in some form or another.
If you’ve come this far, then congratulations! This is the nuts and bolts of being a game designer. The final step is to take what you’ve learned and use that information to iterate on the process again. We will cover that in the next article.
