Le Blog du Panda, soit disant game designer chez Ubisoft

Par elPanda Blog créé le 20/08/12 Mis à jour le 18/09/13 à 11h07

Un peu de tout, et j'fais même le café* !

* et des fautes d'ortographeux aussi

Ajouter aux favoris
Signaler

Vous allumez votre ordinateur (on ne tergiversera pas sur le fabricant, pomme ou fenêtre), vous checkez vos mails, vous checkez vos notifications facebook, vous checkez vos tweets ... C'est bon, vous êtes prêts à lancer votre jeu du moment, ce nouveau jeu online à la mode dont tout le monde parle.

Cette scène vous parle ? Rien d'étonnant, on est plusieurs millions à le faire chaque jour.

Cependant, avez-vous la moindre idée que ce simple geste de "lancer votre jeu [...]" active un mécanisme incroyablement complexe que de petits savants en blouses blanches vont analyser dans les minutes qui suivent ?

 

 

BIG BROTHER

 

En effet, les dev' on mit en place d'énormes systèmes de tracking sur les actions des joueurs afin d'étudier leur comportement. Cette logique a ses raisons, et fondamentalement, ça se comprend. Les stats parlent beaucoup et elles mentent beaucoup moins souvent (que les joueurs, bien entendu).

Cet engouement pour les stats dans les jeux vidéos à même pousser certains studios à changer l'organisation pour devenir ce qu'on appelle "Data Driven" = "On analyse les stats, et on fait des mis à jour en fonction"

Il faut quand même savoir qu'il n'y a rien de nouveau, c'est le même principe que google analytics. Il fallait juste penser à porter et adapter la théorie des stats du web vers le jeu vidéo.

Mais dis donc Jamy, comment ça marche tout ça?

La réalisation technique est simple : Les dev rajoutent à des endroits précis des appelles à des services web en leur fournissant un maximum d'information standard (par exemple : OS, CG, Processeur, Pays, Langue utilisée, résolution et l'heure de l'envoi) ainsi que des infos propres à l'événement (par exemple, si j'ai un événement qui s'appelle "quitter_circuit", on aura un paramètre "nb_tour" qui permet de savoir combien de fois le joueur à fait de tour avant de quitter)

Ce système permet donc rapidement de récolter des millions d'informations sur les joueurs, leur façon de jouer et sans qu'ils ne s'en rendent compte.

Maintenant, il faut traiter tout ça

Les Outils

Il existe beaucoup d'outils de stats. Pour faire simple, je vais citer le plus gros Kontagent (que je n'ai pas eu la chance d'essayer étant donné qu'il coûte les deux bras) et KissMetrics.

Je n'ai été amené à travailler qu'avec KissMetrics et déjà, l'outil est puissant. (sachant que Kontagent propose des fonctionnalité encore plus folle et complexe)

Google Analytics tells you what happened, KISSmetrics tells you who did it.

Voilà ce qu'on peut lire sur le site de KissMetrics. C'est bon, on est en plein dedans !

On a des events, What's next ?

Maintenant qu'on a notre base remplie d'événement, il faut en extraire les infos. Et c'est là que ça se complique (et que ça devient intéressant). Voici donc quelques possibilités sur la façon d'analyser ces informations. Bien sûr, il y'en a beaucoup d'autre et il faut bien comprendre que c'est un sujet complexe en constante évolution.

Les funnels

"Entonnoir" en français. Les funnels permettent d'étudier le taux de réussite d'un processus défini. Par exemple, je veux étudier mon tutorial. Je vais mettre en place un funnel sur l'inscription et je vais savoir, à chaque étape, combien j'ai perdu de joueurs (combien ont arrêté). À la fin, je me retrouve avec un % correspondant au nombre de joueurs qui ont fini le tutorial, par rapport au nombre de joueurs que j'avais en entrée.

Cette méthode est puissante et intéressante (si elle est bien mise en place, c'est là le piège), car elle permet précisément de corriger le comportement des joueurs pour ne pas les perdre. Car c'est là aussi toute la problématique : on ne veut pas perdre nos joueurs (en particulier sur les F2P)

La complexité réside surtout dans l'analyse des fuites : comprendre pourquoi tel joueur est parti à tel moment. Problème technique ? Tutorial trop long ? Problème de traduction ? C'est donc le début d'un travail de recherche, d'analyse, de test pour trouver le problème et le corriger.

Les cohortes

Les cohortes permettent de regrouper les joueurs par point commun, et d'analyser leur comportement de manière globale. Par exemple, je peux étudier les joueurs qui se sont inscrits entre cette date et cette date, par rapport à celle-là. Ou bien, je peux étudier les joueurs qui ont entre 15 et 20 ans, qui vivent en France et qui ont un processeur < à 1.6 ghz.

J'extrais ensuite les métriques qui m'intéressent, et là, je peux parler.

Par exemple : Grâce aux cohortes, je peux me rendre compte que mon super jeu (qui n'est dispo qu'en Français et en Anglais) à un franc succès au Brésil. Cependant, je me rends compte que les jeunes Brésiliens (qui parlent vraisemblablement mal/peu l'anglais ou le français) n'arrivent pas à finir le tutorial. Peux être que je devrais songer à traduire tout ça.

La rétention

La rétention est une métrique à proprement parler. Elle est généralement appliquée sur une cohorte précise. La rétention permet de répondre à la question "Si 100 joueurs viennent tel jour, combien reviendront au moins une fois dans 3 jours ? 1 semaine ? 1 mois ?".

La encore, il y'a plusieurs façons d'analyser/de calculer cette information. On peut parler de jours glissants, on peut parler de rétention cumulative (est-ce qu'un joueur compte plusieurs fois ? Est-ce qu'on définit plutôt une moyenne sur le nombre de connexions d'un utilisateur sur une période de temps donnée ?) etc ...

Pour simplifier (et introduire un nouveau terme), la rétention pour un nouvel utilisateur est assimilée à l'engagement : sur 100 nouveaux joueurs inscrits, combien vont vraiment accrocher à mon jeu (il faut définir ce qu'est cette notion d'accore du joueur)

le K-factor

Le k-factor est une notion venant de la viralité (plus d'infos sur wiki !). Il s'agit de déterminer maintenant, pour chaque joueur, le nombre d'amis qu'il va ramener. Si le K-factor est supérieur à 1, votre nombre de joueurs aura tendance à augmenter.

Cette métrique est très puissante et fut le sujet de toutes les attentions pendant l'âge d'or des F2P sociaux sur facebook (farmville and co).

Le degré de "stickyness"

Cette métrique est aussi (souvent) ramenée à définir l'engagement, mais de manière globale, sur l'ensemble des joueurs. Il s'agit d'établir le rapport DAU/MAU (MAU = nb joueurs actifs dans le mois // DAU = nb joueurs actifs sur la journée)

Ce rapport donne un % qui se traduit pas "j'ai N% de mes joueurs actifs sur le mois qui se connecte tous les jours"

Entre 15 et 20%, le business est correct
En dessous, c'est pas bon signe.
Au dessus... Champagne :)

Le prix dans tout ça ?

Mettre en place tous ces outils à un coup non négligeable (outils, analyste, dev qui intègrent des événements, etc.). On peut même dire que c'est un gouffre financier. Mais si c'est devenu monnaie courante, c'est que cette pratique est bien souvent rentable (pas tout le temps non plus ...).

L'objectif global est d'améliorer de manière constante et précise le jeu, en effectuant des opérations de maintenances chirurgicales pour corriger tel ou tel problème, et conserver les joueurs. La dépense se fait en amont, dans la partie R&D pour diminuer les coûts de production. C'est un peu comme des chirurgiens qui étudieraient leur patient pendant des heures, des jours, des semaines, pour mettre un simple petit coup de bistouri précisément là où il faut et le guérir en quelques secondes.

 

On peut par contre se demander, et la magie dans tout ça ? Avant (et ouais...), les Game Designer bossaient corps et âme sur des projets, en y mettant leur coeur et en faisant un jeu fruit de toute cette passion. Ils avaient UNE chance.
Est-ce que c'était mieux ? Ça, par contre... 

Ajouter à mes favoris Commenter (0)

Commentaires

Édito

Beaucoup de blabla autour du game design.


CONNECT

Archives

Favoris