Comment synchroniser "l'état" de toute la chaîne de jeu ?

Par Fiona, IOSG Ventures

TL;DR

• La chaîne complète de jeux/mondes autonomes (“FOG/AW”) est l’un des rares récits importants entourant le Web 3. Par rapport aux applications Web2.5 qui se connectent uniquement au Web3 via NFT, FOG/AW met la logique du jeu sur la chaîne. Il utilise la blockchain comme serveur de jeu, devenant une source de confiance décentralisée pour l’état du jeu. Cela apporte des avantages tels que la persistance, la résistance à la censure, la composabilité, etc., mais limite également la variété et la complexité des jeux construits dessus.
• Avec la complexité croissante et les exigences de jouabilité du jeu, davantage de défis sont proposés pour l’architecture du moteur : tels que le délai de trame, le nombre aléatoire, la récupération de santé, l’effet passif continu, la minuterie, etc. Le concept d’unités de temps et de ticks est différent sur la blockchain. La boue fournit de nombreuses idées pour simuler le passage du temps et les compétences de récupération passive. Par exemple, lorsque le joueur se déplace dans la pièce, la transaction consiste à déplacer tous les éléments de la pièce selon une conception prédéfinie. Utilisez-le pour percevoir les changements de temps et d’état.
• La pile technologique FOG/AW peut être résumée comme suit : les développeurs écrivent des codes frontaux et principaux pour l’interface utilisateur/ux et la logique de base du jeu, puis synchronisent tous les changements via la boucle d’état du jeu, et enfin reflètent le nouvel état sur le périphérique local frontal par l’indexeur.
• Étant donné que de nombreux types de jeux, tels que RTS, nécessitent des tickrates élevés et que les chaînes de blocs produites par consensus ne peuvent gérer que les changements de temps de bloc, le tickrate est un gros problème à résoudre ici. Curio et Argus sont des leaders à cet égard, et ils augmentent le tickrate du jeu au niveau de la chaîne d’échappés. Mud essaie de maximiser la chaîne complète et l’état entier de l’application est stocké dans l’EVM. Il n’est pas prévu d’introduire une intégration hors chaîne pour obtenir un tickrate plus élevé pour le jeu.
• Pour la sélection des différentes chaînes, Dojo dirige l’ensemble de l’écologie de la chaîne de Starknet. Selon la description de @ tarrenceva, Starknet a des différences d’état entre les différences d’état, qui sont différentes des cumuls optimistes et se concentrent sur la sortie d’exécution plutôt que sur l’entrée. L’impact sur les jeux est probablement principalement d’optimiser le coût, par exemple une partie d’échecs : dans une partie de trois minutes, 50 coups peuvent se produire. Grâce aux différences d’état, une seule preuve et un état final peuvent prouver la “sortie”. Les cumuls optimistes, en revanche, nécessitent des “entrées” de tous les états intermédiaires.

Définir FOG/AW : comment l’état du jeu est synchronisé

Je pense que pour juger s’il s’agit de FOG, la référence est la façon dont l’état du jeu est synchronisé (source de vérité).

Pour les jeux Web 2.5 ou les jeux multijoueurs traditionnels, il existe un serveur centralisé qui définit l’état actuel du jeu, et lorsque les joueurs envoient des actions, le serveur compile ces entrées et renvoie des résultats mis à jour à l’appareil de chaque joueur connecté. Le serveur gère toutes les entrées (ticks), résout les incohérences et envoie périodiquement des mises à jour au joueur, fournissant un instantané de tous les éléments du jeu, mettant à jour l’état du jeu à chaque tick. L’**état du jeu (“état du jeu ou tick”) est un instantané dans le temps des propriétés de chaque objet dans le monde du jeu. Tickrate est le nombre de fois par seconde que le serveur de jeu calcule et diffuse l’état du jeu mis à jour aux joueurs. Plus le Tickrate est élevé, plus l’expérience de jeu sera précise et fidèle. En général, les jeux de stratégie ou d’action en temps réel exigent beaucoup. tickrate, contrairement aux jeux au tour par tour tels que les jeux de cartes.

Source:

Pour les jeux qui fonctionnent entièrement en chaîne, la blockchain est le serveur de jeu et agit comme une source de confiance décentralisée pour l’état du jeu. Dans ce cas, non seulement les NFT ou les jetons ont une propriété réelle, mais même les ticks et la logique de jeu du joueur sont en chaîne. C’est pourquoi la véritable propriété, la persistance, la résistance à la censure, la composabilité, etc. sont possibles. Idéalement, chaque action d’un joueur devrait être soumise à la blockchain, et une fois qu’un consensus est atteint, l’état du jeu est mis à jour et renvoyé à l’appareil local. Ainsi, naturellement, les types de jeux qui nécessitent moins de tickrate sont mieux adaptés pour être joués entièrement en chaîne.

** Résolvez les défis du retard de jeu, du temps, etc. **

Avec l’augmentation de la complexité du jeu et des exigences de jouabilité, davantage de défis sont posés pour l’architecture du moteur : tels que le délai de trame, les nombres aléatoires, la récupération de vie, les effets passifs continus, les minuteries, etc.

Retard du nombre de trames En fait, il est également très courant dans le monde Web2, y compris les retards dans le rendu du client et les opérations de l’utilisateur. Surtout pour les jeux à cadence élevée comme les FPS, une fois qu’il y a un retard, l’expérience du joueur sera très médiocre.L’une des solutions de Web2 est la mise à jour de l’état du verrouillage, qui permet à tous les joueurs d’être synchronisés selon la norme de retard la plus élevée parmi les joueurs, afin de résoudre l’expérience équitable du joueur. Ce retard peut être encore pire lorsque la blockchain est introduite et que les transactions doivent être confirmées. À cette fin, Mud ajoute également le mécanisme de rendu optimiste couramment utilisé dans les jeux, en supposant que l’opération de l’utilisateur est réussie, et la rend dans le client avant que le serveur n’accepte (ou dans ce cas, avant que la transaction ne soit confirmée).

La génération de nombres aléatoires sur la chaîne est un sujet souvent abordé. Mud pense que le comportement de l’utilisateur peut être utilisé comme entrée de résultats aléatoires, qui peuvent être générés après l’interaction.

Le concept d’unités de temps et de ticks est différent sur la blockchain. @SebastienGllmt pense qu’il est difficile d’utiliser des minuteries sur des chaînes qui utilisent des concepts anti-fraude (comme Op), car une fois que quelque chose ne va pas, il faudra l’annuler. Si des minuteries sont utilisées dans le jeu, l’expérience sera médiocre. La boue fournit de nombreuses idées pour simuler le passage du temps et les compétences de récupération passive. Par exemple, en augmentant les pièces d’or au fil du temps, chaque fois que le joueur effectue une opération qui nécessite des pièces d’or, calculez la quantité de pièces d’or du joueur en fonction du nombre de pièces d’or précédent du joueur, du dernier nombre de rafraîchissements et du taux de rafraîchissement. Pour un autre exemple, lorsque le joueur se déplace dans la pièce, la transaction consiste à déplacer tous les éléments de la pièce selon une conception prédéfinie. Utilisez-le pour percevoir les changements de temps et d’état.

** Écrire des scripts pour “tricher” peut ne pas être un problème. **@BriefKandle ne pense pas que le MEV du système de jeu est une tricherie. Empêcher le MEV avec des scripts simples est quelque chose que l’équipe du jeu doit prendre en compte. Le développement de jeux Web2 doit changer la façon de penser. Un bon bot MEV est un PNJ dans le jeu.

Certaines de ces fonctionnalités ont été implémentées dans certains jeux en chaîne récemment lancés, tels que Rhascau, où ils utilisent des minuteries et des effets passifs continus. Fondamentalement, en utilisant le temps de bloc comme une coche. (Dans la L2 actuelle, temps de bloc = tickrate).

Pile technologique FOG/AW

Le framework de moteur FOG/AW est une pile d’outils de développement qui permet aux développeurs de créer des jeux en utilisant la blockchain comme serveur et source de confiance. De plus, cela peut résoudre certains problèmes actuels :

• Inefficacité dans la construction de FOG/AW en chaîne en raison du manque de cadre standard/prêt à l’emploi ;
• Manque de modularité et de réutilisation du code ;
• Manque de composabilité. Avec le développement du moteur FOG/AW, les jeux en chaîne peuvent être plus intéressants et imaginatifs.

Pour faciliter la compréhension, le processus technique généralement simplifié de ce type de moteur est le suivant : les développeurs écrivent des codes frontaux et principaux pour l’interface utilisateur/ux et la logique de base du jeu, puis synchronisent toutes les modifications via la boucle de l’état du jeu, et enfin reflètent le nouvel état sur le périphérique local frontal par l’indexeur.

Afin de faire fonctionner correctement les jeux fonctionnant sur la blockchain, Mud, Dojo, Curio, Argus, le moteur Paima et Lootchain développent leurs propres piles technologiques à cette fin. La pile technologique se compose de 3 éléments clés : la chaîne, la pile de développement de base et le front-end du jeu. Ils ont tous leurs propres innovations, faisant des compromis entre la décentralisation et la complexité du jeu.

• Interface de jeu : Contient des moteurs traditionnels tels que Unity, Unreal, etc., ainsi que react/Threejs et d’autres langages, ainsi que des outils puissants pour fournir le rendu et d’autres fonctions, ce qui est indispensable pour améliorer la jouabilité et l’expérience du jeu. Les projets ci-dessus peuvent essentiellement fournir des SDK pertinents aux développeurs.
• Pile de développement de base : concevez un ensemble de solutions pour permettre à la logique du jeu de s’exécuter sur la blockchain et de se synchroniser avec le front-end à temps. Les composants clés incluent une structure de base de données appropriée (définissant le comportement et la logique du jeu), ainsi que la synchronisation et le retour de l’état du jeu.
• Chaîne : la plupart d’entre eux choisissent de s’appuyer sur Ethereum, Optimism et Starknet.

La figure ci-dessous montre comment différents protocoles conçoivent leurs piles technologiques respectives. Prenez Mud V2 comme exemple pour voir son flux de fonctionnement :

1. Un développeur appellera certains outils frontaux Web2 dans Mud pour écrire du code et utilisera ces fonctions puissantes telles que le rendu pour rendre le jeu plus visuel et plus amusant ;
2. Dans le même temps, les développeurs écriront les personnages, les objets et la logique de fonctionnement spécifique du jeu conformément au cadre de contrat intelligent de Mud (Mud World), par exemple lorsque le héros A se déplace de X à Y et lance une croisade contre le terrain Y, quelle probabilité ou dans quelles circonstances le terrain peut-il être occupé avec succès ;
3. Les actions ci-dessus et l’état du jeu seront enregistrés dans Mud Store, qui est une base de données en chaîne responsable de l’état global du jeu et une source de confiance pour la synchronisation de l’état du jeu ;
4. Lorsque le héros A attaque Y, le joueur clique sur la souris sur la machine locale frontale et soumet la commande à télécharger sur la chaîne. La commande est basée sur la logique de conception du jeu du développeur et l’état actuel du jeu dans le magasin, ce qui donne un résultat. Le résultat est mis à jour avec le nouvel état global du jeu et synchronisé avec la chaîne ;
5. Games on Mud prend en charge divers frontaux tels que Web et Mobile, mais peut être confronté à des exigences d’indexation complexes. Mode est un indexeur hors chaîne développé à cet effet.

Parlons maintenant des conceptions communes et différentes de ces cadres de base.

• La plupart d’entre eux suivent la conception Mud v1 et utilisent ECS comme structure de données pour le développement de jeux. C’est ainsi que la logique du jeu est écrite et présentée. Mud V2 l’a amélioré et les données sont définies dans des tables et des s, ce qui permet d’autres normes de données (il n’est pas nécessaire de se conformer à la norme de modélisation de données ECS comme V1), ce qui donne aux développeurs plus de choix et les rend plus inclusifs.
• La plupart utilisent des bases de données décentralisées, car la blockchain est naturellement la source de confiance pour l’état du jeu et la base de données. Mud essaie de maximiser la chaîne complète et l’état entier de l’application est stocké dans l’EVM. Il n’y a aucun sacrifice de décentralisation ou d’introduction de schémas d’intégration hors chaîne pour obtenir un tickrate plus élevé pour le jeu.
• Étant donné que de nombreux types de jeux, tels que les FPS, nécessitent des tickrates élevés et que les chaînes de blocs produites par consensus ne peuvent gérer que les changements de temps de bloc, le tickrate est un gros problème à résoudre ici. Dans leurs conceptions innovantes, Curio et Argus sont les premiers à espérer augmenter les tickrates au niveau de la chaîne.
• Pour la sélection des différentes chaînes, Curio et Loot utilisent Caldera pour créer des chaînes de pile Op. De plus, Dojo dirige l’ensemble de l’écologie de la chaîne de Starknet. Selon la description de @ tarrenceva, Starknet a des différences d’état entre les états, qui sont différentes des cumuls optimistes et se concentrent sur la sortie d’exécution plutôt que sur l’entrée. L’impact sur les jeux est probablement principalement d’optimiser le coût, par exemple une partie d’échecs : dans une partie de trois minutes, 50 coups peuvent se produire. Grâce aux différences d’état, une seule preuve et un état final peuvent prouver la “sortie”. Les cumuls optimistes, en revanche, nécessitent des “entrées” de tous les états intermédiaires.

Il existe déjà des jeux construits sur ces moteurs. Mud et Dojo organisent des hackathons pour inciter les développeurs à créer des applications. Curio vient de publier la démo du mini-jeu de Warcraft à l’ETHCC.

Évidemment, FOG/AW devient une écologie clé pour la concurrence des chaînes publiques.L’AW (Autonomous World) proposé par Lattice est un grand concept, qui ne se limite pas aux jeux, mais comprend également de nombreux attributs tels que sociaux et financiers. Ainsi, construit en plus de cela se trouve un monde virtuel imaginatif, le Metaverse. Nous pouvons nous attendre à de nouvelles formes d’applications intégrées telles que les jeux, les réseaux sociaux et la finance.

Référence: