Les idéaux du Web3 semblent parfaitement correspondre à l'industrie du jeu vidéo et à la tendance de ces dernières années à la gamification. Cela fait un certain temps qu'on nous promet une nouvelle révolution sous la forme d'une expérience unique : le jeu en chaîne. Avec des fonctionnalités telles que la décentralisation qui déplace l'équilibre des pouvoirs entre les acteurs historiques de l'industrie du jeu vidéo et les entités créatives, la composabilité qui fait tomber les murs des jardins fermés depuis longtemps et une véritable propriété pour les joueurs.

Mais ces puissants idéaux restent de côté, car nous ne les avons pas encore mis en pratique. MUD est la première tentative courageuse de créer un framework complet pour les jeux en chaîne, une étincelle qui pourrait donner naissance à la prochaine génération de jeux. Ce n'est pas une chimère. Au cours de sa courte période, l'équipe MUD est à l'origine d'OpCraft, un véritable jeu 3D sur le thème de Minecraft entièrement intégré.

Les leçons de l'industrie du jeu vidéo traditionnelle

On peut en dire long sur l'obsession d'innover, de tout construire à partir de zéro et de créer une toute nouvelle créature. Mais en ce qui concerne les jeux vidéo, il y a des dizaines d'années de leçons sur les modèles de conception et la création d'un nouveau créneau d'ingénierie à prendre au sérieux. Les rejeter revient à essayer de créer un jeu AAA avec la technologie Atari.

Si l'on considère les premières années du développement de jeux vidéo, on peut constater une ressemblance flagrante avec les jeux en chaîne : de nombreux talents et des projets très inspirants, mais aussi un manque de coordination et de cadres clairs.

Au tout début des jeux vidéo, avant l'apparition des moteurs de jeu, ils établissaient des convictions et des modèles de conception. Les différents jeux vidéo n'avaient pas grand-chose en commun. Jusqu'à un certain point, des jeux similaires pouvaient avoir une base de code complètement différente. Mais avec l'introduction des moteurs de jeu, tout a changé.

Il est difficile d'établir une distinction claire entre les moteurs de jeu et les jeux eux-mêmes. En général, les moteurs de jeu sont des frameworks dotés d'un ensemble de règles et de modèles de conception qui peuvent être légèrement modifiés et étendus pour créer différentes implémentations de jeu. Dans les années 90, après des années de développement fragmenté, quelque chose a changé. Les moteurs de jeu « basés sur les genres » et certains efforts visant à développer des moteurs polyvalents ont pris les devants. Des jeux comme Doom et Unreal comportaient des composants de base qui pouvaient être réutilisés pour créer de nombreux jeux différents. Les jeux de genres similaires ont commencé à partager bon nombre de leurs principes de logique de base. Le coût et la complexité du développement de jeux de course, de combat et de tir à la première personne ont considérablement diminué. L'impossible est devenu possible, et des générations de jeux et de code amélioré se sont accumulées les unes sur les autres. Du point de vue logiciel, c'est l'une des principales raisons pour lesquelles le développement de jeux vidéo est devenu une industrie importante.

Les jeux en chaîne présentent quelques problèmes fondamentaux :

1. Manque de cadres : chaque équipe essaie de tout créer à partir de zéro, ce qui se traduit par une faible efficacité et un manque de connaissances systémiques, compte tenu de l'expérience cumulée des constructeurs qui abordent les mêmes problèmes et optimisent pour trouver les meilleures solutions.
2. Absence de réutilisation du code : prenez l'exemple de la plupart des jeux en chaîne développés aujourd'hui. Combien d'entre eux peuvent être copiés avec succès pour créer des jeux légèrement différents ? Combien d'entre eux font une distinction claire entre les différentes couches et les différents composants du jeu, ce qui permet de créer une nouvelle génération avec une base de code similaire ? La promesse de créer le projet open source le plus important et le plus interconnecté pour les jeux vidéo semble loin.
3. Manque de composabilité des données : cela ne s'arrête pas à la réutilisabilité du code. Il s'agit également de la capacité des jeux en chaîne à tirer parti de l'état partagé de la blockchain pour s'appuyer les uns sur les autres en utilisant les données du jeu A dans le jeu B. En pratique, intégrer les données et la logique d'un jeu dans l'autre demande beaucoup de travail et de ressources.

La solution de MUD :

Mud est la première tentative courageuse de créer un moteur et un framework pour les jeux en chaîne en fournissant la structure nécessaire à la maintenabilité, à l'évolutivité et à la moulabilité. Le modèle Entity Component System (ECS) préconisé par Mud est logique, non seulement en termes de développement général de jeux, mais encore plus pour le développement de jeux en chaîne.

L'ECS dans les contrats intelligents :

Les éléments de base de MUD sont les composants. Ce sont des contrats de déploiement qui fonctionnent comme des bases de données stockant des données concernant des entités. Par exemple, prenons une entité (une adresse) comme le portefeuille du joueur. Cette entité représentée par une adresse peut avoir différentes propriétés, telles que la valeur de position (x, y) dans la composante position, le niveau 10 dans la composante niveau et 50 dans la composante pièces. Les composants consistent uniquement en un mappage et une configuration de base. Les systèmes sont plus complexes et mettent en œuvre la logique qui consiste à modifier la valeur des composants. Vous pouvez y penser car les systèmes spécifient l'API pour les requêtes POST sur les bases de données (composants). Ils ne pouvaient le faire que s'ils avaient accès en écriture à des composants spécifiques. Ici, ça devient intéressant. Les systèmes peuvent interagir avec différents composants pour créer une logique détaillée. Vous pouvez avoir un système de mouvements qui spécifie le mouvement valide que le joueur peut effectuer (par exemple, deux pas à chaque fois), et vous pouvez avoir un système de récompenses qui donne des pièces aux joueurs à chaque fois qu'ils passent de niveau. Ils sont tous enregistrés sur « World Contact », de sorte que chaque modification des données des composants est suivie d'un événement émis. Les contrats mondiaux sont sans autorisation. Tout le monde peut ajouter de nouveaux systèmes et composants. En théorie, différents mondes peuvent interagir les uns avec les autres.

Intégrer ECS aux jeux en chaîne permet d'obtenir une structure très élégante, de sorte qu'OpCraft ne se compose que de 10 composants et d'une quinzaine de systèmes. Vous pouvez consulter cet excellent article de blog sur MUD.dev

Une véritable composabilité

Le système ECS n'est pas seulement parfaitement logique pour le développement de jeux traditionnels, mais encore plus pour les jeux en chaîne, car il propose deux fonctionnalités importantes

1. Évolutivité du jeu déployé
2. Le plus haut degré de composabilité

Imaginez deux voies. La première est de préserver le design de base. Et l'autre est de changer la logique de base du jeu.

Pensez à un jeu de stratégie JcJ classique dans lequel les joueurs peuvent constituer des armées pour s'affronter. La version de base était en 2D, mais l'équipe a décidé de créer un rendu 3D détaillé du jeu. Il leur suffit de prendre tous les systèmes liés à la position et de créer des versions améliorées avec des coordonnées (x, y, z) au lieu de (x, y). Tous les autres systèmes et composants (comme le système d'attaque, les HP et la construction de l'armée) peuvent rester les mêmes. Cela va même au-delà des équipes de développement initiales. Les communautés peuvent créer différents mods du jeu en redéployant les systèmes et les composants ou même interagir avec les mêmes composants en autorisant l'écriture à de nouvelles consoles (s'il s'agit d'un jeu appartenant à la communauté, différents modèles de gouvernance peuvent être appliqués à ce type de décisions)

L'autre approche conservera les mêmes composants et systèmes sans donner accès à l'écriture aux nouveaux systèmes. Mais avec l'ajout de composants et de systèmes visant à étendre les fonctionnalités du jeu, à quoi cela pourrait-il ressembler ? Pensez à une partie d'échecs en chaîne de base. Les systèmes de mouvements et de règles sont déjà déployés. Les joueurs peuvent jouer comme s'ils jouaient aux échecs, mais peut-être que votre équipe décidera de créer une couche supplémentaire, une couche sociale qui consiste en un système de classement pour le matchmaking ou tout autre scénario d'utilisation. Il vous suffit d'ajouter un composant de notation et un système avec des règles de notation. Cela se traduit non seulement par une transition fluide vers les nouvelles versions du jeu (expérience utilisateur améliorée), mais aussi par la création de moyens techniques permettant aux différentes versions de coexister côte à côte ou les unes sur les autres au niveau des contrats intelligents. Les joueurs peuvent continuer à utiliser différentes versions du jeu tout en interagissant avec les données des mêmes composants de base, ce qui est très innovant, mis à part les applications de composabilité. Cela crée une fonction d'immuabilité de l'opt-in, créant ainsi une autre dimension de propriété que les jeux en chaîne apporteraient. La véritable propriété des différents éléments du jeu (comme le score, les NFT, les succès), garantie par une logique immuable qui peut être étendue par des améliorations supplémentaires, mais qui ne change pas fondamentalement. Cela résout l'un des principaux problèmes des jeux Web3, à savoir la capacité des créateurs à renforcer leurs actifs sans consentement.

Côté client, un point de vue d'ensemble :

Notez que MUD est un projet en cours. La partie suivante n'est peut-être pas à jour et contient des inexactitudes et des distinctions approximatives, mais l'architecture générale ne devrait pas être radicalement modifiée.

Jusqu'à présent, nous avons étudié MUD au niveau des contrats intelligents. Mais il y a bien plus encore. MUD propose une suite complète avec des bibliothèques et des couches clientes. MUD a été conçu pour certaines fonctionnalités uniques.

1. Composabilité des clients
2. Le client est complètement synchronisé avec le changement d'état de la blockchain (données de jeu)
3. PhaseRX comme couche de rendu

Passons aux détails techniques pour les rendre plus concrets.

Couche réseau :

La couche réseau est la couche de base du client. Il contient la configuration de base (contrat mondial, configuration du jeu et du réseau) et l'API pour les interactions entre les jeux. Lorsque la couche réseau est créée, elle contient une spécification des différents composants et systèmes avec lesquels votre client pourra interagir, et vous pouvez choisir de n'interagir qu'avec des composants/systèmes spécifiques. Par exemple, si vous souhaitez créer du mouvement dans votre jeu et le représenter sur le frontend, vous devrez créer une couche réseau synchronisée avec le contrat intelligent déployé par le composant de position et également avec le système de mouvement. Vous pouvez maintenant créer une API Move qui prend une position et un objet du jeu (entité) et définit sa position ou le déplace d'un endroit à un autre. Les joueurs peuvent utiliser l'API Move à tout moment. Ils vont soumettre une transaction à la blockchain. Dans le cas du système de mouvement, ils vont exécuter une fonction dans le cadre du contrat intelligent du système de mouvement.

Cette structure permet de jouer à plusieurs clients. Tout le monde serait capable de créer des clients uniques, et ils ont tous la même validité tant qu'ils sont synchronisés avec la blockchain et qu'ils suivent la structure de base de la couche réseau. Nous avons vu des cas d'utilisation très intéressants pour les jeux multi-clients, comme dans le cas de A Dark Forest, dans lequel les joueurs s'affrontent mais utilisent des clients et des plugins différents. La structure du client nous permet d'implanter la couche réseau et de modifier l'API pour obtenir les différentes versions du client très rapidement, atteignant ainsi un haut niveau de moulabilité et de composabilité.

Vous vous demandez peut-être comment les composants du client se synchronisent exactement avec ceux de la chaîne. C'est l'un des principaux défis auxquels sont confrontés les constructeurs lorsqu'ils gèrent le côté client des jeux en chaîne. MUD propose quelques solutions pour y remédier.

Tout d'abord, MUD a mis en place une fonction de capture instantanée qui permet au client de se synchroniser avec l'état mondial (c'est-à-dire les valeurs des entités par composants) sans traiter tous les événements passés pour reconstruire l'état, ce qui se traduit par une faible latence et une diminution de la complexité.

De plus, le système d'identification de MUD, dans lequel chaque système et composant reçoit un identifiant basé sur son nom. Une fois déployé, ils sont enregistrés au World Contract, ce qui permet de suivre les modifications, d'interagir avec le jeu et de consulter facilement les événements.

Couche de rendu : quand et comment les événements sont rendus

MUD est livré avec PhaserX, « un moteur hautement évolutif qui s'appuie sur Phaser ». PhaserX n'est pas obligatoire. Dans OpCraft, il existe un moteur de voxels Noa à la place de PhaseRX. En théorie, vous pouvez utiliser le moteur de votre choix à condition qu'il respecte la structure.

Comme indiqué précédemment, chaque composant et chaque système sont enregistrés dans le contrat mondial, et en cas de modification, un événement est émis (avec des données identifiées telles que l'identifiant du composant et l'identifiant de l'entité). Ici, le service de streaming ECS peut offrir au client la possibilité de choisir les événements auxquels s'abonner.

La représentation graphique des entités peut être ce que vous voulez. Un jeu de combat peut mettre en scène des personnages d'anime, des chevaliers ou même vos influenceurs cryptographiques préférés. Ce sont toutes des versions valides dans la mesure où elles représentent les événements en chaîne et y réagissent.

Avertissement：

1. Cet article est reproduit depuis [mirror]. Tous les droits d'auteur appartiennent à l'auteur original [Matchbox DAO]. En cas d'objection à cette réimpression, veuillez contacter l'équipe de Gate Learn (« Gate Learn »), qui s'en occupera rapidement.
2. Avertissement en matière de responsabilité : Les points de vue et opinions exprimés dans cet article sont uniquement ceux de l'auteur et ne constituent en aucun cas un conseil d'investissement.
3. Les traductions de l'article dans d'autres langues sont effectuées par l'équipe de Gate Learn. Sauf mention contraire, il est interdit de copier, de distribuer ou de plagier les articles traduits.