Le maquettage dans les jeux vidéo : la pratique
Dans un billet précédent, nous avons rapidement illustré les avantages du maquettage dans un projet de jeu. Nous avons également décrit quelques techniques rapides et pas chères pour commencer à tester certaines mécaniques du jeu. Dans ce billet, nous vous proposons d’aller encore plus loin.
Un exemple concret
Nous prendrons ici un exemple concret auquel nous avons été confrontés chez LudoTIC : il s’agit d’un jeu visant à sensibiliser les voyants aux problématiques des non-voyants dans leur déplacement urbain. L’objectif du jeu est de parcourir différents lieux en vue du dessus sans aucune information visuelle. Tout se fera donc par l’écoute des sons environnants. L’utilisateur saura s’il doit avancer, tourner ou reculer selon les sons qu’il entendra dans son casque : s’il entend un son dans les deux oreilles en même temps, c’est que le son est en face ; s’il entend un son uniquement dans l’oreille droite, c’est qu’un obstacle se trouve à 90° sur sa droite. La question qui nous a poussés à réaliser une maquette digitale est la suivante : « Quel est le déplacement le plus intuitif pour que le joueur sache à chaque instant se diriger vers un son ? » Rappelons que comme le joueur n’a pas d’écran pour savoir où est son personnage sur la carte du jeu ni la direction à laquelle il fait face, il peut être délicat de progresser sans repère. C’est la raison de ce questionnement, qui nous a mené à identifier deux alternatives aux déplacements de l’avatar :
- La rotation : dans le jeu, lorsque le joueur « tourne », l’avatar reste fixe et c’est l’environnement qui tourne. On dira que le référant ici est l’avatar : tout (son) évolue en fonction de sa position par rapport à l’avatar. Comme dans la vraie vie, les sons sont modifiés selon notre orientation spatiale. Mais dans la vrai vie, notre vision compense ce référant dynamique et le cerveau arrive à calculer voir même à anticiper la position des bruits par rapport à notre personne. Nous ne sommes pas surpris qu’un son face à nous « glisse » vers notre droite lorsque nous nous tournons vers la gauche. Notre cerveau n’est pas surpris d’entendre à droite le son qui été devant lui avant qu’il ne tourne sur la gauche (Vous suivez ?!). Cette modalité d’interaction est plutôt naturelle. Mais sans la vue et sans le sens de l’équilibre, est-ce que le joueur sera capable de comprendre le comportement « glissant » du son ?
- Le déplacement latéral : l’avatar se déplace en pas chassés, un déplacement latéral, comme un crabe (« strafe » pour les intimes). Dans le cas présent (déplacement latéral vers la gauche), le son étant présent devant l’avatar restera devant mais se déplacera légèrement sur la droite (le niveau du son diminuera dans l’oreille gauche). Ici, le référant est le nord, le haut de l’écran, qui est fixe. Ainsi, bien que cela soit moins réaliste (nous nous promenons rarement en strafe… si ?), le joueur n’a pas besoin de compenser cognitivement par un traitement supplémentaire lié à l’évolution du référant (qui dans la rotation est dynamique, alors qu’ici il est fixe : c’est le haut de l’écran). Cette modalité d’interaction est peu naturelle.
Mais comme une vidéo vaut mieux que tout un discours, mettez votre casque (dans le bon sens… l’oreillette gauche dans l’oreille gauche et l’or… bon vous avez compris) :
Par défaut nous aurions tendance à penser que le fonctionnement naturel soit meilleur, plus ergonomique, et plus agréable pour le joueur… pas si sûr !
Nous allons voir à travers la méthode d’évaluation proposée quels sont les résultats obtenus.
Méthodologie pratique
La méthodologie suivante est davantage pragmatique que scientifique. L’objectif ici n’est pas d’alourdir le travail des concepteurs. Au contraire, une méthodologie basée sur le principe d’itération-correction, permettant assez rapidement d’avoir un retour utilisateur, nous paraît plus pertinent pour s’adresser à tout potentiel concepteur de jeu.
La cible
Avant toute chose, il est important de sélectionner des testeurs correspondant à la cible de votre jeu : si la cible prioritaire est le grand public (Aïe !), il vous faudra sélectionner un échantillon assez hétérogène quant à ses compétences « vidéo-ludiques ». S’il s’agit d’hardcore gamer, il faudra là aussi sélectionner des joueurs répondant cette cible.
L’analyse du comportement des « joueurs débutants » permet de vérifier l’accessibilité du jeu. Si eux y arrivent, tout le monde y arrive. L’analyse du comportement des joueurs plus assidus permettra d’évaluer le fun ainsi que la cohérence du jeu par rapport à son écosystème : tous les jeux ont leur propre code. Est-ce que les joueurs experts retrouvent assez vite leur marque ? Si l’objectif du jeu est justement de rompre avec les codes, il est aussi intéressant d’observer les réactions des joueurs experts : sont-ils désorientés ?
Pour notre jeu « aveugle », étant destiné à ce fameux grand public, nous avons tenté de prendre davantage de non joueurs. S’ils y arrivent, tout le monde peut y arriver.
Concernant le test sur le jeu aveugle, nous avons pris 5 participants : 3 femmes et 2 hommes, dont une femme et un homme considérés comme étant des joueurs confirmés et les 3 autres comme des non-joueurs.
Ok. De combien de testeur avons-nous besoin ?
Sans entrer dans les détails, dites-vous que pour observer la majorité des problèmes d’un site ou d’un logiciel (environ 80%), il est souvent préconisé de tester l’interface sur au moins 4 ou 5 groupes de test. Le retour d’un seul participant n’est pas suffisant : peut-être n’est-il pas représentatif de l’intégralité de la cible. Celui de 2 personnes est difficilement interprétable : si les 2 résultats diffèrent pour beaucoup, comment trancher ?
Faire entre 3 à 5 passations paraît le plus rentable. « Rentable » car le but ici est d’être rapide et efficace. Cela va surtout dépendre de l’importance de ce que vous cherchez à évaluer et de la facilité à trancher. Si vous pouvez avoir davantage de testeurs, ça ne sera que mieux ! Mais attention, si c’est un jeu solo, il vous faudra 5 personnes pour tester 5 fois votre prototype et pouvoir porter des conclusions légitimes. Si c’est un jeu multi-joueurs à quatre, il ne vous faut pas 4 personnes mais bien 4×5 personnes pour tester 5 fois le prototype ! Vous avez beau avoir 4 personnes, dans les faits, vous n’aurez observé qu’une seule partie de jeu !
Pour le test sur le jeu aveugle, nous avons ainsi pris 5 participants et donc fait 5 passations.
Tous les tests doivent-ils être identiques ? Combien de boucles ?
Comme dit précédemment, nous ne vous proposons pas une méthodologie des plus scientifiques. Ici, l’objectif est de pouvoir déceler le plus rapidement possible les avantages et les inconvénients de votre concept maquetté à la manière de la méthode RITE. L’intérêt n’est pas d’attendre que les 5 testeurs échouent au même endroit pour corriger la faille : vous aurez tous les résultats possibles démontrant l’existence d’un problème mais aucune proposition d’amélioration. Il s’agit là de faire preuve de bon sens : si dès le premier testeur vous constatez un problème évident et arrivez à le corriger facilement avant que le deuxième test commence, il faut le faire ! Si par contre le 4ème testeur échoue sur un élément qui a été facilement passé par les 3 joueurs précédent, attendez plutôt de voir le comportement d’un dernier joueur (le 5ème) pour pouvoir traiter votre 4ème testeur de nigaud !
Pour reprendre une fois encore Jesse Schell :
« La règle de la boucle n’est pas un objectif, parce que ce n’est pas un point de vue, c’est une vérité absolue »
Contre-Balancement
Dans notre expérimentation sur le jeu d’aveugle, nous avions 2 alternatives à tester : la rotation et le « strafe ». Chaque testeur s’est essayé aux 2 modes de jeu. Pour éviter un effet d’apprentissage d’un mode sur l’autre (le fait de tester le premier mode peut rendre le joueur plus aguerri lorsqu’il arrive sur le deuxième mode et donc fausser les résultats) nous avons introduit une notion de contre-balancement : alors que le premier joueur à commencer par tester le mode « rotation » puis « strafe », le deuxième joueur a fait l’inverse. Et ainsi de suite. Nos 2 joueurs « experts » ont d’ailleurs réalisé la séquence inverse.
A moins que votre prototype ne propose des séquences dépendantes les unes des autres, c’est à dire qu’il est nécessaire de faire l’une avant l’autre, évitez de présenter les séquences toujours dans le même ordre.
Consignes
Il faut bien comprendre que lors du test d’une maquette, vous devez faire « comme si » le ou les joueurs étaient seuls chez eux devant le jeu. Il faut donc au préalable bien définir les consignes afin que le joueur soit le plus autonome pendant son test, qu’il ait le moins possible besoin de vous (expérimentateur et/ou concepteur) ou de quelques conseils, toujours « comme si » il était seul chez lui devant son jeu. Travailler donc le corpus de ces consignes, leur ordre d’apparition, leur modalités d’affichage (inscrites sur une pancarte ou un post-it, énoncées par l’expérimentateur – « comme si » il s’agissait d’une cinématique, etc.) et s’en tenir à les donner comme tel toute au long des différentes passations ! Au moins bien sûr que votre consigne présente un problème évident ou soit incompréhensible, auquel cas, comme dit précédemment, modifiez la pour le test suivant et tentez de vous y tenir pour la suite.
Il faut aussi éviter de donner des conseils à l’un que vous n’auriez pas donné aux autres. Cela ne veut pas dire qu’il faille laisser un joueur dans le flou, dans l’impossibilité d’avancer. Mais si vous l’aidez, notez cette demande comme un échec et observez le comportement des joueurs suivants dans la même situation. Si tous montrent la même difficulté, c’est que le premier joueur ayant relevé le problème a vu juste. Si vous estimez avoir une solution suite à son échec, intégrez-la directement dans vos prochaines sessions.
Enfin, si votre discours auprès des joueurs évolue entre 2 tests, notez l’évolution que vous proposez, testez-la, et si cette solution s’avère efficace, proposez-la ensuite aux prochains joueurs.
Quelles sont les mesures d’évaluation ?
Celles-ci sont très variables et dépendent grandement de l’objet à tester. Il peut s’agir du temps mis par un joueur pour répondre à une consigne, le nombre de clics (sur bouton ou sur clavier/souris) pour réaliser une action, le nombre d’itération avant réussite (on peut imaginer une mesure d’itération dans laquelle au-delà d’un certain nombre d’échec on considère l’objet évalué comme mauvais). Que ce soit la consigne, les commandes, le level design, etc.), le nombre de fois où le joueur s’est retourné vers l’expérimentateur pour qu’on lui apporte de l’aide (chose qu’il sera impossible de réaliser dans le « vrai » jeu), etc.
Pour notre prototype, nous avons relevé 2 mesures :
- le temps mis à réussir la tâche
- le nombre de clic
En fonction de ces deux mesures, nous avons constaté un temps de réussite et un nombre de clics significativement meilleur pour l’interaction par « strafe ». C’est à dire, dans ce cas-là, moins de temps (8 secondes en moyenne pour répondre à la consigne lorsque le déplacement se fait par strafe contre 23 secondes lorsqu’il se fait par rotation) et moins de déplacements (6 déplacements en moyenne pour réussir la mission en mode strafe contre 19 en mode rotation). Ce qui révèle, pour nous, que le mode le moins naturel est pourtant le plus intuitif. Cela peut s’expliquer de différentes façons, mais nous ne rentrerons pas ici dans nos interprétations du fonctionnement cognitif humain. Nous avons donc décidé d’implémenter ce mode de déplacement pour être le plus accessible pour la large cible que nous visons. Cela n’empêche pas l’autre modalité « par rotation » d’être jouable, voire même davantage fun, mais instaurant dans notre échantillon « grand public » une ambiguïté du repérage suffisamment importante pour ne pas la sélectionner.
Qui doit réaliser le test ?
Il est fondamental de garder un esprit critique quant à son jeu. « Ne vous y attachez pas ! » comme dirait Jesse Schelle :
« Vous devez commencer votre phase de travail de [maquette] en ayant à l’esprit sa nature temporaire : la seule chose qui importe est la réponse à la question »
(Vous vous rappelez de la question hein ? Celle à l’origine de votre maquettage).
Il faut prendre toutes critiques sans nécessairement se sentir attaqué par chacune d’entre elle. Ce qui peut être difficile puisqu’il s’agit « du bébé » d’un ou de plusieurs créatifs. Le meilleur compromis est donc de laisser à un tiers (ergonome ou expert en expérimentation) le soin de réaliser le test. Il faut partir du principe que tout retour du joueur est pertinent et qu’une fois à la maison devant son jeu final, il n’aura pas d’expérimentateur ou de Game Designer à ses côtés pour l’aider ou pour défendre une idée de gameplay incomprise par le joueur.
Durée des passations
Il n’y a pas de temps « type ». Cela peut varier d’une minute à 45 minutes voire une heure. Sachez toutefois que plus le test est long, plus l’analyse à réaliser sera importante et complexe. Sans compter la prise en compte des autres itérations. L’objectif de ces maquettes est de pouvoir segmenter le jeu en petits morceaux. Une maquette trop lourde ou un test trop long traduisent souvent une mauvaise compréhension du principe : il faut modéliser un voire deux aspects du jeu afin de pouvoir les évaluer. Trop de variables à évaluer à la fois empêchent de pouvoir tirer des conclusions claires sur les observations faites.
Evaluer la satisfaction du joueur
Il est très intéressant d’observer le joueur au cours de sa partie en vue d’une analyse, notamment en relevant ses comportements physiques (bâillement, posture contrainte du joueur reflétant la tension qu’entraîne le jeu – positif ou négatif), et verbaux (« c’est génial ! », « j’ai rien compris! », « j’dois faire quoi!? », ainsi que les niveaux sonores de ses verbalisations (parler doucement dans un jeu d’infiltration peu indiquer une bonne immersion du jeu, etc.).
Vous pouvez également proposer un questionnaire au joueur à la suite du test pour évaluer son ressenti, ses impressions sur le jeu, sur la maquette, (« souhaiterais-tu rejouer à ce jeu ? « attends-tu sa sortie en « vrai »? », « donnes-moi 3 adjectifs positifs et/ou négatifs concernant ton expérience pendant la partie », etc.). L’analyse de la satisfaction peut donner des indications sur les aspects préférés ou détestés par le joueur, les pistes d’amélioration, etc.
Enfin, n’hésitez pas à corréler ces deux analyses issues d’une part de l’observation (ce que les gens font) et d’autre part du questionnaire (ce que les gens disent qu’ils font) pour vérifier la validité de votre analyse.
Conclusion
L’intérêt du maquettage dans le jeu vidéo est donc de pouvoir tester certaines mécaniques très tôt dans sa conception. Le faible coût de sa mise en place comparativement à la quantité d’informations qu’il permet d’extraire en fait l’une des techniques les plus pertinentes et efficace de la conception interface homme-machine.
La méthodologie présentée ci-dessus est en cours d’élaboration, elle est-elle même une sorte de maquette. Alors n’hésitez pas à la tester, à l’évaluer, à l’améliorer, puis à la partager avec nous mais surtout avec d’autres.
