Ces deux dernières années, en observant les jeux blockchain, j'ai eu une impression assez "contre-intuitive" : ce n'est pas le gameplay qui manque, ni la qualité graphique, mais la plupart des équipes considèrent le LiveOps comme un "coup de feu temporaire" - dès que l'engouement diminue, elles lancent des événements, si les données sont mauvaises, elles balancent des récompenses, et si la communauté s'agite, elles lâchent des airdrops. À court terme, cela semble ramener les joueurs, mais à long terme, elles brûlent le système économique comme du bois : les récompenses deviennent de moins en moins motivantes, le prix des tokens et des biens s'effondrent, et au final, ce ne sont pas les joueurs qui restent, mais les scripts et les fermes.
C'est pourquoi je préfère maintenant adopter une approche "industrialisation du LiveOps" pour analyser la trajectoire de PIXELS, surtout depuis qu'ils ont positionné Stacked comme un moteur de LiveOps récompensé (pas un de ces apps de récompenses vagues) ; toute la logique devient alors fluide : il ne s'agit pas de "distribuer plus", mais de "distribuer de manière plus précise, plus contrôlée et plus explicable en termes de causalité". En d'autres termes, le LiveOps n'est plus une planification intuitive des opérations, mais un système de croissance itératif, testable et révisable.
D’abord, voici le point que je trouve le plus crucial : l’essence de LiveOps n’est pas l’événement en lui-même, mais « quels signaux vous utilisez pour juger ce que le joueur va faire ensuite ». Les signaux des jeux blockchain traditionnels sont très grossiers : il y a eu un passage du portefeuille, des missions accomplies, des récompenses récupérées… Du coup, l’exploitation ne peut répondre que de façon plus brutale : distribution uniforme, seuils uniformes, horaires uniformisés. Résultat : tout le monde est traité comme la même personne — débutants, joueurs de retour, joueurs core, joueurs qui dépensent, joueurs à dimension sociale, et même robots — tous mélangés dans un même bassin. Plus la récompense est grande, plus elle attire les « moutons » ; plus elle est petite, plus les vrais joueurs trouvent ça sans intérêt ; plus la fréquence des récompenses est élevée, plus l’inflation arrive vite ; plus la fréquence est faible, plus la rétention chute rapidement. On dirait que c’est « difficile à opérer », mais en réalité, c’est que les signaux sont trop mauvais : on ne peut tout simplement pas faire de la personnalisation fine.
J’interprète l’ensemble de ce que fait Stacked comme « affiner les signaux d’entrée de LiveOps, puis rendre les actions de sortie expérimentables ». En surface, il y a un « AI game economist ». Beaucoup de projets utilisent cette expression comme un gadget marketing, mais dans le contexte de LiveOps, si elle fait vraiment le travail, elle devrait résoudre trois choses : premièrement, le découpage en cohortes (segmentation des joueurs) ne doit pas se faire selon les étiquettes que vous imaginez, mais selon les trajectoires de comportement ; deuxièmement, identifier les points de chute ne doit pas reposer sur l’intuition, mais quantifier les ruptures des chemins critiques ; troisièmement, les récompenses ne doivent pas être « décidées au feeling », mais utilisées comme outil d’intervention pour faire du test A/B ou des expériences à variables multiples, puis revenir à des indicateurs concrets comme la rétention, les revenus et le LTV.
Je vais donner un exemple plus concret. Imaginons que vous constatiez que « le taux de churn est particulièrement élevé après le 3e jour de jeu ». La méthode traditionnelle serait « d’offrir un gros pack au jour 3 ». Mais si vous avez vraiment fait de la data, vous pourriez découvrir que les causes du churn sont peut-être totalement différentes : certains sont bloqués par des cartes/ressources, d’autres ont une chaîne de quêtes rompue, certains n’arrivent pas à accrocher socialement, d’autres pensent que les gains sont trop lents, et il y en a même une partie qui sont des scripts que votre contrôle de risque a touchés par erreur. Donner le même pack à tout le monde ne produit que deux effets secondaires : les vrais joueurs sont « éduqués » par une tranche unique à se dire « on attend juste que ça vienne », tandis que les scripts apprennent à entrer en masse le 3e jour pour récolter. La vraie approche efficace devrait être : découper les comportements avant et après le jour 3, voir quels actions sont fortement liées à la rétention, lesquelles le sont davantage à la monétisation / la contribution, puis décomposer les récompenses en une combinaison de « fonctions d’objectif » différentes : aider ceux qui sont bloqués à passer plus vite, aider les joueurs à dimension sociale à rejoindre plus vite une guilde/alliance, donner des incitations plus longues aux joueurs potentiellement à forte valeur, et pour les comportements suspects, fournir une vérification/limitation plus forte. C’est ça la bonne façon d’ouvrir LiveOps : la récompense n’est pas un bonbon, c’est un bistouri.
Cela mène à un deuxième point qui m’importe particulièrement : l’anti-fraude n’est pas une « fonctionnalité ajoutée », c’est une condition préalable pour que LiveOps puisse exister. Le système de récompenses des jeux blockchain s’effondre facilement non pas parce que l’idée de récompense est mauvaise, mais parce qu’il attire naturellement les adversaires. Tant que les récompenses sont prévisibles, que les seuils sont réplicables et que les chemins sont scriptables, on verra apparaître un comportement de farm professionnalisé : multi-comptes, scripts, travail à la place, arbitrage, lavage de volume… jusqu’à vider le budget de récompenses et transformer le modèle économique en « subvention accordée au crime organisé ». Beaucoup d’équipes échouent précisément ici : elles pensent qu’elles font de l’exploitation, mais en réalité elles nourrissent leurs adversaires en données et en budget.
Donc, quand Stacked met la prévention de la fraude, l’anti-bot et les données comportementales dans le « cœur de l’engine », je comprends pourquoi je le vois plutôt comme une infrastructure que comme un outil d’animation. Parce que ce n’est que si vous pouvez identifier de façon continue des « comportements de vrais joueurs » et des « comportements falsifiés » que LiveOps peut faire des placements précis ; ce n’est que si votre budget de récompenses n’est pas siphonné de manière stable par les activités illégales que vous osez lancer des incitations sur le long terme ; et ce n’est que si vous pouvez tenir tête, dans un environnement de production, à l’affrontement entre utilisateurs réels et attaquants que le prétendu « P2E durable » n’est pas juste un slogan. Sinon, même si vous faites le show aujourd’hui, demain quand les données s’effondrent, l’économie meurt en premier.
Troisième point, selon moi assez facile à ignorer : une fois que LiveOps atteint un certain niveau de complexité, ce dont l’équipe a le plus besoin n’est pas « des idées de gameplay », mais « une intégration de bout en bout, de l’insight à l’action ». Beaucoup d’équipes font de l’analyse, regardent des dashboards, mais la mise en œuvre finale dépend quand même de personnes qui modifient manuellement les configurations, les missions, les récompenses, les probabilités : c’est long, l’itération est lente, et la boucle de rétrospective ne se referme pas. Vous verrez alors un cas très typique : l’équipe pense qu’une action A est efficace, donc elle renforce ; mais en réalité, ce qui était efficace venait de la mise à jour de contenu de la même période. Ou bien vous pensez qu’augmenter la récompense améliore la rétention, mais en fait vous retenez surtout des joueurs à faible valeur, et le LTV diminue. Sans conception d’expériences rigoureuse et sans exécution en boucle fermée, LiveOps devient « plus vous essayez, plus c’est de la magie ».
Dans le récit de Stacked, la partie que j’apprécie le plus, c’est qu’elle transforme LiveOps en un système « questionnable, expérimental et exécutable ». Vous demandez : « pourquoi les joueurs décrochent au jour 3 ? », et elle ne vous donne pas seulement un graphique : elle vous guide pour segmenter, choisir les indicateurs, concevoir des interventions de récompense, et elle relie directement les actions d’intervention à la configuration et au déploiement. C’est cette boucle fermée que l’« AI game economist » devrait faire vraiment : pas écrire le rapport à votre place, mais vous aider à transformer le budget de récompenses en levier de croissance contrôlable.
En allant plus loin, ce qui rend la ligne de PIXELS plus intéressante, c’est qu’elle traite cette engine comme une « couche de récompenses trans-jeux », plutôt que de ne servir qu’un seul jeu. Le plafond d’un jeu blockchain unique est très clair : le cycle de vie, l’offre de contenu, la façon dont les joueurs pensent le produit, le cycle du marché — tout vous verrouille. Une fois que vous avez vécu une séquence « explosion — sortie du cercle — passage en mode ferme — effondrement de l’économie — dispersion des joueurs », vous comprenez à quel point c’est fragile d’attacher des tokens à un seul mode de jeu. À l’inverse, si l’engine de LiveOps récompensé peut être réutilisée sur plusieurs jeux, ce qu’elle accumule est quelque chose de plus difficile à reproduire : l’expérience anti-fraude, des actifs de données comportementales, une expertise en design de récompenses, et un système d’expérimentation trans-produits. Tout cela est bien plus difficile que « refaire un système de missions ».
Dans les informations externes, on mentionne aussi à plusieurs reprises que Stacked tourne déjà en production, et qu’elle ne reste pas au stade du livre blanc. Elle serait décrite comme ayant soutenu des produits comme Pixels, Pixel Dungeons, Chubkins, etc., et comme ayant géré des ordres de grandeur de « centaines de millions » d’événements de récompense, couvrant « des millions » de joueurs, avec en plus des affirmations publiques de « contribution à des dizaines de millions de dollars de revenus ». Pour moi, la valeur la plus importante de ce type de chiffres n’est pas de servir de slogan promotionnel, mais de montrer une chose : si elle a vraiment tourné à cette échelle, elle a nécessairement traversé énormément de conditions aux limites — lutte contre la triche, abus des récompenses, inflation économique, fatigue liée aux événements, cadence des mises à jour de contenu, coûts de migration des joueurs… Beaucoup de ces pièges ne se voient pas à petite échelle : c’est seulement quand tu passes à grande échelle que tu découvres que le système est aussi fragile que du papier. Un moteur LiveOps capable de tourner en production prouve au moins qu’il ne s’agit pas d’une structure de type PPT.
Bien sûr, je ne vais pas, parce que ces récits existent, considérer directement que c’est une « réponse invincible ». Je préfère plutôt le voir comme une direction qui mérite une observation continue : si Stacked veut devenir une infrastructure, elle doit se prouver durablement sur plusieurs points. D’abord, l’expliquabilité des déploiements de récompenses doit être suffisamment forte — sinon les joueurs vont interpréter « précision » comme « manipulation », et la confiance de la communauté chutera. Deuxièmement, la stratégie anti-fraude doit équilibrer le coût des erreurs : un contrôle trop strict fera fuir les vrais joueurs, trop laxiste sera percé par les activités frauduleuses, et le point d’équilibre est extrêmement difficile. Troisièmement, la couche de récompenses trans-jeux introduira un nouveau jeu : les structures économiques de différents jeux diffèrent, est-ce que la circulation des récompenses dans différents modes va déclencher de nouveaux arbitrages ? Comment limiter la « contamination en retour » de tout le système par le jeu le plus facile à exploiter ? Ce sont là des problèmes d’ingénierie incontournables après la transformation de LiveOps en infrastructure.
Mais quoi qu’il en soit, faire évoluer LiveOps de « distribution de bonus » vers « moteur de croissance basé sur les récompenses », puis faire passer l’engine d’un jeu unique à un niveau trans-écosystème : ce parcours ressemble au moins davantage à la résolution de la plus vieille maladie de la plupart des jeux Web3 que « refaire un panneau de missions » de plus. Cette maladie, c’est que dès qu’une récompense apparaît, elle est immédiatement « scalée », et dès que l’économie se met en place, elle est vidée — jusqu’à ne rester que des bulles et des plaintes. Le point le plus intéressant à discuter pour PIXELS aujourd’hui n’est donc pas la hausse ou la baisse à court terme, mais de savoir si elle peut vraiment transformer la « récompense » de coût en actif, et faire en sorte que « le budget d’acquisition » ne soit plus siphonné par des activités illégales, mais reste chez les vrais joueurs. Si cela tient, alors GameFi aura vraiment fait un pas en avant.
