Comment créer un meilleur environnement pour les développeurs de jeux traditionnels techniquement

Auteur: Luo Benben, CTO de Tabi Chain

Introduction:Depuis la naissance d’Axie et de Stepn dans le cycle précédent, GameFi et les jeux Full-Chain ont toujours été l’un des hotspots de l’industrie de la blockchain. .Bien que ces visions soient belles, elles sont confrontées à un problème qui n’a jamais été résolu:

La jouabilité de la tournée en chaîne n’est généralement pas élevée, et le plaisir est insuffisant, ce qui est plus enclin à la spéculation financière.Essence

De toute évidence, cela va à l’encontre du modèle de développement des jeux traditionnels.Le développement fluide des jeux traditionnels reposait souvent sur le plaisir du mécanisme de jeu, qui peut attirer un grand nombre d’utilisateurs. et IPS en raison de leur propre influence.On peut dire que l’ensemble du système qui a été opéré est positif.

En revanche,La tournée en chaîne actuelle est plus basée sur des rendements purs pour attirer les joueursEssenceEn plus de la faiblesse de la jouabilité, les jeux Web3 sont également confrontés à des problèmes anciens tels que des seuils à usage élevé et des processus d’interaction lourds.

Quelle est la racine de tout cela?Différentes personnes ont des opinions différentes.L’équipe Tabichain estime qu’un facteur important affectant le jeu Web3 est un excellent développeur de jeux traditionnel difficile à entrer dans l’écosystème Web3 en raison de la technologie et des coûts d’apprentissage.Pour ceux qui ne comprennent pas le développement du jeu ou du logiciel, de Web2 à Web3, ce n’est qu’un récit et un environnement, mais la situation réelle est bien pire que prévu.

Alors nous devrionsComment réaliser la technologie pour créer un environnement plus convivial pour les développeurs de jeux traditionnels ou les fabricants connexes?Dans ce qui suit, nous analyserons de manière approfondie les problèmes rencontrés par les jeux Web3 et les solutions correspondantes à partir de plusieurs aspects pour expliquer comment la future industrie du jeu Web3 devrait techniquement plus adaptée aux praticiens de jeu traditionnels.

Les raisons techniques qui entravent les développeurs de jeux traditionnels entrent dans l’écologie web3

Dans l’article précédent, nous avons brièvement mentionné que la haute technologie et les coûts d’apprentissage élevés sont le facteur principal qui entrave les praticiens de jeu traditionnels entrant dans l’écologie Web3.

1. La différence entre l’application WWEB3 et la structure logicielle traditionnelle

La blockchain et l’application (DAPP) sont essentiellement différents de l’architecture logicielle traditionnelle.Les développeurs de jeux traditionnels doivent passer beaucoup de temps pour apprendre la solidité ou d’autres langages de contrats intelligents, et doivent comprendre les méthodes de travail 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 le statut de jeu complexe et une interaction à haute fréquence.Exécuter la logique de jeu sur la blockchain nécessite une simplification ou une reconstruction élevéeParce que chaque opération doit être libérée dans un réseau distribué, puis la chaîne est activée, ce qui est sérieusement limité par les performances et le coût de la blockchain.

2. Concevoir des restrictions sur les contrats intelligents

Bien que l’EVM soit satisfait de l’exhaustivité de Turing et peut théoriquement exprimer une logique arbitraire, ses caractéristiques sont très défavorables pour le développement du jeu, comme:

• Manque de minuterie.Toutes les opérations de la chaîne Ethereum doivent être déclenchées par le compte EOA.Afin d’atteindre l’effet similaire à la minuterie, les développeurs doivent déployer un service supplémentaire pour maintenir un compte EOA et une liste d’événements pour déclencher manuellement la tâche de synchronisation.En raison du retard dans la chaîne, ces tâches de synchronisation ne peuvent pas être terminées à temps.

>

• Il n’y a pas de rappel et d’autres mécanismes, et ne prennent pas en charge le multi-étanches et les asynchrones.Étant donné que la solidité est conçue pour le développement de contrats intelligents Ethereum, son environnement d’exécution est considérablement différent de l’environnement d’exécution traditionnel.Le fonctionnement de l’EVM est transactionnel.Cela signifie qu’un appel de fonction dans la solidité commence jusqu’à la fin de la fin, qui est atomique et ne peut pas être interrompu par d’autres transactions.

• Il n’y a pas de capacité à citer des données externes.Bien qu’il existe une machine prophétique comme ChainLink, que ce soit du point de vue de l’intégration ou des appels de données, sa facilité d’utilisation et sa demande directe HTTPS peuvent obtenir des appels de données.

• Extension et restrictions de performance.La logique de jeu doit être simplifiée ou décomposée en transactions simples multiples pour empêcher les frais de gaz d’une seule transaction d’être trop élevés ou de dépasser la limite maximale, ce qui limite la réalisation d’une interaction et d’une fonction complexes.

3. Limitez le stockage et l’appel des données

• L’espace de stockage des contrats intelligents est coûteux et a une conception limitée, ce qui ne convient pas au stockage d’une grande quantité de données de jeu.

• Il peut avoir besoin d’utiliser des journaux d’événements pour suivre indirectement l’état du jeu, et la saisie de l’événement peut ne pas être instable.Comment actualiser le statut de jeu et d’autres problèmes exigent souvent que les joueurs ou les opérateurs de jeu se déclenchent manuellement.

• La structure de données du compte adoptée par EVM a provoqué une mauvaise capacité d’indexation des donnéesEssenceLorsque vous vérifiez les données d’un certain compte, vous ne pouvez comprendre que l’équilibre de son jeton ETH ou chaîne-primaire, mais quels actifs ERC-20 et contrepoids de chaque actif qu’il ont, ne peut être directement connu.Il en va de même pour NFT.Ces informations sont encapsulées dans les contrats exclusifs de chaque actif, non stockés dans le propre compte de l’utilisateur.

>

Nous pouvons voir à partir d’outils tels que Etherscan et d’autres outils, quel type d’informations telles que le jeton et leurs soldes, etc. Celles-ci sont indexées à partir d’outils périphériques tels que les navigateurs de blockchain. La chaîne.

Les développeurs Web3 ont généralement intégré des fournisseurs de données de troisième partie tels que Etherscan, NFTSCAN, le graphique et même payer leur clé API.De plus, ces services de troisième partie sont l’essence des bases de données sous la chaîne, et il peut y avoir une stagnation, des erreurs, dépasser la limite d’appel et l’échec du service.

Comparons les différences entre les deux de la base de données du jeu et la méthode de stockage des données dans la blockchain.La structure de données de la plupart des jeux est complètement personnalisée par elle-même.

>

4. La difficulté de s’intégrer aux actifs de jeu existants

Les actifs de jeu existants (tels que les accessoires et les personnages) ne sont généralement pas créés et gérés sur la blockchain.Le déplacement de ces actifs vers la blockchain, convertissant généralement les types de données universels mais à longue queue en NFT ou en jeton standard, qui implique des travaux de migration et d’intégration complexes, affectera le système d’économie de jeu existant.

5. MODIFICATION, PATCH ET PRÉVENIR DES COURS

Sur Ethereum, une fois le contrat intelligent déployé, le code est immuable, ce qui rend les programmes de mise à niveau et de réparation plus compliqués que les logiciels traditionnels.Les développeurs utilisent souvent des contrats de proxy ou des modèles de versions pour contourner cette limite, mais cela augmente la complexité de la structure globale.De plus, le risque de divulgation de l’autorité de gestion est également grave.

La mise à niveau du code des jeux traditionnels n’est pas si compliquée dans la structure technique.Le seul possible qui peut devoir être restreint est l’autorité de mise à niveau centralisée,Cela peut être mis en œuvre au lieu de contrats intelligents via DAO et d’autres méthodes.

De plus, les jeux traditionnels effectuent souvent des instantanés de base de données ou des sauvegardes.Cela peut ne pas être important, mais s’il y a un bug majeur lorsque vous rencontrez une mise à niveau, vous pouvez faire reculer rapidement les données, et c’est essentiellement la chaîne de nuit.Même si les données de certains jeux sont annulées par la reconstruction du contrat, comment migrer les données et le statut de l’ancien contrat vers le nouveau contrat est toujours compliqué.

6. Problèmes de division écologique et d’expérience utilisateur

Différentes chaînes publiques et VM, leur langage de contrat intelligent, leur architecture, leur structure de données, etc. sont très différentes.Dans web2, les développeurs de jeux choisiront le moteur avant de la plate-forme croisée comme l’unité, qui peut réaliser un ensemble de codes légèrement adaptés et s’exécute dans différents environnements tels que l’iPhone, Android, le bureau. .

Dans WEB3, il s’agit essentiellement d’espoirs extravagants.

Au niveau de l’expérience utilisateur, la blockchain est interconnectée et son complexe.

Après avoir répertorié les 6 arguments majeurs, résumez: les développeurs de Web2 vers Web3 sont confrontés à un énorme seuil d’adaptation. qui ne savent pas s’ils peuvent réussir.

On peut dire,La plupart des meilleurs développeurs de jeux ne sont pas entrés dans WEB3, dans une certaine mesure, cela fait que la plupart des jeux Web3 se soumettent de la spéculation financière sans joueur et plaisir particulièrement élevésEssence

Il y a aussi la même nature du côté de l’utilisateur.

Y a-t-il un projet de niveau infra qui peut résoudre les problèmes ci-dessus?Tabi Chain peut être l’un des projets qui sont très proches de la solution ultime du jeu Web3.: Les développeurs n’ont pas besoin de se soucier des différences entre diverses machines virtuelles ou environnements d’exploitation, et développer directement ou transplanter les jeux qu’ils connaissent ou peuvent même être personnalisés.

De plus, Tabi Chain a également les caractéristiques du consensus modulaire et des couches de sécurité.

Couche d’exécution Tout-Puissant: Selon les besoins des développeurs pour sélectionner l’environnement d’exécution

Rappelons quelle est l’essence de la blockchain.Certaines personnes peuvent dire qu’il s’agit d’un grand livre décentralisé non-imprévient.Mais s’il est plus proche de l’essence de la technologie, il convient de dire que la synchronisation permanente de l’État vérifiée de la machine d’état dans un réseau distribué est synchronisée.

C’est-à-dire que la blockchain maintient en fait une machine d’état reconnue par l’État et son état de fonctionnement:

• Chaque entrée est certaine, enregistrée dans chaque bloc;

• La fonction de conversion d’état est certaine, qui se manifeste spécifiquement sous forme de machine virtuelle ou s’exécute dans le client blockchain;

• La sortie de l’état est également certaine et elle est également enregistrée dans chaque bloc;

Par conséquent, dans le système consensuel d’une chaîne, il n’y a peut-être pas une seule couche d’exécution (comme uniquement EVM), peu importe combien,Tant que cette chaîne peut vérifier l’état de plusieurs couches d’exécution dessus et laisser chaque jeu fonctionner dans son propre environnement, nous pouvons résoudre les divers problèmes que nous avons mentionnés ci-dessusEssence

>

Dans Tabi, chaque jeu ou DAPP peut créer son propre service indépendant.Tous les services soumettent leurs propres blocs au système consensuel de la chaîne;

existerLe noyau de la couche d’exécution de Tabi All-Around peut être considéré comme une machine virtuelle avec le polymorphisme, il est donc appelé VM du polymorphisme.

>

Pour la VM Blockchain existante, la machine virtuelle de polymorphisme doit inclure la machine virtuelle dans son propre environnement de fonctionnement et fournir la méthode d’appel d’interface correspondante.Le concept de « incluse » a deux implémentations spécifiques ici:

Partager l’état du monde:Semblable à Ethermint, il fournit un soutien à l’EVM sur le cosmos.Mais EVM n’est qu’une couche de surface, en se concentrant sur l’interaction utilisateur, les opérations de contrat, etc., de sorte que toutes les opérations de la côté de l’utilisateur semblent être implémentées sur EVM.Mais les résultats finaux et les données de ces opérations sont toujours stockés dans d’autres modules COSMOS.Cette compatibilité EVM est donc essentiellement la cartographie des données inférieures.

Par conséquent, cette relation de cartographie peut également être étendue à d’autres machines virtuelles.

>

Ceci est similaire à l’utilisation de VMware sur PC pour démarrer une machine virtuelle Windows.Si vous démarrez une machine virtuelle Mac pour le moment, elle peut également monter les données du disque physique de la même manière.De cette façon, de nombreuses machines virtuelles partagent les ressources et le statut du même monde.

>

Les principaux services de la chaîne Tabi utiliseront cette forme de partage de l’État mondial.Par conséquent, tant qu’il y a une adaptation à la machine virtuelle correspondante, le DAPP développé sur la base de la machine virtuelle peut choisir d’être déployé directement sur le service principal plutôt qu’un autre service.

Statut mondial indépendant:En raison des différents besoins des différentes applications et jeux, certains jeux ont des opérations personnalisées et toutes les VM incluent unifié dans la méthode VM du polymorphisme via le « STATURE WORLD ».Par conséquent, l’État mondial indépendant est également nécessaire.

Mais quelle que soit la forme, il doit être vérifié par les nœuds de superviseur, c’est-à-dire que le polymorphisme VM contient toutes les méthodes de mise en œuvre VM ou Runtime.

Cas de transplantation de jeu web2

Le polymorphisme VM est hautement personnalisé, en particulier pour les développeurs Web2, ils peuvent utiliser leur langage et leur cadre familiers pour transplanter toute logique métier en polymorphisme VM.

En supposant que Minecraft veut transplanter à Tabi, le processus général est:

1. Modifiez légèrement le code latéral du service Minecraft (Java, autres langues), déplacez les données qui doivent être sur la chaîne dans une base de données (ou un groupe) et mettre toutes les fonctions qui peuvent provoquer le changement de DB (c’est-à-dire l’état Fonction de conversion) également sélectionnée.

2. L’emballage de la base de données et ces fonctions en tant que package JAR peuvent être comprises comme un programme exécutable pour Java.Enfin, plus JRE est l’environnement de fonctionnement de Java.Ceci est chargé dans la VM du polymorphisme dans son ensemble, et toutes ses données finiront par la chaîne.

3. Il exécutera une autre logique de dos (comme les équipes, les chats, etc.) qui ne seront pas exécutées sur le serveur.

4. Démarrez un service dans la chaîne Tabi et informez la machine virtuelle de polymorphisme dans les nœuds de superviseur pour charger le même JRE.

>

Jusqu’à présent, tous les processus sont terminés.

Pour les développeurs, ces modifications sont achevées sous la langue et le cadre Java d’origine.Il en va de même pour tous les autres jeux de développement.Pour les utilisateurs, l’interaction du jeu n’a pas changé de manière significative.De toute évidence, cette façon de transplanter les jeux Web2 est très rapide et efficace, et elle peut devenir le paradigme de base de l’adoption de masse de jeu Web3.

Détails de la fonction de conversion du statut de jeu STR

L’exemple ci-dessus est le processus général de la transplantation de jeu Web2.Nous devons également en savoir plus sur les détails.Cette fois, nous utilisons un exemple de jeu commun plutôt que spécifique pour afficher les détails qui impliquent dans la couche en cours d’exécution.

Fondamentalement, l’environnement de fonctionnement d’un jeu personnalisé peut être considéré comme une machine d’état qui crée un jeu sur la blockchain, qui s’appelle State Transition Runtime dans Tabi.

>

STR peut s’intégrer dans la VM du polymorphisme par binaire ou module.

Dans un système de blockchain similaire, nous devons assurer la transparence de l’entrée, la visibilité ouverte de la conversion d’état et la capacité d’expression de l’état mondial.Pour répondre à ces besoins, nous devons construire les caractéristiques suivantes:

1. Base de données mondiale (World DB)Contient toutes les données utilisateur qui doivent être enregistrées dans la blockchain.Ces données doivent être précieuses et importantes, donc une structure similaire à la blockchain est nécessaire pour garantir sa disponibilité.Par conséquent, toutes les données ne doivent pas être enregistrées sur la blockchain.Par exemple, dans le jeu, le contenu de chat des utilisateurs n’est généralement pas important et peut être jeté, il n’a donc pas besoin d’être placé sur la blockchain.

2. Il peut exprimer un état mondial complet.Dans de nombreux scénarios, comme dans le jeu, cette expression ne signifie pas nécessairement qu’une traçabilité de niveau élevé – un accumulateur simple suffit, ce qui signifie que la structure de données comme l’arbre Merkel n’est pas toujours nécessaire pour toujours être nécessaire.Cependant, peu importe la structure des données utilisée pour représenter l’état du monde, il est important que le statut mondial de la base de données mondiale puisse être exprimé comme abstrait.

3. Toute fonction qui peut entraîner des changements dans la base de données mondiale est appeléeFonction de conversion d’étatEt doit être encapsulé pendant la conversion de l’État.Toute modification de la base de données mondiale en plus de l’exécution doit être considérée comme illégale et rejetée.

4. L’interface d’entrée et de sortie doit être conforme aux conceptions de l’interprète d’entrée et du proposant de blocs.C’est relativement simple, et je ne fais pas une explication détaillée ici.

La structure organisationnelle suivante est un contenu essentiel dans le STR.Tabi fournira un par défaut SDK pour faciliter les développeurs pour effectuer cette exécution.

Worldd DB

En pratique, les jeux ou les applications sont susceptibles d’utiliser plus d’une base de données, et ces bases de données peuvent être des types différents.Supposons que les jeux spécifiques utilisent en même temps des bases de données relationnelles et des bases de données de valeur clé.

Ce qui suit est un exemple de base de données de relations simples:

>

1. UID: représente un utilisateur unique, il peut être une clé publique ou d’autres identifiants.

2. NONCE: utilisé pour empêcher les attaques de remplacement.

3. Champ de données supplémentaire: tout type de données.

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

>

Fonction de conversion d’état

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

>

Accumulateur d’État mondial

Nous pouvons construire une fatigue de hachage très simple pour représenter l’état du monde:

A_s + 1 = hachage (a_s + hash (requête))

Grâce à cette structure, il peut garantir qu’après toute modification de la base de données mondiale, il y aura toujours un état unique et déterminé pour correspondre à cette opération de modification.

Il convient de noter que cela signifie que cette méthode doit être implémentée dans chaque fonction de conversion d’état.Cette exigence peut être obligée de mettre en œuvre en utilisant des modificateurs, des interfaces, des crochets ou une autre logique unique à la langue.Parce que différentes langues ont des caractéristiques différentes, aucun détail spécifique n’est discuté ici.

Le processus de mise à jour de la base de données de valeurs de clé (KVDB) est le même.

Nombre aléatoire

Il ne devrait pas y avoir de nombres aléatoires dans aucune fonction de conversion d’état, sinon différents résultats entraîneront des résultats différents pendant la vérification, et la cohérence est guidée.Le nombre aléatoire doit être inclus dans les paramètres d’entrée du système.

Résumer

Grâce aux deux exemples ci-dessus, nous pouvons constater que la couche d’exécution All-Around de Tabi Chain offre une grande flexibilité pour les développeurs de jeux de manière modulaire.Parce que nous ne pouvons pas discuter de tous les détails ici, le contenu de base ci-dessus est suffisant pour démontrer que la solution de la chaîne Tabi est très pratique et nouvelle.

Dans le cadre du système Web3 original, les travaux développés sur différentes chaînes et les machines virtuelles n’ont pas de transplantabilité; de compréhension.

Dans Tabi, les développeurs utilisent la langue d’origine, la plate-forme de développement et le moteur.L’amélioration de cette efficacité et la diminution de la complexité sont les niveaux d’indice.

Nous attendons avec impatience sa singularité pour l’adoption de masse du jeu web3, attire les excellents développeurs de jeux de Web2 et apportez web3 avec une valeur de divertissement et une jouabilité réelles.