This is a post duplicated from the Digitanks website. Digitanks.com
Today I bring you the first ever video I’ve created of the current progress of the game. If your jaw doesn’t drop while watching it, that’s okay, it’s only a prototype.
I thought I’d talk briefly about my playtesting process. This process helps me a great deal and I feel like other indie game developers can profit by hearing about it and using it to develop their games. Part of my playtesting practice I learned from my visits to Valve, who has a great playtesting process. I also saw Mike Ambinder, who works at Valve, give a talk at GDC ‘09 about their playtesting. Many people probably already use a similar process.
The goal of playtesting is to see how people will play your game once it’s on their computers and the developer isn’t there to coddle them anymore. Usability is key for indie games, if the player isn’t able to pick up the game quickly and intuitively then they’ll put it down and never play it again, so good first impressions are a must. I start working on the usability of the game from the start, and all of my design decisions take usability into account. Designing complex game systems can be a benefit for certain games, but if players can’t figure out how to use them, they won’t have any fun, and if the game isn’t any fun then what good is it? First step to good playtesting is to find somebody who doesn’t know anything about your game other than what the general idea of the game. When you’re talking to playtesters, you don’t want to affect their opinions of the game with things that you say. Typically the only thing I tell playtesters before they begin testing is something like, “This is a turn-based tank artillery game.” Or, for my previous project, “This is a multiplayer FPS/RPG.” It’s simple, it lets them know what they’re getting into, but it doesn’t tell them how to play the game, which would be defeating the entire point of the exercise. Then I inform the playtester that they are welcome and encouraged to ask questions, but as the developer I can’t answer any of their questions, because this is a simulation of how the person would be playing the game in their home without any help from the developer. With that, sit them in front of the computer and run the game, prepare your notepad and pen, and just watch.
Now that your guinea pig is (hopefully) happily playing your game, it’s your job to simply observe. There’s no substitute for being next to a person while they are playing your game, in that it gets you a thousand times more quality feedback than if you email it to them and ask for their opinion. You’re watching their actions to see what confuses them, what they take a while to understand, what they don’t immediately grasp that is important and what distracts them. What frustrates them? What do they enjoy? How do they learn how to use the fun parts of your game? As they play, take careful notes on what they do, so that you can remember it later, as this is data that will factor into your design decisions.
Many playtesters will ask you questions. “How do I do this?” “What’s this thing for?” “Why isn’t this working?” You may not under any circumstances answer their questions. My stock response for these kinds of things is, “That’s a good question,” and then I write down their question in my notebook. Later on, I can analyze why the player needed to ask that question, and decide how I can modify the game to make the answer to that question more apparent. In this way, you can make your game easy enough that people understand the game easily without having to be explained.
I typically end my playtesting sessions by reviewing my notes with them to clarify fine points. Talk about the game and ask them why they did certain things and what their general impressions were. This discussion is useful for helping to determine why the playtesters did what they did. Finally, to close the session I ask three questions:
“What was your favorite or the best part of the game?” This question helps you isolate where the fun of your game is. You hear a lot that you should pick one or two core fun concepts and iterate on them — maybe there are things in your game that are fun that you didn’t anticipate. Maybe these things can be identified and improved, to add to the fun value of the game. Make sure to write these down, once you have enough of these, the most often heard ones also become your list of features on the front page of your website. Nothing will sell your game better than a list of the most-liked features of your game.
“What was your least favorite or the worst part of the game?” This question helps you isolate what people don’t like. It’s an important question because people are generally polite and won’t advance negative opinions of your game unless they’re prompted. Positive feedback isn’t as qualitatively helpful as constructive criticism. It’s good practice to find the things that people don’t like about your game and fix them. Maybe some quirk that irritated them (a bug?) or maybe they became lost in your levels a lot (navigation problem?) or maybe they couldn’t understand how to use something (usability problem?) or they couldn’t figure out why they died (gameplay problem?) Whatever it is, find it, fix it.
“How much would you pay for a full version of this game?” This question has obvious usefulness. Explain what your full feature set when the game is done will be, and ask how much a game like that would be worth. This will help you pinpoint a price level that people will accept as reasonable.
Now that you’ve gotten your playtest data, it’s time to take a look at your game and figure out where it all went wrong. Improve the things that worked well, and go back to the drawing board with things that didn’t work well. Once it’s done, it’s time to repeat the whole playtest process to see if players respond better. Playtest as early and often as you can.
The benefits of having observation-based playtesting area clear — you get a definite feel for how players will react to your game. Talking with the playtester is also essential, as you can help discover why they took certain actions in your game. Was it because they didn’t understand the game mechanic, or did they have an intentional plan? You can’t get that by just observation alone. However there are a couple drawbacks that you should be aware of. For example, your observation can bias your results. Playtesters know that they’re being watched, so they behave differently than if they are simply in their living room. Some people will try to be more daring in order to impress their observers, or some people will be more conservative to avoid embarrassing themselves. Discussing the game with the playtester also has drawbacks in that although people are intelligent they often don’t even know exactly why they do things. If they did it just because everybody else was doing it, they may make up a reason for it later. There have been studies that show that when everybody else in the group expresses a clearly incorrect opinion on something, people will often go along with that. (Don’t quote me on that, I don’t know the exact study!) So, you also need to be careful that you’re getting the correct information.
There are other more advanced playtesting methods, such as data mining and biometric tracking, but I won’t go into that kind of thing, as it’s not really in the scope of indie game developers.
So it’d be rather hypocritical of me to talk at length (what?!? I thought I said I’d be brief!) without sharing the results of the playtesting that I did today. I went to see a long time friend of mine who had never seen the game before and set him in front of it. I got a number of good results. For example, he got confused when he hadn’t aimed his tank yet at anything, but he couldn’t figure out why he didn’t have any attack power. If you think about it, it makes sense, you can’t use any attack power if you don’t even intend on firing your tank’s cannon. However, being new to the game he didn’t realize he hadn’t aimed his tank yet. So, the solution I decided on was to make it so that if you try to use some attack power without aiming your tank, the game goes into aiming mode instead. Naturally, every time you implement a solution to one of your playtester’s confusions, it has the potential to bring about other confusions, such as, “Why did it go to aiming mode when I tried to use attack power?” It’ll be up to my next playtesting cycle to see if this causes problems. Another problem that he had was with the shift button. The hint explained that you can command all your tanks at once with the shift button, so he tapped it, but he didn’t realize that you have to hold it, and he couldn’t figure out why it did nothing once it was tapped. The typical solutions for that problem are either saying “Hold shift” specifically in the hint, or creating a feature that uses a toggle if the player taps the button and a hold behavior if the player holds the button.
Adding hints and tutorials to the game is a very common way of helping players through the game and lowering the learning curve. The general results of today’s playtest were good — although he wasn’t the kind of guy who really enjoys strategy games, he was able to learn how to use and play Digitanks quite easily due to my tutorial system and he won his first game, despite a couple bugs and usability problems.
Thanks for reading all that. If this article inspired you, please shoot me a line and tell me what you think!
