iMA - Ergonomie d'un jeu de simulation de vol zen

1. iMA : Présentation du projet
   1. Processus de développement
2. Pitch
3. Pré-production
   1. Modèle de vol d’une simulation zen
   2. Que faisaient les joueurs spontanément pour controller la crêpe?
      1. La moitié des participants utilisait principalement le modèle du planeur, l’autre utilisait le modèle du rameur.
      2. Les joueurs utilisant le modèle du rameur battaient une main avec une amplitude plus grande que l’autre.
      3. Les joueurs utilisant le modlèle du planeur positionnaient leurs mains avec des hauteurs différentes pour tourner.
      4. Pour prendre de la vitesse, la pluspart des participants battaient des mains rapidement avec une amplitude faible et quelque-un disaient faire un plongeon
      5. Pour ralentir, les participants indiquaient qu’ils essaieraient de monter.
      6. Pour monter, les joueurs utilisant le modèle du rameur utilisaient des battements lents mais amples.
      7. Pour descendre, la pluspart des joueurs mettaient leur deux mains immobiles le plus bas possible et quelques uns les retiraient totalement des capteurs.
      8. Pour monter, descendre ou ralentir certains joueurs utilisant le modèle du planeur inclinaient leur mains.
      9. Les utilisateurs pensaient que battre des mains était plus intéressant, original et tirait mieux parti du dispositif.
   3. Quels gestes étaient le plus fatiguant?
      1. Garder les bras horizontaux pour planner était plus fatiguant que battre des bras.
      2. Les participants avaient une tolérance limitée pour répéter le même type d’interaction de façon prolongée en général.
   4. Comment les joueurs explorent-ils le niveau?
4. Méthodologie et mise en place
5. Déroulement des tests
6. Résultats, décisions, conclusions
7. Modèle d’interaction et fatigue liée aux contrôles gestuels
   1. Question de départ et enjeux
   2. Méthodologie et mise en place
   3. Déroulement des tests
   4. Résultats, décisions, conclusions
8. Retour d’expérience
9. Principaux résultats
10. conclusion

iMA : Présentation du projet

Réalisé dans le cadre des projets étudiants de première année de master à l’ENJMIN, iMA est une simulation de vol centré sur l’exploration d’un milieu mêlant vie aérienne et aquatique. L’utilisateur incarne “la crêpe volante” à la recherche d’orbes qui lui permettent de faire grandir et évoluer son corps. In fine, le jeu propose une expérience zen et relaxante à travers une nouvelle approche des contrôles. L’objectif: créer une expérience proposant un retour aux sources, concrétisant un rêve d’enfant, provoquant un plaisir physique de voler.

La spécificité technique du projet réside dans la prise en main : des télémètres ultrason branchés sur un microcontrôleur arduino permettent de reproduire les gestes du joueur : ses mains deviennent ses ailes.

Pour en savoir plus sur le jeu, je vous invite à consulter le site du projet, qui présente plus en détail les aspects de gameplay et de conception graphique. Vous y trouverez également le jeu en téléchargement et toutes les informations requises pour construire votre dispositif et expérimenter vous même le dispositif.

Processus de développement

Pour ce projet, notre équipe de 9 personnes disposait de 3 mois pour créer une expérience complète, jouable sans intervention extérieure. Nous nous sommes organisés en sprints hebdomadaires pour itérer rapidement. Le début des sprints était décalés entre différents corps de métiers.

[insérer visuel du planning]

Ainsi, les concepteurs commençaient leur sprint le jeudi, les développeurs le lundi et l’ergonomie le mardi. Cela permettait au travail de chacun d’être prêt quand le sprint des suivant commençait.

Pitch

Avant que le projet ne commence, un petit groupe de personnes intéressés se forma autour d’un intérêt partagé pour la technologie arduino. Le projet émerga autour de trois moments clé.

Un inventaire des options disponibles pour créer un controlleur arduino que nous aimerions utiliser amena l’idée de construire un jeu avec des télémètres.

Avec cette idée en tête, chacun proposa une idée de jeux qui pouvait fonctionner avec ce type d’interactions. En plus de la facilité de prise en main et la durée de l’expérience, le critère le plus important pour nous était de trouver un concept qui rendrait indispensable la technologie. Il fallait que ce soit plus qu’un gadget. Le jeu ne devait pas avoir de sens sans les capteurs.

Après en avoir choisi 2, nous les avons raffiné pour les soumettre au processus de création d’équipe, en espérant qu’une des deux soit retenue. C’est iMA qui l’emporta.

Pré-production

Le premier mois du projet fut consacré à lever les inconnues, qu’elles soient techniques ou non. Par exemple:

• identifier le design précis du jeu: ce qu’il est, ce qu’il n’est pas, ce qu’on aimerait faire, ce qu’on aura le temps de faire ou pas.
• commander le matériel et s’assurer que le montage électronique fonctionne
• se familiariser avec les API et outils de développement prévus pour le projet, tester l’utilisation des données des capteurs pour controller le jeu
• explorer des pistes graphiques, concevoir le personnage principal et l’ambiance des décors
• créer une première version des environnements sous forme de “greybox” pour se faire une idée de leur taille et de la quantité de travail à prévoir.
• identifier les attentes et apréhensions des futurs joueurs, adéquation entre l’interface et l’es ‘usages
• identifier un modèle d’interaction gestuel naturel et les risques associés à l’utilisation de ce dispositif (confort, fatigue, activation accidentelle etc.)
• identifier les informations nécessaires au joueur pour apprendre et comprendre le jeu, sa prise en main et la notion de succès

Pour détailler d’un point de vue de l’ergonomie les questions que je me posais à ce stade du projet, ajoutons:

• Comment contrôler une multitude d’actions et d’activités avec seulement deux valeurs comme input?
• Quels sont les contrôles les plus intuitifs? Les plus confortables?
• Quels aspects de ces contrôles sont le plus fatiguant pour le joueur?
• Comment évaluer un modèle d’interaction à mesure qu’il évolue et s’affine?
• Quels sont les indicateur les plus pertinents pour savoir si le projet sera un succès?
• Quels aspects du gameplay faudra-t-il évaluer? Quelles mesures nous y aideront? Quand sera le bon moment pour évaluer chaque aspect?
• Quelles stratégies d’exploration et de navigation les joueurs utilisent-ils pour progresser dans le jeu?
• Comment évaluer la difficulté en vue de l’ajuster?
• Combien de temps faut-il aux joueurs pour trouver toutes les orbes?

Modèle de vol d’une simulation zen

Utilisant les capteurs de distance comme controlleur, nous avions toute liberté sur quel niveau de controlle donner au joueur:

• l’avatar pourrait copier chaque geste du joueur précisément. Par exemple, si le joueur lève les bras, les ailes montent. S’il les baisse, les ailes descendent. Ce contrôle local demande donc au joueur d’apprendre à battre des ailes pour voler avancer, controller sa trajectoire etc. On appela ceci le modèle du rameur.
• l’avatar pourrait être relativement autonome pour laisser le joueur se focaliser sur la trajectoire, pendant que la créature s’occupe de “voler” selon un modèle du planeur. Cela permettrait aussi de lui personnalité plus forte.

Tout un éventail de solutions intermédiaires était également envisageable, pour trouver le bon équilibre entre profondeur et complexité des contrôles, versus simplicité à prendre en main et confort d’utilisation.

Pour prendre la bonne décision, chaque discipline fit son étude de la question, et j’utilisai leur travail pour tester avec des utilisateurs finaux nos hypothèses. Pour cela, j’utilisai les prototypes développés pour tester l’acquisition et le traitement du signal des capteurs. La crêpe était représentée par trois points: le corps et le bout de chaque aile. Elle volait sur un fond noir. Pour tester, je demandais donc aux participants de faire preuve d’imagination en proposant des scénarios hypothétiques tels que:

• Imaginez que vous suivez des oiseaux migrateurs, ils vont tout droit en prenant leur temps. Que feriez vous pour avancer tout droit?
• Les oiseaux tournent à droite, comment faites vous pour les suivre?
• vous essayez de rattrapper un avion, allez le plus vite possible pendant aussi longtemps que vous le pouvez

Voici les principaux résultats combinés des différentes études réalisées:

Que faisaient les joueurs spontanément pour controller la crêpe?

Hypothèse: si nous créons des controles basés sur les comportements spontanés des joueurs, le jeu sera intuitif à prendre en main.

La moitié des participants utilisait principalement le modèle du planeur, l’autre utilisait le modèle du rameur.

Toutefois, la pluspart des joueurs utilisait un mélange des deux modèles pour certaines actions. (Basé sur l’observation de 12 participants.)

Les joueurs utilisant le modèle du rameur battaient une main avec une amplitude plus grande que l’autre.

La main qui bougeait le moins indiquait toujours l’intérieur du virage. Certains la gardaient totalement immobile, alors que d’autres la bougeaint légèrement.

Les joueurs utilisant le modlèle du planeur positionnaient leurs mains avec des hauteurs différentes pour tourner.

La main la plus basse indiquait toujours l’intérieur du virage.

Pour prendre de la vitesse, la pluspart des participants battaient des mains rapidement avec une amplitude faible et quelque-un disaient faire un plongeon

Pour plonger, certains levaient les bras, d’autres les baissaient et d’autres enfin retiraient les pains des capteurs.

Pour ralentir, les participants indiquaient qu’ils essaieraient de monter.

Pour ne pas regagner de la vitesse en descendant, ils indiquaient descendre avec une pente douce.

Pour monter, les joueurs utilisant le modèle du rameur utilisaient des battements lents mais amples.

Pour descendre, la pluspart des joueurs mettaient leur deux mains immobiles le plus bas possible et quelques uns les retiraient totalement des capteurs.

Pour monter, descendre ou ralentir certains joueurs utilisant le modèle du planeur inclinaient leur mains.

Ils mettaient les doigts vers le haut pour ralentir ou monter, et vers le bas pour descendre. Ceci posait des problèmes car les capteurs n’identifiaient qu’un seule position par main: le point le plus bas.

Les utilisateurs pensaient que battre des mains était plus intéressant, original et tirait mieux parti du dispositif.

Planer était au contraire vu comme étant déjà fait dans d’autres jeux avec une simple manette avec un résultat satisfaisant.

Quels gestes étaient le plus fatiguant?

Hypothèse: Nous pouvons créer une expérience relaxante si nous définissons un modèle d’interaction peu fatiguant par défaut et utilisons avec parcimonie des gestes qui demandent plus d’effort comme élément de difficulé.

Garder les bras horizontaux pour planner était plus fatiguant que battre des bras.

Les participants utilisant le modèle du planeur tenaient moins longtemps que ceux utilisant le rameur quand on les incitait à prolonger l’interaction le plus longtemps possible.

Note: Ceci est cohérent avec la littérature scientifique. En ergonomie du travail, on recommande de limiter le maintien prolongé de postures statiques par exemple à l’origine de lombalgies.

Les participants avaient une tolérance limitée pour répéter le même type d’interaction de façon prolongée en général.

Recommandation: tenir compte de cela en s’assurant que le level design pousse à changer d’interaction et que les distances à parcourir restent raisonnables.

Note: En ergonomie du travail toujours, les gestes répétés sont plus propices au développement de troubles musculo squelettiques. Dans les deux cas, une solution pour réduire le risque est de varier les activités pour ne pas solliciter trop une seule partie du corps.

Comment les joueurs explorent-ils le niveau?

Basé sur une première version du niveau du jeu “LD Bloc” pour délimiter temporairement les parcours et obstacles par des boites grises, nous nous attendions à ce que les joueurs explorent différents endroits selon qu’ils utilisent les contrôles de type “rameur” ou “planeur”.

---

Quel impact sur le déroulement de la partie, en termes de comportements et stratégies d’exploration des joueurs? GD: est-ce que le dispositif fait gadget? Est-ce que l’expérience est fortement dégradée si on retire le dispositif?

Méthodologie et mise en place

Afin de tester le modèle de vol, nous avons réalisé un test utilisateur.

Trois choses ont joué en faveur de la réalisation de tests utilisateurs dès les premières semaines du projet. D’une part, la technologie Arduino est bien documentée et les drivers disponibles et rapidement utilisables. D’autre part, nos programmeurs avaient commencé en amont à préparer une librairie permettant d’interpréter les inputs selon nos besoins. En conséquence, les différents modèles de vol ont pu être implémentés rapidement.

D’autre part, le choix du moteur Unity nous a permis de réaliser en de très brefs délais un prototype fonctionnel et adapté à une première session de test. En effet, le moteur est fourni avec un niveau proposant un environnement complet et jouable tel quel, ce qui permettait de réaliser des tests sans attendre d’avoir réalisé nos environnements de jeux.

De plus, la phase de test des pipelines d‘intégration graphiques nous a permis d’avoir à disposition un premier avatar animé de façon adéquate aux besoins du test. Dès le second prototype, nous avons donc pu implémenter deux niveaux de contrôle de l’avatar, dans le but de les tester et comparer.

Un modèle de vol dit « animé » déclenchait les différentes animations du modèle dès qu’une séquence d’action appropriée était détectée. Le second modèle, dit couplé, associait des frames de l’animation de l’avatar à la hauteur de main du joueur. L’état de l’avatar reflétait donc les actions du joueur de façon rudimentaire, et se déplaçait en fonction des détections, sans que celles-ci soient explicitement représentées.

Déroulement des tests

Les tests utilisateurs se sont déroulés dans un premier temps dans les locaux de l’école avec des étudiants extérieurs au projet. Ces premiers tests ont été complétés par des étudiants totalement extérieurs à l’école.

Durant une première phase, le joueur était livré à lui-même, avec pour seule explication le fonctionnement basique des capteurs de distance. Ceci était le sujet d’une première série d’observations : quels sont intuitivement les gestes adoptés par le joueur pour contrôler l’avatar?

Après quelques minutes, le vrai test commençait. Les déplacements étaient expliqués aux joueurs, et ils étaient libres d’évoluer dans le décors, de l’explorer, pendant un temps limité. Une fois ce temps, le second prototype leur était proposé, avec le modèle de vol alternatif. Après chacun des essais, les joueurs remplissaient un court questionnaire évaluant leur expérience de jeu, en termes d’efficience, d’identification à la créature et de sensation de contrôle. A la fin de la session, les utilisateurs indiquaient quel prototype ils avaient préféré et un temps était consacré à des commentaires libres.

Résultats, décisions, conclusions

Les scores d’efficience, d’identification et de sensation de contrôle se sont avérés tout juste moyens pour chacun de prototypes. Le modèle couplé, dans lequel les gestes du joueur étaient reproduits avaient cependant des résultats légèrement meilleurs, sans que la différence soit significative.

Les données verbales par contre allaient plutôt dans le sens du prototype couplé, arguant que la reproduction était presque parfaite. Le modèle animé, en outre, ne permettait pas aux joueurs de distinguer différent types d’inputs, justifiant le déclenchement ou non du battement des ailes et les modifications de trajectoires. En effet, la vitesse de l’animation étant la même indépendamment des battements du joueur, et le déclenchement étant légèrement décalé par rapport à l’action, l’absence de feedback immédiat était considéré comme un dysfonctionnement ou un erreur de manipulation de la part du joueur essayant en vain de s’adapter.

A l’inverse, les modifications de trajectoire provoquées avec le modèle couplé étaient difficilement perçues, c e qui menait à des manipulations extrêmes. Ceci était en partie dû, également, au fait qu’aucun feedback ou même effet de camera ne venait souligner les gestes reconnus et modifiant la trajectoire.

A partir des premiers résultats dont j’ai résumé les points clés, nous avons commencé à tester les différentes adaptations possibles, en particulier pour améliorer les feedbacks possibles du modèle animé. En effet, notre première décision était d’étudier les solutions techniques possibles, telles que réaliser différentes fréquences de battement pour le modèle animé, qui reflèteraient mieux les gestes du joueur. Au contraire, nous avons également étudié les possibilités de rétrocontrôle pour clarifier les seuils de déclenchement du modèle couplé.

En fin de compte, nous avons choisi d’adopter le modèle couplé, pour trois raisons. Premièrement, le modèle était globalement mieux perçu et son utilisation avait des effets légèrement meilleurs sur l’expérience. Deuxièmement, les feedbacks supplémentaires nécessaires pouvaient passer par la caméra, et s’intégraient aux différents feedbacks que nous désirions implémenter par ailleurs.

Enfin, et c’est ce qui a porté le coup de grâce au modèle anime, nous avons convenu que la seule façon de réaliser un modèle animé qui ne se décale pas par rapport à la fréquence du joueur, était de réaliser un grand nombre de paliers de fréquences d’animation. Hors, plus nous ajouterions de paliers, plus nous nous rapprocherions en fait du modèle couplé.

Modèle d’interaction et fatigue liée aux contrôles gestuels

Question de départ et enjeux

L’utilisation d’un dispositif de contrôle gestuel implique la question de la fatigue liée à l’utilisation. En effet, contrôler un jeu avec des gestes de ses bras ou de son corps est plus contraignant que la simple utilisation d’une manette. Nous avons donc étudié en amont du projet les contraintes de fatigabilité dont nous devions tenir compte dans la conception des interactions : quel type d’action est le plus fatiguant, et en conséquence, quelle proportion de différentes actions pouvons-nous attendre du joueur ? Il en va du confort d’utilisation autant que de l’impact sur l’expérience.

Méthodologie et mise en place

Afin d’évaluer les contraintes liées au mouvement, nous avons réalisé deux tests utilisateurs spécifiques. Le premier, réalisé sur un prototype Processing nous a permis de tester les effets de l’amplitude des gestes et de la fréquence du mouvement, deux variables que nous voulions utiliser comme déterminants du contrôle.

Le second test nous a permis d’évaluer le type de battements que les joueurs avaient tendance à effectuer naturellement selon qu’ils désirent aller vite ou monter par exemple.

Déroulement des tests

Réalisé sur une quinzaine de sujet, l’évaluation de la fatigue a été réalisée à partir de la durée du test et d’un questionnaire d’évaluation de la fatigue en fin de test. Chaque sujet était amené à réaliser des gestes de battements d’ailes répercutés sur un oiseau filiforme dans le prototype processing. L’amplitude des battements demandée était repérée visuellement par des marqueurs, ce qui permettait aux utilisateurs de voir sur le prototype si l’amplitude de leurs battements correspondait à celle demandée.

Ce même prototype a été utilisé pour le second test : les marqueurs étaient cachés et on mesurait l’amplitude de battement faite par les joueurs selon la consigne donnée : essayer de voler le plus vite possible, monter, etc.

Résultats, décisions, conclusions

A partir de ces observations et des retours des testeurs, nous avons déterminé les valeurs critiques à ne pas dépasser et une correspondance entre l’effort et la durée de maintien envisageable lorsqu’on demande au joueur de faire cet effort. Nous avons ainsi défini des valeurs de base pour notre modèle de vol, que nous avons réglées plus finement par la suite.

La prise de vitesse se caractérisait par une fréquence de battement très élevée comparé à la fréquence « de base ». La prise d’altitude, elle se caractérisait par l’amplitude des battements, mais également, d’une asymétrie entre la vitesse avec laquelle le joueur levait et baissait les bras. Ceci nous a amené dans un premier temps à associer ainsi le contrôle de la créature : • La fréquence de battement détermine sa vitesse, • L’amplitude des battements détermine son assiette.

Retour d’expérience

Au final, la réalisation de ce test abstrait aurait pu être évitée : bien qu’il soit fonctionnel, ces observations auraient pu être effectuées sur un prototype du jeu rendant les consignes pour intéressantes pour le joueur. Par contre, l’absence de feedback sur l’avancement réel de la créature a pu accentuer les réponses des utilisateurs en termes de type de gestes effectués, sans l’influencer par les paramètres de vol implémentés.

Pour ce qui est de la fatigue en soi, ce test nous a permis d’obtenir des valeurs plutôt extrêmes que nous n’avons finalement jamais retrouvées en jeu. Le test était rapide, fonctionnel et a donné des résultats précis, avec un niveau de précision supérieur à ce qui nous était réellement nécessaire.

Enfin, au vu des réglages que nous avons réalisés après coup, les résultats de ce test ont eu malgré leur précision, une portée limitée dans le sens ou elle ne tenait pas compte d’un certain nombre de facteurs : pour le calibrage du modèle de vol, cela s’est avéré utile pour concevoir la première version du vol. Il n’a par contre apporté aucune information supplémentaire pour le Level Design ou les facteurs de difficulté, qui n’aurait pas été obtenue dans un autre test.

En conclusion, cette pratique de tests « abstraits » pour obtenir des données en amont m’a semblé intéressante mais pas indispensable, et pourrait probablement être évitée. Cela reste un recours intéressant en cas de besoin de données et impossibilité d’obtenir un prototype plus avancé avant de devoir prendre la décision. En l’état, elle me semble justifiée pour ce projet, mais je n’y aurais pas recours systématiquement, car je la trouve trop éloignée du contexte écologique d’utilisation.

Principaux résultats

Pendant trois mois, ce sont plus de 10 test utilisateurs qui ont été réalisés sur ce projet : les différentes versions du modèle d’interaction, les problématiques de fatigue liée aux contrôles gestuels, de positionnement des capteurs, de didacticiel sous forme de storyboard, d’abord, puis sous forme d’animation…

Réalisés sur support papier, vidéo ou prototype processing et unity, de nombreux résultats ont accompagné le développement d’iMA. En voici une sélection, des résultats principaux, illustratifs à la fois de l’avancement du projet que de la maturation de la démarche en place en termes de recherche utilisateur.

https://www.slideshare.net/orsoral/ima-3-mois-d-ergonomie

conclusion

En conclusion, cette série de tests a bien répondu aux besoins de l’équipe. En effet, le modèle d’interaction était un enjeu majeur et un des plus gros risques du projet qu’il fallait gérer.

Le recours à des prototypes simplifiés, presque caricaturaux de l’interaction dans un premier temps, et la disponibilité d’un niveau par défaut nous a permis de choisir une direction rapidement. En effet, mettre en évidence les conditions de réussite pour chacune des options nous a donné la possibilité de valider leur faisabilité et de prendre la décision en connaissance de cause, ce qui nous a fait gagner du temps.

Ces tests en amont ont également contribué à rassurer le jury d’évaluation qui examinait notre travail. La question du modèle de vol a été remise au goût du jour à deux reprises et le fait d’avoir les données des tests nous a permis de justifier nos choix et de clore rapidement ces régressions en permettant de comparer facilement les nouvelles données aux critères qui nous avaient amené à notre choix initial, plutôt que devoir refaire la totalité du raisonnement. Là aussi, cela constituait un gain de temps significatif pour l’avancée du projet.

En termes de méthodologie, réaliser des tests itératifs est relativement coûteux, et n’est pas une solution que j’envisagerais dans tous les cas. Cet exemple montre cependant l’intérêt de réaliser des tests en amont.

Une limite de cette méthode est que réaliser les observations sur des situations analogues au jeu, qui ne sont pas des conditions réelles d’utilisation laisse tout de même une part d’imprévu. En somme, cela permet effectivement de mettre en évidence les conditions requises pour que le modèle soit fonctionnel et agréable à utiliser. Cela ne permet pas en soit de régler avec précision les contrôles, en particulier, parce que le contexte a une influence importante sur les besoins en termes de contrôles, et c’est quelque chose qui s’est particulièrement vu sur ce projet, comme nous le verrons dans l’article suivant, à travers une suite de tests itératifs.