Mise au point du protocole
L’expérimentation et mise au point de la méthode QRC a été réalisée sur Crusaders, un jeu en cours de développement par le studio Kylotonn, membre Capital Games.
Le protocole repose largement sur le travail effectué sur les existants, cependant, le fait de travailler sur un jeu en cours de développement a révélé de nouvelles questions et de nouveaux axes de travail présentés ci-dessous.
Axe 1 : Le gamedesigner et le publisher.
Pour fournir une méthode de test adaptée à l’industrie des jeux vidéo, il a été nécessaire de passer du temps à bien comprendre les acteurs et leurs problématiques respectives. Dans un premier temps, il s’agit de comprendre la problématique du gamedesigner. Le
gamedesigner est le créatif qui porte le jeu. Il a pour objectif de concevoir une œuvre unique qui saura captiver le joueur. Il entretient donc une relation affective forte avec son jeu et il est très important de bien comprendre ses intentions créatives pour que le test soit orienté vers l’amélioration de son concept, plutôt qu’un test-sanction qui chercherait à démontrer que l’objectif n’est pas atteint. Il faut donc consacrer du temps à comprendre l’intention créative puis fournir un travail de conseil pour imaginer le protocole de test qui saura révéler les problèmes tout en donnant une orientation constructive à la démarche. Par exemple, si l’analyse ergonomique du prototype donne à penser qu’il y a un problème au niveau des contrôles, il peut être intéressant de travailler avec le gamedesigner en amont pour développer une seconde option. Ainsi, le test pourra mesurer objectivement si la solution proposée est plus performante que la solution initiale. La difficulté de l’exercice consiste à évaluer ce qui est une difficulté ludique, voulue par le concepteur par opposition à une difficulté collatérale qui n’est pas issue d’une volontée créative. Enfin, le fait de demander au designer de décrire précisément son intention créative permet d’imaginer des exercices qui valideront ou invalideront les solutions proposées. (exemple : combien de fois penses tu qu’un joueur doive utiliser la parade dans une partie de 30 minutes ?). Ce type de question permet d’identifier une variable à observer durant le test. Le résultat apportera des réponses précises au gamedesigner sur le niveau d’accomplissement de ses objectifs de conception. On voit donc ici que la mise en place du test se fera de façon itérative. Il doit y
LutinGameLab Rapport final ANR Février 2009 Page 40
avoir un échange entre le gamedesigner qui est le garant de concept créatif et le responsable du test qui va imaginer un protocole adapté.
Un autre facteur important de contexte est le publisher. Nous n’avons pas travaillé sur un jeu en cours de production mais sur un prototype que Kylotonn développe avec l’objectif de convaincre un publisher d’investir pour produire l’intégralité du jeu. L’utilisateur final du prototype a donc un profil particulier – très différent du casual gamer par exemple.
Axe 2 : identifier les fonctions clés
Dans le cas de crusader, nous avons identifié de nombreuses fonctions clés ou features qui forment le core gameplay et/ou les éléments à forte valeur ajoutée, facteur de
différenciation. Attendu qu’un joueur ne peut pas les connaître avant de jouer, nous avons recommandé de développer un tutoriel – qui avait pour objectif de transmettre la
connaissance des mécanismes du jeu avant de tester la maitrise de ces mécanismes par le joueur. Ce tutoriel n’a pas pour objectif d’être intégré au jeu final tel quel. Il s’agit d’une approche permettant finalement de faire des tests unitaires sur l’ergonomie des
fonctionnalités clés du jeu. De plus, avec le tutoriel, nous étions assurés que la phase de transmission de la connaissance du jeu vers le joueur avait eu lieu, il devenait donc
pertinent de mesurer ensuite, dans une phase de jeu libre l’utilisation réelle des features par le joueur. (capacité à réappliquer les connaissances).
Axe 3 core gameplay
Crusdader est un jeu d’action aventure de type Hack/slash. Une dimension clé du jeu est la gestion des combats. Nous avons donc recommandé d’implémenter une mini arène de combat (practice) dans lequel le joueur affronte un ennemi. Ici donc pas d’histoire, l’objectif est de pouvoir travailler la mise au point de la mécanique de combat. Dans le cadre du test, ce développement permettait aussi d’évaluer la progression du joueur dans une situation exactement similaire avant et après la phase de jeu libre (soit 30 minutes plus tard)
Axe 4 Level design
Kylotonn avait développé un niveau représentatif de ce qu’allait être l’ensemble du jeu (graphiques/son/intrigue). Pour la mise au point de ce niveau (level design), nous avons proposé de mesurer :
o l’utilisation précise des fonctions clés du jeu (statistiques : features / controls)
o les parcours dans le niveau (trace du joueur en XY dans la map)
o la résolution des énigmes (succès/échec)
Les séances de test
Description du protocole
Prise en main (5mn)
Tutorial (19 étapes correspondants aux compétences élémentaires et avancées)
Exercice : le joueur affronte 3 ennemis dans une arène
Phase de jeu libre avec quelques interruptions (environ 25mn)
Exercice : le joueur affronte 3 ennemis dans une arène (2eme itération)
Questionnaire standard Gamelab (5mn)
Entretien ouvert (5mn)
Il ya eu un pré-test pour ajuster le protocole puis 5 tests (environ 1H30 à chaque fois) effectués au Laboratoire Lutin. Le gamedesigner a assisté au premier test.
Pendant le test, l’expérimentateur prend des notes (essentiellement la verbalisation par les joueurs, les réponses (succès/échec) aux questions posées pendant les interruptions.
Game Doctor : analyse des résultats.
Les notes des tests sont réorganisées par thème plutôt que par séance de test afin de faire ressortir les thèmes problématiques ou les succès rencontrés.
LutinGameLab Rapport final ANR Février 2009 Page 41
Les logs (recueil automatique de données) sont reformatés pour pouvoir être utilisés dans les logiciels de restitution graphique. Lorsque tout est prêt, le responsable du test organise la séance de gamedoctor : on analyse toutes les données avec le gamedesigner pour tirer des conclusions et imaginer des solutions. Pour cette étape, les supports de travail sont :
- Les notes prises lors des tests (réorganisées par thème) - Le parcours du joueur (logiciel de restitution graphique)
- La table des évènements (visualisation graphique des statistiques d’utilisation des features)
LutinGameLab Rapport final ANR Février 2009 Page 42
Chaque point soulevé par les tests a fait l’objet d’une discussion : le problème est il réel, faut-il le résoudre (priorité) ? Quelles sont les solutions. A la suite de ces tests, le studio a fait évoluer son prototype.
LutinGameLab Rapport final ANR Février 2009 Page 43
Conclusion
Si l’on regarde l’ensemble de la démarche, le projet a permis de faire une avancée significative dans les méthodes de test de l’ergonomie et du gameplay des jeux vidéo en cours de développement. Nous avons désormais un protocole composé d’une batterie de briques de méthodes applicables à de nombreux jeux dans quatre genres représentatifs du jeu vidéo.
La mise au point de la méthode a porté sur 8 jeux et a fait intervenir 21 testeurs, sans compter les pré-tests qui ont été effectués sur chaque protocole. Les premières approches mobilisaient jusqu'à 3 expérimentateurs pour dérouler le protocole qui était assez lourds (1) conduite du test, (2) annotation vidéo et (3) prise de note en temps réel.
La version finale de la méthode repose sur une ou deux séries de 5 tests et ne requiert qu’un seul expérimentateur. Il y a donc eu un gain réel en termes de productivité (besoin de moins
d’expérimentateurs) qui s’explique par l’automatisation du recueil de données (installation de capteurs dans le jeu) et le développement d’outils de restitution graphique qui réduisent considérablement le temps d’analyse. La démarche a permis de montrer les avantages de d’une approche plus légère que les méthodes traditionnelles (ex : pas d’utilisation de la vidéo) qui est plus alignée avec les contraintes de délais tendus de l’industrie du jeu vidéo. Cependant, la méthode n’est pas exhaustive, et pourra être complétée par d’autres protocoles selon les spécificités des jeux et leur avancée dans le cycle de développement. Il faut aussi noter que temps de traitement des résultats a été largement automatisé, mais il reste une marge de progression pour avoir la chaine complète. Plus d’automatisation permettrait également d’obtenir un retour plus précis des
testeurs : si on était en mesure d’obtenir les résultats graphiques en temps réel, on serait en mesure d’interroger le testeur en fin de séance à la lumière de ces informations.