Cela va clairement à l'encontre du modèle de développement des jeux traditionnels. Les jeux traditionnels à succès attirent de nombreux utilisateurs grâce à des mécanismes de jeu captivants, permettant aux développeurs de construire des voies rentables et de potentiellement s'étendre vers des marchandises et des IP connexes. Ces jeux fonctionnent dans un cycle positif où les joueurs apprécient le jeu et bénéficient souvent d'avantages économiques à la fois à l'intérieur et à l'extérieur du jeu.

En revanche, les jeux actuels sur la blockchain attirent principalement les joueurs par le biais des rendements financiers. Outre leur faible jouabilité, les jeux Web3 sont également confrontés à des problèmes de longue date tels que des barrières à l'entrée élevées et des processus d'interaction complexes.

Quelle est la cause profonde de ces problèmes? Les opinions varient. L'équipe de TabiChain estime qu'un facteur important est que les développeurs de jeux traditionnels talentueux ont du mal à entrer dans l'écosystème Web3 en raison de barrières techniques et d'apprentissage. Pour ceux qui ne sont pas familiers avec le développement de jeux ou de logiciels, la transition de Web2 à Web3 pourrait sembler être simplement un changement de récit et d'environnement, mais la réalité est beaucoup plus rude.

Alors, comment pouvons-nous créer un environnement plus accueillant pour les développeurs de jeux traditionnels ou les entreprises connexes grâce à la technologie? Dans les sections suivantes, nous analyserons en profondeur les défis auxquels sont confrontés les jeux Web3 et leurs solutions, expliquant comment l'industrie future du jeu Web3 peut être techniquement adaptée pour mieux convenir aux développeurs de jeux traditionnels.

Raisons techniques empêchant les développeurs de jeux traditionnels d'entrer dans l'écosystème Web3

Dans l'article précédent, nous avons brièvement mentionné que la technologie peu conviviale et les coûts d'apprentissage élevés sont les principaux facteurs qui empêchent les praticiens de jeux traditionnels d'entrer dans l'écosystème web3. La soi-disant technologie peu conviviale et les coûts d'apprentissage élevés peuvent être étendus aux points suivants :

1. La différence entre les applications web3 et les structures logicielles traditionnelles

La blockchain et les applications qui y sont basées (dApps) sont fondamentalement différentes de l'architecture logicielle traditionnelle et nécessitent que les développeurs aient un nouveau système de connaissances, tel que le principe de fonctionnement de la blockchain, les protocoles de consensus, les modèles de programmation des contrats intelligents, etc. Les développeurs de jeux traditionnels doivent passer beaucoup de temps à apprendre Solidity ou d'autres langages de contrats intelligents et doivent comprendre comment fonctionne l'EVM.

De plus, la logique de jeu traditionnelle est généralement exécutée sur un serveur centralisé, qui peut gérer de manière flexible des états de jeu complexes et des interactions à haute fréquence. Exécuter la logique de jeu sur la blockchain nécessite un degré élevé de simplification ou de refonte, car chaque opération doit être publiée sur le réseau distribué pour exécution, puis téléchargée sur la chaîne, ce qui est fortement limité par les performances et les coûts de la blockchain.

1. Limitations de conception des contrats intelligents

Bien que l'EVM soit complète de Turing et puisse théoriquement exprimer une logique arbitraire, ses caractéristiques sont très défavorables au développement de jeux, telles que :

• Manque de minuterie. Toutes les opérations sur la chaîne Ethereum doivent être déclenchées manuellement par le compte EOA. Pour obtenir un effet similaire à une minuterie, les développeurs doivent déployer un service supplémentaire et maintenir un compte EOA et une liste d'événements pour déclencher manuellement les tâches planifiées. En raison du problème de retard sur la chaîne, il n'est pas garanti que ces tâches planifiées seront terminées à temps.

• Il n'y a pas de rappel et d'autres mécanismes, et cela ne prend pas en charge le multitâche et l'asynchrone. Comme Solidity est conçu pour le développement de contrats intelligents Ethereum, son environnement d'exécution est significativement différent des environnements d'exécution traditionnels. Le fonctionnement de l'EVM est transactionnel et chaque appel de fonction doit être complètement exécuté dans une transaction. Il n'y a pas de concept d'"asynchrone" au sens traditionnel. Cela signifie qu'un appel de fonction en Solidity est atomique du début à la fin et ne peut pas être interrompu par d'autres transactions.
• Il n'y a pas de capacité à faire référence à des données externes. Bien qu'il existe des oracles comme Chainlink, que ce soit d'un point de vue d'intégration ou d'appel de données, sa facilité d'utilisation est très différente de celle d'obtenir directement des appels de données via des requêtes https, ce qui permet aux développeurs d'ajouter des intégrations supplémentaires. Charge et dépendance.
• Limitations de scalability et de performance.La logique du jeu doit être simplifiée ou décomposée en plusieurs transactions simples pour éviter que les frais de gaz d'une seule transaction ne deviennent trop élevés ou dépassent la limite maximale, ce qui limite la mise en œuvre d'interactions et de fonctions complexes.

1. Limitations sur le stockage et la récupération de données

• Les contrats intelligents ont un espace de stockage coûteux et une conception limitée, ce qui les rend inadaptés pour stocker de grandes quantités de données de jeu.
• Les journaux d'événements peuvent être nécessaires pour suivre indirectement l'état du jeu, et la capture d'événements peut ne pas être stable. Des problèmes tels que le moment de rafraîchir l'état du jeu nécessitent souvent que les joueurs ou les opérateurs de jeu le déclenchent manuellement.
• La structure de données du compte adoptée par l'EVM entraîne de mauvaises capacités d'indexation des données. Lorsque vous interrogez les données d'un compte, vous ne pouvez connaître que le solde de ses ETH ou jeton natif de la chaîne, mais les actifs ERC-20 qu'il possède et le solde de chaque actif ne peuvent pas être directement connus. Il en va de même pour les NFT. Cette information est encapsulée dans le contrat exclusif de chaque actif, plutôt que d'être stockée sous le compte de l'utilisateur.

Nous pouvons voir quel type de jeton et quel solde une certaine adresse possède à partir d'outils tels que Etherscan. Ceux-ci sont indexés par des outils périphériques tels que les navigateurs de chaînes de blocs, et ces derniers doivent construire une énorme base de données dédiée et la parcourir complètement. Ce n'est qu'en collectant toutes les données de bloc ou en surveillant les événements sur la chaîne que toutes les données sur la chaîne peuvent être résumées.

Les développeurs Web3 doivent généralement intégrer des fournisseurs de données tiers tels que Etherscan, NFTscan, The Graph, etc., et même payer pour leur API KEY. De plus, ces services tiers sont essentiellement des bases de données hors chaîne, ce qui peut entraîner des retards, des erreurs, des dépassements de limites d'appel, une non-disponibilité du service et d'autres échecs.

Comparons les différences entre la forme de base de données de la plupart des jeux et les méthodes de stockage de données dans la blockchain. La différence entre les deux est évidente. La structure de données de la plupart des jeux est entièrement personnalisée par elle-même, a de bonnes capacités d'expression et d'indexation, et n'a pas besoin de s'appuyer sur des services tiers.

1. Défis dans l'intégration des actifs de jeu existants avec la blockchain

Les actifs de jeu existants (comme les accessoires et les personnages) ne sont généralement pas créés et gérés sur la blockchain. La migration de ces actifs vers la blockchain implique généralement de convertir des types de données communs mais spécifiques en NFT ou Tokens standard, ce qui nécessite un travail de migration et d'intégration complexe et aura un impact sur le système économique de jeu existant.

1. Mises à niveau, correctifs et prévention des catastrophes

Sur Ethereum, une fois qu'un contrat intelligent est déployé, le code est immuable, rendant les mises à jour et correctifs plus complexes que les logiciels traditionnels. Les développeurs utilisent souvent des contrats proxy ou des modèles de version pour contourner cette limitation, mais cela augmente la complexité de la structure globale. Les contrats proxy doivent être utilisés avec précaution pour éviter la corruption des données causée par des conflits d'emplacement de stockage. De plus, le risque de fuite des droits administratifs est également sérieux.

La mise à niveau du code des jeux traditionnels n'est pas si compliquée en termes de structure technique. La seule chose qui puisse nécessiter d'être restreinte est l'autorité de mise à niveau centralisée. Cela peut être réalisé grâce à des méthodes telles que DAO plutôt que de s'appuyer sur des contrats intelligents.

De plus, les jeux traditionnels prennent souvent des instantanés ou des sauvegardes de base de données. Cela peut ne pas être très important en général, mais si vous rencontrez un bogue majeur lors de la mise à jour, vous pouvez rapidement revenir en arrière les données, ce qui est fondamentalement une fantaisie sur la blockchain. Même si certaines données de jeu sont restaurées en reconstruisant le contrat, la migration des données et de l'état de l'ancien contrat vers le nouveau reste compliquée.

1. Fragmentation écologique et problèmes d'expérience utilisateur

Différentes chaînes publiques et machines virtuelles ont des langages de contrat intelligent complètement différents, des architectures, des structures de données, etc. En Web2, les développeurs de jeux choisiront des moteurs frontaux multiplateformes tels que Unity, qui peuvent rendre un ensemble de codes légèrement adapté pour fonctionner dans différents environnements tels que iPhone, Android et desktop. Comme le back-end ne s'exécute pas sur le terminal utilisateur, il n'y a pas de problèmes de compatibilité multiplateforme.

En Web3, c'est essentiellement un luxe. Migrer vers une chaîne ou une machine virtuelle différente signifie reconstruire l'ensemble du projet et entraîner des coûts énormes. De plus, les développeurs novices en Web3 n'ont aucune expérience pour choisir un écosystème qui leur convient. Est-ce une question de point de vue technique ou écologique?

Au niveau de l'expérience utilisateur, les interactions blockchain sont extrêmement complexes. Le concept d'abstraction de compte, si populaire auparavant, est apparu précisément pour résoudre les problèmes d'expérience utilisateur de web3, donc je ne rentrerai pas dans les détails ici.

Après avoir énuméré les 6 principaux arguments ci-dessus, permettez-nous de résumer : les développeurs de web2 à web3 font face à un énorme seuil d'adaptation. S'ils sont des développeurs de premier plan dans web2, il n'est pas nécessaire d'abandonner leur carrière dans web2 pour se tourner vers un inconnu comme web3. Dans cet environnement, nous développons des entreprises dont nous ne savons pas si elles pourront être couronnées de succès ou non.

On peut dire que la plupart des principaux développeurs de jeux n'ont pas encore intégré le Web3. Dans une certaine mesure, cela rend la plupart des jeux Web3 plutôt orientés vers la spéculation financière que vers une jouabilité et un plaisir particulièrement élevés.

Des obstacles de même nature existent également du côté de l'utilisateur. Les jeux Web3 ont une série d'étapes opérationnelles qui entravent les taux de conversion des utilisateurs, entraînant un groupe d'utilisateurs important de Web2 qui ne sont pas disposés à expérimenter, voire totalement inconscients de l'existence des jeux Web3.

Y a-t-il un projet au niveau de l'infrastructure qui peut résoudre les problèmes ci-dessus ? Tabi Chain peut être un projet très proche de l'une des solutions ultimes pour les jeux Web3. Son concept principal est la "Couche d'exécution Omni" : les développeurs n'ont plus besoin de se soucier des différences entre les différents VM ou environnements d'exploitation. Ils peuvent directement utiliser leurs environnements d'exploitation familiers, voire personnalisables, pour développer ou porter directement des jeux.

En outre, Tabi Chain dispose également d'un consensus modulaire, d'une couche de sécurité et d'autres fonctionnalités. Tout est modulaire et personnalisable pour répondre aux besoins des différents jeux et applications.

Couche d'exécution Omni: Sélection de l'environnement d'exécution en fonction des besoins des développeurs

Revisitons le concept fondamental de la blockchain. Alors que certains pourraient le décrire comme un registre décentralisé et immuable, il est plus précisément défini comme la synchronisation vérifiable de l'état permanent d'une machine d'état au sein d'un réseau distribué.

Essentiellement, la blockchain maintient une machine à états universellement acceptée et son statut opérationnel :

• Chaque entrée est déterministe, enregistrée dans chaque bloc;
• La fonction de transition d'état est déterministe, représentée par la machine virtuelle ou le runtime au sein du client blockchain;
• L'état de sortie est également déterministe, enregistré dans chaque bloc;

Ainsi, le système de consensus d'une blockchain n'a pas besoin d'être limité à une seule couche d'exécution (comme uniquement l'EVM). Peu importe le nombre de couches d'exécution, tant que la chaîne peut vérifier les états à travers plusieurs couches, permettant à chaque jeu de fonctionner dans son propre environnement, nous pouvons aborder les divers problèmes précédemment discutés.

Dans Tabi, chaque jeu ou dApp peut construire son propre Service indépendant. Tous les Services soumettent leurs propres blocs générés au système de consensus de la chaîne ; Les nœuds superviseurs incluent le runtime/VM dans tous les Services pour vérifier l'état des blocs de service. L'existenceLe cœur de la couche d'exécution globale de Tabi peut être considéré comme un VM avec des capacités polymorphes, c'est pourquoi il est appelé Polymorphism VM.

Pour les VM blockchain existantes, une VM de Polymorphisme doit intégrer ces VM dans son environnement d'exécution et fournir les méthodes d'appel d'interface nécessaires. Le concept d'“intégration” peut être implémenté de deux manières :

État du monde partagé : Similaire à Ethermint, qui prend en charge l'EVM sur Cosmos. L'EVM agit comme une couche de surface, se concentrant sur les interactions utilisateur et les opérations de contrat, faisant apparaître toutes les activités côté utilisateur comme étant exécutées sur l'EVM. Cependant, les résultats finaux et les données de ces opérations sont stockés dans d'autres modules Cosmos. Ainsi, cette compatibilité EVM est essentiellement une cartographie des données sous-jacentes.

Cette relation de mappage peut être étendue à d'autres machines virtuelles également. Par exemple, Ethermint peut incorporer une couche de module SVM supplémentaire, où à la fois le SVM et l'EVM correspondent aux mêmes données sous-jacentes.

Cela revient à utiliser VMWare sur un PC pour exécuter une machine virtuelle Windows. VMWare peut accéder à la fois au disque dur virtuel de la machine virtuelle et au disque dur physique de l'ordinateur. Si vous démarrez ensuite une machine virtuelle Mac, elle peut monter les données du disque physique de la même manière. Cette configuration permet efficacement à plusieurs machines virtuelles de partager les ressources et l'état du même environnement.

Le service principal de Tabi Chain utilisera une approche d'état mondial partagé. Cela signifie que tant que la machine virtuelle correspondante est adaptée, les dApps développées pour cette machine virtuelle peuvent être déployées directement sur le service principal sans avoir besoin de créer un service séparé.

État du monde indépendant : Différentes applications et jeux ont des exigences uniques, et certains jeux utilisent des runtimes personnalisés. Par conséquent, une approche universelle d'intégration de toutes les machines virtuelles à travers un "état du monde partagé" dans la machine virtuelle de polymorphisme n'est pas adaptée à tous les cas. Un état du monde indépendant est également nécessaire, car il est plus simple à mettre en œuvre et idéal pour les services avec des données entièrement séparées.

Quelle que soit l'approche utilisée, elle doit être vérifiable par les nœuds superviseurs. Cela signifie que le Polymorphism VM doit inclure tous les VM ou runtimes utilisés par les différentes méthodes de mise en œuvre.

Exemple de portage de jeu Web2

Le VM Polymorphisme est hautement personnalisable, ce qui le rend particulièrement bénéfique pour les développeurs Web2. Ils peuvent utiliser des langages et des cadres familiers pour porter n'importe quelle logique métier sur le VM Polymorphisme.

Suppose Minecraft wants to port to Tabi. The general process would be as follows:

1. Modifier le code du serveur : Modifier légèrement le code du serveur Minecraft (Java ou tout autre langage), déplacer les données qui doivent être sur la chaîne à une base de données (ou un ensemble de bases de données). Identifier et sélectionner toutes les fonctions qui pourraient modifier cette base de données (c'est-à-dire les fonctions de transition d'état).
2. Emballer les composants: Emballez cette base de données et ces fonctions dans un fichier JAR, qui est un programme exécutable en Java. Incluez le JRE (Java Runtime Environment) dans ce package. Ce package entier est ensuite chargé dans le Polymorphism VM, garantissant que toutes les données sont sur la chaîne.
3. Exécution de la logique hors chaîne : exécuter d'autres logiques backend qui n'ont pas besoin d'être sur la chaîne (comme la formation d'équipe, le chat, etc.) sur des serveurs hors chaîne.
4. Démarrer un service : Lancez un service dans Tabi Chain et notifiez au VM de polymorphisme des nœuds superviseurs de charger le même JRE.
   

Avec cela, le processus est complet.

Pour les développeurs, ces modifications sont apportées dans le langage et le cadre Java existants. Le même concept s'applique aux jeux développés selon toute autre méthode. Pour les utilisateurs, l'interaction du jeu reste largement inchangée. Clairement, cette méthode de portage des jeux Web2 est très rapide et efficace, devenant potentiellement le modèle fondateur pour l'adoption massive des jeux Web3.

Détails des fonctions du jeu STR (State Transition Runtime)

L'exemple précédent a fourni un aperçu général du portage d'un jeu Web2. Pour obtenir une compréhension plus approfondie, nous devons plonger dans plus de détails. Cette fois, nous utiliserons un exemple général au lieu d'un jeu spécifique pour illustrer les détails impliqués dans l'exécution de la couche d'Omni-Execution.

Essentiellement, la personnalisation de l’environnement d’exécution d’un jeu peut être considérée comme la création de la machine d’état du jeu sur la blockchain, appelée State Transition Runtime (STR) dans Tabi.

L'exemple ci-dessus est le processus général de portage de jeu Web2. Nous devons encore en savoir plus sur les détails. Cette fois, nous utilisons un exemple général plutôt qu'un exemple de jeu spécifique pour montrer les détails impliqués dans l'exécution en temps réel dans la couche d'exécution omnipotente.

Fondamentalement, la personnalisation de l’environnement d’exécution d’un jeu peut être considérée comme la création d’une machine d’état pour un certain jeu sur la blockchain, ce qui est appelé State Transition Runtime dans Tabi.

STR peut être intégré dans Polymorphism VM sous forme binaire ou de module.

Dans un système de type blockchain, nous devons garantir la transparence des entrées, la visibilité publique des transitions d'état et l'expressivité de l'état global. Pour répondre à ces exigences, nous devons construire un exécuteur avec les caractéristiques suivantes :

1. World DBContient toutes les données utilisateur au sein de l'application qui doivent être enregistrées sur la blockchain. Ces données doivent être précieuses et importantes, donc une structure similaire à celle de la blockchain est nécessaire pour garantir leur disponibilité. Par conséquent, toutes les données n'ont pas besoin d'être enregistrées sur la blockchain. Par exemple, dans les jeux, le contenu du chat de l'utilisateur n'est généralement pas important et est jetable, donc il n'est pas nécessaire de le mettre sur la blockchain.
2. Il peut exprimer l'état complet du monde. Dans de nombreux scénarios, comme dans les jeux, cette expression n'implique pas nécessairement un haut degré de traçabilité - un simple accumulateur suffira, ce qui signifie qu'une structure de données comme un arbre de Merkle n'est pas toujours nécessaire. Cependant, peu importe la structure de données utilisée pour représenter l'état du monde, il est crucial que l'état du monde de la base de données mondiale puisse être exprimé sous forme résumée.
3. Toute fonction susceptible de modifier la base de données mondiale est appelée fonction de transition d'état et doit être encapsulée dans le runtime de transition d'état. Toute modification de la base de données mondiale en dehors du runtime devrait être considérée comme illégale et rejetée.
4. Les interfaces d'entrée et de sortie doivent être conformes à la conception de l'Interprète d'Entrée et du Proposant de Bloc. Cela est relativement simple et ne sera pas expliqué en détail ici.

Les structures organisationnelles suivantes sont des éléments essentiels de cette STR. Tabi fournira par défaut un SDK pour faciliter aux développeurs la création du runtime.

Base de données mondiale

En pratique, un jeu ou une application utilisera très probablement plus d'une base de données, et ces bases de données peuvent être de types différents. Supposons qu'un jeu particulier utilise à la fois une base de données relationnelle et une base de données clé-valeur.

Voici un exemple simple de base de données relationnelle :

1. UID: Représente un utilisateur unique, qui peut être une clé publique ou un autre identifiant.
2. Nonce : utilisé pour prévenir les attaques de rejeu.
3. Champs de données supplémentaires : tout type de données.

Il s'agit d'une base de données clé-valeur simple :

Fonction de transition d'état

Il s'agit d'une fonction de transition d'état simple. Lorsque cette fonction reçoit une entrée de l'utilisateur, elle la multiplie simplement par 5 et modifie les données dans la base de données relationnelle.

Accumulateur d'état mondial

Nous pouvons construire un accumulateur de hachage simple pour représenter l'état du monde :

A_s+1 = hash(A_s + hash(query))

Cette méthode garantit qu'après toute modification de la base de données mondiale, il y aura toujours un état unique et défini correspondant à cette modification.

Il est important de noter que chaque fonction de transition d'état doit implémenter cette méthode. Cette exigence peut être appliquée à l'aide de modificateurs, d'interfaces, de hooks ou d'autres mécanismes spécifiques au langage. En raison des caractéristiques différentes des divers langages de programmation, nous n'entrerons pas dans les détails spécifiques ici.

Le processus de mise à jour d'une base de données clé-valeur (KVDB) suit le même principe.

Nombres aléatoires

Les fonctions de transition d'état ne doivent pas inclure de nombres aléatoires, car cela entraînerait des résultats différents lorsqu'ils sont validés par différents vérificateurs, rompant ainsi la cohérence. Les nombres aléatoires doivent être inclus comme partie des paramètres d'entrée du système.

Résumé

Des exemples ci-dessus, nous pouvons voir que la couche d'exécution omni de Tabi Chain offre aux développeurs de jeux une flexibilité significative grâce à une approche modulaire. En raison de contraintes d'espace, nous ne pouvons pas discuter de tous les détails ici, mais les points principaux mentionnés suffisent à démontrer que la solution de Tabi Chain est à la fois pratique et innovante.

Dans l'écosystème Web3 actuel, les œuvres développées sur différentes chaînes et machines virtuelles manquent généralement de portabilité. Pour que les jeux Web2 passent à Web3, cela signifie souvent réécrire le jeu dans des langues et environnements inconnus, en faisant face à diverses restrictions incompréhensibles.

Avec Tabi, les développeurs peuvent utiliser leur langue d'origine, leur plateforme de développement et leur moteur. Ils n'ont qu'à apporter des adaptations et des modifications simples, similaires à l'appel d'un SDK, pour introduire leurs projets dans le monde de la blockchain. Cela se traduit par des améliorations exponentielles de l'efficacité et des réductions de la complexité.

Nous espérons que Tabi Chain peut devenir un catalyseur pour l'adoption de masse des jeux Web3, attirant des développeurs de jeux Web2 talentueux et apportant des jeux vraiment divertissants et jouables à l'espace Web3.

Avertissement：

1. Cet article est repris de [GateWeb3 Geek]. Tous les droits d'auteur appartiennent à l'auteur original [罗奔奔]. Si des objections sont formulées à cette réimpression, veuillez contacter le Gate Learnéquipe, et ils s'en occuperont rapidement.
2. Responsabilité de non-responsabilité : Les points de vue et opinions exprimés dans cet article sont uniquement ceux de l'auteur et ne constituent aucun conseil en investissement.
3. Les traductions de l'article dans d'autres langues sont effectuées par l'équipe Gate Learn. Sauf mention contraire, la copie, la distribution ou le plagiat des articles traduits est interdit.