Navigation▲
II. Introduction▲
Splash Damage est un studio londonien créé en 2001 qui se consacre aux jeux multijoueurs : Wolfenstein , Ennemy territory, Brink, Batman, Extraction.
Leur idée est d'enregistrer les statistiques de jeu et des joueurs afin de les utiliser dans le but d'améliorer leurs jeux.
III. Enregistrer les statistiques de jeux▲
III-A. L'âge sombre▲
Au début, il n'y avait aucune statistique et lorsqu'il y en avait, personne ne les analysait. Malgré cela, Splash Damage a réussi plusieurs jeux ayant beaucoup de fans. Ils se concentrent sur l'aspect amusant et balancé de leurs jeux, mais cela reste une tâche compliquée. En effet, il n'est pas simple de correctement balancer le jeu et de trouver les problèmes liés au gameplay. Chaque modification risque de casser le précieux équilibre des mécanismes du jeu.
Les designers ont un travail énigmatique, ou chacun peut être en désaccord avec ses collègues. Comment ce processus peut-il être amélioré ?
Actuellement, le processus de développement est très itératif :
- hypothèse ;
- action ;
- hypothèse ;
- action ;
- …
Cela pourrait donc être amélioré :
- les développeurs jouent (en interne) : mains moites et conjectures ;
- ensuite, les joueurs jouent (statistiques, classements, expériences, nombre de morts…).
Mais ce processus n'est pas une boucle. Une fois que le jeu est commercialisé, les statistiques des joueurs ne sont pas analysées.
Un processus scientifique ressemblerait plus à :
- analyse des données ;
- hypothèse ;
- action ;
- vérification ;
Mais d'abord, il est nécessaire de récupérer ces données.
Pour Wolfenstein, il n'y avait absolument pas de statistiques (mis à part les mods). Dans Enemy Territory, seul un classement global était disponible. Pour Brink, c'était un classement de la progression des joueurs.
Toutes ces données sont arrivées trop tard et personne ne s'en préoccupait.
Les données brutes ne sont pas utiles, que ce soit pour les programmeurs ou les game designers. Les serveurs généraient aussi des données qui n'étaient pas gardées.
III-B. Transition▲
Une transition a eu lieu en 2011 avec la possibilité de s'autopublier. Le travail a commencé sur de nombreux jeux et cela à travers les différentes plateformes. Splash Damage a commencé à développer et à exécuter ses propres services en ligne. Cela fut donc une parfaite opportunité pour faire quelque chose d'utile avec ces données.
Ils ne savaient pas vraiment s'ils avaient le droit de le faire et, si ce n'est pas le cas, ils présentent leurs excuses.
Il y avait beaucoup de données à collecter :
- statistiques sur les joueurs (scores, cartes de chaleur pour indiquer où les joueurs passent le plus de temps, où ils sont tués, d'où ils se font tuer…) ;
- les statistiques sur les performances du serveur (bande passante…) ;
- les statistiques sur le client (FPS, ping…).
Et cela a fonctionné. Grâce à ce système, les level designers ont pu découvrir les couloirs de la mort, les game designers ont amélioré l'équilibre entre les armes, les programmeurs ont corrigé des bogues sur le serveur.
Grâce à cela, il a été possible de mettre en place un nouveau processus de développement :
- les développeurs font des tests et les données sont stockées ;
- les données sont analysées pour améliorer le jeu.
Toutefois, tout n'est pas parfait. Les statistiques sont récupérées manuellement, cela ne fonctionne que pour un seul jeu et cela n'est en place que pour l'équipe interne.
Que faire des autres données de gameplay. Comment doit-on gérer l'identification des joueurs (changement de nom) et que se passe-t-il après la publication du jeu ? Le jeu n'est pas pour les concepteurs, mais pour les joueurs.
III-C. Révolution industrielle▲
Un nouveau système a été mis en place pour améliorer le processus de récupération des données et de l'automatiser. Dans celui-ci, les matchs sont perçus comme des sessions possédant des événements. Chaque session et chaque événement possèdent un horodatage. Chaque session et événement possèdent des données arbitraires combinées en clé/valeur.
Fireteam a adopté des systèmes pouvant être redimensionnés linéairement. Ils ont migré leurs services sur Amazon EC 2 et ont modifié le système tout en gardant en tête les cas problématiques.
Le processus est maintenant une vraie boucle (voir photo) :
Les netvars sont de simples variables (stockées sur le Web) qui modifient le comportement du jeu, permettant ainsi aux développeurs d'agir sur le jeu.
III-C-1. Mise en place▲
Le système est automatisé, agnostique au jeu, peut fonctionner de n'importe où, enregistre les données sous forme de paires clé/valeur, consistant sur le temps et permet de suivre un joueur en particulier (grâce à l'identifiant steam/xbox/PSN).
Le premier lancement a été effectué sur Batman Arkham Origins. Les designers analysaient les données dans des feuilles de calcul et le système permettait de vérifier les retours des joueurs (forums…).
Pour chaque utilisateur, ce sont quatorze types d'événements qui sont enregistrés et environ 1000 en sont enregistrés par match. L'enregistrement a été effectué sur 5 % des matchs.
Ces statistiques ont énormément aidé les développeurs, les designers pouvaient facilement identifier les problèmes de balancement.
Grâce aux netvars, il n'y avait plus vraiment besoin de faire des mises à jour permettant aux designers de réagir rapidement (et cela même sur un jeu publié) rendant les designers heureux.
III-C-2. Extraction▲
Extraction est le premier FPS « Free to Play » de Splash Damage et le premier jeu à utiliser le système de statistiques.
Le système peut recevoir 24 événements différents. La plupart sont envoyés au début de la partie ou à la mort.
Une interface JavaScript personnalisée basée sur Angular JS a été mise en place, permettant des itérations rapides. Les données couvraient la plupart des cas d'usage. Le système est conscient des particularités du jeu et affiche les données afin de pouvoir les utiliser facilement. L'interface communique directement avec la bibliothèque du système. Le navigateur de l'utilisateur gère le rendu.
Grâce à ce système, les développeurs ont pu découvrir une triche permettant de tuer un joueur d'un bout à l'autre de la carte.
III-C-3. Retours▲
Excel est la meilleure arme du designer, ainsi que les tables pivots.
Les statistiques sont essentielles à l'équilibrage des armes. Les designers examinent constamment les dernières données et ne modifient jamais une variable sans avoir regardé les données. Ces données sont aussi cruciales pour l'équilibrage des cartes et permettent de détecter et de corriger rapidement les problèmes. Les métriques de performances sont aussi très utiles.
III-C-4. Leçons sur le dimensionnement de l'application▲
Il est nécessaire de réfléchir aux données qui doivent être envoyées. L'échantillonnage est effectué du côté du client. Le plus grand coût est celui de la location des machines.
III-C-5. Améliorations▲
Les requêtes sur les données ne sont pas simples. Les simples requêtes devraient être instantanées. L'intégration dans le jeu pourrait être plus simple : utilisation de bibliothèques clients, automatisation des tâches.
III-C-6. Qu'est-ce qu'ils ont appris▲
Les statistiques sont utiles lorsqu'elles sont correctement effectuées. Cela permet de générer de jolis graphiques. Il existe des logiciels et des bibliothèques efficaces : Flash, HBase, Flume. La technique est applicable dans beaucoup de domaines du jeu vidéo.
Deux ingénieurs peuvent effectuer énormément en un temps court, s'ils ont la liberté pour le faire.
L'ajout et l'utilisation des statistiques de jeu sont faciles (mais, il faut s'assurer que les données sont accessibles).
Il n'est jamais trop tard. L'analyse est une partie essentielle du processus de design. Fireteam offre leur logiciel tel un service.
IV. Questions/Réponses▲
IV-A. Est-ce que vos statistiques ont aussi été utilisées pour la composante payante de votre « free to play » ?▲
Oui