Construire un monde virtuel : comment utiliser la technologie blockchain pour garder l'heure des « dieux numériques » ?

Adresse d'origine :

Traduit par : Justin @captainz

En tant que créateurs de mondes virtuels, notre objectif est de créer des environnements amusants et profondément engageants pour les utilisateurs. Cela nous oblige à trouver un équilibre entre la conception d'une physique numérique qui permet l'émergence de comportements complexes et inattendus et la garantie que l'infrastructure existante peut prendre en charge ces comportements. Pour ce faire, nous devons considérer trois dimensions principales de la physique numérique : le temps, la forme de ses lois et la mesure dans laquelle ces lois s'appliquent.

temps

Nous nous référons au passage du temps dans le monde virtuel comme l'application itérative des lois du monde à lui-même. Chaque application discrète est un "instant" dans l'écoulement du temps dans ce monde. Une façon de concevoir le temps dans le monde est de le rendre continu avec le temps extérieur. Dans un monde virtuel basé sur la blockchain, chaque bloc correspond à un certain nombre de moments passés dans le monde, quelles que soient les transactions contenues dans le bloc. C'est ce qu'on appelle le temps synchrone, ou le phénomène de "tic". Cette approche peut rendre le monde plus intéressant pour les utilisateurs car ils peuvent voir les résultats de leurs actions en temps réel. De plus, cela se traduit par un temps plus long dans le monde et le monde continue de se mettre à jour, ce qui encourage des comportements intéressants.

Cependant, cette approche a aussi ses inconvénients. Les délais plus importants nécessitent généralement plus de ressources informatiques, qui peuvent rapidement dépasser les capacités de la chaîne ou du serveur. Il peut également être difficile de mettre en œuvre ce système sur une blockchain normale, car tous les changements en chaîne doivent être initiés par des transactions initiées par des utilisateurs externes.

Cette difficulté devient évidente lorsque vous imaginez quelque chose d'apparemment simple : un jeu en chaîne avec des personnages non-joueurs (PNJ). Sur le réseau principal Ethereum, vous pouvez définir une fonction de mise à jour qui définit la position de chaque PNJ sur la carte du jeu, et faire en sorte qu'un compte externe l'appelle périodiquement pour mettre à jour sa position. Mais cela peut ne pas être fiable, car vous ne pouvez pas garantir que le compte externe ne sera pas surenchéri pour les frais de gaz dans le bloc qui devrait appeler la mise à jour. La structure temporelle de votre jeu va donc dériver (prenez l'exemple de la fonction originale CryptoKitties giveBirth() ; à mesure que les frais de gaz sur la chaîne augmentent, Axiom Zen doit en fait augmenter la récompense pour avoir appelé la fonction giveBirth pour s'assurer que le nouveau NFT La transaction de naissance est appelée 256 blocs après que l'utilisateur a élevé Kitty). Nous appelons cette méthode d'utilisation des comptes externes le "tic-tac manuel".

Les cumuls personnalisés nous donnent plus de flexibilité pour ajouter une fonctionnalité "tick" sur la chaîne, pas besoin de comptes externes, et la progression du temps synchronisé est garantie par le protocole. Nous appelons cette méthode "auto-tick". Les ticks automatiques peuvent être implémentés en écrivant un "contrat de tick" qui est appelé par le protocole lui-même plutôt que par un compte externe.

À titre d'exemple, @therealbytes a développé une chaîne de ticks de preuve de concept basée sur la pile OP qui exécute une implémentation du jeu de la vie de Conway qui se déclenche automatiquement (vous pouvez en trouver une vidéo de démonstration ici). Bytes utilise une transaction système modifiée pour invoquer automatiquement le contrat de simulation d'automate cellulaire tick-tick. Afin de tester pleinement les limites de la chaîne elle-même, il a implémenté le jeu de deux manières : l'une sous la forme d'un contrat intelligent Solidity fonctionnant sur la chaîne, et l'autre sous la forme d'une précompilation de la chaîne elle-même. L'implémentation Solidity maximise le CPU après avoir atteint une grille 70x70 avec deux mises à jour par bloc (1 bloc/sec, ou environ 10k cellules/sec), tandis que la chaîne du moteur précompilé personnalisé utilise environ 6% Atteindre le même taux pour un 256x256 grille avec un processeur plus élevé (environ 130k cellules/sec).

Dans la dernière phrase du dernier paragraphe, le mot clé est "atteindre la limite". Les chaînes tick-tick ajoutent une couche supplémentaire de complexité : chaque bloc supplémentaire nécessite que plus d'états soient touchés par des transactions qui simulent le jeu. A terme, les nœuds cumulatifs seront limités par le calcul brut (CPU, E/S disque, etc.). La seule solution ici est d'utiliser des nœuds de plus grande capacité.

Une alternative au "temps synchrone" est le "temps asynchrone". Selon ce schéma, le passage du temps dans le monde n'avance pas nécessairement à mesure que le temps extérieur avance. Au lieu de cela, le temps avance généralement lorsque certains événements (généralement des actions de l'utilisateur) se produisent. Les jeux de société traditionnels qui n'impliquent pas de minuterie entrent dans une catégorie similaire. Il est plus facile d'atteindre le temps asynchrone sur la chaîne car c'est le modèle que les chaînes de blocs sont conçues pour prendre en charge. Cependant, il sacrifie également certaines fonctionnalités qui pourraient rendre le monde plus intéressant (comme le déplacement automatique des PNJ).

WildWood, une première version d'un jeu de preuve de concept de @notdavidhuang et cha0sg0d, révèle ce sacrifice. Dans ce jeu, deux joueurs doivent défendre leur base contre un siège de PNJ agressifs. Dans les versions précédentes du jeu, le mouvement des PNJ n'était déclenché que lorsque le joueur se déplaçait lui-même - une implémentation peu pratique du temps asynchrone. Après avoir ajouté des ticks, les PNJ se sont déplacés, mais un autre problème a persisté. La chaîne coche toutes les secondes, ce qui signifie que si le joueur se déplace plus d'une fois par seconde, le jeu doit diffuser la position du joueur sur la carte avec des mises à jour du cumul optimiste. Cependant, vos coéquipiers ne verront pas automatiquement votre client, ce qui signifie qu'il y aura un retard dans les mises à jour de la position des joueurs. Pour surmonter ce problème, l'équipe a utilisé le service de relais de MUD, un réseau peer-to-peer pour diffuser les clients locaux sur toute la chaîne. Voilà, le passage du temps asynchrone au temps synchrone est accompli.

Lois des formes fermées et ouvertes

Les constructeurs de monde doivent également décider si leur monde virtuel suit une représentation de forme ouverte ou fermée. Les expressions de forme fermée ont un nombre fixe d'opérations. Cependant, le nombre d'opérations exprimées sous forme ouverte (ou récursive) croît en fonction des variables données. Sous des représentations de forme ouverte, l'état futur du monde ne peut être calculé qu'en appliquant à plusieurs reprises les lois du monde à des états connus. Les environnements graphiques complexes, comme Dwarf Fortress, entrent généralement dans cette catégorie. Les représentations de forme fermée, d'autre part, permettent de calculer n'importe quel état futur à partir des états passés et du temps écoulé entre eux (en supposant qu'aucune action future de l'utilisateur ne modifie l'état), comme les taux d'extraction des ressources dans Age of Empires II.

Les formes ouvertes peuvent rendre les mondes virtuels plus intéressants car, comme le monde réel, ils sont imprévisibles. Prédire l'état futur du monde nécessite de plus en plus de temps et de ressources informatiques (le jeu de la vie de Conway implémenté en chaîne en est un bon exemple : vous ne pouvez pas calculer des états futurs arbitraires car vous devez exécuter le jeu à temps). De plus, des comportements macroscopiques inattendus peuvent émerger de simples interactions microscopiques. Dans un monde régi par une forme fermée, ces comportements émergents ne se produisent généralement qu'à l'extérieur, à travers les actions des utilisateurs (eux-mêmes comme dans la forme ouverte), et non à l'intérieur de la physique du monde elle-même.

L'arbitrage entre formes ouvertes et fermées implique un équilibre semblable à celui du temps. Les formes fermées peuvent rendre le monde potentiellement moins intéressant, mais elles le rendent également plus efficace sur le plan informatique. La forme fermée peut être utilisée avec une heure synchrone ou asynchrone. Lorsqu'ils sont implémentés sur une blockchain, ils présentent des avantages significatifs par rapport aux formes ouvertes en matière de synchronisation temporelle. Étant donné que le coût est constant pour n'importe quelle durée, le monde peut être conçu de sorte que l'état de la chaîne ne soit mis à jour que lorsqu'un utilisateur envoie une transaction, mais il est défini sur l'état après le temps écoulé depuis la dernière mise à jour.

Plage de temps et de forme

Considérez l'approche standard actuelle de la dynamique en chaîne, une approche connue sous le nom de "mises à jour paresseuses". Dans une mise à jour paresseuse, le joueur initie le début et la fin d'une action, mais les temps intermédiaires sont simulés plutôt que calculés directement. Par exemple, un joueur plante un pommier dans le 1er morceau, puis récolte les pommes dans le 10e morceau. Une logique de mise à jour paresseuse peut être écrite pour que les joueurs puissent récolter une pomme par unité de temps, soit un total de 9 pommes. C'est parfaitement bien pour la logique de mise à jour avec des fonctions de formulaire fermées (comme une pomme par bloc), mais échoue si la logique agricole change en fonction de l'entrée entre les actions du joueur. Si au bloc 5, une forte pluie augmente le taux de croissance des pommes et qu'au bloc 7, une invasion de criquets détruit presque la récolte, alors au bloc 10, peu importe le nombre de pommes que le joueur peut récolter. événements qui se sont produits (vous n'aurez pas assez de puissance de calcul pour rattraper le nouvel état). Pourtant, les mises à jour paresseuses sont idéales pour les calculs bon marché de certains monstres (comme les plantes avec un taux de croissance fixe), mais ce n'est toujours pas suffisant pour une boîte à outils complète pour un monde dynamique.

Dans le monde réel, le temps est partout et passe tout à la fois, et l'univers est potentiellement infini (bien qu'avec quelques complications de relativité). Dans un monde virtuel, cependant, ce n'est pas nécessairement le cas.

Premièrement, les mondes virtuels peuvent être nettement limités. Les possibilités d'intrigue augmentent généralement avec la taille - il se passe plus de choses dans un monde de 20 milliards de galaxies que dans un monde de deux atomes - mais le coût de calcul aussi. Ces deux relations sont étroitement liées aux deux compromis mentionnés précédemment : le passage du temps et la forme physique.

Deuxièmement, le temps ne doit pas passer partout dans le monde virtuel. Le monde peut être divisé en régions discrètes avec des laps de temps différents pour réduire la charge de calcul du monde. Par exemple, des règles de physique plus complexes et coûteuses pourraient être utilisées dans les zones d'activité des utilisateurs, et des règles de physique plus simples dans les endroits où il n'y a pas d'activité. L'inconvénient de cette approche est double : elle peut donner l'impression que le monde est incohérent et manquer d'exhaustivité, ce qui limite l'espace de conception des règles mondiales et met la pression sur les constructeurs du monde pour éviter de dérouter les utilisateurs ; Limiter la propagation de la causalité dans le monde, si les actions d'un territoire ne peut avoir de conséquences dans des territoires éloignés, l'espace entre les deux est figé dans le temps. La taille de la zone où les règles de physique s'appliquent est une considération de conception importante qui affectera les ressources dont un monde a besoin et le niveau de plaisir qu'il peut atteindre.

Afin de créer un monde virtuel intéressant et engageant, il est nécessaire d'équilibrer soigneusement l'efficacité informatique et le plaisir. Cela inclut de décider du type de temps à utiliser (synchrone ou asynchrone) et d'évaluer la forme des lois de la physique qui régissent le monde. La taille de la zone à laquelle s'appliquent les lois de la physique est une autre décision importante. En faisant ces choix avec soin, les constructeurs de mondes peuvent non seulement garder la charge de calcul du monde intéressante à gérer, mais ils peuvent également fournir aux autres développeurs une base très fertile pour l'innovation.