Jeux entièrement sur chaîne / Mondes autonomes (FOG/AW) : Analyse de la synchronisation de l'état du jeu et des défis techniques
TechFlow SélectionTechFlow Sélection
Jeux entièrement sur chaîne / Mondes autonomes (FOG/AW) : Analyse de la synchronisation de l'état du jeu et des défis techniques
Pour les jeux fonctionnant entièrement sur la blockchain, celle-ci sert de serveur de jeu et constitue une source de confiance décentralisée pour l'état du jeu.
Dédié à des analyses Web3 approfondiesAuteur : Fiona, IOSG Ventures
TL;DR
-
Les jeux entièrement sur chaîne / mondes autonomes (« FOG/AW ») constituent l'une des rares narratives importantes autour du Web3. Contrairement aux applications « Web2.5 », qui ne sont liées au Web3 que via les NFT, les FOG/AW placent également la logique du jeu sur la blockchain. Ils utilisent la blockchain comme serveur de jeu, servant ainsi de source de confiance décentralisée pour l'état du jeu. Cela offre des avantages tels que la pérennité, la résistance à la censure et la composable, mais limite aussi la diversité et la complexité des jeux pouvant être construits dessus.
-
À mesure que les exigences en matière de complexité et de jouabilité augmentent, l'architecture du moteur fait face à de nouveaux défis : latence par image, génération de nombres aléatoires, récupération de points de vie, effets passifs continus, minuteries, etc. La notion de temps et l'unité « ticks » sont différentes sur une blockchain. Mud propose plusieurs approches pour simuler l'écoulement du temps et les compétences de récupération passive. Par exemple, lorsqu'un joueur se déplace dans une pièce, la transaction inclut le déplacement de tous les objets présents selon un design prédéfini, permettant ainsi de percevoir les changements d’état et d’écoulement du temps.
-
La pile technologique FOG/AW peut être résumée ainsi : les développeurs écrivent le code frontend et backend pour l’interface utilisateur, l’expérience utilisateur et la logique centrale du jeu, puis synchronisent toutes les modifications via une boucle d’état du jeu ; enfin, un indexeur reflète ce nouvel état sur les appareils locaux du frontend.
-
De nombreux types de jeux, comme les RTS, nécessitent des taux de « tick » élevés, or les blockchains basées sur un consensus ne peuvent traiter que les variations correspondant à leur temps de bloc. Le taux de « tick » est donc un problème majeur à résoudre. Curio et Argus sont des leaders dans ce domaine, explorant des moyens d’augmenter le taux de « tick » au niveau de la chaîne. Mud cherche quant à lui à maximiser la présence sur chaîne, en conservant tout l’état de l’application dans la machine virtuelle Ethereum (EVM), sans introduire de solutions hybrides hors chaîne pour améliorer le taux de « tick ».
-
En ce qui concerne le choix de la chaîne, Dojo mène l’écosystème entièrement sur chaîne de Starknet. Selon @tarrenceva, Starknet utilise des « state diffs » (différences d’état), contrairement aux rollups optimistes qui se concentrent sur les entrées plutôt que sur les sorties. L’impact sur les jeux pourrait principalement concerner l’optimisation des coûts. Par exemple, dans une partie d’échecs de trois minutes, il peut y avoir 50 coups. Grâce aux différences d’état, une seule preuve et l’état final suffisent à prouver la « sortie ». En revanche, les rollups optimistes exigeraient toutes les « entrées » des états intermédiaires.
Définir FOG/AW : comment l’état du jeu est-il synchronisé ?
Je pense que le critère pour déterminer si un jeu est un FOG repose sur la manière dont l’état du jeu est synchronisé (la « source of truth »).
Pour les jeux Web 2.5 ou les jeux multijoueurs traditionnels, un serveur centralisé définit l’état courant du jeu. Lorsqu’un joueur envoie une action, le serveur compile ces entrées et renvoie les résultats mis à jour à chaque appareil connecté. Le serveur traite toutes les entrées (« ticks »), résout les incohérences et envoie régulièrement des mises à jour aux joueurs sous forme d’instantanés de tous les éléments du jeu, mettant à jour l’état à chaque « tick ». L’état du jeu (« game state ou tick ») est une capture temporelle des attributs de chaque objet dans le monde du jeu. Le taux de « tick » désigne le nombre de fois par seconde où le serveur de jeu calcule et diffuse l’état mis à jour. Plus le taux de « tick » est élevé, plus l’expérience de jeu est précise et fidèle. Généralement, les jeux d’action ou de stratégie en temps réel exigent un taux élevé, tandis que les jeux de cartes ou autres jeux par tours n’en ont pas besoin.
Dans un jeu entièrement exécuté sur la blockchain, celle-ci sert de serveur de jeu et constitue la source de confiance décentralisée pour l’état du jeu. Dans ce cas, non seulement les NFT ou jetons sont véritablement possédés, mais aussi les actions des joueurs (« ticks ») et la logique du jeu sont elles-mêmes sur la chaîne. C’est pourquoi on peut atteindre une véritable propriété, pérennité, résistance à la censure et composable. Idéalement, chaque action d’un joueur devrait être soumise à la blockchain ; après consensus, l’état du jeu est mis à jour et renvoyé aux appareils locaux. De ce fait, les types de jeux nécessitant peu de « ticks » sont naturellement mieux adaptés à une exécution entièrement sur chaîne.
Relever les défis liés à la latence, au temps, etc.
L’augmentation de la complexité et des exigences de jouabilité pose de nouveaux défis architecturaux : latence par image, génération de nombres aléatoires, récupération de points de vie, effets passifs continus, minuteries, etc.
La latence par image est très courante même dans le monde Web2, due notamment aux retards de rendu côté client et aux actions des utilisateurs. Pour les jeux à haut taux de « tick » comme les FPS, toute latence détériore gravement l’expérience. Une solution dans le Web2 consiste à utiliser une mise à jour d’état synchrone (« lockstep state update »), synchronisant tous les joueurs selon le délai maximal constaté, garantissant ainsi une expérience équitable. L’introduction de la blockchain, avec son attente de confirmation de transaction, peut aggraver cette latence. Pour y remédier, Mud intègre un mécanisme courant dans les jeux : le rendu optimiste, qui suppose que l’action réussit et la rend immédiatement côté client, avant que le serveur (ou ici, la transaction) ne confirme.
La génération de nombres aléatoires sur chaîne est un sujet fréquemment discuté. Mud suggère d’utiliser le comportement de l’utilisateur comme entrée pour produire un résultat aléatoire généré après l’interaction.
La notion de temps et l’unité « ticks » diffèrent sur la blockchain. @SebastienGllmt souligne qu’il est difficile d’utiliser des minuteries sur les chaînes basées sur la preuve de fraude (comme Op), car une erreur nécessiterait un retour arrière, nuisant fortement à l’expérience. Mud propose plusieurs méthodes pour simuler l’écoulement du temps et les compétences de récupération passive. Par exemple, pour augmenter progressivement les pièces d’or, on calcule la quantité disponible chaque fois qu’un joueur effectue une action, en fonction de sa réserve précédente, du dernier moment de rafraîchissement et du taux défini. Un autre exemple : quand un joueur se déplace dans une pièce, la transaction inclut le déplacement de tous les objets selon un schéma prédéfini, permettant ainsi de percevoir l’évolution du temps et de l’état.
Écrire des scripts (« tricher ») n’est peut-être pas un problème. @BriefKandle ne considère pas que l’exploitation MEV (extraction de valeur par ordre de transaction) soit de la triche ; prévenir les bots simples capables de générer du MEV relève de la conception du jeu. Les développeurs Web2 doivent changer de paradigme : un bon bot MEV peut devenir un PNJ intégré au jeu.
Certaines fonctionnalités sont déjà implémentées dans des jeux récents sur chaîne, comme Rhascau, qui utilise des minuteries et des effets passifs continus, basés essentiellement sur le temps des blocs (sur les L2 actuels, temps de bloc = taux de « tick »).
Pile technologique FOG/AW
Un framework de moteur FOG/AW est un ensemble d’outils permettant aux développeurs de construire des jeux en utilisant la blockchain comme serveur et source de confiance. Il vise également à résoudre plusieurs problèmes actuels :
-
L’absence de cadre standard ou prêt-à-l’emploi rend inefficace la construction de FOG/AW sur chaîne ;
-
Manque de modularité et de réutilisabilité du code ;
-
Manque de composable. À mesure que les moteurs FOG/AW évoluent, les jeux sur chaîne pourront devenir plus riches et imaginatifs.
Pour simplifier, le flux technique typique est le suivant : les développeurs écrivent le code frontend et backend pour l’UI/UX et la logique centrale, synchronisent ensuite tous les changements via une boucle d’état du jeu, et un indexeur reflète finalement le nouvel état sur les appareils locaux du frontend.
Pour permettre à ces moteurs de fonctionner efficacement sur blockchain, Mud, Dojo, Curio, Argus, Paima Engine et Lootchain développent chacun leur propre pile technologique. Celle-ci se compose de trois parties clés : la chaîne, la pile de développement principale et le frontend du jeu. Chacun apporte ses innovations, en trouvant un compromis entre décentralisation et complexité du jeu.
-
Frontend du jeu : comprend des moteurs traditionnels comme Unity, Unreal, ainsi que des langages comme React ou Three.js, offrant des outils puissants pour le rendu. Cette composante est essentielle pour améliorer la jouabilité et l’expérience. Ces projets fournissent généralement des SDK adaptés aux développeurs.
-
Pile de développement principale : conçoit une architecture permettant d’exécuter la logique du jeu sur la blockchain et de la synchroniser avec le frontend. Les composants clés incluent une structure de base de données adaptée (définissant comportements et logiques du jeu), ainsi que la synchronisation et le retour de l’état du jeu.
-
Chaîne : la majorité choisissent de construire sur Ethereum, Optimism ou Starknet.
Le schéma ci-dessous illustre comment différents protocoles conçoivent leur pile technologique. Prenons Mud V2 comme exemple pour décrire son flux de fonctionnement :
-
Un développeur utilise des outils Web2 frontend fournis par Mud pour coder, tirant parti de leurs fonctionnalités avancées (comme le rendu) pour rendre le jeu plus visuel et attractif ;
-
Parallèlement, le développeur écrit, selon le cadre de contrats intelligents de Mud (Mud World), les personnages, objets et logiques spécifiques du jeu, par exemple : quand le héros A se déplace de X à Y et lance une attaque contre la zone Y, quelle est la probabilité ou sous quelles conditions il réussira à conquérir cette zone ;
-
Ces actions et états du jeu sont enregistrés dans Mud Store, une base de données sur chaîne responsable de l’état global du jeu, servant de source de vérité pour la synchronisation ;
-
Quand le héros A attaque Y, cela signifie que le joueur a cliqué sur son interface locale et envoyé la commande sur la chaîne. Cette commande, selon la logique définie par le développeur et l’état actuel dans Store, produit un résultat qui met à jour l’état global du jeu, puis est synchronisé sur la chaîne ;
-
Les jeux sur Mud supportent divers frontends (Web, Mobile), mais peuvent rencontrer des besoins complexes en matière d’indexation. Mode a justement été développé comme indexeur hors chaîne pour répondre à ce besoin.
Examinons maintenant les similitudes et différences dans la conception de ces frameworks principaux.
-
La plupart suivent la conception de Mud v1 et utilisent ECS (Entity-Component-System) comme structure de données pour le développement de jeux — une méthode d’écriture et de représentation de la logique. Mud V2 l’améliore : les données sont désormais définies dans des Tables et des Systems, permettant d’autres standards de données (pas obligatoirement ECS comme en v1), offrant ainsi plus de flexibilité et d’inclusivité aux développeurs.
-
La plupart utilisent une base de données décentralisée, car la blockchain est naturellement la source de confiance pour l’état et la base de données du jeu. Mud cherche à maximiser la présence sur chaîne, en conservant tout l’état de l’application dans l’EVM, sans sacrifier la décentralisation ni introduire de solutions hybrides hors chaîne pour augmenter le taux de « tick ».
-
Comme de nombreux types de jeux, tels que les FPS, exigent des taux de « tick » élevés, alors que les blockchains fondées sur consensus ne gèrent que les variations selon leur temps de bloc, le taux de « tick » reste un problème crucial. Curio et Argus, grâce à leurs innovations, cherchent à augmenter ce taux directement au niveau de la chaîne.
-
Concernant le choix de la chaîne, Curio et Loot utilisent Caldera pour construire une chaîne Op Stack. En revanche, Dojo mène l’écosystème entièrement sur chaîne de Starknet. Selon @tarrenceva, Starknet utilise des « state diffs », contrairement aux rollups optimistes qui se concentrent sur les entrées plutôt que sur les sorties. L’impact sur les jeux pourrait principalement concerner l’optimisation des coûts. Par exemple, dans une partie d’échecs de trois minutes, il peut y avoir 50 coups. Grâce aux différences d’état, une seule preuve et l’état final suffisent à prouver la « sortie ». En revanche, les rollups optimistes exigeraient toutes les « entrées » des états intermédiaires.
Des jeux ont déjà été construits sur ces moteurs. Mud et Dojo organisent des hackathons pour attirer les développeurs, et Curio vient de présenter un mini-jeu démo de Warcraft à ETHCC.
Il est clair que les FOG/AW deviennent un écosystème clé dans la course entre blockchains. L’AW (monde autonome) proposé par Lattice est un concept vaste, allant au-delà du jeu pour inclure la socialisation, la finance, etc. Ce qui est construit dessus est donc un monde virtuel imaginaire, soit le Métavers. Nous pouvons attendre avec impatience de nouvelles formes d’applications combinant jeu, social et finance.
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
IOSG Ventures
