Play-testing is fundamental to Game Design. The aim is to observe people playing your game to so that you can identify areas of weakness in your design and methodically improve it. There are 3 keys to help you play-test your games.
The 3 Keys
This is similar to how you would conduct a science experiment. Game design can be turned in to a discipline with methodical rules to follow that, when combined with your creative ideas, can guarantee consistent quality. Let’s break down these rules for play-testing.
Observing people play your game is critical. Your primary goal is to see if your game design works as expected. As you watch, ask yourself questions like, “Is the game’s objective clear?” “Is the difficulty correct?” “Is that ledge too high?” And so on.
In the early stages, making general observations of your game and watching how people interact with it is useful. As the game gets further into development, you should apply a more methodical approach and observe specific elements that need further testing and refining, which we’ll discuss more later in the article. An example, however, would be observing players attempt the jumps in a platforming game to determine appropriate heights and distances for those jumps.
Testing comprises of two elements. The initial tests are where you get people to just play through the game and you get a feel for how the overall design is working, observing for possible weaknesses in the design, and the later tests where you have made changes and are now testing it either on the same people or fresh players to see if the changes worked. You should be testing every individual element of your game. Are there ledges to jump on? Test their height and distance. Do you have to kill enemies with a sword? Get players to attempt it. Do you have a shield to block bullets? Get players to block bullets. Are there special abilities and combo moves? Get players to try them.
Make sure when you are testing that you don’t take one person’s experience as all you need to know. With a puzzle game, for example, one person may find a particular puzzle very hard, even impossible, for some unknown reason, whereas on average the difficulty may be just right. In this case, make sure you test with at least 3 people to get an average before making significant changes – unless it is very obvious that something needs to be changed. It’s a good general rule to follow.
Make sure you have tested every element of the game and that some people have played through the entire game. This is particularly important for difficulty balancing. If only some players play the early levels and some players play the later levels, you don’t have a consistent comparison of how a single player experiences the entire game. You need some players to do that to see how they progress through the challenges and difficulties. However, for small changes, do test specific components separately without always doing an entire play through.
Don’t be precious with your idea’s. No game is perfect on the
first go. View each area that’s not working properly as an opportunity to improve the design and make your best game yet.
This is the really important part that can be easy to miss. You might be tempted to just watch people, then make changes from memory. Don’t do this. Instead, you should be recording observations and key data.
Have a writing tool nearby and jot notes as you observe the player. If you’re testing for specific and measurable things, such as, how many players died on level 3, or how long does it take each player to complete each level, record such things in an appropriate way. For level time completion, I would use a spreadsheet. Many things could probably be measured on a spread sheet, but a notepad or word document is also fine. Use whatever works, so long as you are tracking your data, which usually means tracking numbers. How many people died at the waterfall in level 3? How many people died at the waterfall after you made changes? How many people passed the first level? etc.
What Are You Testing
What you test and measure differs with each game, so I am going to give you 3 helpful questions to identify your area of need. Remember these words:
We’ll now turn those words in to questions.
Does The Player Understand…
What sort of things are in your game? Is it a puzzle game? If it is, does the player understand the puzzle? Notice I didn’t say can they solve it – but can they understand how to begin solving it? Any good puzzle, no matter how difficult, should give clues to the player how they can begin trying to solve it. For example, The Nodus is a block pushing puzzle game. So I helped players understand that they had to push the blocks to the right location to pass the puzzle. Finding the correct path is up to them.
Does your player understand the individual components of your game? You’re not just looking for general understanding but you want to break it down to the smallest, individual elements. Does the player understand the controls? Do they understand how they can die? Do they understand how they can win? Keep reviewing this as you observe. If a player seems confused, take note and write it down somewhere (measure it). If you make changes, get that person or another to try it again and see if that element is still confusing.
Is The Difficulty Appropriate
Notice I didn’t say is the game too hard. Some games are successful because they are so hard. But is it appropriate? Don’t just take this as a general statement for the difficulty of the overall game, but again, apply it to individual elements.
For example, you may observe there is a certain bottomless pit where every player falls to their death. Does it benefit the game, or is it just bad design? The right kind of difficulty motivates the player to play, and is hard because the player needs to improve their skills. It should feel like it’s the players fault that they died, and they should feel like if they just try a bit harder, they can overcome. Bad difficulty is when the player struggles to complete a challenge due to bad design, eg, the unknown bottomless pit. In such cases, the game feels unfair and the player gives up. In the bottomless pit scenario, should there be some sort of clue that there is a bottomless pit, or is it the players fault for not realizing? You have to consider these questions.
Seeing how many times a player attempts to overcome a challenge before giving up is a good indicator of if it is working well or not. My game The Nodus is hard, but puzzles that were well designed motivated players to keep attempting them. Some puzzles early in development confused players because they were too complex and not designed as well. Some of those were redesigned and some were removed. You shouldn’t be precious with your idea’s but instead be willing to admit when things could be improved or removed. Be excited about the opportunity to make your game better – it could be your best game yet.
Can The Design Be Improved
If a player isn’t understanding something or playing the game differently to how you intended, never assume the player is wrong. Assume that your design might need improving. Remember, when you release this game, you won’t be able to stand there and explain to a new player how to play. The game needs to be self explanatory. With that in mind, as you observe people playing the game, you need to be looking for clues about what may or may not be working, then be prepared to test and measure those elements. This is the most critical part of the process. This question is what should lead to all other questions: Can the design be improved?
3 Key Areas to Review
There are 3 key area’s of your game to review. Keep this in mind to break your game into different parts to observe, test and measure. Remember these words:
Let’s break them down. You can apply the observe, test and measure principles and the questions we discussed to these 3 area’s.
Does the player understand the goals of the game? This can be read as the overall goal of the game, such as saving the Princess from the Evil King, and the smaller individual goals, such as, “Do they know they need a fire sword to melt ice to get to the secret cavern?” Or “Do they understand they need to go to the forest to continue their journey?” This can be broken down as small as you like, right down to, “Do they understand how to solve this type of puzzle, by putting the red ball in the red hole?” Remember that there should be some type of clues throughout the game to assist the player to know what they have to do. A mission objectives list on the pause screen is an example of this.
So, what are the goals? Does the player understand them? Is the difficulty appropriate in completing them? Are there aspects that can be improved? Eg, I force the player to climb the ladder to get to the top of the tree, but should I just let them teleport?
Challenges are literally the things that try to stop the player from reaching the goal. Again these can be broad and general, but should also be broken down to the smallest and most specific examples. In a platformer this could be the space and height between jumps. Are they the right height? Does the player understand how to jump up there? Is the difficulty appropriate? Could it be improved in anyway?
It could be you need to help the player learn how to defeat certain types of enemies because they’re not understanding it, eg, green bullets kill green enemies, blue bullets kill blue enemies, but the player keeps trying to use green bullets on blue enemies. How can you help them understand to use the right bullets? If it’s a block pushing puzzle game, does the player even understand that they can push the blocks, or can’t push certain blocks? Do they know what to do with the blocks when they push them? Do they know why they are pushing blocks?
Does the player understand the challenge? Is the difficulty appropriate? Could the design be improved? After you’ve changed a challenge, go back and test it on another player. Is it working better now?
This is a broad subject, but it involves anything to do with how the player navigates the game. The key one is the controls. Does the player understand the controls and are they appropriate? But it’s also how the player explores your game world and how they navigate the menu screens. Does the player know how to start a new game from the main menu? Do they understand how to switch individual options on and off? Do they understand how to leave the first town and enter the wild lands? This also includes finding things within the game, such as finding a shopkeeper and navigating the game menu.
I remember playing the first Pokemon game and all of my friends, including myself, struggled to figure out how to leave Ashes house in pallet town. Walking up and down the stairs was obvious, but none of us realized for several days that walking into the “doormat” was how to leave the building. We did eventually figure it out, but it probably could have been designed better, especially since we were young children and the game was designed for us.
Does the player understand how to navigate the menu screens? Is it difficult to navigate? Could the menu design be improved?
Does the player understand the controls? Are the controls placed in the right place? Could different buttons be used? Could there be less buttons or the controls made simpler, or do they need to be more complex?
Does the player understand how to execute combos and jump on ledges? Can the player figure out how to wall jump? Can they understand how to find the next mission objective? Do they know how to find food and water?
How To Apply These Lessons
The key thing to remember, when it comes to applying what I’ve shared with you, is that each question and method should be applied not just generally but to every specific element of the game. Do you need to go to X location to achieve Y goal? Test and see if the player can figure it out. Do you need to shoot the weakspot on an enemy? Test and see if the player can figure it out. At the end of the day, that’s all it is. Observing people play your game, finding the area’s of weakness, making improvements and testing it again.
Remember also that any game could be improved or have new features added. Aim to make a solid quality game, but remember when to call it a day and finish the project so you can move on to the next.