Conservatoire National des Arts et Métiers / Ludolab
Résumé
Dans cet article, le Ludolab s’intéresse aux analytics. Après la conception et le déploiement de jeux vidéo dit sérieux, nous nous sommes interrogés sur les informations que nous pouvions obtenir de ces dispositifs. Des logs au score, que pouvons-nous enregistrer ? Que devons-nous enregistrer ? Nous nous sommes aperçus qu’une réflexion en amont permettait de mettre de côté des informations plus large que les enregistrements des résultats de partie, et que ces enregistrements pouvaient s’inscrire dans un contexte de dispositifs de plus en plus « éclaté ».
L’objectif final est donc d’inscrire la réflexion des analytics dans une vision plus globale, pour valider les acquis des apprenants mais aussi pour éventuellement leur offrir le choix entre différentes modalités.
Introduction
Le Ludolab du Conservatoire National des Arts et Métiers est un laboratoire qui a pour but de promouvoir les jeux sérieux dans l’enseignement et la formation tout au long de la vie. Pour accomplir cette mission, les membres du Ludolab testent des jeux pour évaluer leurs modalités d’utilisation en formation. Ils les analysent également afin de comprendre les mécaniques qui les composent soit pour les adapter à une formation, soit pour créer de nouveaux jeux dédiés à des formations. Plusieurs types de jeux ont été ainsi analysés, par exemple les jeux d’escape Game sous forme de jeux de cartes (Unlock et Exit).
Aujourd’hui il est question de réfléchir aux informations que peut nous fournir un jeu sérieux de type jeu vidéo.
L’objectif premier est de nous interroger sur la mise en place d’un jeu sérieux surtout lorsqu’il s’agit d’un jeu vidéo : va-t-il fonctionner ? Est-il équilibré ? Va-t-il être efficace ? Les apprenants vont-ils apprendre ET prendre du plaisir en l’utilisant ?
D’autant que nous ne saurons peut-être pas derrière l’apprenant pour vérifier comment se déroule le jeu : imaginons un cas où l’apprenant joue de chez lui, sans formateur, sans ingénieur pédagogique, comment savoir si tout se passe bien ? Si les objectifs pédagogiques sont atteints ?
Par ailleurs, en aurons-nous bien investi notre argent ? Parce que mine de rien, un jeu sérieux sous forme de jeu vidéo représente un budget certain.
Résumons : prise de risque pédagogique, technique et financière, incertitudes, comment répondre à nos angoisses ?
L’une des réponses pourraient se trouver dans les analytics. Nous verrons donc ce que sont ces analytics, différentes manières de les recueillir, de les analyser et combien cela fait sens dans une vision plus globale au sein de l’offre de formation.
1 Introduction aux analytics
1.1 Définition première
La définition de Wikipédia des Analytics est : « les analytics des jeux vidéo sont une forme d’analyse comportementale qui concerne les jeux vidéo. Elles impliquent l’utilisation de mesures quantitatives, de métriques et d’outils qui peuvent être utilisés pour suivre les évènements qui se produisent au cours d’un jeu, dans le but de capturer ces données pour une analyse statistiques. »
Alors plus précisément, de quoi parle-t-on ?
Un exemple simple serait de programmer un jeu vidéo pour qu’il enregistre le nombre de fois où les joueurs meurent dans chaque niveau et qu’il reçoive les données aux concepteurs, afin que ces derniers sachent si certains niveaux sont trop difficiles et s’il faut donc les revoir.
Dans ce cas précis, nous visualisons très bien le type d’information que l’on souhaite analyser, l’observation de cette information et la décision qui en découle : trop de morts/d’échecs à un endroit = niveau trop difficile => correction dudit niveau/endroit.
Revenons-en à la définition. Cette dernière indique plusieurs éléments qu’il nous faut souligner :
⁃ Les analytics sont des informations provenant du jeu (à la fois en tant que dispositif permettant de jouer et d’informations provenant de la partie). Pendant que le joueur joue, le jeu va enregistrer ses décisions, ses réussites, ses échecs. Cela va créer une quantité de données, propre à chaque partie et propre à chaque joueur.
⁃ Les données peuvent être interprétées, on va les analyser, d’où leur nom,
⁃ L’analyse vous nous permettre de déduire des conclusions,
⁃ Ces conclusions peuvent être de différents types : réglages du jeu, succès du jeu, etc.
La définition des analytics indiquent que l’observation et l’analyse reposent sur des « mesure quantitatives, de métriques et d’outils ». Mais quels sont-ils ?
On peut citer au moins deux outils qui s’imposent naturellement lors d’une réflexion : le score et les logs.
1.2 Score & logs : une définition plus précise
Le score se définit comme « le nombre de points ou de buts obtenus par chaque adversaire ou équipe dans une compétition. » in https://www.larousse.fr/dictionnaires/francais/score/71577 Dans le cas d’un jeu solo, cela revient aux points et/ou bonus obtenus par joueurs lors d’une partie, qu’il soit victorieux ou pas, qu’il atteigne un ou plusieurs objectifs, ou pas.
Les logs maintenant se définissent comme suit : « Dans le domaine informatique, le terme log désigne un type de fichier, ou une entité équivalente, dont la mission principale consiste à stocker un historique des événements. Le terme peut être traduit en français par « journal ». Le log s’apparente ainsi à un journal de bord horodaté, qui ordonne les différents événements qui se sont produits sur un ordinateur, un serveur, etc. Il permet ainsi d’analyser heure par heure, voire minute par minute, l’activité interne d’un processus. »
in : https://www.journaldunet.fr/web-tech/dictionnaire-du-webmastering/1203463-log-definition-traduction/
On pourrait introduire une nuance entre les logs de la partie et les logs du dispositif lui-même.
Les logs de la partie sont donc définis par les concepteurs pour être constatés mais ils n’entrent pas forcément dans la définition du score. Prenons par exemple le temps d’une partie. Il peut appartenir au score dans le cadre d’un jeu à temps limité (exemple un jeu de combat ou un jeu de stratégie en temps réel), mais il sera une simple information dans un jeu à temps illimité (exemple un jeu de rôle ou d’exploration). Dans le second cas, l’information sera apparentée davantage à un log de jeu qu’à un score, car elle n’inclue pas la notion de « point » propre au score.
Les logs du dispositif lui-même sont des informations liées à l’utilisation du jeu mais en dehors du jeu. Prenons par exemple l’accès au jeu : via un smartphone, IOS ou Androïd, cette information peut être intéressante, mais elle provient du dispositif global et est en dehors de la partie.
Partant de ces définitions, les analytics semblent se composer de trois éléments :
– les logs du dispositif,
– les logs de la partie,
– le score du joueur.
2 Les analytics concrètement
2.1 Au niveau 0 : les informations du dispositif
Exemple pour un jeu que nous développons sous VTS/Unity :
10.0.0.15 – – [07/Feb/2022:16:07:53 +0100] « GET /Module2/silent.mp3 HTTP/1.1 » 206 3086 « https://revesdevelo.cnam.fr/Module2/ » « Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/97.0.4692.99 Safari/537.36 »
10.0.0.15 – – [07/Feb/2022:16:07:53 +0100] « GET /Module2/StreamingAssets/PackedProjectData.data HTTP/1.1 » 200 2170062 « https://revesdevelo.cnam.fr/Module2/ » « Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/97.0.4692.99 Safari/537.36 »
10.0.0.15 – – [07/Feb/2022:16:07:53 +0100] « GET /Module2/TemplateData/img/background.jpg HTTP/1.1 » 200 1529614 « https://revesdevelo.cnam.fr/Module2/TemplateData/css/style.css » « Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/97.0.4692.99 Safari/537.36 »
10.0.0.15 – – [07/Feb/2022:16:07:53 +0100] « GET /Module2/TemplateData/img/favicon.ico HTTP/1.1 » 200 15752 « https://revesdevelo.cnam.fr/Module2/ » « Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/97.0.4692.99 Safari/537.36 »
10.0.0.15 – – [07/Feb/2022:16:07:53 +0100] « GET /Module2/Build/WebPlayer.data.unityweb HTTP/1.1 » 200 6366460 « https://revesdevelo.cnam.fr/Module2/ » « Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/97.0.4692.99 Safari/537.36 »
10.0.0.15 – – [07/Feb/2022:16:07:53 +0100] « GET /Module2/Build/WebPlayer.wasm.unityweb HTTP/1.1 » 200 6558447 « https://revesdevelo.cnam.fr/Module2/ » « Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/97.0.4692.99 Safari/537.36 »
Ce sont des logs/traces du serveur apache. Le serveur qui permet d’accéder au jeu vidéo. On peut y constater des informations intéressantes :
⁃ L’adresse ip du joueur : 10.0.0.15 (est-ce utile ?)
⁃ La date et l’heure du jeu : 07/Feb/2022:16:07:53 (pour la dernière ligne. Qu’en déduire ?)
⁃ La cible de la requête http : Module2/Build/WebPlayer.wasm.unityweb (autrement dit, l’information à laquelle le joueur accède. Comment l’utiliser ?)
⁃ Le client web utilisé : Chrome/97.0.4692.99 Safari/537.36 (est-ce que cela peut être utile ?)
Est-ce que c’est suffisant pour en déduire des choses ?
En décrivant les logs il est possible de déduire des choses :
⁃ le nombre de joueur qui ont joué au jeu : on va filtrer par adresse ip. Ça peut nous donner un nombre qui peut être faussé : si des joueurs jouent à travers un proxy (ce qui est souvent le cas lorsque vous vous connectez depuis votre université pour accéder à internet), nous n’auront pas le nombre individuel. Limite : dans le cas d’une ouverture à une classe par exemple, il nous sera difficile de conclure que toute la classe a joué.
⁃ La date nous permet de déduire l’effet « curiosité » du jeu : s’il s’agit d’une mise en ligne public, nous allons pouvoir suivre le pic d’accès au jeu, puis, en toute logique, une courbe descendante à mesure que les joueurs ont effectué une partie. Ils se détourneront pour aller jouer à autre chose. Cela nous permet de suivre dans le temps l’adhésion au jeu : est-ce qu’en dehors de toute promotion, des joueurs continuent à se connecter au jeu ? Est-ce que le bouche à oreille fonctionne ?
⁃ L’accès aux différents modules peut nous indiquer à quel endroit s’arrêtent les joueurs : accomplissent-ils tous le module 1, le module 2, etc ? Dans le cas où la participation s’étiole, à quel moment perd-on des joueurs ?
⁃ Le logiciel client peut nous servir surtout à débuter : quelqu’un nous appelle pour dire que le jeu ne fonctionne pas. Il est possible de vérifier avec le navigateur si l’on peut reproduire le bug et donc le réparer. Potentiellement.
Arrivé ici, nous disposons d’informations qui sont intéressantes, mais qui tournent autour du jeu. Nous parlons ici de l’accès au jeu, mais finalement, pas de son utilisation, des parties en tant que telles. Pour aller plus loin, il faut se pencher sur les logs et les scores à l’intérieur du jeu.
2.2 Au niveau 1 : les logs de la partie
Cette fois-ci nous allons regarder de quelle manière le joueur joue. Nous regardons donc les logs du jeu et le score.
Petit point : un jeu vidéo sérieux ou pas sérieux, n’enregistre les scores que de ce que vous souhaitez enregistrer.
Voici l’exemple d’un de nos modules en construction :
+————————————+———-+———–+—————————–+———————+———————+
| ident | activite | nom | valeur | date | date_replay |
+————————————+———-+———–+—————————–+———————+———————+
| 1460ee271f5730c0037c3fXXXX | 1 | Croquis | True | 2022-01-22 09:13:16 | 2022-01-22 09:13:16 |
| 1460ee271f5730c0037c3fXXXX | 1 | Dessin | False | 2022-01-22 09:13:16 | 2022-01-22 09:13:16 |
| 1460ee271f5730c0037c3fXXXX | 1 | NBClients | 5 | 2022-01-22 09:13:16 | 2022-01-22 09:13:16 |
| 1460ee271f5730c0037c3fXXXX | 1 | Velo | True | 2022-01-22 09:13:16 | 2022-01-22 09:13:16 |
+————————————+———-+———–+—————————–+———————+———————+
Nous avons conçu un module de jeu disponible sur un serveur web. Ce module est appelé depuis un mooc disponible sur FUN.
On peut constater en premier lieu que c’est assez pauvre.
Tout d’abord, nous avons l’identifiant du joueur avec un id propre FUN (notons ici l’importance de la RGPD dans le contexte de la création d’un jeu vidéo). Cet identifiant ne nous permet pas d’identifier le joueur mais il nous permet d’individualiser le score. On sait ce qu’un apprenant a fait.
Pour savoir ce qu’il a fait, nous avons défini des variables utiles au jeu. En premier, nous avons nommé les modules pour les distinguer (nous en avons 4). Viennent ensuite les variables propres à chaque module.
Enfin, vient l’horodatage. Nous en avons défini deux car nous avons pris le parti de modifier les valeurs en cas de rejouabilité. Lorsqu’un apprenant rejoue une partie, ses anciens logs et scores sont effacés. Cela pourrait nous induire en erreur : en observant les résultats finaux, avec un taux de réussite trop fort, nous pourrions jauger le jeu trop facile. Grâce à ses deux dates nous détectons une partie rejouée.
2.3 Au niveau 2 : le score du joueur
Je n’insiste pas, dans l’exemple ci-dessus, nous voyons que certaines variables permettent d’évaluer les actions du joueur et donc de nous fournir son score au final de chaque module.
Le score est en quelque sorte son taux de réussite.
En conclusion de cette partie, j’attire l’attention sur le fait qu’in jeu vidéo n’enregistre que ce qu’on lui demande d’enregistrer. Les informations utiles pour analyser la partie, l’apprenant, le dispositif.
Il est donc nécessaire dès le cahier des charges pédagogique de commencer à réfléchir aux informations qui vous seront utiles.
Car les mesures peuvent « mesurer » n’importe quoi à savoir :
⁃ le temps passé au cours d’une seule session de jeu,
⁃ le temps nécessaire aux joueurs pour terminer un niveau,
⁃ les victoires et les échecs des joueurs,
⁃ le nombre de joueur par jour,
⁃ etc.
3 L’utilité de ces analytics
La première utilisation des analytics dans le monde du jeu vidéo est d’abord d’étudier le comportement des joueurs lorsqu’ils jouent. L’objectif est d’améliorer le jeu, de conserver les joueurs sur le jeu le plus longtemps possible, ce qui améliore sa longévité.
L’exemple le plus vieux remonte au siècle dernier : Evequest 1999, qui enregistraient ses données sous forme de fichiers journaux. Ces données permettaient de suivre le comportement des joueurs.
Depuis 2009, les studios de jeux vidéo y recourent de plus en plus à tel point que Georg Zoeller a fait créer à Bioware un système de collecte sur mesure.
Aujourd’hui, des studios comme EA, Ubisoft, Activision collectent ces mesures de jeux.
Alors dans l’univers des jeux sérieux, à quoi peuvent-elles nous servir ?
3.1 À évaluer la partie ludique
– Vérifier que le jeu fonctionne
On peut toujours effectuer des tests, solliciter des testeurs, vérifier toutes les options, tous les passages d’un jeu. Mais le nombre de testeurs disponibles est toujours limité. Les testeurs sont aussi souvent des joueurs aguerris. Ils connaissent différents gameplays, ils peuvent avoir beaucoup jouer, être à l’aise avec les jeux vidéo, ce qui ne sera pas forcément le cas des joueurs finaux.
– Améliorer le jeu
Récupérer les analytics permet de consolider le jeu en vérifiant que sur un grand nombre, il n’y pas de point problématique. Un jeu trop dur : imaginons une énigme que tous les testeurs ont réussi. Une fois le jeu dans les mains du grand public, ces derniers échouent à 80% sur cette énigme. Les testeurs l’auront réussi mais le taux d’échec nous avertira qu’il faut modifier ce passage sans quoi, l’expérience de jeu s’arrêtera là.
Un jeu trop facile : imaginons que la même énigme est résolue par 100% des joueurs. Le concepteur peut se féliciter en se disant : « le niveau n’est pas trop dur. » Sauf qu’en se penchant sur le temps de réponse, si on s’aperçoit que le temps moyen pour résoudre l’énigme est de 5 secondes, on comprendra que le niveau de difficulté de cette dernière est bien trop faible.
– Conserver les joueurs sur le jeu le plus longtemps possible/nécessaire
L’objectif est de vérifier ainsi sur les différentes parties que les joueurs vont bien au bout de l’expérience que propose le dispositif.
Un jeu décourageant ou ennuyeux : les points ci-dessus sont des points de vigilance, car de l‘équilibrage dépend la participation des joueurs. Sans rappeler ce qu’est le Flow (ref), notons simplement qu’un jeu trop dur est décourageant et que le joueur arrête de jouer, à l’inverse, un jeu trop facile ne maintient pas une tension nécessaire et devient ennuyeux. Là encore, le joueur arrête de jouer. Dans ces deux cas, le dispositif perdra de son attrait et de son efficacité.
L’objectif est bien que le joueur reste le temps nécessaire pour utiliser, découvrir ou mobiliser ce que l’on souhaite mobiliser en lui.
3.2 À évaluer la partie sérieuse
– Vérifier que les joueurs jouent
Contrairement à un jeu grand public, un jeu sérieux s’adresse en général à une population donnée (une classe, des inscrits à un diplôme, des membres d’une équipe professionnelle, etc).
Le point le plus évident et le plus simple est de vérifier que le nombre de joueurs correspond aux nombres de joueurs potentiels.
– Vérifier que les joueurs maitrisent bien le dispositif
Le score des joueurs indique en général leur taux de réussite.
Tout dépend du type de jeu : un escape game virtuel se conclue sur une réussite ou un échec.
Pour un jeu de gestion par contre, le dispositif pourra indiquer un score plus fin, précisant si le joueur a réussi de justesse ou a excellé.
De là, il est possible de déclencher un retour revenant sur ses fautes, ses faiblesses ou sur les bonnes pratiques. Il s’agit d’automatiser ici une forme de débriefing.
Éventuellement, le dispositif pourra lui proposer de recommencer si le joueur se situe à un seuil de réussite insatisfaisant.
– À évaluer le dispositif
L’évaluation de l’utilité d’un jeu sérieux est toujours délicate : a-t-il été efficace ? Les apprenants sont-ils plus compétents grâce à lui ?
L’ensemble des scores est une piste permettant de considérer l’efficacité du dispositif.
Ici j’attire l’attention sur le fait que le modèle CEPAJE, outil pour évaluer un jeu sérieux, repose souvent sur la présence d’un formateur. Nous réfléchissons à l’implémenter sans formateur, c’est à dire à faire en sorte que le dispositif lui-même évalue l’apprenant et nous permette de vérifier son niveau de maîtrise ou de compréhension.
3 De l’analyse à l’adaptative
Récupérer les logs et autres scores est intéressant. Encore faut-il savoir où les stocker, comment les traiter et qu’en faire. Dans un monde idéal, sans question budgétaire, sans problème d’interaction, et avec une vision claire sur les outils déployés, voici comment pourrait-être utilisé les analytics.
3.1 Le stockage des analytics : de la galaxie…
Déployer plusieurs jeux vidéo posent la question du mode de déploiement : sur smartphone ? Sur un site web ? Via des sources téléchargeables ?
Suivant la modalité retenue, les concepteurs vont devoir se questionner sur le rapatriement des logs/scores ou pas. Prenons par exemple un jeu jouable en ligne. Les analytics seront disponibles du le serveur. L’équipe pourra y accéder, les récupérer, les traiter.
Prenons maintenant une université, cette dernière déploie des jeux sérieux dans différentes UFR ou laboratoires, sur différents serveurs.
Il est encore possible d’utiliser un serveur central pour récupérer les informations des différents jeux sérieux.
Ajoutons maintenant des jeux disponibles sur smartphone, la récupération commence à devenir épineuse.
Faut-il les centraliser ?
3.2 … à la centralisation ?
On peut considérer que le jeu sérieux est une activité parmi d’autres. Quand nous concevons un jeu, nous indiquons toujours au formateur qu’il doit avoir un plan B : le jeu peut ne pas convenir à certain pour des questions de goûts, d’accessibilité, ou de problème informatique le jour J.
L’activité peut donc est complété par un dispositif plus habituel : un polycopié – pour les anciens, une activité sur un LMS (par exemple Moodle), etc.
Or à la fin, l’enseignant doit évaluer ses apprenants. Dans un contexte de multi-dispositifs, va-t-on lui demander de vérifier sur le jeu, puis sur Moodle, puis sur les polycopiés, éventuellement sur d’autres outils ?
C’est là qu’un système centralisant les informations apparaît nécessaire. On parle de Learning Record Store (LRS). Il s’agit ni plus ni moins qu’une base de données centralisant les traces d’apprentissage.
Ces traces, une fois réunies et liées dans les ténèbres, peuvent-être analyser et déclencher des actions.
3.3 Le traitement des analytics : de la validation…
Une fois les analytics centralisés, il est possible de les analyser.
De là, peuvent être automatisés des rapports, pour visualiser par exemple quelles sont les modalités les plus utilisées par les enseignants, les plus utilisées par les apprenants, quels sont les taux de réussite par Diplômes, par UFR, par UE, etc.
Ici il serait possible de détecter et de valider des sous-compétences mobilisées dans les apprentissages. Par exemple ce jeu sérieux permet de mettre en œuvre la curiosité, la compétition et l’analyse de marché. Quelles compétences vont-être mobilisées par l’apprenant ? L’une ou l’autre ? À quel degré ? Toutes ?
L’intérêt de ces validations des acquis pourrait être la création de cv automatique (via un portfolio type Karuta par exemple).
3.4 … à l’adaptation ?
Grâce aux analytics, il est envisageable de proposer des dispositifs différents suivant l’apprenant (adaptative learning).
Un apprenant est en difficulté avec l’activité Moodle, il doit être possible de lui proposer un jeu sérieux. Cet apprenant obtient un score à la limite au jeu sérieux, peut-être qu’une activité gamifiée pourrait venir en renfort.
Conclusion
Au final, si nous devions refaire les jeux vidéo que nous avons mis en œuvre, nous intégrerions la partie analytics dès le cahier des charges pédagogiques. Car au-delà des scores utiles pour le jeu, nous aurions défini les compétences, les connaissances à détecter, et nous aurions adapté les jeux pour nous les indiquer.
Nous aurions également mis l’accent sur le temps de jeu, sur le succès du jeu via le nombre d’utilisateurs mais aussi sur son taux de complétion, le score moyen, etc.
Les analytics ont été une sorte d’angle mort durant nos premiers développements, mais en prenant conscience de leur importance, de leur imbrication possible dans le système d’information, dans la capacité à déclencher des aides ou des activités spécifiques, nous nous sommes rendus compte qu’ils sont au cœur des Tices.