Il y a quelques années lorsque je me suis intéressé aux GaaS (Games as a Service), à une époque où tout le monde cherchait la « viralité » sur internet et les réseaux sociaux, je me suis intéressé à ce concept de « viralité » pour mettre au point cette méthode de conception (inspirée donc des virus) et qui peut être utilisée pour beaucoup d’autres produits.
Alors, comment créer la pandémie ?
FONCTIONNEMENT GÉNÉRAL
CEIR signifie Contagiosité / Efficacité / Infectivité / Résilience, il s’intéresse aux valeurs-clés que doit proposer un GaaS et permet de mieux se représenter l’ensemble du projet ainsi que son suivi sur le temps. Pour sortir d’un cadre viral assez cynique et peu engagent, on parlera alors de modèle AECR, pour Acquisition / Efficacité / Conversion / Rétention.
L’idée est de classer les différentes fonctionnalités qui constituent le jeu dans les 3 catégories C, E, I et R (que nous allons détailler ensuite), de leur attribuer un indice d’impact préliminaire que l’on pense réaliste.
À partir de ce catalogage, on pourra déjà déterminer de quoi le jeu manque, ce qui donnera des pistes sur quel point précis travailler.
Bon pour mieux comprendre il faut que je parle des catégories, alors allons-y :
- Contagiosité – Acquisition
La contagiosité d’un virus est sa capacité à se propager. Pour un jeu, c’est la nécessité qu’il se fasse connaître des joueurs par ses mécanismes intrinsèques, on parle d’acquisition utilisateur.
Ici on classe toutes les mécaniques dont le but est de faire en sorte que l’utilisateur fasse connaître le jeu à autrui. Cela peut par exemple correspondre à ce qui va leur donner envie d’en parler, de partager du contenu, de streamer, de faire produire du contenu in-game, production de fanart/fanfic, etc. - Efficacité
On peut voir ça pour le virus comme sa faculté à… remplir son rôle. Pour un jeu, heureusement c’est plus joyeux, c’est sa capacité à aussi remplir son rôle : répondre aux attentes des joueurs.
On classera alors ici toutes les mécaniques qui servent le cœur et l’expérience de jeu, les innovations, les points intéressants du game design, de l’ergonomie, etc. - Infectivité – Conversion
Cela représente la capacité du virus à infecter son hôte, c’est-à-dire s’y reproduire et provoquer un état pathologique. Dans un jeu, généralement pour un jeu gratuit, ce sera son potentiel à faire payer un joueur, on parle alors de conversion (joueur gratuit convertit à joueur payant).
Se mettront ici les différents modèles économiques, les méthodes de paiement et les mécaniques qui sont là pour donner à l’utilisateur envie de dépenser de l’argent dans le jeu. - Résilience – Rétention
Pour un virus (ou toute autre forme de vie), la résilience représente le pouvoir de résister aux perturbations extérieures. Pour un jeu, on parlera ainsi de rétention, c’est à dire son efficacité à retenir les joueurs le plus longtemps possible.
Ainsi, on rangera ici toutes les mécaniques dont le but est de donner au joueur l’envie de revenir sur le jeu régulièrement, après un court temps d’absence et/ou après un long temps d’absence.
Une fois toutes les mécaniques et fonctionnalités classées, on peut les pondérer en essayant d’anticiper quel impact cela peut avoir. On peut le faire avec des mots comme « faible » « fort », des + et des -, des nombres en déterminant d’une granularité à l’avance, peu importe tant que ça parle le plus à l’équipe.
Pour être plus efficace, on peut aussi faire la même chose par segmentation du public cible.
Un bon moyen est de ranger tout ça dans un tableur.
La colonne Références peut renvoyer à d’autres documents qui vont détailler le fonctionnement des mécaniques. A chacun d’adapter la forme selon ses besoins.
PHASE DE CONCEPTION
Pendant la conception du jeu, c’est un moyen supplémentaire de rationaliser le game design, en ayant une vue d’ensemble du projet vis à vis de ses objectifs, en exprimant « sur papier » les impressions et attentes que l’on a de la part de ses différents constituants.
C’est un bon moyen d’être d’avoir une base générale sur laquelle chaque membre de l’équipe peut exprimer ses avis, afin d’arriver à une représentation générale de la vision d’équipe. On peut dès le départ voir quelles sont les forces et faiblesses, les points peu travaillées ou sur lesquels on exprime des doutes.
PHASE DE DÉVELOPPEMENT
Le document peut d’une part servir de suivi de projet pour les game designers, mais de suivi tout court lors des phases de test en regardant via les différentes metrics si les éléments ont bien l’impact prévu par le modèle lors de la phase de conception.
On peut ainsi mettre les résultat de ce que les données montrent et ajouter des notes, puis procéder à des ajustements. L’outil devient ainsi un historique de développement qui tient compte de l’efficacité des mécaniques dans le temps auprès du public.
PHASE DE VIE
Une fois mis sur le marché, l’outil sert de la même façon que lors de la phase de développement. Le modèle étant évolutif et gardant la trace des différents opérations, il peut servir de base efficace aux game designers pour préparer les mises à jour, surtout si le jeu inclus des système de recueil de données analysés par un data scientist. On peut segmenter les observations en fonction de différents publics, de contexte, d’événements particuliers… N’hésitez pas à colorer des cases, y adjoindre un Power Bi, etc.
En plus de noter l’efficacité des différentes mécaniques au fil du temps, on peut y rajouter les changements dûs au patchnotes et les différentes évolutions par rapport à l’analyse précédente.
POST-MORTEM
L’avantage de ce modèle, c’est qu’il est accessible par n’importe qui car donne une bonne représentation du projet lors de son cycle de vie. On peut donc assez facilement en tirer des leçons.
Laisser un commentaire