L’expérimentation sur des jeux existant a été l’occasion de mettre en pratique les méthodes analysées dans l’inventaire des méthodes.
En résumé la mise au point de la méthode à porté sur :
2 jeux Aventure/action (10 testeurs, 5 par jeu)
12 indicateurs, interruptions pour verbalisation, questionnaire standard Gamelab 11 questions + questionnaire spécifique – enregistrement vidéo. Enregistrement vidéo et annotation avec Dartfish. Trois expérimentateurs.
2 jeux de type FPS (3 testeurs, qui jouent aux 2 jeux)
14 indicateurs, 9 exercices, questionnaire exagéré 11 questions, questionnaire spécifique. Enregistrement vidéo et annotation avec Dartfish. Annotation des évènements en temps réel. Trois expérimentateurs.
3 jeux casuals (3 testeurs ont joué aux 3 jeux).
7 variables observées, jeu libre+6 exercices, questionnaire standard gamelab 11 questions + questionnaire de comparaison. Filmé avec la caméra de l’eye tracker mobile. Deux expérimentateurs.
Cette étape a présenté de nombreuses difficultés mais a finalement permis de poser les fondations de la méthode QRC. Il y a eu deux difficultés principales à surmonter : la dimension exploratoire (1) et la difficulté pratique liée au coté boite noire du jeu commercialisé(2).
La dimension exploratoire a présenté quelques difficultés pour les tests : en effet, nous n’avions pas accès aux gamedesigners des jeux que nous allions tester, nous n’avions donc pas de
commanditaire qui nous guidait sur les points du jeux sur lesquels il désirait avoir une réponse. Nous avons donc du procéder en deux temps : émettre des hypothèses et établir un protocole de test qui valide ou infirme ces hypothèses.
L’enseignement que l’on retire de cette étape se situe à plusieurs niveaux. A un premier niveau, il apparaît qu’il faut commencer toute démarche de test par une phase d’inspection de l’ergonomie et du gameplay du jeu. A un second niveau, cette phase a permis de tester un grand nombre
d’indicateurs et d’évaluer leur pertinence. A titre d’exemple au travers de différents tests, nous avons cherché à identifier ce qui peut-être mesuré dans un jeu.
LutinGameLab Rapport final ANR Février 2009 Page 36
Chronométrer : le temps nécessaire pour accomplir une tache, pour terminer le niveau.
Cette information est relativement aisée à obtenir, cependant, il est difficile d’en tirer des conclusions dans l’absolu. C’est donc un critère qui acquiert de la valeur dans la
comparaison.
Nombre de tentatives : si le nombre de tentatives est trop élevé, le joueur commence à
ressentir de la frustration, cet indicateur permet de mettre en lumière un problème d’équilibrage de la difficulté dans le jeu. Par exemple, ce point a permis de mettre en lumière la différence entre difficulté ludique et difficulté de compréhension. (une difficulté ludique génère du challenge, du fun, tandis qu’une difficulté de compréhension génère de la frustration). Cet indicateur est à mettre en relation avec les indicateurs de succès ou d’échec à une tache ou un objectif du jeu.
Nombre d’ennemis tués : nous cherchions à évaluer l’intensité du jeu. Il est très difficile
de tirer des conclusions sur la qualité du jeu en fonction de ce seul critère, mais cela donne une idée précise de l’intensité d’une séquence (ce n’est pas pareil de tuer 30 ennemis ou 3). Une séquence intense peut appeler une séquence plus lente pour obtenir un meilleur rythme et conserver le joueur immergé dans l’expérience du jeu.
Score : pour les casual games , le score est un indicateur synthétique qui mesure la
performance (en combinant parfois plusieurs critères). Ce qui est intéressant ici, c’est de mesurer la progression dans le temps. Si un joueur progresse, d’une partie à l’autre, son score reflétera cette progression et il est probable qu’il passe un bon moment. Dans tous les cas, on devra valider ces hypothèse par de la verbalisation.
Petits exercices : pour évaluer une primitive du gameplay (ex combat ou déplacement),
nous avons élaboré une série de petits exercices que les joueurs devaient effectuer en début puis en fin de session. Nous voulions évaluer la progression (le joueur a-t-il progressé dans sa maitrise des contrôles ?)
Comparaison des jeux : en fin de partie, on demande au joueur d’évaluer le jeu selon
une grille. Ensuite, il joue à un autre jeu comparable et on lui demande d’évaluer le second jeu avec la même grille. Enfin, on lui demande de produire plusieurs classements des jeux en fonction de critères (graphisme, son, prise en main etc…) Cela permet d’inscrire le jeu testé dans le contexte concurrentiel, ce qui correspond à la réalité commerciale du jeu (il est positionné en rayon à coté des jeux concurrents).
L’interruption : durant le jeu, on demande au joueur de mettre sur pause le temps de
répondre à une question, par exemple un question de compréhension sur l’interface. Cette technique fonctionne bien, il faut avoir une check list pour vérifier que tous les joueurs auront répondu à toutes les questions. Pendant que le testeur joue, il faut attendre le bon moment adéquat pour vérifier la compréhension de tel ou tel élément d’interface.
LutinGameLab Rapport final ANR Février 2009 Page 37
Questionnaires : dans le cadre du montage de l’expert artificiel, nous avions élaboré un
premier questionnaire pour l’évaluation des jeux par les joueurs. Durant la phase de test sur les jeux en cours de développement, nous avons, dans un premier temps réutilisé ce
questionnaire. Nous avons reformulé plusieurs questions dans l’optique d’obtenir un questionnaire plus contrasté, qui devait permettre de faire ressortir plus clairement les lacunes d’un jeu. Les expressions étaient volontairement exagérées (par exemple : « c’est le meilleur jeu auquel j’ai joué » ou « les graphismes sont époustouflants »). Bien que les résultats soient encourageants, nous avons décidé de revenir au premier questionnaire afin de pouvoir se laisser la possibilité de comparer les réponses du joueur avec l’information recueillie dans le cadre du montage de l’expert artificiel. Cette piste n’a pas été explorée mais cette base de données d’appréciation subjective sur le corpus de jeu reste un actif du gamelab sur lequel il sera possible de capitaliser par la suite.
La vidéo : les premiers tests on largement utilisé les équipements vidéo du laboratoire
lutin. Nous cherchions à avoir une image qui assemble trois flux vidéo : le visage du joueur, le contexte, l’écran de la console. Ce dispositif est relativement satisfaisant dans la mesure où l’information collectée est de bonne qualité, et facilement réutilisable pour une analyse ultérieure à la séance de test. Cependant, l’enregistrement vidéo pose le problème du temps d’analyse. Si on considère qu’il faut 3 heures d’analyse pour une heure d’enregistrement, et qu’il y a 10 testeurs (X1H) cela signifie 30 heures d’analyse vidéo, hors synthèse, ce n’est pas compatible avec le rythme de l’industrie du jeu vidéo. Nous avons essayé de solutionner ce problème en utilisant plusieurs techniques d’annotation des séquences vidéo (en utilisant la suite Dartfish par exemple). Bien que ce logiciel soit de bonne qualité, l’annotation de vidéo en temps réel est une tache très fatigante pour l’opérateur et nécessite d’immobiliser une personne supplémentaire pour toute la durée du test. Enfin, pour les raisons de fatigue évoquée ci-dessus, il faut limiter le nombre d’éléments à relever. Pour toutes ces raisons, nous avons décidé de ne pas faire reposer la méthode QRC sur l’analyse vidéo.
Difficultés et limites :
N’ayant pas accès au code source du jeu, nous ne pouvions pas automatiser ces mesures. Il a donc fallu beaucoup de travail pour compter le nombre d’ennemis tués, chronométrer le nombre de tentatives, etc. Cela rend ce type de mesure difficilement applicable aux développeurs de jeu vidéo si cela n’est pas automatisé. La méthode QRC que nous proposons repose donc sur l’utilisation extensive de capteurs intégrés au jeu pour automatiser toutes les mesures des actions des joueurs.
LutinGameLab Rapport final ANR Février 2009 Page 38 Il est difficile de comparer précisément les jeux. Lorsqu’on chronomètre le temps qu’il faut
pour effectuer une action d’un jeu à l’autre, c’est rarement exactement la même chose qu’on mesure (les décors sont différents, il est donc difficile de garantir qu’une distance dans le jeu A est équivalente à une distance dans le jeu B par exemple). Il est donc préférable de se limiter à des comparaisons exprimées explicitement par le joueur.
Conclusion : une structure générique de test « QRC »
Le protocole que nous avons mis au point repose en grande partie sur les enseignements tirés de cette étape du projet. De façon générique, le protocole QRC se compose des étapes suivantes
Prise en main (5mn)
Exercices - première itération (10mn)
Phase de jeu libre avec quelques interruptions (environ 25mn)
Exercices - 2eme itération (10mn)
Questionnaire standard Gamelab (5mn)
Entretien ouvert (5mn)