Nous sommes déjà à la septième semaine de l’incubateur et les jeux sont prêts à être testés! Cette semaine, nous parlons de tests avec les joueurs et d’assurance qualité, d’importantes étapes dans la conception d’un jeu.

We’re already at week seven of the incubator and the games are now ready to be tested! This week, we talked about playtesting and quality assurance testing, important steps in game making.

Playtest

Lorsque l’on teste un jeu, on présente un produit qui est encore en développement à plusieurs joueurs. Il n’est donc pas nécessaire d’avoir un jeu totalement fini avant d’effectuer des playtests, et nous vous encourageons même à le faire le plus souvent possible. Les playtests sont très utiles pour de nombreuses raisons. Ils permettent :

• d’identifier des bogues;
• d’analyser la compréhension du joueur du jeu et de ses règles;
• d’avoir du feedback à propos de notre jeu;
• d’évaluer la difficulté de notre jeu, s’il est trop facile ou trop difficile.

N’importe qui peut playtester votre jeu, que ce soit vos ami.e.s, votre famille ou vos collègues. Mais, idéalement, vous ne devriez pas le tester vous-même. Vous êtes probablement le pire testeur pour votre jeu. Vous travaillez fort sur ce jeu depuis maintenant plusieurs semaines, vous y êtes attaché.e.s, et vous pourriez probablement le jouer les yeux fermés. Vous connaissez beaucoup trop votre jeu pour donner des commentaires objectifs. Essayez de faire tester votre jeu par plusieurs personnes. Faites les changements que vous voulez et faites le tester à nouveau. Il est possible de faire des playtests à tout moment, mais essayez de les faire le plus tôt possible, et le plus souvent possible. Il est même possible de faire un playtest pour avoir des commentaires sur une seule mécanique de jeu. N’attendez pas à la dernière minute. Il serait dommage de remarquer que plusieurs éléments ne fonctionnent pas, ou qu’une mécanique n’est pas amusante, quelques heures avant de rendre le jeu disponible en ligne.

Maintenant, vous vous demandez probablement comment effectuer un bon playtest. Voici donc quelques conseils pour vous :

• Parlez le moins possible aux joueurs. Essayez de ne pas les aider, ça vous aidera à savoir où ils sont bloqués et ce qu’ils n’ont pas compris. Prenez des notes lorsque les joueurs jouent : ce qu’ils disent, ce qu’ils font…
• Essayez de ne pas expliquer votre jeu aux joueurs. Lorsque votre jeu sera disponible en ligne, vous ne serez pas là pour l’expliquer à tous les joueurs du monde.
• Choisissez certains éléments sur lesquels porter attention. Par exemple, combien de temps ont-ils besoin pour accomplir une certaine tâche? Savent-ils où aller? Comprennent-ils comment faire quelque chose, ou quand ils devraient la faire? Comprennent-ils la fonction d’un objet en particulier?
• Poser des questions ouvertes, et non des questions qui peuvent se répondre par oui ou par non. Vous obtiendrez beaucoup plus de détails comme ça.
• Ne donnez pas d’indices sur la réponse que vous voulez obtenir dans la question elle-même. Par exemple, une moins bonne question pourrait être : As-tu eu peur quand ce monstre est apparu? Une meilleure manière de formuler cette question pour obtenir plus d’informations sur les ressentis du joueur pourrait être : Qu’as-tu ressenti en jouant? Quand tu as vu ce monstre?
• Il est parfois plus facile pour les joueurs de donner des solutions que d’identifier des problèmes. Essayez d’identifier le problème derrière le commentaire ou la suggestion du joueur. Par exemple, si un joueur vous dit : « je veux des powerups! », le problème pourrait être tout simplement qu’ils ne se sentent pas assez puissants. Améliorer leur arme pourrait alors aussi être une bonne solution.
• Définissez des tâches pour le joueur, mais évitez de décrire les étapes. Il y a deux types de tâches à considérer : exploratoire et dirigée. Les tâches exploratoires sont ouvertes et sans fin claire, ce qui est idéal pour tester l’intérêt et l’engagement. D’autre part, les tâches dirigées sont spécifiques et orientent le joueur vers des choses en particulier. Ceci est utile pour tester les fonctionnalités ou les mécaniques.
• Demandez aux joueurs de réfléchir à voix haute lors de l’exécution de tâches. Y a-t-il quelque chose qu’ils ne comprennent pas? Le contraire s’applique également : y a-t-il quelque chose de particulièrement facile à comprendre? Oui, oui, les playtests ne consistent pas seulement à identifier les problèmes!
• Observez ce que le joueur fait dans le jeu. Recherchez toute hésitation / question de ce qu’il faut faire, être surpris par ce qui s’est passé, ne pas trouver quelque chose et répéter l’action / regarder aux mêmes endroits plusieurs fois.
• Les interactions auront un impact sur les actions du joueur! Évitez d’expliquer / de défendre ce qui se passe ou d’aider trop tôt. Essayez plutôt de renvoyer la question, par exemple “Que feriez-vous normalement?” De plus, clarifiez les commentaires en faisant écho aux propres mots du joueur. Si le joueur dit: “ce singe est bizarre”, vous pouvez répéter en demandant “ce singe est bizarre?”

Playtesting

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?”

Assurance qualité

Alors que les playtests sont plutôt axés sur le ressenti et la recherche de rétroaction, l’assurance qualité (QA) s’intéresse plutôt aux différents problèmes qu’on peut rencontrer dans un jeu, que ce soit des incohérences, des bogues ou des « glitchs ». Il est aussi important de chercher à reproduire les problèmes que l’on rencontre, et d’essayer de comprendre ce qui les a causés.

Comme pour les playtests, vous devriez considérer l’assurance qualité dans votre jeu le plus tôt possible, et le plus souvent possible. Il est toujours plus facile d’identifier la cause d’un nouveau bogue lorsque l’on teste son jeu souvent, et vous ne voulez surtout pas vous rendre compte à la dernière minute que votre jeu est complètement brisé.

Les grands studios ont souvent plusieurs testeurs pour essayer leurs jeux, mais, dans le cadre de cet incubateur, vous êtes seul.e.s. Voici donc quelques conseils à considérer lorsque vous voudrez faire l’assurance qualité de votre propre jeu :

• Jouez à votre jeu. Souvent!
• Essayez tous les éléments de base de votre jeu. Est-ce que je peux sauter? Est-ce que je peux gagner/perdre? Est-ce que je peux naviguer dans les menus correctement? Est-ce que les collisions fonctionnent?
• Essayez de “briser” votre jeu. Faites ce que vous n’êtes pas censés faire. Vous devez protéger quelqu’un? Essayez de l’attaquer. Faites des choses étranges et inattendues. Tous les joueurs ne joueront pas comme vous ou comme ils sont censés le faire, et pourraient rencontrer des bogues que vous n’avez jamais remarqués. Essayez de « speedrun » votre jeu pour voir si cela cause des problèmes.
• Faites un build de votre jeu! Ce n’est pas parce que tout fonctionne correctement dans le moteur que vous utilisez que votre build fonctionnera. De nouveaux problèmes peuvent émerger. Essayez aussi votre jeu dans différentes résolutions, afin de voir si tout fonctionne correctement, notamment pour votre interface. Tout le monde ne jouera pas sur votre ordinateur, avec la même résolution que vous.
• Testez votre jeu le plus souvent possible. Il est beaucoup plus facile d’identifier la cause des problèmes ainsi.
• Certains bogues sont pires que d’autres. Mettez votre attention en premier sur ceux qui pourraient vraiment nuire à l’expérience de jeu si vous manquez de temps.
• Il y aura probablement encore certains bogues dans votre jeu à la toute fin, et c’est parfaitement correct ainsi! Vous pouvez toujours décider que quelque chose est assez bien, et qu’il restera tel quel dans la version finale de votre jeu. Et n’oubliez pas que vous pouvez toujours transformer un bogue amusant en une nouvelle mécanique!

Quality Assurance

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!

LES DEVOIRS

• Continuez à travailler sur votre jeu.
• Testez, testez, testez!
• Faites un “build” de votre jeu.

La semaine prochaine, nous parlerons de finition et de deboguage.

À la semaine prochaine et bonne création de jeu!

HOMEWORK

• 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!