J'ai récemment tiré une conclusion plutôt désagréable mais réelle sur les LiveOps de Pixels : ça ne se soucie plus trop de savoir si tu « aimes » ou pas, mais plutôt de savoir si tu « vas partir ». Ça peut sembler conspirationniste, mais si tu mets la ligne Stacked à côté et que tu regardes l'évolution du système de récompenses de Pixels sur la même timeline, tu verras que la direction est très cohérente - ce n'est pas de rendre les récompenses plus bruyantes, mais de les rendre plus précises, plus contrôlables, et prouvant de manière quantifiable si « cette campagne a vraiment augmenté la rétention/revenus/LTV ». Je ne veux pas utiliser de phrases accrocheuses, mais si tu veux vraiment un résumé en une phrase, c'est : les LiveOps de Pixels ne sont plus des opérations d'événements, mais un système d'expérimentation des récompenses, Stacked a juste mis à jour l'enveloppe de ce système.
D’abord, clarifions le “pourquoi”. Le LiveOps dans les jeux Web3 est plus difficile que dans les jeux traditionnels : ce n’est pas parce qu’on ne sait pas faire des événements, c’est parce que vos adversaires ne sont pas seulement les joueurs, mais aussi les scripts, les fermes et les équipes d’arbitrage. Dans les jeux traditionnels, le pire scénario quand on fait des événements, c’est que les joueurs farment vite et consomment le contenu rapidement : au maximum, vous vous faites critiquer par les joueurs. Dans les jeux Web3, le pire scénario, c’est que le budget des récompenses est capté par une série de machines : les joueurs réels n’obtiennent pas les bonbons, l’économie est vidée, et au final il n’y a plus même la possibilité de “se faire insulter les gens qui gèrent la conception”. En clair, la durabilité du P2E ne se règle pas juste en disant “il y a un peu moins de récompenses”. Elle doit régler “les fuites de budget des récompenses”, c’est-à-dire : l’argent est-il réellement dépensé pour des joueurs réels ? Pixels a, ces deux dernières années, constamment affronté cette contradiction structurelle : quand les récompenses sont distribuées de façon trop moyenne, les plus heureux sont ceux qui savent aspirer la valeur avec le plus de professionnalisme ; quand elles deviennent agressives, la notoriété monte, mais avec l’inflation et la pression à la vente ; quand elles sont prudentes, l’économie reste plus stable, mais les gens finissent par partir. Dès que l’anti-fraude monte en intensité, les dommages collatéraux apparaissent, et ensuite vous ne pourrez jamais tout expliquer dans la communauté. Tout se résume à ça : la question n’est pas seulement “combien de récompenses”, mais “où part le budget”.
La valeur de cette ligne, tombe précisément à cet endroit. Ce n’est pas une appli “avec une entrée de récompense en plus”, mais un outil qui abstrait des capacités de rewarded LiveOps déjà en place et actives dans Pixels depuis un moment : vous pouvez décider à qui vous donnez, quand, quoi, combien, et sous quelle forme—et surtout, vous devez pouvoir prouver en revenant en arrière que, une fois les récompenses distribuées, les indicateurs se sont améliorés. Sinon, ce n’est pas du LiveOps : c’est juste jeter de l’argent. Vous remarquerez que le système de Pixels insiste particulièrement sur le caractère “mesurable”. Ce n’est pas juste pour faire joli : c’est parce que ça doit être mesurable. Sans mesure, vous ne saurez pas à qui le budget a fui, vous ne saurez pas quelle chaîne de quêtes s’est fait “traverser” par des scripts, vous ne saurez pas quelle forme de récompense se transforme sur le marché en outil d’arbitrage, et vous ne saurez pas non plus si le problème vient de la conception des événements ou du contrôle anti-fraude. Beaucoup de projets meurent ici : c’est animé, mais ils ne savent pas d’où vient l’animation, et ils ne savent pas non plus à qui coûte cette animation.
C’est pour ça que je préfère comprendre le LiveOps actuel de Pixels comme une “redistribution du budget des récompenses”. Imaginez-le comme une enveloppe fixe d’exploitation (incitations on-chain, envoi d’objets, ou encore toutes sortes de récompenses). Avant, c’était dispersé comme de la poudre : qui allait le plus vite le prenait. Maintenant, c’est du déploiement par paliers : pour les nouveaux, l’objectif est “ne pas être bloqués” ; pour le retour des joueurs, “donner une raison de revenir” ; pour les joueurs stables, “ne pas s’ennuyer” ; pour les joueurs à forte valeur, “ne pas casser la boucle”. Et pour le lot supposé anormal : “des gains qui s’amincissent, un parcours incertain, des coûts plus élevés”. Ça ressemble à du bon sens, mais le transformer en capacité de système ne relève plus du bon sens : il faut satisfaire deux conditions exigeantes en même temps. D’abord, vous devez vraiment savoir distinguer. Ensuite, vous devez prouver que l’effet du déploiement par paliers peut être validé.
Ici, on ne peut pas esquiver cette couche d’AI game economist. Beaucoup de projets aiment mettre l’IA dans tous les discours, et moi aussi ça m’agace, mais je reconnais que dans le LiveOps, l’IA a vraiment une utilité : pas pour écrire des textes, mais pour faire tourner des cohortes, des courbes de rétention, trouver des nœuds de churn, proposer des expérimentations de récompenses, puis transformer “suggestion—déploiement—observation—revue” en boucle fermée. Si vous ne comptez que sur l’expérience humaine, vous pouvez faire du LiveOps, bien sûr. Mais dans le Web3, le bruit est trop fort : variations de marché, actifs on-chain, arbitrage, événements externes… tout perturbe votre jugement, et vous ne pouvez pas itérer uniquement au feeling. Si l’AI economist fonctionne vraiment, ce qu’elle sort ne doit pas être des banalités, mais du concret : “dans la prochaine itération, passez les récompenses de la forme A à la forme B ; déployez à tel type de joueur à tel nœud ; l’objectif est de faire monter tel indicateur ; la fenêtre d’observation est de tant ; le seuil d’échec est de tant.” Voilà à quoi ressemble un “économiste”, pas un chatbot.
Je vais en dire un autre, assez facile à ignorer, mais que je trouve le plus révélateur de la direction de Pixels LiveOps : il dépend de moins en moins d’un “revenu fixe” lié à une tâche unique, et ressemble de plus en plus à un assemblage “chaîne de quêtes + rythme + seuils”. Le revenu fixe, c’est le favori des scripts : c’est prédictible et scalable ; les chaînes de quêtes et le rythme, c’est plus pénible pour les scripts : cela demande des comportements plus complexes, plus difficile à reproduire de façon stable, et ça laisse plus facilement des traces du point de vue du contrôle anti-abus. Vous verrez que dès qu’un projet commence à attaquer sérieusement les fuites de budget, il réduit forcément ce genre de chemin direct “fais X et obtiens Y”, puis augmente les parcours enchaînés : “commence par A, puis B, puis C”, avec des récompenses davantage comme du carburant, des accréditations, des déverrouillages—plutôt que des choses qu’on peut emporter immédiatement. Je reste volontairement prudent dans la formulation, parce que les détails changent à chaque étape, mais la direction est bien celle-ci. Vous n’aurez peut-être pas envie de cette sensation d’être “guidé par le système”, mais du point de vue de la durabilité, c’est inévitable.
Ajoutons cette logique commerciale : “redirect ad spend to players”. Vous comprenez alors pourquoi il faut absolument faire cela. Dans les jeux traditionnels, la majeure partie du budget de croissance sert à acheter des acquisitions via des canaux : une fois dépensé, s’il reste suffisamment de gens, c’est surtout affaire d’expérience et de chance. Le chemin Pixels/Stacked veut dire quelque chose de plus précis : investir une partie du budget directement dans les joueurs, mais pas de manière aléatoire—comme un investissement de croissance, puis prouver le ROI avec des données. Sur le papier, c’est séduisant ; mais si vous ne pouvez pas résoudre les fuites de budget, ça devient immédiatement “payer les arbritragistes”. C’est pourquoi, dès le départ, l’ensemble Stacked doit avoir deux mains en même temps : l’une, c’est l’orchestration LiveOps (pour concevoir des parcours d’incitations complexes et contrôlables) ; l’autre, c’est la lutte anti-fraude et le contrôle du comportement (pour que les incitations tombent autant que possible sur les vrais joueurs). C’est aussi pour cela que Pixels, quand elle présente ce système, mentionne toujours des capacités comme anti-bot et fraud prevention : sans cette couche, engine n’est qu’une machine à répandre de l’argent, incapable de devenir une infrastructure.
Vous pourriez demander : en quoi est-ce différent d’un “système de récompenses” ordinaire ? La différence, c’est qu’il admet une réalité : les joueurs ne sont pas tous identiques, et les récompenses ne devraient pas l’être non plus. Il ne cherche pas à ce que “tout le monde soit content”, il cherche à ce que “les bonnes personnes ne décrochent pas aux moments clés”. Cette phrase est froide à dire, mais c’est exactement comme ça que fonctionne l’exploitation. Ce qu’on appelle “durabilité” vient souvent de cette froideur : vous devez accepter qu’une partie des gens n’obtienne pas les bonbons les plus sucrés, sinon le système se fait vider. Si, par le passé, Pixels faisait encore des injections assez larges et uniformes pour chercher de la chaleur, aujourd’hui ça ressemble davantage à de la précision : les récompenses sont comme un bistouri, pas comme une salière. Vous pouvez y voir un signal : on passe d’un “récit de subvention” vers une “science de l’exploitation” dans les jeux Web3.
En arrivant là, je m’autorise seulement deux phrases sur PIXEL ; au-delà, je risque de partir hors sujet. Pour que “l’expansion du rôle” de PIXEL tienne, le préalable n’est pas de raconter une histoire : c’est que ce moteur LiveOps puisse vraiment tourner de façon transversale entre jeux, qu’il puisse vraiment amener des partenaires externes à utiliser cette capacité pour distribuer des récompenses, mener des expériences de rétention, et contrôler les fuites de budget. Tant que cela n’est pas validé, toute discussion sur une “monnaie de récompenses inter-écosystèmes” ne peut être qu’un rêve. À l’inverse, si l’intégration externe se met vraiment en place, alors la demande à laquelle PIXEL répond—carburant / tenue de comptes / support de récompenses—pourrait apparaître naturellement. Je ne conclus pas ici, parce que ce n’est pas quelque chose qu’on peut faire “passer à la parole” : au final, c’est toujours les données. Le volume d’intégrations, l’uplift de la rétention active, la baisse du taux de fuite du budget de récompenses, et si les comportements anormaux sont durablement comprimés. Ce sont ces indicateurs qui sont les “preuves du progrès” du LiveOps.
Je vais enfin expliquer clairement les trois signaux d’observation que je pense qu’il faut surveiller en priorité, comme pour poser les choses au sol (j’essaie de ne pas écrire avec un ton de “conseil pédagogique” ; considérez que je termine une revue interne). Premièrement, l’événement devient-il de plus en plus “expérimental” : pour une même catégorie d’événements, voit-on apparaître plus souvent des variantes, avec des ajustements itératifs à petite échelle—forme des récompenses, seuils, rythme—plutôt que de tout changer d’un coup ? Cela signifie qu’on fait des expériences continues, pas qu’on improvise. Deuxièmement, les récompenses deviennent-elles de plus en plus “difficiles à arbitrer” : les formes de récompense se déplacent-elles davantage vers des accréditations, des déverrouillages, du carburant, de l’avancement, plutôt que vers de simples gains immédiatement “démontables” ? Cela veut dire qu’on réduit les fuites de budget. Troisièmement, les gains anormaux continuent-ils de s’amincir : ce n’est pas via un grand nettoyage ponctuel, mais en rendant les règles et les parcours durablement pénibles pour les scripts. Le taux de rendement baisse, les coûts montent, le risque augmente : cela montre que la lutte anti-abus et le LiveOps travaillent vraiment ensemble, au lieu de chacun faire sa partie.
Si vous voulez que je sois plus direct : la voie suivie par le LiveOps de Pixels aujourd’hui, c’est transformer la “récompense” d’un simple outil marketing en un système de croissance contrôlable, mesurable et capable de résister aux scripts. De l’extérieur, Stacked ressemble à une “appli de récompenses”, mais fondamentalement c’est la marchandisation à l’extérieur de ce système. Peu importe si vous aimez ou non : le plus important, c’est si ça marche. Et les critères pour dire que “ça marche” sont très concrets : le budget n’est pas vidé, la rétention et les courbes de paiement des joueurs réels montent de façon stable, et des studios externes acceptent de payer le coût d’intégration pour utiliser cette capacité. Si vous réussissez ces trois choses, c’est une infrastructure. Sinon, ce n’est qu’une autre entrée de récompense, mieux emballée.