Présentation du document
En tant que designer de jeu, je voulais apprendre comment produire des processus de playtest de jeu concluants qui répondent aux bonnes questions. Je voulais m’assurer que les sessions de playtest que j’allais produire ne serais pas une perte de temps pour l’équipe et que les bonnes informations seraient recueillies.
Comment préparer un processus de playtest?
J’ai alors décidé de faire des recherches sur comment produire un processus de playtest qui serait court et qui ne donne pas de réponse redondante.
Temps de production:
- 40 heures
Mes recherches ont été séparées en ces sections
- Que sont les limitations humaines qu’il faut prendre en compte en préparation à un playtest?
- Combien de temps devrait prendre l’équipe entre chaque itération et playtest d’une fonctionnalité?
- Comment le joueur devrait-il être mis à jour sur le processus de playtest et sur les demandes de l’équipe?
- Quels outils l’équipe devrait-elle utiliser pour le processus de playtest?
- Quelles questions l’équipe devrait-elle poser au joueur?
- Quelles questions l’équipe devrait-elle éviter de poser lors de playtest?
J’ai recherché de plusieurs façons, entre autre :
- En analysant des documents de recherche sur les limitations humaines et les accommodations à faire.
- En lisant des livres sur la préparation de playtest et les questions à éviter.
- En regardant des présentations sur comment préparer un processus de playtest et quelles informations sont importantes pour l’équipe de développement.
- Etc
Vous voulez en savoir plus?
Objectifs
- Apprendre les limitations humaines d’un joueur qui playtest le jeu.
- Apprendre comment ce préparer pour ces limitations.
Mes apprentissages
Perception
- La perception humaine est limitée, car celle-ci est influencée par la
cognition de l’être, ce qui la rend subjective.- Il se peut que plusieurs joueurs analyse les signifiants, icônes, textes et mécaniques de façons différentes, il faut en prendre compte lors la prise de note.
- Il faut prendre en compte également que certains joueurs possèdent un handicap tel qu’un daltonisme, ce qui peut affecter la perception.
- Il est important de ce rappeler que l’expérience console et PC n’est pas le même, alors, il faut faire des tests sur les deux types de plateformes.
Mémoire
- L’une des plus grosses limitations humaines est la mémoire, il faut s’assurer que le joueur se rappelle des informations lors de playtest.
- Utiliser des défis contextuels augmentant en difficulté pour que le joueur ait une plus grande facilité à se rappeler de l’information apprise.
Attention
- L’attention est une autre limitation humaine importante à considérer. L’être humain à très peu de ressource attribuée à l’attention, il est beaucoup plus efficace s’il travaille sur une seule tâche.
- Si une tâche est nouvelle ou complexe, le plus de ressource attentionnelle sera demandée de la part du joueur.
- Pour le test de jeu, limiter les demandes cognitives du joueur en ne créant pas de situation demandant du multi-tasking est une bonne façon de diriger l’attention du joueur vers la tâche qu’il est en train de faire.
Motivation
- Finalement, la motivation est une autre limitation humaine. Le joueur offrira de meilleures performances si celui-ci a une récompense à la fin du processus.
Objectifs
- Apprendre le temps optimal que l’équipe devrait attendre avant de produire une autre session de playtest.
- Apprendre comment utiliser le cycle itératif de façon optimal.
Mes apprentissages
- Un prototype papier peut-être utile pour les premières boucles itératives, cela permet que l’équipe découvre les faiblesses et les forces d’une fonctionnalité le plus tôt possible.
- Une transition vers un prototype interactif est ensuite faite et c’est ce prototype qui est implémenté dans de futurs tests.
- Il faut faire attention à la vitesse de la production et du temps limité, une fonctionnalité peut être faite trop rapidement et avoir été mal testée.
- Éventuellement, le cycle itératif n’impactera pas uniquement une simple caractéristique du jeu, mais le jeu en entier.
- Le cycle itératif fonctionne pour 3 principales raisons :
- Le cycle itératif permet de dé-risquer la production, en ajoutant et testant rapidement des fonctionnalités avec les joueurs.
- Le cycle itératif permet d’économiser du temps et de l’argent en validant rapidement les solutions auprès de la clientèle, permettant de savoir si le produit sera populaire.
- Le cycle itératif permet de mettre au point un produit centré sur l’utilisateur, à la fin de chaque itération, il est possible de recevoir de la rétroaction des clients en eux-mêmes.
Le cycle itératif peut être séparé en 5 étapes :
- La délimitation du périmètre et des objectifs.
- L’analyse et conception avec les parties prenantes.
- La construction de prototype.
- Les tests de jeu.
- Les feedbacks et révisions.
Objectifs
- Apprendre ce que l’équipe devrait donner comme informations au joueur avant le playtest.
- Apprendre quel type de joueur l’équipe devrait aller chercher pour les tests.
Mes apprentissages
- Selon SteamSpy, 20 % des joueurs qui jouent à un jeu arrêtent du jouer après seulement 1 heure de jeu.
- La première heure de jeu est cruciale pour le First-Time-User-Experience, où la majorité de l’onboarding cette passe.
- L’onboarding est nécessaire à chaque fois qu’une nouvelle fonctionnalité, mécanique ou système est montré au joueur
- Il faut que le joueur se sente compétent et autonome.
Le plan d’onboarding
Une façon de rendre l’onboarding à la fois engageant et efficient est de créer un plan d’onboarding.
- Créer une liste de tous les éléments que le joueur doit apprendre.
- Catégoriser les éléments par les systèmes généraux.
- Définir les éléments les plus importants pour que le joueur apprenne l’expérience principale.
- Mettre la liste dans un tableau avec les éléments dans une colonne, chaque élément sur une ligne différente.
- Catégorie primordiale
- Niveau de priorité (de 1 à 4)
- À quelle moment dans le jeu est-ce que l’élément devrait être appris?
- L’ordre de tutoriel
- Difficulté (simple, modéré, difficile)
- Pourquoi le joueur apprendre la mécanique.
- Comment la fonctionnalité sera apprise.
- Emballage narratif
- Une mécanique qui est commune avec de nombreux jeux sera facile à apprendre et une mécanique unique à un jeu sera beaucoup plus difficile à apprendre.
- Il faut s’assurer que le joueur puisse retourner voir le tutoriel ou puisse accéder aux astuces facilement dans le jeu.
- Il est cependant important que l’onboarding soit le plus simple possible.
Objectifs
- Apprendre quels outils sont optimaux pour le processus de playtest, que ce soit l’enregistrement vidéo ou la prise d’information.
Mes apprentissages
Affronter les fuites
- La première étape pour la création de la session de test de jeu est de s’assurer qu’il n’y a pas de fuite (leaks) à propos du jeu hors de test de jeu. Il y a plusieurs façons de protéger les secrets des jeux lors de possible test de jeu.
- Signature de NDA
- Le plus basique est possiblement les accords de non-divulgation ou non disclosure agreement (NDA).
- Il est typique de le signer lorsque l’on travaille sur des projets de jeux et tout aussi typique de demander aux testeurs de les signer au début des tests de jeu.
- Faire des recherches et test de jeu en personnes.
- Un test de jeu optimal se fait en personne dans un laboratoire, cela permet de surveiller les testeurs et de les prévenir, de prendre des photos ou une capture d’écran hors de la session.
- Il est aussi possible de demander aux testeurs de mettre leur téléphone dans un casier pour s’assurer qu’il n’est pas accès à un appareil photo.
- Si le test doit être fait à distance
- Il est possible de regarder le joueur tester le jeu et de demander au joueur de parler en temps réel pour ainsi lui offrir moins de possibilités de capturer de l’information qui ne doit pas être montrée au public.
- Pour certains jeux, il peut être judicieux de diffuser (stream) le jeu au joueur, plutôt que de lui envoyer directement une version.
- Mettre des filigranes (watermark) dans le prototype
- Il est possible de rendre les filigranes invisibles au joueur, mais visible à l’équipe. Le but de cela est de faire savoir au joueur que l’information qui fait partie d’une fuite peut être retracée jusqu’à lui.
- Retirer les assets importants des tests de jeu
- Lorsque l’équipe travaille avec une propriété intellectuelle établie, il peut être utile de masquer la propriété dans la version de test.
- La suppression d’assets peut être réalisée soit en créant une version personnalisée, soit en évitant d’inclure les assets finaux dans n’importe quelle version jusqu’à l’annoncement
officiel.
- Filtrer les participants des tests de jeu
- Pendant l’entrevue, il est important de vérifier :
- Que le testeur n’est pas un journaliste.
- Que le testeur n’est pas un créateur de contenu.
- Qu’ils n’ont pas de connexion avec les autres participants.
- Pendant l’entrevue, il est important de vérifier :
- Signature de NDA
Les outils à utiliser
- Rapport de bogue et engagement du joueur lors de tests
- La meilleure façon de calculer l’engagement d’un joueur est de faire un questionnaire. Il faut poser des questions sur l’expérience de jeu au joueur pour ainsi lui faire penser fort sur l’expérience qu’il vient de passer.
- Le logiciel recommandé est Google Forms, quoiqu’il y a d’autre équivalent.
- Pour la prise de données et statistiques
- Le moyen le plus simple de collecter des données importantes pour le jeu consiste à utiliser un logiciel d’analyse.
- Cela vous permet d’équilibrer et de tester des mécanismes individuelles, de cartographier les tendances du comportement des joueurs et de s’assurer que les joueurs voient tout le contenu que l’équipe veut qu’ils voient.
- Jouabilité, capture d’écran et vidéos
- Enregistrer des séquences de jeu des testeurs peut être incroyablement utile.
- Des vidéos permettent de voir comment un joueur ordinaire interagit avec le jeu et les vidéos et images en question peuvent même être utilisées pour le marketing.
- L’outil recommandé est OBS.
Objectifs
- Apprendre quelles questions sont utiles pour l’équipe de développement lors de session de playtest.
- Apprendre quelles questions sont à éviter lors de session de playtest.
- Apprendre le nombre de question à poser par chaque session de playtest.
Mes apprentissages
- Faire un test de jeu sans avoir de but spécifique en tête est une perte de temps.
- Pour des questions de test de jeu, il faut être le plus précis possible.
- Des questions tel « Est-ce que mon jeu amusant » ne sont pas assez précises pour être utile.
- Une fois que l’équipe à trouver la ou les raisons pour avoir un test de jeu, il faut que l’équipe pense à qui sera testé.
- D’habitude, l’équipe voudra choisir des testeurs qui font partie du client cible, mais même dans cette situation, il y a des choix possibles :
- Les développeurs : Toujours disponibles mais très proches du jeu, cela peut déformer leurs opinions.
- Les amis et familles des développeurs : Disponibles après les tests et confortables à parler. Ne veulent cependant pas blesser les émotions des développeurs, ils vont alors déformer la vérité.
- Les joueurs experts ou hardcore : Après avoir joué à beaucoup de jeu de même type et genre que le jeu que l’équipe produit, les joueurs experts peuvent communiquer des informations détaillées en utilisant de la terminologie technique et des exemples spécifiques. Cependant, ces joueurs demandent des défis et mécaniques plus difficile et complexes que ce que le joueur ordinaire demanderait.
- Les « testeurs tissus » ou testeurs qui n’ont jamais entendus parlé du jeu : Les testeurs de cette catégorie vont voir le jeu avec des yeux frais et peuvent remarquer des choses ou émettre des commentaires sur des éléments dont l’équipe c’était habitué. Cependant, si l’équipe n’utilise que des testeurs tissus qui jouent au jeu pour la première fois, cela pose un risque de créer un jeu qui démontre une forte attraction lors de la première session de jeu, mais qui peut devenir ennuyant lors de plusieurs sessions de jouabilité.
- Lors des retours de test de jeu, il est important de diriger la discussion et de prendre l’initiative. C’est une bonne idée de demander quelles étaient les premières impressions de chaque testeur.
- L’important est de trouver des problèmes et non des solutions.
- Dépendamment du type de questions, un processus de test devrait contenir entre 3 et 10 questions ouvertes dépendamment de ce que l’équipe de jeu recherche.
- 3 à 10 questions ouvertes n’épuise pas les testeurs et leurs permet de s’interroger sur leurs expériences.