ima3

iMA : 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.

Leave a Reply

Your email address will not be published. Required fields are marked *