Howdy, folks! Today I want to talk about playtesting. This is something that can be really hard to nail down for an indie, or hobbyist game developer. As someone who has primarily made multiplayer games, playtesting has been an extremely important part of development. However it can be tricky to get helpful feedback under certain circumstances.
What is playtesting?
For those of you who may not know, playtesting is when you have other people play your game during development to give feedback. This is often done to find bugs, determine if the game is fun, and to help iron out general issues that players may run into. It is very easy to overlook things as a developer, and it is even easier to have bad ideas that don’t turn out well. Playtesting is key in the development of any game.
To help you get the most out of player feedback, here are my top three lessons learned about playtesting:
1. Playtest in person
If at all possible, you should be right there next to your play testers. This is difficult for me since I live in the middle of nowhere, and don’t get a chance to make it out to big events too often, but when I can, it makes a huge difference. The reason this is so important is because you are able to watch the body language of your play testers. Anyone can send you an email, a tweet, or a discord message saying “Wow this game was really fun! good job!” but it's entirely possible that the person is… well… just being nice! Being able to watch a person smile, laugh, or sigh in frustration can be a much more honest sign of how your game is doing. You also have the benefit of asking or answering questions in real time with the person, which can make a world of difference for the tester.
I remember the first time I went to GDC, I was showing off a fighting game. Prior to going, almost all of my playtesting had been done online, and feedback was always positive. I was so excited to play with people, and it was a complete flatline! No one had any reaction. People played with blank faces. No smiles, no frustration, no excitement. Nothing! When it was over everyone would hand me the controller and say “It's fun." It definitely wasn’t fun.
Later that night, I went back to my hotel room early, and spent almost all night making changes to the game. The next day I wrangled up some play testers, and this time people were having visible reactions to what was happening in the game.
2. Identify the real problem
A play tester's perception of the game, especially if it is early in development, may not always be accurate. Especially gut reactions that you may get from people who only play your game for a few minutes, which you’ll see a lot of if you take your game to shows and conferences. In my case, when making a fighting game, it takes many hours of play to understand the nuance and situations that are presented. When someone who has played for less than thirty minutes tells me that a character, or a special move, is “overpowered,” it likely points to another issue entirely.
During the development of the Knight Club prototype, lots of players would pick up the game, play for about 10-15 minutes, and then give some feedback. Almost everyone said that one of the weapons was way overpowered due to its range. Back then Knight Club was a one hit kill style of party game, so long ranged weapons had a big advantage against new players who didn’t understand the ways to get around those weapons. So it wasn’t that the weapon was too strong, it was that the solutions to deal with that weapon were not apparent. After playing for an hour or so, players would easily be able to deal with this weapon and the impression that it was over powered ended up going away.
In this case there wasn’t much I could do to help new players overcome this hurdle. They simply had to play, and want to understand the mechanics of the game. Considering that I was trying to make a game for a very specific kind of player, I wasn’t too concerned with some folks just not getting it or not wanting to put in the time to get it. That was okay for me, and for Knight Club.
It is very important to break down the feedback you are receiving. Identify if the feedback is describing the problem, or if it is going to lead you to the problem. From there you can determine if this is actually a problem (such as something being literally broken and not functioning as intended) or a problem of player perception. Which, technically, is still a problem! It just has a different solution.
3. Know when to change
A common pitfall with playtesting is wanting to make changes based on every little bit of feedback you receive. Using Knight Club as an example again, I made a conscious decision not to adjust the range and playstyle of a certain weapon because new players were having issues with it. I was confident that they would find ways around it if they wanted to, and they did. We all want people to enjoy our games and it is so easy to let little bits of negative feedback make you want to change things. Do not fall into this trap!
Consider your design when making any changes based on player feedback. You will often run into a situation where the feedback is at odds with your initial design, or ideas for the game. Assuming that the feedback you have received is at least a little subjective, It is up to you to decide if you should make those changes. This is a somewhat controversial idea, but I’m not a firm believer that the player needs to understand everything the first time they see it. It's okay if a player has to learn a bit when playing one of my games, and I’m okay with a player not doing that and not playing. That may not be okay for you! That may not be the case for me down the road, depending on the kind of game I’m making.
All in all, playtesting and parsing feedback is highly subjective. I don’t want any of you to follow what I’ve said here as a hard and fast rule. There are a few key takeaways though.
Playtest in person. Look at the play testers face! Are they smiling!
Learn to identify what people really mean when they provide feedback. It isn’t always easy, and it doesn’t always need to be deciphered. Sometimes the feedback is spot on.
Understand your game, and what you are trying to do with your game.
Try to implement feedback as it aligns with your design and goals.
I hope this was helpful to some of you fledgling developers. As always, you can reach me on Twitter or visit my website.
Nathan Ranney is the founder of game development studio Gutter Arcade. He's best known for the creation and development of Knight Club, an online indie fighting game.