Charlotte de Brabant - UX Designer
Dans Cache-Cache, deux joueurs doivent coopérer afin de trouver différents personnages cachés au sein d’un diorama coloré, avec une particularité : chaque joueur a son propre écran, et n’a pas accès à ce que voit son partenaire !
Chaque joueur voit une maquette en "miroir" de l'autre joueur. L'un a une maquette hivernale, tandis que l'autre a un paysage d'été.
Rôle
Équipe
Outils
Durée
UX Designer
7 personnes
Excel
Adobe XD
Google Forms
Papier & Crayon
2,5 mois
Fonctionnement du jeu
Dans l’expérience proposée, il existe deux maquettes : une représentant l’hiver, et une représentant l’été.
Lorsque les joueurs cliquent sur un objet, ils déclenchent une animation. S’il s’agit d’un personnage, il sera considéré comme ayant été « trouvé » et partira s’installer sur la lune au centre de l’écran.
Les joueurs peuvent également déplacer certains objets via un drag’n’drop, ainsi que s’échanger ces mêmes objets en les plaçant dans la lune, qui transfère alors un objet d’un joueur à l’autre.
Les défis
Cache-Cache est un puzzle game coopératif : un aspect fondamental pour le succès de l’expérience est donc de pousser la communication entre les joueurs.
Pour mieux cerner la direction à prendre, nous avons donc établi le type de public que nous visions avec Cache-Cache :
Des joueurs qui aiment interagir et explorer l’environnement de jeu, ainsi qu’interagir avec d’autres joueurs.
Nous n’avons pas explicitement restreint l’âge de notre public cible, car nous voulions que Cache-Cache puisse plaire à des enfants autant qu’à des adultes, pour peut-être permettre à des parents et enfants de jouer ensemble.
Dans cette optique, nous avons décidé de réduire le texte du jeu au minimum, afin d'éviter de créer des barrières de lecture ou de langue pour les joueurs.
Taxonomie de Bartle pour les joueurs de Cache-Cache
Processus de design & organisation des sprints
Je voulais que les joueurs puissent comprendre d’eux-mêmes, en communiquant, qu’ils évoluaient sur des maquettes séparées bien que liées.
L’intention était de provoquer une émotion positive, un sentiment d’émerveillement qui peut survenir lorsqu’on comprend quelque chose par soi-même pour la première fois. Différents playtests ont permis de s’assurer que les méthodes mises en place dans ce but fonctionnaient, et de les peaufiner.
Nous avons décidé de commencer par un tutoriel afin que les joueurs puissent comprendre qu’il s’agissait d’un jeu en coopération. Le but était que ce tutoriel soit suffisamment clair pour ne pas nécessiter de texte.
Pour couvrir toutes les possibilités, j’ai néanmoins prévu d’afficher du texte pour aider les joueurs qui mettraient trop de temps à passer cette étape, pour éviter tout blocage.
La boîte permet d’expliquer aux joueurs qu’ils jouent ensemble malgré les écrans séparés, puisqu’ils doivent nécessairement l’ouvrir à deux.
Document proposé pour faciliter la compréhension du tutoriel.
C'est ainsi qu'est née la "boîte".
Nous avons créé plusieurs éléments pour que les joueurs puissent faire le lien entre ce qu’ils voient et ce que le jeu attend d’eux. Notamment, si un joueur fait tourner la maquette, elle tourne également du côté de l’autre joueur.
Par exemple, les arbres : un côté feuillu qui s’ouvre comme une boîte pour le joueur côté été, et un arbre nu pour le joueur côté hiver.
Il s’agit d’une des premières énigmes du jeu : un personnage saute d’arbre feuillu en arbre feuillu quand le joueur clique dessus.
Le but est de faire sauter le personnage sur un arbre sans feuille afin d’interrompre les sauts du personnage. Il y a deux possibilités : le joueur côté été peut envoyer l’arbre à l’autre joueur qui a les arbres nus, ou le joueur côté hiver peut lui donner un de ses arbres.
Transfert d'un arbre d'une maquette à l'autre
L'élément central que nous avons utilisé pour que les joueurs comprennent qu'ils interagissent sur des maquettes différentes est la grande roue.
Imposante, elle est difficile à manquer. Le joueur peut cliquer sur les nacelles pour les faire se balancer, mais rien de plus.
Du côté hiver, à la place de la grande roue, le joueur a un simple bouton sur lequel il peut appuyer, mais qui ne semble rien déclencher de son côté.
Ce bouton met la grande roue en marche, provoquant nécessairement de la surprise et de la communication, qui conduisait systématiquement à la compréhension des joueurs lors des playtests.
Playtests
Une fois les défis de design établis, j'ai commencé à concevoir un protocole de test au cours du premier sprint.
Le prototype prévu contenait une première énigme fonctionnelle, ainsi que les modélisations 3D nécessaires intégrées au prototype.
J'ai commencé par isoler 3 sujets principaux :
-
Est-ce que l’énigme est comprise ?
-
Est-ce que les joueurs communiquent pour résoudre l’énigme ?
-
Est-ce que les interactions “écho” sont comprises ?
J'ai réuni 3 éléments pour ce protocole :
-
une observation des actions des testeurs
-
un questionnaire
-
un entretien individuel
Le questionnaire comporte des questions pour identifier la position du joueur – ainsi que pouvoir lier les binômes – ainsi que différentes échelles de Likert notées sur 7.
Puisque ce que je cherchais à identifier concernait la communication, une chose difficile à évaluer, j’ai doublé certaines questions afin de minimiser les risques d’erreur d’interprétation.
Exemple de réponse lors du premier playtest (8 participants). On y constate un manque de compréhension certain.
Pour mener à bien les tests, j'ai recruté un second observateur pour m'accompagner car, les deux joueurs étant face-à-face, il m'aurait été difficile de correctement observer les deux en même temps.
En plus de l'observation, j'avais prévu un questionnaire et un entretien individuel pour chaque testeur.
J'ai pu facilement recruter des testeurs parmi les autres étudiants. Il s'agit nécessairement d'une population biaisée :
-
Les testeurs connaissent particulièrement bien les codes du jeu vidéo, et peuvent donc moins être dérangés par des éléments qui manquent pourtant de clarté
-
En tant que professionnels du secteur, leurs exigences peuvent être différentes d'un public général
Mais qui présente ses propres forces :
-
Les testeurs se connaissent déjà, il n'y a donc pas de frein supplémentaire à la communication (contrairement à un public recruté indépendamment), ce qui rend la situation de test plus proche d'une situation réelle
-
Ils connaissent l'exercice et risquent moins de ne pas oser critiquer le prototype
J’ai réalisé plusieurs sessions de tests utilisateur au cours du projet selon ce même schéma afin de répondre aux nouvelles questions qui se posaient avec l’avancée du projet et la résolution d’anciens problèmes.
Après avoir interprété les résultats des playtests, je les compile dans un powerpoint que je présente à l’équipe avec les changements que je préconise pour résoudre les problèmes rencontrés. Nous avons ainsi pu itérer et améliorer le prototype tout au long du projet.
Visualisation de la progression
Lors d'un des playtests, j'ai notamment constaté 2 difficultés :
-
Les joueurs ne comprenaient pas quand une énigme était résolue
-
Les joueurs ne savaient pas où ils en étaient en termes de progression
J'ai donc proposé la solution suivante :
-
Ajouter des feedbacks de réussite plus clairs : jingle sonore et animation visuelle
-
Placer les personnages trouvés sur la lune pour permettre de suivre la progression de manière diégétique et constante, sans pour autant gêner la lisibilité de la maquette
Lors de la présentation finale du projet, je suis restée tenir notre stand et observer les joueurs la majeure partie du temps. J’ai pu constater beaucoup de sourires, cris d’exclamation et de rires, particulièrement lorsqu’ils comprenaient le fonctionnement du jeu.
J’ai également pu observer différents obstacles rencontrés par certains groupes de joueurs, qu’il s’agisse de la difficulté de l’énigme finale, ou même d’obstacles de compréhension de la mécanique de transfert.
Pour la majorité des joueurs, le problème restait marginal, de par la nature coopérative du projet : tant qu’un des joueurs comprenait quoi faire, il pouvait guider l’autre pour avancer ensemble.
Cependant, j’ai pu prendre conscience de défauts restants dans ce projet « terminé ». Bien qu’il n’ait pas été possible d’améliorer le projet à ce stade, j’ai quand même trouvé cette expérience utile, et j’y ai appris des informations qui serviront pour des projets futurs.
Accessibilité
En raison de la technicité du projet – un jeu qui se voulait en réseau – et du court temps de production, j’ai été limitée concernant la mise en place de l’accessibilité, et ai donc dû faire des choix qui nécessiteraient peu de ressources.
Le premier élément que j’ai poussé était l’accessibilité pour les personnes daltoniennes. Puisqu’une grande partie du charme initial de Cache-Cache se situe dans son environnement coloré, je ne voulais pas d’un filtre qu’on ajoute pour changer les couleurs du jeu, au risque de perdre une certaine harmonie visuelle. J’ai préféré opter pour une solution plus directe et universelle : chaque objet a une forme distincte des autres et ne peut pas être confondu, même en jouant en nuances de gris.
Comme je n’aime pas informer le joueur par le biais d’un seul élément – comme la couleur – ce choix, loin d’être un obstacle, permet une meilleure clarté à l’écran pour tous les joueurs. Son avantage est également de ne pas demander de travail supplémentaire à l’équipe, puisqu’il ne s’agit pas d’une option à implémenter via un menu.
Pour m’assurer du bien-fondé de cette stratégie, j’ai commencé par tester des filtres pour simuler différents types de daltonisme afin de constater par moi-même si on pouvait bien distinguer chaque objet, notamment à l’aide d’outils comme le testeur de contraste de Webaim, ou des simulateurs de daltonisme.
Une fois cette étape validée, j’ai pu demander directement l’avis d’un camarade de classe daltonien qui a pu me confirmer que le prototype convenait à son type de daltonisme.
Nous avions prévu d’ajouter des motifs propres à chaque objet si besoin, (pour remplacer l’information donnée par la couleur) mais ça n’a pas été nécessaire.
Un autre aspect d’accessibilité que j’ai voulu inclure était d’uniquement proposer des interactions simples. Mon but était de limiter les actions disponibles afin de rendre le jeu accessible à un maximum de personnes même dans sa version par défaut, sans option.
Si cette décision a été en partie prise en raison des contraintes du projet – le peu de temps et de ressources ne permettraient pas d’intégrer de véritables options - je vois également ces contraintes comme une façon de ne pas s’éparpiller lors du processus de design.
Le jeu comporte donc deux interactions, prévues à la souris :
-
le clic gauche simple pour interagir avec un objet
-
le drag’n’drop pour déplacer un objet
Drag'n'drop d'un arbre
Limiter le nombre d’interactions possibles permet de toucher plus facilement différents publics :
-
Les jeunes générations sont plus familières des smartphones que des ordinateurs et ont parfois du mal avec les souris
-
Nombre de personnes âgées ont une connaissance limitée des ordinateurs
-
Les personnes avec différents problèmes moteur (tendinite, mouvements limités, douleurs, etc) rencontreront moins d'obstacles
-
Le jeu devient plus facilement portable sur mobile
J’ai donc designé deux options pour remplacer cette interaction :
-
Si, sur un objet que l’on peut déplacer, le joueur utilise le clic droit au lieu du clic gauche, alors l’objet sera « aimanté » à la souris et se déplacera avec le curseur. Cette possibilité est prévue pour aider les joueurs avec des douleurs ou une faible amplitude de mouvement (et leur éviter d’aller chercher une icône à chaque fois). Intégrer cette option par défaut facilite également le remapping avec des outils comme joy2key.
-
Pour les personnes pouvant bouger le curseur mais n’ayant qu’un seul input disponible (avec un contrôleur alternatif par exemple), j’ai proposé une icône à cliquer qui aimante les objets quand elle est activée.