Analyse des défis auxquels est confronté le développement de jeux en ligne et effet réseau des moteurs de jeux Web3
TechFlow SélectionTechFlow Sélection
Analyse des défis auxquels est confronté le développement de jeux en ligne et effet réseau des moteurs de jeux Web3
Les différents moteurs s'efforcent actuellement d'améliorer le taux de tick et d'étendre leur réseau, dans le but de permettre aux blockchains de supporter des interactions de jeu plus complexes.
Dédié à des analyses Web3 approfondiesAuteur : Ishanee @IOSG Ventures
Résumé préliminaire :
Dans la première partie de notre série FOG, nous avons présenté un aperçu des jeux sur chaîne et des moteurs de jeu. Un grand merci à Sylve, Tarrence, Andy, Alvirus, Kevin & Iain pour leur soutien dans la rédaction de cet article.
Les jeux sur chaîne et leurs moteurs en sont encore au stade initial. Bien que des moteurs comme MUD et Dojo soient déjà utilisables pour le développement de produits, et qu'une communauté de développeurs s'y appuie déjà, il reste beaucoup de chemin à parcourir. Les moteurs de jeu bénéficient généralement d'effets de réseau importants, car de nombreux jeux reposent sur leur architecture et y ajoutent progressivement de nouvelles fonctionnalités.
Dans l'écosystème des jeux sur chaîne, les plus grands effets de réseau proviennent de la composable et de l'extensibilité des jeux, ainsi que de la capacité à combiner les actifs d'un jeu avec d'autres jeux basés sur le même écosystème et moteur. À mesure que des bibliothèques open source permettent aux développeurs de résoudre collectivement les problèmes techniques, la fidélité (stickiness) du moteur augmente exponentiellement.
Si nous imaginons l'évolution de l'écosystème des moteurs de jeu, leurs effets de réseau et couches d'accumulation de valeur pourraient ressembler à ce schéma. Le marché des modules/vérificateurs peut facilement être absorbé par la couche moteur, de manière similaire aux modules Gnosis Safe. Par défaut, la couche AW est composable, mais cela dépend du choix des développeurs de jeux et des joueurs quant au niveau de composable souhaité. De nombreuses entreprises tentent actuellement de capter deux niveaux ou plus dans cette pile technologique.
À présent, plongeons-nous dans les principaux défis du développement de jeux en ligne, et examinons comment les moteurs de jeu peuvent y répondre. Problématiques auxquelles sont confrontés les moteurs de jeu blockchain :
Encombrement du réseau
À chaque lancement de CryptoKitties, Axie Infinity ou Loot Realms, le réseau entier a été saturé. Comment ont-ils résolu ce problème ? En créant chacun leur propre chaîne : Flow, Ronin et Loot Chain. Les jeux sur chaîne nécessitent davantage de ressources informatiques, et tous ces jeux se disputent l'espace disponible dans les blocs. Ainsi, les équipes commerciales disposant de financements optent naturellement pour la création de leur propre couche L2 spécifique à l'application. Elles collaborent avec des fournisseurs de services Rollup (RaaS) tels que Caldera, Conduit, Eclipse ou Alt Layer. Actuellement, le framework L2 le plus populaire semble être OP Stack, bien que cela devrait évoluer avec la maturité d'autres technologies telles qu'Arbitrum Orbit, Starkware L3 ou ZkSync Hyperchains, désormais prêtes pour la production.
Nombre de requêtes ayant causé la saturation du réseau lors du lancement de CryptoKitties en décembre
Argus a également présenté son nouveau produit : une couche 2 EVM intégrant une couche de disponibilité des données. Il s'agit d'une shard de base (base shard). Nous n'avons pas encore plus de détails, mais cela rappelle fortement Momoka de Len. Cette couche EVM de base permettra à d'autres développeurs de jeux de construire des couches d'exécution hautement personnalisables (« game Shards »), tandis que la base Shard assurera la composable pour l'ensemble de la couche 2 Argus.
Basse vitesse de la blockchain
Sur une blockchain, l'état du contrat ne change qu'après confirmation de la transaction. Si vous souhaitez que f(a) déclenche f(b), ce processus doit attendre. Ainsi, la latence dans les jeux semble inévitable. Sur Ethereum, cela représente environ 15 secondes jusqu'à la résolution du bloc, puis 30 à 45 secondes supplémentaires pour éviter les risques de réorganisation.
Grâce à l'utilisation des « ticks », l'état d'un jeu peut changer automatiquement sans avoir à attendre la finalisation des transactions. La fréquence des ticks correspond à la cadence de mise à jour. Dans les MMO compétitifs, le taux de tick est généralement de 20 à 30 Hz, tandis que pour les RTS, il peut atteindre 60 Hz. Comme la majorité des développeurs travaillent aujourd'hui sur des MMO, une fréquence de 20 Hz est idéale. Le temps moyen de bloc sur les rollups est de 1 à 2 secondes (Momoka connectée à Polygon PoS toutes les 2 secondes), alors qu'Argus propose une nouvelle solution atteignant 20 ticks/seconde, la plus rapide du secteur à ce jour.
L'équipe de 0xCurio a été la première équipe commerciale à utiliser des L2 personnalisés (via Caldera) afin d'optimiser une fréquence de ticks plus élevée. Elle a déjà créé la première application de chaîne de ticks sur OP Stack, qui pourrait être lancée conjointement avec son jeu (treaty.earth).
Discussion en ligne sur la fréquence moyenne de ticks dans les jeux
L'expérience développeur doit encore être améliorée
Le moteur MUD est né du fait que l'équipe de Lattice rencontrait systématiquement les mêmes problèmes backend lors de la création de nouveaux jeux sur chaîne. Ils ont donc décidé de développer un cadre de développement universellement adoptable. Outre la composable, deux défis clés subsistent : synchroniser plus rapidement l'état entre contrats et clients joueurs, et permettre des mises à jour faciles (modification/mise à jour du contenu) sans avoir à réécrire l'indexeur à chaque fois (indexeur automatique).
Dans cet article, nous supposerons que toutes les applications construites sur un même cadre de moteur de jeu sont composable entre elles.
Présentation des moteurs de jeu
Cet article présente quatre projets concurrents pour devenir la référence des moteurs de jeu blockchain. Deux sont des biens publics, les deux autres sont développés par des équipes commerciales ayant levé des fonds. Examinons maintenant certaines questions avancées, ainsi que les solutions proposées par ces équipes.
MUD v2 :
MUD est le moteur de jeu le plus populaire, servant de base à plus de 95 % des jeux en ligne sur EVM. Le moteur de jeu de Lattice introduit « Store », une solution permettant de représenter les données sur chaîne de manière similaire à une base de données relationnelle. Comparé au stockage piloté par le compilateur, Store offre une meilleure upgradeabilité des données contractuelles et réduit massivement les coûts en gaz.
Les mises à jour d'état génèrent automatiquement des événements, permettant à l'indexeur automatique d'indexer tout l'état sans configuration personnalisée. Contrairement aux données statiques de Solidity, de nouvelles données (tables) peuvent être ajoutées à l'exécution, rendant le système upgradeable. Le coût de stockage est comparable à l'émission manuelle d'événements pour chaque état, mais MUD compresse les données plus efficacement que le Solidity natif, ce qui le rend moins cher à long terme.
Store : Une alternative au stockage piloté par le compilateur de Solidity. Stocker des données dans un contrat consomme du gaz, et en Solidity, ce stockage est statique et non inspectable, ce qui signifie que les interfaces/applications doivent supposer que leurs appels sont corrects. Grâce à la base de données sur chaîne de Store, le stockage des contrats peut désormais être indexé par des indexeurs hors chaîne, des interfaces ou d'autres contrats. Les avantages incluent l'upgradeabilité des données contractuelles et une réduction massive des coûts en gaz.
Mode : Un indexeur hors chaîne utilisant PostgresDB. Il peut indexer toute application MUD sur EVM, principalement utilisé pour une synchronisation d'état plus rapide avec le client MUD.
World : Un cadre incluant l'utilisation de Store, de systèmes, de création sans permission, de contrôle d'accès, de modules, etc. En résumé, le contrat World est un contrat unique regroupant état centralisé et logique contractuelle. Il peut être étendu grâce à des plugins sur chaîne et à un ensemble d'outils de développement améliorés. Chaque nouveau plugin MUD ajoute de la valeur au cadre et au moteur pour les développeurs suivants.
Quelques exemples :
-
Endless Quest : Génère des récits cohérents, metadata et art dans AW
-
MUDVRF : Module MUD générant des nombres aléatoires sur chaîne pour les jeux
-
DeFi Wonderland : Module de gestion de compte utilisant le wallet via un client burner
-
MUD Scan : Tableau de bord de classement pour les jeux MUD
Dojo Engine :
Dojo Engine est un moteur de jeu public développé par les créateurs de Starknet. C'est le seul moteur de jeu vérifiable, dont la vérifiabilité est conçue spécifiquement pour l'architecture et les outils du moteur.
Ici, la prouvabilité signifie que la même boucle de jeu peut être vérifiée aussi bien par le séquenceur du rollup que par un client local (comme un navigateur). Avec Dojo, les utilisateurs peuvent exécuter la logique de preuve côté client, et ne valider que la vérification sur chaîne, à très faible coût. Cela permet notamment des fonctionnalités anti-triche et des mises à jour optimistes : même si le séquenceur valide encore la transaction du joueur, la logique est déjà exécutée dans le navigateur du joueur.
Leur solution de stockage de données est similaire à Store de MUD, mais personnalisée pour les preuves de validité et la vérifiabilité. Ils utilisent Torii pour un indexage automatiquement vérifiable. L'indexation s'appuie sur les différences de stockage, offrant un index O(1), et prend en charge la vérifiabilité client de l'état global via des preuves de stockage. Dojo supporte le déploiement sur Starknet ainsi que sur des séquenceurs performants de niveau 3 comme Katana et Madara. Il fournit Katana (un réseau de développement local), Sozo (une interface en ligne de commande pour déployer, mettre à jour et interagir avec le jeu) et Torii (un indexeur vérifiable). Dojo propose un SDK Rust, compilable en WASM pour les navigateurs, utilisable dans des jeux basés sur Rust (ex : avec Bevy), ainsi que des liaisons pour Unity et Unreal (en cours de développement).
Les développeurs de jeux sont encouragés à écrire leurs applications en Cairo, un langage similaire à Rust, destiné à créer des programmes prouvables pour le calcul général. Un avantage de Dojo est de pouvoir implémenter nativement des mécanismes de « brouillard de guerre » grâce aux zkps, sans avoir à coder en Circom sur Solidity.
Argus Labs :
Argus Labs, fondé par Scott, cofondateur de Dark Forest, a récemment publié sa dernière (et unique) mise à jour. Ce projet ambitieux vise à devenir à la fois un studio de création de jeux, un moteur de jeu, et une infrastructure que d'autres développeurs peuvent étendre et déployer. Actuellement fermé, l'équipe promet de l'ouvrir au moment du lancement.
Comme décrit précédemment, il s'agit d'un L2 personnalisé doté d'une shard de base et de shards de jeu personnalisables. Associé à World Engine (moteur propriétaire), les développeurs peuvent créer des environnements d'exécution uniques avec des paramètres spécifiques (fréquence de ticks plus élevée, AA locale avec personnalisation du gaz, base de données ECS, compatibilité avec Unity, Unreal, JS, etc.). Ils offrent également un indexeur automatique similaire à ceux des autres moteurs. Argus optimise le L2 et le moteur World, rendant abstraite l'écriture en Solidity et encourageant le développement de jeux en Go. Bien que Go soit un excellent langage, il n'est traditionnellement pas privilégié car la plupart des moteurs et bibliothèques supportent C, C++ ou C#.
Scott a évoqué lors d'une récente conférence une proposition de valeur unique : des shards basés sur la géolocalisation (par exemple « serveur Asie », « serveur Europe »), pouvant réduire significativement la latence. Par exemple, la plupart des séquenceurs étant situés aux États-Unis, les joueurs asiatiques subissent souvent une latence minimale de 300 ms, durée importante dans un jeu. Toute l'architecture repose sur un séquenceur partagé optimisé pour la latence, plutôt que pour la composable atomique ou la synchronisation. Il n'utilise pas de verrous bloquant le runtime — supporte plusieurs shards sans blocage mutuel ni ordre total imposé.
Cardinal Shard est le premier shard de jeu mis en œuvre par l'entreprise, avec une fréquence de 20 ticks par seconde, comparable aux jeux traditionnels.
Keystone :
L'équipe Curio a été la première équipe commerciale à expérimenter un L2 personnalisé, collaborant finalement avec Caldera pour implémenter leur propre OP Stack. Ils intègrent la structure ECS dans leur chaîne de ticks, et proposeront des fonctionnalités telles qu'un indexeur automatique et un support client Unity. Il s'agit d'un projet de R&D, fruit de leurs efforts pour construire Treaty.earth. Plus d'informations seront probablement partagées lorsque l'équipe sera prête.
Autres initiatives :
Bien que ces quatre projets soient les plus avancés et connus dans l'écosystème EVM/Ethereum, d'autres moteurs personnalisés sont en cours de développement par des équipes comme Playmint, Solana (Arc by Jump Crypto), ou Topology, un autre pionnier des jeux en ligne ayant lancé Isaac sur Starknet via son moteur propriétaire, avec un nouveau jeu, Shoshin, bientôt disponible.
Conclusion :
Aujourd'hui, chaque moteur cherche à améliorer le taux de ticks et à étendre le réseau, dans le but de permettre des interactions de jeu plus complexes sur blockchain — cela me rappelle la concurrence entre équipements de jeux VR il y a quelques années : l'émergence de nouvelles technologies, une course effrénée autour de la bande passante des casques VR, une ruée des développeurs pour créer des versions VR/AR de tous types de jeux. Mais après validation par le marché, on s'est rendu compte que seuls certains genres étaient adaptés au VR, et que la bande passante n'était finalement pas si critique. De même, la victoire entre les moteurs full-chain sera le résultat d'une dynamique complexe, mais on peut anticiper qu'une fois le PMF atteint (avec un succès phare sur le moteur), l'avantage concurrentiel sera significatif.
Nous sommes enthousiastes face à l'évolution de chaque couche, à la sortie de nouveaux jeux et à l'apparition de nouveaux moteurs. À l'exception de MUD v2 et Dojo, les autres n'ont pas encore été testés à grande échelle. Avant de savoir quel moteur deviendra l'Unreal ou l'Unity du monde sur chaîne, le chemin sera encore long.
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
