We’re already at week seven of the incubator and the games are now ready to be tested! This week, we met Anne-Li Porlier to talk about playtesting and quality assurance testing, important steps in game making.
Learn all her advice in the following presentation. (In French only)
When we playtest a game, we are presenting a game that is still in development to players. There is no need to have a finished product before performing playtests, and we even encourage you to do so as often as possible. Playtesting can be useful for many reasons, it:
- identify bugs;
- see the player’s understanding of the game and its rules;
- get feedback about your game;
- rate the difficulty of your game, and see if it’s too easy or too hard.
Anyone can playtest your game: friends, family, colleagues, etc. Ideally, it shouldn’t be yourself. You’re probably the worst tester for your game. You’ve been working hard on this game for a while now, so you’re already attached to it and you could probably even play it with your eyes closed. You know way too much about your game to give objective feedback. Try to playtest your game with as many people as possible, fix what you want, and test again. You can also do that anytime, but try to do this as early as possible, and as often as possible. You can even do a playtest only to have feedback on a single mechanic if you want. Just don’t wait until the end, you don’t want to notice that a lot of stuff in your game is broken, or that a mechanic isn’t fun, just a few hours before putting it online.
Now, you’re probably wondering how to do a good playtest. Here are a few tips for you:
- Talk to the player as little as possible. Try not to help them, it will let you see where they get stuck and what they don’t understand. Take notes when they play: what do they say, what are they doing?
- Try not to explain the game to the player. When your game is online, you won’t be there to explain it to every player in the world.
- Choose some specific elements to focus on. How many times do players need to complete a task? Do they know where to go? Do they understand how to do something, or when they should do it? Do they understand what a specific object does?
Ask open questions instead of questions that can be answered by yes or no. You’ll get a lot more details that way.
- Do not give the answer you want in the question itself. For example, you could want to ask: “Were you scared when that monster appeared?” A better way to ask the same thing and get a more detailed answer could be: “How did you feel throughout the game? When you saw that monster?”
- It’s sometimes easier for the player to give solutions rather than to identify a problem. Try to extract the problem behind the player’s comments or suggestions. For example, if a player tells you « I want powerups! », the problem may be that they don’t feel strong enough and improving their weapon could fix the issue.
- It’s ok not to act on all feedback. For example, a specific idea given by a player could sound very interesting, but if it would require a bunch of code that you’re unsure how to do, and you only have a few days left, maybe it’s not the best idea to do it. You can always keep it for later! However, if all your players agree that, for example, your game is too hard, it might be a good idea to listen to them and find a solution!
- Set tasks for the player but avoid describing the steps. There are two types of tasks to keep in mind: exploratory and directed. Exploratory tasks are open-ended with no clear end, which is great for testing interest and engagement. On the other hand, directed tasks are specific and direct the player towards particular things. This is especially good for testing features/mechanics.
- Ask the player to think out loud when performing tasks. Is there anything that they don’t quite understand? The opposite also applies: is there anything that was particularly easy to understand? That’s right, playtesting is not just about identifying problems!
- Observe what the player is doing in-game. Look out for any hesitation/questioning what to do, being surprised by what happened, not finding something, and repeated action/looking in the same places multiple times.
- Interactions will impact the player’s actions! Avoid explaining/defending what is happening or helping out too early. Instead, try to return the question, for example, “What would you normally do?” Additionally, clarify any comments by echoing the player’s own words. If the player says, “that monkey is weird”, you can echo by asking, “that monkey is weird?”
While the playtest is more focused on feelings and the search of feedback, quality assurance (QA) is more about the different problems that can be encountered in a game: inconsistencies, bugs, glitches, exploits. It’s important to try to reproduce those issues, and to figure out what causes them.
Much like with playtesting, you should try to consider QA in your game as soon and as often as possible. It’s always easier to find what might have caused a specific bug when you test it often, and you don’t want to notice at the very last minute that your game is completely broken.
Big studios often have a bunch of testers to look at their games, but as part of this incubator, you are working on your own. So here are a few tips to QA your own game:
- Play your game. A lot!
- Try every basic element of your game. Can I jump? Can I win/lose? Can I navigate the menus properly? Do collisions work?
- Try to break your game. Don’t do what you’re supposed to do. If you’re supposed to protect someone, try to attack them. Do weird and unexpected things. Not all players will play like you, or like they’re supposed to, and might encounter bugs that you never noticed. Try to speedrun your game to see if that creates some issues.
- Build your game! It’s not because it’s working in the editor, that your build is going to work. New issues might appear. Also try playing the game in different resolutions to see if something breaks, like for example the UI. Not everyone will play on your computer, with the same resolution as you.
- Try to test your game as often as possible. It’ll be easier to find what might have break your game.
- Some bugs are worse than others. Focus on the ones that would really break the player’s experience first if you run out of time.
- There will probably be some bugs left in your game… and that’s fine! You can always decide that something is good enough, and that it will remain as is. And don’t forget that you can always transform a fun bug into a feature!
- Continue working on your game prototype.
- Test, test, and test again.
- Build your game!
Next week, we’ll talk about polish and debugging.
See you then and have fun making your game!