Intervenants : Andrea, Gabriele, Co-Fondateur de Magicblock
演讲标题 :UN FRAMEWORK POUR LES JEUX ON-CHAIN
Préface du traducteur : « BOLT est un moteur de jeu full-chain développé par l’équipe Magicblock pour l’écosystème Solana. Cet article est compilé à partir des présentations des deux fondateurs de Magicblock lors de l’événement Breakpoint 2023. "
Bonjour à tous, c’est le dernier discours avant Halloween, et j’espère que le contenu du discours intéressera tout le monde. Je m’appelle Andrea et je suis ma co-fondatrice, Gabriele. Aujourd’hui, nous allons introduire un nouveau framework de jeu (moteur) à chaîne complète.
01.Pourquoi avez-vous besoin d’un jeu à chaîne complète
Je vais commencer par les bases, c’est pourquoi je vais m’embêter à construire un jeu à chaîne complète avec à la fois un état et une logique sur la chaîne, et à gérer toutes les complexités qui l’accompagnent. La raison simple est d’obtenir des fonctionnalités que l’infrastructure de jeu traditionnelle n’a pas.
La première fonctionnalité est celle des mods sans permission. Cela signifie que tous les joueurs et développeurs peuvent personnaliser n’importe quel composant du jeu, y compris l’introduction de plugins ou de mods, à partir du client avancé. Même la logique sous-jacente du jeu peut être étendue par le biais de contrats intelligents. Essentiellement, il s’agit d’un nouveau mode où chaque jeu est une nouvelle plate-forme par défaut, et vous pouvez devenir une centrale de contenu, quelle que soit la taille de votre équipe.
La deuxième caractéristique est la persistance. Les mondes autonomes et le fait que ces expériences virtuelles puissent exister à l’infini ont eu beaucoup de répercussions. Parce qu’aucun serveur ne peut être censuré ou fermé, ces expériences introduisent en fait une toute nouvelle signification. Les jeux sont devenus une plate-forme permettant aux joueurs de jouer, de socialiser et de faire du commerce mondial, ce qui est plus universel que les plateformes de jeux traditionnelles.
La dernière caractéristique est l’ouverture des économies. Les jeux peuvent tirer parti du système de paiement mondial ouvert et sans friction de la blockchain, en particulier les micropaiements dans notre écosystème, et réutiliser l’infrastructure on-chain existante telle que les DEX ou les places de marché NFT.
02.Solution existante
Le problème actuel avec les jeux omnichain est que l’expérience de développement est très mauvaise, et nous regardons les solutions sur le marché et constatons qu’il existe des frameworks de développement qui tentent de simplifier l’expérience du développeur.
Certains d’entre eux sont très intéressants en ce sens qu’ils essaient d’itérer sur des sessions prouvables, où vous pouvez effectuer des calculs hors chaîne et prouver l’intégrité des calculs sur la chaîne. Vous pouvez également introduire un environnement d’exécution piloté par les événements qui convient mieux aux moteurs de jeu de la blockchain, plutôt qu’un environnement d’exécution basé sur des boucles.
Mais tous ces frameworks nécessitent des compromis entre les performances et la composabilité pour obtenir des performances plus élevées et un TPS plus élevé. En règle générale, vous allez soit créer un isolement, soit introduire un environnement d’exécution différent avec des partitions.
Mais nous ne sommes pas satisfaits de ce compromis. Nous nous sommes demandé s’il existait un cadre qui pourrait prendre en charge le TPS dont nous avions besoin. Lorsque votre jeu a du succès, vous n’avez pas à sacrifier leur expérience utilisateur, même avec des millions de joueurs, car les guerres du gaz n’auront pas lieu. Et le framework ne nécessite pas de partitionnement et de fragmentation, vous pouvez donc utiliser des sessions de jeu prouvables et même simuler le passage du temps sans payer de frais de gaz. Il n’est pas du tout nécessaire de fragmenter le système ou d’utiliser la couche 3.
03.Moteur de développement de jeux en chaîne complète sur Solana : BOLT
C’est pourquoi nous sommes ravis de vous présenter BOLT, un framework de développement de jeux haute performance, composable et basé sur SVM.
BOLT est modulaire et composable, ce qui lui permet d’utiliser toute l’infrastructure existante sur Solana. Il travaille avec nos installations on-chain existantes telles que l’identité on-chain, l’API sans gaz, la clé de session, ainsi qu’avec le cadre de développement Anchor existant et tous les programmes existants sur Solana. Les deux peuvent évoluer à un ordre de grandeur plus élevé grâce aux cumuls éphémères, qui sont des sessions de jeu qui s’ouvrent et se ferment selon les demandes de l’utilisateur, et mises à l’échelle selon les besoins.
BOLT est rapide comme l’éclair, et nous pouvons atteindre le même niveau de performance qu’un moteur de jeu traditionnel avant d’utiliser ces environnements d’exécution dédiés pour accélérer certaines opérations.
Il s’agit d’un affichage panoramique du cadre BOLT. Il est évidemment conçu pour Solana, mais il peut l’utiliser sur n’importe quelle plate-forme compatible avec la SVM, telle que la couche 2 compatible avec la SVM. BOLT a deux objectifs principaux, la composabilité et l’évolutivité.
Le système ECS (Entity Component) est l’un des moyens par lesquels nous simplifions l’utilisation des composants on-chain. L’autre est le cumul éphémère, qui a été brièvement mentionné plus tôt, et je vais me plonger dans ces deux technologies dans un instant.
BOLT a été intégré aux moteurs de jeu hérités les plus couramment utilisés, tels que Unity, qui servent souvent de front-end aux jeux. Bien sûr, cela inclut également d’autres moteurs de jeu open-source et appréciés tels que Godot et Phaser. Nous travaillons même avec un client de jeu mis à jour, Turbo, qui se concentre sur l’amélioration de l’expérience des développeurs indépendants et la facilitation de la création rapide de jeux. Il y aura peut-être d’autres partenaires à l’avenir.
Je vais commencer ici et continuer à expliquer pourquoi nous avons besoin d’un système de composants d’entité ECS. La réponse est simple, car il permet une composabilité maximale, ce qui signifie que nous pouvons créer et réutiliser des composants prêts à l’emploi.
Comme son nom l’indique, ECS est construit en trois éléments principaux : les entités, qui sont essentiellement des identifiants enregistrés dans une instance distincte du monde du jeu, les composants, qui définissent la structure de données de sorte qu’ils sont essentiellement les données associées à l’entité, et enfin le système, qui est la logique qui manipule les composants attachés à l’entité.
L’avantage de cette architecture est que tous les systèmes et composants sont réutilisables. Ils peuvent être publiés dans un registre public, et les développeurs peuvent facilement contribuer, construire, découvrir et intégrer n’importe quel type de composant, de sorte que vous n’avez plus besoin d’écrire une seule ligne de code à partir de zéro, mais que vous pouvez réutiliser tous les composants existants et éventuellement y contribuer. Par exemple, nous pouvons avoir une structure de données de grille (comme un labyrinthe ou un champ de bataille), un système mobile ou un système de preuve à divulgation nulle de connaissance pour le brouillard de guerre.
04.Pratique de programmation ECS du moteur BOLT
(Note du traducteur : cette partie est recommandée aux développeurs pour regarder la vidéo originale, les non-développeurs peuvent ignorer cette partie)
MAINTENANT, JE VAIS PASSER À MON IDE ET VOUS MONTRER UN EXEMPLE DE JEU SIMPLE UTILISANT LE MOTEUR BOLT ECS.
Nous allons définir plusieurs entités, un composant d’emplacement et deux systèmes qui manipuleront et modifieront les données de ce composant d’emplacement. Ainsi, le premier point d’entrée est d’interagir avec le Programme Mondial. Le programme mondial fait partie du framework BOLT et expose certaines extractions qui vous permettent d’enregistrer de nouvelles instances mondiales.
Vous pouvez ajouter des entités à votre instance mondiale et vous pouvez enregistrer des composants avec les entités que vous venez de définir, qui sont essentiellement définies par le programme de composant. Le programme du composant contient deux directives, dont la première est initialiser, créer et allouer de l’espace pour stocker les lignes de données qui seront utilisées dans votre composant. Dans cet exemple simple, nous définissons un composant de localisation, et si nous regardons le contexte de la directive d’initialisation, nous pouvons voir que nous avons des données de composant, et que les données de composant définissent simplement une structure avec des coordonnées XYZ qui peut stocker par exemple l’emplacement du joueur.
Maintenant, la deuxième directive est probablement la plus intéressante, c’est un point d’entrée qui nous permet d’exécuter n’importe quelle logique. Il recevra nos composants et nos systèmes arbitraires en entrée, et exécutera la logique définie en interne dans le système en exécutant sur plusieurs sites de programmation. Maintenant, si vous regardez à la ligne 15, nous avons notre appel CPI (Common Programming Interface), qui exécutera la logique définie en interne via le CPI. Il effectuera tous les calculs définis par le système, puis retournera à notre emplacement, où le programme du composant le récupérera et le réinitialisera dans nos données.
Maintenant, essayons de regarder le contexte de notre fonction apply, où nous pouvons voir que nous n’avons fondamentalement que deux comptes. Le premier est le compte qui contient les données de nos composants, et le second est le programme système. Par conséquent, un programme système est désormais une interface plutôt qu’un programme unique. Par conséquent, tout programme qui adhère à l’interface de notre système BOLT peut être exécuté via cette application.
05.Importance du système ECS
Essentiellement, cela change la façon dont vous concevez la logique de votre jeu et bouleverse les processus traditionnels. Auparavant, si vous vouliez créer ou encapsuler une logique dans votre programme, vous ajoutiez généralement d’abord des fonctionnalités, chacune d’entre elles étant une directive dans le programme, puis finalement, à un moment donné, vous verrouilliez le programme de jeu que vous développiez.
Avec le modèle ECS, cependant, nous pouvons avoir un programme immuable dès le départ, puis avec ce mécanisme de proxy, nous pouvons ajouter un système construit en interne ou par n’importe qui, de sorte que nous pouvons avoir un jeu qui peut fonctionner éternellement, qui est évolutif et qui peut vraiment changer la logique du jeu.
Ils peuvent déployer de nouveaux systèmes qui fonctionneront sur ces composants. Maintenant, l’interface vous permet également d’effectuer quelques vérifications, afin que nous puissions concevoir une mécanique de jeu qui permet d’ajouter sans permission de nouveaux systèmes pouvant modifier les données des composants.
Ou nous pouvons mettre en place une interface pour vérifier si le système permet l’exécution sur le composant. Par exemple, vous pouvez concevoir un système de gouvernance où si quelqu’un propose une nouvelle logique, et que cette logique est approuvée, alors tous les joueurs peuvent utiliser cette logique dans le jeu.
Cela peut même conduire à une bifurcation dans le monde du jeu (le contrat mondial). Dans un monde, vous possédez le système de vol. Et dans un autre monde, si le système n’est pas approuvé, il est possible d’avoir des règles différentes et chacun pourra toujours contribuer à sa propre version du monde.
Voyons maintenant comment construire un système capable de modifier ce composant. Le système n’est essentiellement qu’un programme sur Solana qui définit une instruction d’exécution, et l’instruction d’exécution est celle que nous appelons à partir du programme composant dans l’interface de programmation commune (CPI). Ici, il encapsule simplement une logique très simple dans laquelle il reçoit la direction d’entrée, calcule le delta, puis modifie les positions X et Y du composant.
Jetons donc un coup d’œil à un autre système qui pourrait être déployé par quelqu’un d’autre, même après la sortie du jeu. Voici un autre exemple d’un système qui implémente ute. Ici, la position Z est augmentée de 1, donc quelqu’un essaie d’ajouter un système de contournement, qui pourrait être une interface avec une couche différente au-dessus de votre jeu.
Donc, l’idée maintenant est que tous ces systèmes, tous ces composants sont vraiment composables, les utilisateurs du jeu ne sont plus de simples utilisateurs, le jeu est devenu une plate-forme ouverte, évolutive et persistante. Je vais donc essayer d’exécuter les tests unitaires que j’ai préparés dans cet exemple, et je vais utiliser l’interface de ligne de commande BOLT, qui est construite sur Anchor, un cadre de contrat intelligent pour Solana, donc si vous êtes déjà familier avec Solana, vous n’avez pas besoin d’apprendre quoi que ce soit de nouveau.
Maintenant, vous pouvez développer des programmes sur Solana, il suffit de développer des programmes, des programmes de test, donc ici j’exécute bolt build et bolt test, et ici je déploie notre programme, puis je fais le test de type que j’ai préparé ici.
Donc, ici, le test envoie une transaction pour initialiser un nouveau monde. Nous enregistrons quelques entités, nous attachons des composants de localisation à certaines d’entre elles, et peut-être que la partie intéressante est de créer des systèmes ici. Donc, ici, nous appelons la fonction apply, puis nous utilisons l’un de ces systèmes. Donc, voici juste un système par défaut.
Ici, nous appelons un mouvement simple, puis nous volons un mouvement ici. Eh bien, maintenant, si nous regardons les logs du test, dans le premier trade, nous utilisons ici un système de déplacement avec une direction ascendante, augmentant la position Y de 1. Dans la deuxième transaction, nous utilisons le même système pour nous déplacer vers la droite, puis enfin, nous exécutons le système de vol, qui fait le contraire, en augmentant notre position Z de 1. Ce n’est qu’un exemple simple, mais il offre une mécanique très puissante qui permet à quiconque de développer, d’étendre et potentiellement de rendre votre jeu amusant.
06.Cumul éphémère
Maintenant que nous allons revenir à la diapositive, je vais décrire le deuxième aspect intéressant du framework BOLT, qui est notre solution d’évolutivité, que nous appelons le cumul éphémère.
Il est généralement admis que Solana est déjà très rapide et bon marché, et qu’il génère actuellement un bloc toutes les 400 millisecondes et peut traiter des milliers de transactions, il est donc en fait prêt à construire un jeu à chaîne complète. Cependant, si vous avez une ancienne chaîne logique pour le multijoueur, les mises à jour de l’emplacement seront trop lentes.
Nous pouvons donc construire une couche d’accélération de courte durée qui est entièrement compatible avec la durée d’exécution de Solana. Le temps utilisé est facultatif, il peut servir d’accélération réelle d’une opération particulière, alors que la majeure partie de la logique est toujours exécutée sur la chaîne principale, il s’appuie donc sur la fonctionnalité que tout l’état sur Solana est stocké dans le compte.
Normalement, vous aurez un programme de jeu qui définit la logique, puis tout l’état sera stocké dans ce compte, de sorte que nous pouvons déléguer certains de ces comptes à cette couche éphémère qui utilise le moteur BOLT.
Dans cet exemple, il existe deux comptes autorisés qui stockent l’emplacement du lecteur, et le fournisseur écoute activement les demandes de délégation et les demandes d’approvisionnement. Il va démarrer un nouveau temps d’exécution selon les besoins, qui est rapide, personnalisable, ne peut pas avoir de transactions de gaz ou de ticks, et nous permet vraiment d’effectuer des transactions inférieures à 50 ms, et peut-être d’évoluer en ayant plusieurs environnements d’exécution dédiés.
Maintenant, l’autre partie intéressante est que toute cette complexité peut être abstraite de l’utilisateur. Nous avons un routeur RPC, qui est essentiellement similaire à un routeur RPC traditionnel. Le client RPC peut interagir directement avec le RPC pour envoyer des transactions. Étant donné que sur Solana, toutes les transactions sont prédéclarées pour tous les comptes mutables et lisibles, les routeurs RPC peuvent essentiellement acheminer les transactions, les requêtes de données et la récupération vers le bon niveau.
Puis à un moment donné, la couche éphémère (comme son nom l’indique) sera fermée et tous les états seront réglés dans la couche de base Solana, qui est sous la responsabilité du séquenceur, qui garde une trace de tous les comptes.
Une autre façon de voir ce mécanisme est que nous avons deux couches, et qu’elles exécutent des transactions en parallèle. Nous avons délégué des comptes qui nous permettent de mettre à jour avec une latence plus faible sans utiliser le débit de la chaîne principale. Et puis nous avons d’autres comptes, qui ne sont pas délégués, et qui sont exécutés sur la chaîne principale.
Ce qui est très intéressant, c’est que les programmes, les outils, les cadres et l’infrastructure sont tous sur la chaîne principale. Vous n’avez pas besoin de déployer votre programme dans Rollup, bien que cela soit courant dans de nombreuses autres architectures. Tout est sur la même couche, tout est composable, et comme nous l’avons mentionné, ce runtime spécialisé est également extensible et peut être vraiment personnalisé.
Maintenant, cela débloque une toute nouvelle catégorie de jeux, qu’il construit sur la blockchain et qui est à faible latence. Tout comme vous le feriez avec un serveur multijoueur traditionnel, mais toujours capable de se combiner avec tout ce qui est disponible sur l’écosystème de la couche 1.
Vous avez accès aux liquidités existantes, vous pouvez envoyer des messages via des protocoles, créer des NFT, utiliser des abstractions de compte, des clés de session, des classements et un écosystème unifié, tout le monde enrichit le même écosystème.
Merci beaucoup de m’avoir écouté. Vous pouvez vous inscrire pour un accès anticipé à notre framework à l’aide de codes QR et consulter le référentiel. Vous pouvez d’ores et déjà trouver une documentation solide et des livres blancs qui décrivent en détail le cadre que nous venons d’introduire. Merci beaucoup.
Voir l'original
Cette page peut inclure du contenu de tiers fourni à des fins d'information uniquement. Gate ne garantit ni l'exactitude ni la validité de ces contenus, n’endosse pas les opinions exprimées, et ne fournit aucun conseil financier ou professionnel à travers ces informations. Voir la section Avertissement pour plus de détails.
BOLT : Moteur de jeu ECS à chaîne complète basé sur Solana
Liens vidéo :
Intervenants : Andrea, Gabriele, Co-Fondateur de Magicblock
演讲标题 :UN FRAMEWORK POUR LES JEUX ON-CHAIN
Préface du traducteur : « BOLT est un moteur de jeu full-chain développé par l’équipe Magicblock pour l’écosystème Solana. Cet article est compilé à partir des présentations des deux fondateurs de Magicblock lors de l’événement Breakpoint 2023. "
Bonjour à tous, c’est le dernier discours avant Halloween, et j’espère que le contenu du discours intéressera tout le monde. Je m’appelle Andrea et je suis ma co-fondatrice, Gabriele. Aujourd’hui, nous allons introduire un nouveau framework de jeu (moteur) à chaîne complète.
01.Pourquoi avez-vous besoin d’un jeu à chaîne complète
Je vais commencer par les bases, c’est pourquoi je vais m’embêter à construire un jeu à chaîne complète avec à la fois un état et une logique sur la chaîne, et à gérer toutes les complexités qui l’accompagnent. La raison simple est d’obtenir des fonctionnalités que l’infrastructure de jeu traditionnelle n’a pas.
La première fonctionnalité est celle des mods sans permission. Cela signifie que tous les joueurs et développeurs peuvent personnaliser n’importe quel composant du jeu, y compris l’introduction de plugins ou de mods, à partir du client avancé. Même la logique sous-jacente du jeu peut être étendue par le biais de contrats intelligents. Essentiellement, il s’agit d’un nouveau mode où chaque jeu est une nouvelle plate-forme par défaut, et vous pouvez devenir une centrale de contenu, quelle que soit la taille de votre équipe.
La deuxième caractéristique est la persistance. Les mondes autonomes et le fait que ces expériences virtuelles puissent exister à l’infini ont eu beaucoup de répercussions. Parce qu’aucun serveur ne peut être censuré ou fermé, ces expériences introduisent en fait une toute nouvelle signification. Les jeux sont devenus une plate-forme permettant aux joueurs de jouer, de socialiser et de faire du commerce mondial, ce qui est plus universel que les plateformes de jeux traditionnelles.
La dernière caractéristique est l’ouverture des économies. Les jeux peuvent tirer parti du système de paiement mondial ouvert et sans friction de la blockchain, en particulier les micropaiements dans notre écosystème, et réutiliser l’infrastructure on-chain existante telle que les DEX ou les places de marché NFT.
02.Solution existante
Le problème actuel avec les jeux omnichain est que l’expérience de développement est très mauvaise, et nous regardons les solutions sur le marché et constatons qu’il existe des frameworks de développement qui tentent de simplifier l’expérience du développeur.
Certains d’entre eux sont très intéressants en ce sens qu’ils essaient d’itérer sur des sessions prouvables, où vous pouvez effectuer des calculs hors chaîne et prouver l’intégrité des calculs sur la chaîne. Vous pouvez également introduire un environnement d’exécution piloté par les événements qui convient mieux aux moteurs de jeu de la blockchain, plutôt qu’un environnement d’exécution basé sur des boucles.
Mais tous ces frameworks nécessitent des compromis entre les performances et la composabilité pour obtenir des performances plus élevées et un TPS plus élevé. En règle générale, vous allez soit créer un isolement, soit introduire un environnement d’exécution différent avec des partitions.
Mais nous ne sommes pas satisfaits de ce compromis. Nous nous sommes demandé s’il existait un cadre qui pourrait prendre en charge le TPS dont nous avions besoin. Lorsque votre jeu a du succès, vous n’avez pas à sacrifier leur expérience utilisateur, même avec des millions de joueurs, car les guerres du gaz n’auront pas lieu. Et le framework ne nécessite pas de partitionnement et de fragmentation, vous pouvez donc utiliser des sessions de jeu prouvables et même simuler le passage du temps sans payer de frais de gaz. Il n’est pas du tout nécessaire de fragmenter le système ou d’utiliser la couche 3.
03.Moteur de développement de jeux en chaîne complète sur Solana : BOLT
C’est pourquoi nous sommes ravis de vous présenter BOLT, un framework de développement de jeux haute performance, composable et basé sur SVM.
BOLT est modulaire et composable, ce qui lui permet d’utiliser toute l’infrastructure existante sur Solana. Il travaille avec nos installations on-chain existantes telles que l’identité on-chain, l’API sans gaz, la clé de session, ainsi qu’avec le cadre de développement Anchor existant et tous les programmes existants sur Solana. Les deux peuvent évoluer à un ordre de grandeur plus élevé grâce aux cumuls éphémères, qui sont des sessions de jeu qui s’ouvrent et se ferment selon les demandes de l’utilisateur, et mises à l’échelle selon les besoins.
BOLT est rapide comme l’éclair, et nous pouvons atteindre le même niveau de performance qu’un moteur de jeu traditionnel avant d’utiliser ces environnements d’exécution dédiés pour accélérer certaines opérations.
Il s’agit d’un affichage panoramique du cadre BOLT. Il est évidemment conçu pour Solana, mais il peut l’utiliser sur n’importe quelle plate-forme compatible avec la SVM, telle que la couche 2 compatible avec la SVM. BOLT a deux objectifs principaux, la composabilité et l’évolutivité.
Le système ECS (Entity Component) est l’un des moyens par lesquels nous simplifions l’utilisation des composants on-chain. L’autre est le cumul éphémère, qui a été brièvement mentionné plus tôt, et je vais me plonger dans ces deux technologies dans un instant.
BOLT a été intégré aux moteurs de jeu hérités les plus couramment utilisés, tels que Unity, qui servent souvent de front-end aux jeux. Bien sûr, cela inclut également d’autres moteurs de jeu open-source et appréciés tels que Godot et Phaser. Nous travaillons même avec un client de jeu mis à jour, Turbo, qui se concentre sur l’amélioration de l’expérience des développeurs indépendants et la facilitation de la création rapide de jeux. Il y aura peut-être d’autres partenaires à l’avenir.
Je vais commencer ici et continuer à expliquer pourquoi nous avons besoin d’un système de composants d’entité ECS. La réponse est simple, car il permet une composabilité maximale, ce qui signifie que nous pouvons créer et réutiliser des composants prêts à l’emploi.
Comme son nom l’indique, ECS est construit en trois éléments principaux : les entités, qui sont essentiellement des identifiants enregistrés dans une instance distincte du monde du jeu, les composants, qui définissent la structure de données de sorte qu’ils sont essentiellement les données associées à l’entité, et enfin le système, qui est la logique qui manipule les composants attachés à l’entité.
L’avantage de cette architecture est que tous les systèmes et composants sont réutilisables. Ils peuvent être publiés dans un registre public, et les développeurs peuvent facilement contribuer, construire, découvrir et intégrer n’importe quel type de composant, de sorte que vous n’avez plus besoin d’écrire une seule ligne de code à partir de zéro, mais que vous pouvez réutiliser tous les composants existants et éventuellement y contribuer. Par exemple, nous pouvons avoir une structure de données de grille (comme un labyrinthe ou un champ de bataille), un système mobile ou un système de preuve à divulgation nulle de connaissance pour le brouillard de guerre.
04.Pratique de programmation ECS du moteur BOLT
(Note du traducteur : cette partie est recommandée aux développeurs pour regarder la vidéo originale, les non-développeurs peuvent ignorer cette partie)
MAINTENANT, JE VAIS PASSER À MON IDE ET VOUS MONTRER UN EXEMPLE DE JEU SIMPLE UTILISANT LE MOTEUR BOLT ECS.
Nous allons définir plusieurs entités, un composant d’emplacement et deux systèmes qui manipuleront et modifieront les données de ce composant d’emplacement. Ainsi, le premier point d’entrée est d’interagir avec le Programme Mondial. Le programme mondial fait partie du framework BOLT et expose certaines extractions qui vous permettent d’enregistrer de nouvelles instances mondiales.
Vous pouvez ajouter des entités à votre instance mondiale et vous pouvez enregistrer des composants avec les entités que vous venez de définir, qui sont essentiellement définies par le programme de composant. Le programme du composant contient deux directives, dont la première est initialiser, créer et allouer de l’espace pour stocker les lignes de données qui seront utilisées dans votre composant. Dans cet exemple simple, nous définissons un composant de localisation, et si nous regardons le contexte de la directive d’initialisation, nous pouvons voir que nous avons des données de composant, et que les données de composant définissent simplement une structure avec des coordonnées XYZ qui peut stocker par exemple l’emplacement du joueur.
Maintenant, la deuxième directive est probablement la plus intéressante, c’est un point d’entrée qui nous permet d’exécuter n’importe quelle logique. Il recevra nos composants et nos systèmes arbitraires en entrée, et exécutera la logique définie en interne dans le système en exécutant sur plusieurs sites de programmation. Maintenant, si vous regardez à la ligne 15, nous avons notre appel CPI (Common Programming Interface), qui exécutera la logique définie en interne via le CPI. Il effectuera tous les calculs définis par le système, puis retournera à notre emplacement, où le programme du composant le récupérera et le réinitialisera dans nos données.
Maintenant, essayons de regarder le contexte de notre fonction apply, où nous pouvons voir que nous n’avons fondamentalement que deux comptes. Le premier est le compte qui contient les données de nos composants, et le second est le programme système. Par conséquent, un programme système est désormais une interface plutôt qu’un programme unique. Par conséquent, tout programme qui adhère à l’interface de notre système BOLT peut être exécuté via cette application.
05.Importance du système ECS
Essentiellement, cela change la façon dont vous concevez la logique de votre jeu et bouleverse les processus traditionnels. Auparavant, si vous vouliez créer ou encapsuler une logique dans votre programme, vous ajoutiez généralement d’abord des fonctionnalités, chacune d’entre elles étant une directive dans le programme, puis finalement, à un moment donné, vous verrouilliez le programme de jeu que vous développiez.
Avec le modèle ECS, cependant, nous pouvons avoir un programme immuable dès le départ, puis avec ce mécanisme de proxy, nous pouvons ajouter un système construit en interne ou par n’importe qui, de sorte que nous pouvons avoir un jeu qui peut fonctionner éternellement, qui est évolutif et qui peut vraiment changer la logique du jeu.
Ils peuvent déployer de nouveaux systèmes qui fonctionneront sur ces composants. Maintenant, l’interface vous permet également d’effectuer quelques vérifications, afin que nous puissions concevoir une mécanique de jeu qui permet d’ajouter sans permission de nouveaux systèmes pouvant modifier les données des composants.
Ou nous pouvons mettre en place une interface pour vérifier si le système permet l’exécution sur le composant. Par exemple, vous pouvez concevoir un système de gouvernance où si quelqu’un propose une nouvelle logique, et que cette logique est approuvée, alors tous les joueurs peuvent utiliser cette logique dans le jeu.
Cela peut même conduire à une bifurcation dans le monde du jeu (le contrat mondial). Dans un monde, vous possédez le système de vol. Et dans un autre monde, si le système n’est pas approuvé, il est possible d’avoir des règles différentes et chacun pourra toujours contribuer à sa propre version du monde.
Voyons maintenant comment construire un système capable de modifier ce composant. Le système n’est essentiellement qu’un programme sur Solana qui définit une instruction d’exécution, et l’instruction d’exécution est celle que nous appelons à partir du programme composant dans l’interface de programmation commune (CPI). Ici, il encapsule simplement une logique très simple dans laquelle il reçoit la direction d’entrée, calcule le delta, puis modifie les positions X et Y du composant.
Jetons donc un coup d’œil à un autre système qui pourrait être déployé par quelqu’un d’autre, même après la sortie du jeu. Voici un autre exemple d’un système qui implémente ute. Ici, la position Z est augmentée de 1, donc quelqu’un essaie d’ajouter un système de contournement, qui pourrait être une interface avec une couche différente au-dessus de votre jeu.
Donc, l’idée maintenant est que tous ces systèmes, tous ces composants sont vraiment composables, les utilisateurs du jeu ne sont plus de simples utilisateurs, le jeu est devenu une plate-forme ouverte, évolutive et persistante. Je vais donc essayer d’exécuter les tests unitaires que j’ai préparés dans cet exemple, et je vais utiliser l’interface de ligne de commande BOLT, qui est construite sur Anchor, un cadre de contrat intelligent pour Solana, donc si vous êtes déjà familier avec Solana, vous n’avez pas besoin d’apprendre quoi que ce soit de nouveau.
Maintenant, vous pouvez développer des programmes sur Solana, il suffit de développer des programmes, des programmes de test, donc ici j’exécute bolt build et bolt test, et ici je déploie notre programme, puis je fais le test de type que j’ai préparé ici.
Donc, ici, le test envoie une transaction pour initialiser un nouveau monde. Nous enregistrons quelques entités, nous attachons des composants de localisation à certaines d’entre elles, et peut-être que la partie intéressante est de créer des systèmes ici. Donc, ici, nous appelons la fonction apply, puis nous utilisons l’un de ces systèmes. Donc, voici juste un système par défaut.
Ici, nous appelons un mouvement simple, puis nous volons un mouvement ici. Eh bien, maintenant, si nous regardons les logs du test, dans le premier trade, nous utilisons ici un système de déplacement avec une direction ascendante, augmentant la position Y de 1. Dans la deuxième transaction, nous utilisons le même système pour nous déplacer vers la droite, puis enfin, nous exécutons le système de vol, qui fait le contraire, en augmentant notre position Z de 1. Ce n’est qu’un exemple simple, mais il offre une mécanique très puissante qui permet à quiconque de développer, d’étendre et potentiellement de rendre votre jeu amusant.
06.Cumul éphémère
Maintenant que nous allons revenir à la diapositive, je vais décrire le deuxième aspect intéressant du framework BOLT, qui est notre solution d’évolutivité, que nous appelons le cumul éphémère.
Il est généralement admis que Solana est déjà très rapide et bon marché, et qu’il génère actuellement un bloc toutes les 400 millisecondes et peut traiter des milliers de transactions, il est donc en fait prêt à construire un jeu à chaîne complète. Cependant, si vous avez une ancienne chaîne logique pour le multijoueur, les mises à jour de l’emplacement seront trop lentes.
Nous pouvons donc construire une couche d’accélération de courte durée qui est entièrement compatible avec la durée d’exécution de Solana. Le temps utilisé est facultatif, il peut servir d’accélération réelle d’une opération particulière, alors que la majeure partie de la logique est toujours exécutée sur la chaîne principale, il s’appuie donc sur la fonctionnalité que tout l’état sur Solana est stocké dans le compte.
Normalement, vous aurez un programme de jeu qui définit la logique, puis tout l’état sera stocké dans ce compte, de sorte que nous pouvons déléguer certains de ces comptes à cette couche éphémère qui utilise le moteur BOLT.
Dans cet exemple, il existe deux comptes autorisés qui stockent l’emplacement du lecteur, et le fournisseur écoute activement les demandes de délégation et les demandes d’approvisionnement. Il va démarrer un nouveau temps d’exécution selon les besoins, qui est rapide, personnalisable, ne peut pas avoir de transactions de gaz ou de ticks, et nous permet vraiment d’effectuer des transactions inférieures à 50 ms, et peut-être d’évoluer en ayant plusieurs environnements d’exécution dédiés.
Maintenant, l’autre partie intéressante est que toute cette complexité peut être abstraite de l’utilisateur. Nous avons un routeur RPC, qui est essentiellement similaire à un routeur RPC traditionnel. Le client RPC peut interagir directement avec le RPC pour envoyer des transactions. Étant donné que sur Solana, toutes les transactions sont prédéclarées pour tous les comptes mutables et lisibles, les routeurs RPC peuvent essentiellement acheminer les transactions, les requêtes de données et la récupération vers le bon niveau.
Puis à un moment donné, la couche éphémère (comme son nom l’indique) sera fermée et tous les états seront réglés dans la couche de base Solana, qui est sous la responsabilité du séquenceur, qui garde une trace de tous les comptes.
Une autre façon de voir ce mécanisme est que nous avons deux couches, et qu’elles exécutent des transactions en parallèle. Nous avons délégué des comptes qui nous permettent de mettre à jour avec une latence plus faible sans utiliser le débit de la chaîne principale. Et puis nous avons d’autres comptes, qui ne sont pas délégués, et qui sont exécutés sur la chaîne principale.
Ce qui est très intéressant, c’est que les programmes, les outils, les cadres et l’infrastructure sont tous sur la chaîne principale. Vous n’avez pas besoin de déployer votre programme dans Rollup, bien que cela soit courant dans de nombreuses autres architectures. Tout est sur la même couche, tout est composable, et comme nous l’avons mentionné, ce runtime spécialisé est également extensible et peut être vraiment personnalisé.
Maintenant, cela débloque une toute nouvelle catégorie de jeux, qu’il construit sur la blockchain et qui est à faible latence. Tout comme vous le feriez avec un serveur multijoueur traditionnel, mais toujours capable de se combiner avec tout ce qui est disponible sur l’écosystème de la couche 1.
Vous avez accès aux liquidités existantes, vous pouvez envoyer des messages via des protocoles, créer des NFT, utiliser des abstractions de compte, des clés de session, des classements et un écosystème unifié, tout le monde enrichit le même écosystème.
Merci beaucoup de m’avoir écouté. Vous pouvez vous inscrire pour un accès anticipé à notre framework à l’aide de codes QR et consulter le référentiel. Vous pouvez d’ores et déjà trouver une documentation solide et des livres blancs qui décrivent en détail le cadre que nous venons d’introduire. Merci beaucoup.