To summarise my following thoughts on play testing: Do it. Do a lot.
One of the most painful experiences on development of Outworlder has been the play testing and the key reason for that is silence. When someone that had never seen your game before tries to play it when it lacks any sort of tutorial or instruction and you can only respond to their confusion with silence... that's not easy. Unfortunately, I think that's absolutely the best method, at least for the majority of the time. We've done testing now at a few different stages of development and when there's no guidance, you can really see just how unintuitive your game can be.
Play Testing Pain #1A: The Scuttlers Not Caught Red Handed
These slightly menacing looking bug creatures pack quite a punch when they hit you. It's hard not to notice a large explosion around you and your health dropping down significantly, but it turns out it's a bit harder to notice the little brown scuttling culprit. It's not that they're hard to see, but more that they don't yet make any sound and the player isn't forced to look at where they spawn from. So the first problem with these little guys was making the player aware of them and what they could do.
We'd always been planning on having a character talk to you and give you help and also to make the Scuttlers make a distinct, unmistakeable sound as they scuttled along. While those two things will help a lot, we also incorporated Scuttler training into our new tutorial area (which was the main by product of play testing).
Play Testing Pain #1B: Stop Running From Scuttlers!
So little exploding bug like creatures isn't that unique or exciting in a game, but when you add the fact that you can suck up and shoot small objects in the game, things become more interesting... or so you'd think.
Picture this: There's a cave. In that cave is a pool of water and if you get close, a Scuttler is spawned every so often.
Now imagine that the person playing the runs away the first time. Fair enough, it hasn't dawned on them yet that they could use this creature as a weapon. Now imagine that this player repeats the above 10 times in a row. Take a deep breath.
So how do you fix this issue? The same way I did after the tenth time: you tell them what to do. Of course you might want to do it in a calmer tone of voice, perhaps like the one of the help character. As you saw in the previous entry, there's a wall blocking the way in the new tutorial island and we force the player to learn how to suck and up shoot Scuttlers before they can proceed.
Never expect the obvious to be obvious to everyone.
Run away!
Play Testing Pain #2: Fly Up, Stupid
So flying up a 1 metre incline is difficult. For some reason, play testers would often try to take a running start and boost themselves up anything in one go instead of first gaining altitude. While this is possible if you know that you can use the blast function to instantaneously gain height, most people didn't figure that one out.
To fix this, we added better flying training to the new tutorial area and also made the jetpack give you more of a height boost straight away when using it on the ground.
Play Testing Pain #4: Repeatedly Clicking When Nothing Happens
So the combat in the game is based around shooting rocks, Scuttlers and coconuts that you've sucked up into your jetpack back out at enemies. This means your ammo supply is limited to what you have sucked up. At the time of play testing we did have a HUD element showing the amount of rocks you had sucked up, but it was fairly ambiguous. This led to people often attempting to shoot when they had no ammo. It would usually take a good 5 seconds before they realised the problem and sucked up more ammo.
To fix this problem I put the most time in HUD creation into the rock meter. It now shows the maximum amount of rocks you can hold at your current Fuel Cell level, whether or not you are holding Scuttlers and also how many rocks you'll eventually be able to hold.
Play Testing Pain #5: Keep Shooting, It'll Die Soon
So Fuel Cell's shields were another problem. They would take about 4 rock hits to be destroyed, but the player wasn't told this and there was no indication that damage was done when they were hit.
An easy fix. We block off the passage in the tutorial island with a shield so that the player is forced to destroy it to progress. Also, the shield's colour will now change when damaged.
What to do... what to do...
Those examples were just some of the wealth of things that play testing helped me recognise. Play testing helps you determine what isn't as obvious as it should be or as easy or as simple and so on. It's extremely important to be open to change and to recognise what isn't working in your game and be willing to make changes no matter how much you like it. Something might be awesome for you, a master of the game; but to the new player it's a liability. The secret in those situations isn't to throw in the towel and change it to suit those players and not you, it's to put the thought and effort into creating a compromise. The amount of times that something in the game could've been changed to suit one type of gamer instead of another was numerous, but I always took the approach of finding a mechanic that would suit both and would be better than the original method in every way.
Notice the small things when people are play testing your game. Where do they look when they enter a new area? Do they follow the path that you intended? If they don't follow that path, is the game going to be a worse experience for them? Is there adequate feedback from the game to inform them when they've done something? Do they know what to do in the next 20 seconds of gameplay?
Get people to play test your game. Do it with different levels of gamer at different points in development. Never assume they're at fault when they can't do something. Take note of everything they do. Think about all the little things that could be added or changed in the game to make the play experience they had better.
