Building Virtual Worlds from On-Chain NFTs

We at Quorum Control are excited about the launch of JasonsGame as a part of Satoshi’s Treasure Hunt.

The game itself is a text adventure like Zork or a Multiuser Dungeon (MUD) with a set of challenging puzzles baked in. The prizes for the winners are pre-release Tuples, as well as a bunch of SatoshiTreasure Shamir keys. We had fun putting both the puzzles and story together, but the unique architecture is what differentiates it from those earlier text games.

JasonsGame is built on Tupelo and is driven by ChainTrees. A ChainTree, our unique data structure, is basically an NFT on steroids. ChainTrees are non-fungible tokens owned by private keys to which data can be attached and about which an unalterable history is maintained. ChainTrees are a combination of a tree representing the current state (the data) of an object and a blockchain representing updates to that state (the history). The Tupelo network signs these state transitions as the tree and history are updated, preventing invalid transactions, such as double-spends or history rewrites. Read more about ChainTrees here.

So what parts of JasonsGame are in ChainTrees?

• Every location with relevant commands is a ChainTree
• Every object and artifact is a ChainTree
• The courts keep track of winners in a ChainTree
• Every player has a ChainTree (bag of hodling)

Each player has a wallet and takes ownership of the ChainTrees (artifacts and objects) they find. They can transfer these objects to each other as well as to the world itself in specific scenarios. All these changes in ownership and state are being signed by the Tupelo TestNet in real-time. It can not be overstated how critical it is that Tupelo’s finality is less than a second. A user can take ownership of an item and use it right away. If finality was 10 seconds or a minute (it’s even higher than that on some blockchains) real-time activity would simply not be an option.

The JasonsGame game binary itself is an electron app that we use to generate Windows, MAC and Linux executables. In some sense, the electron app is a wrapper simulating a terminal session and containing some basic logic. The content and puzzles of JasonsGame were almost entirely driven by ChainTrees. The electron app was challenging for a variety of reasons, and if we had a chance to do it over again, we would have used the new Tupelo WASM SDK and built the game client entirely in the browser.

OBJECT CREATION — spawning and transferring artifacts

One of the key puzzles in JasonsGame involves collecting unique artifacts, the player inscribing them (editing their content) and then submitting the artifacts for judgment. If the players track down the right objects and inscribe them with the correct values (derived from 22 clues hidden through the world), they solve the puzzle.

Each artifact in the game is a generated NFT. The logic behind the game determines the rules for spawning new objects and transferring them to the players when they find them hidden at one of the locations in Fae. Because they are NFTs they can be traded among players, but each one is guaranteed to be unique, can not be cloned, and its history can not be altered.

As a simple example of leveraging the ChainTrees history, the final “quest resolver” examined the account that created each of the artifacts submitted for judgment. Although the player could change an artifact’s attributes, the origin of the object that must be “created by a troll” had to have its origin with the appropriate “troll” DID. There was no way a player could alter the history even when the NFT was within their control and in their wallet.

To populate the Fae world with artifacts for the players to discover the game services take advantage of the fact that it is a distributed multiplayer application. The artifact spawning service watches for when a player takes control of an artifact. This triggers the creation of a new artifact NFT. The service randomly selects from a list of the location ChainTrees where artifacts can be hidden and assigns the new NFT to that location. This means there is always one artifact (but only one) for all players to compete to find at any given time.

The DLT is necessary here because players can work together, each collecting and modifying artifacts, and then combining together to win. You need the DLT trust to prevent double-spend of those artifacts or the alteration of key attributes to bypass the game’s puzzles.

OBJECT TRANSFORMATION — joint ownership and grafting

One unique aspect of ChainTrees on the Tupelo network is their flexible ownership use cases. At a basic level, a ChainTree can have one or more owners that are permitted to make modifications to the tree. If Alice and Bob are both owners, either one can modify the ChainTree, with Tupelo providing the trusted history of all changes made. The particularly powerful flexibility comes into play when you “graft” a tree into another. Grafting ChainTrees simply means making one section of a ChainTree a pointer to another ChainTree. By leveraging the built-in ownership rules Tupelo provides, different sections of a ChainTree can have different owners. JasonsGame utilizes this pattern frequently, but the most interesting use case is the location inventories at the Weaver and Binder in Autumn.

Whenever a player visits either of these transformation locations (let’s say the Weaver for this example), a player-location ChainTree gets grafted into the player’s ChainTree, setting its ownership to both the player and the Weaver game service. At this point in the process they are both owners and either could pick it up or update it. As players add elements into this inventory for submission, the element object ChainTrees get grafted into the inventory and gets its ownership set to the Weaver. To hit pause and recap the current structure: a player owned ChainTree grafting a player & Weaver held inventory ChainTree grafting in Weaver owned elements. Now once the player submits an offering to the Weaver, the Weaver generates a new element ChainTree, owned by the player and grafts it into the inventory.

PLAYER GENERATED CONTENT

One exciting option that a multiplayer DLT driven game opens up is new types of player-generated content. In JasonsGame, players can create new objects and locations, update the descriptions and connect them as they wish. Although there were limited applications for this in the puzzles delivered in this round of the game, UGC opens up a wide range of options that could be explored. As an example, we considered puzzles built around players needing to create new locations with specific patterns to how they were connected.

Going beyond puzzles, because these locations are connected NFTs, players could actually start assembling their own worlds, connect them with each other or even trade or sell them if so desired. Tupelo’s fast verified trust opens up a range of unique and interesting possibilities for even deeper player engagement with the game and each other.

EASE OF DEVELOPMENT (particularly compared with smart contracts)

In many of today’s blockchains, logic around NFTs must be baked into a smart contract. This usually requires developers to learn complex languages and specialized APIs. ChainTrees, in contrast, have a simple and straightforward CRUD like API that can be called from a developer’s preferred language. Create, update and changing ownership are just a simple API calls.

While this singular difference is compelling on its own, it also unlocks the potential for a developer to write logic into their application as they would a typical (non-blockchain) app. By having a rich, non-fungible object, combined with the trust of Tupelo, you can securely accomplish 90% of smart contract use cases in off-chain code. JasonsGame is an excellent example of this pattern — the player’s client handles aspects of the logic. However, because Tupelo is providing validation of each ChainTree state change, player’s are unable to lie or hack their way to victory. When a player goes to submit their offering to win, the prize validator is able to look at the history of each ChainTree and compare it against Tupelo to make sure it’s valid. Best of all, these operations are taking place in normal code and in real-time just like the business logic of any other application, but with the added power of a trusted distributed ledger.

Imagine attempting to write this logic inside a typical smart contract. Not only would a developer have to track every state transition with the smart contract, but also each of the validation rules would have to be baked into the smart contract.

Beyond the complexity of development existing smart contract solutions introduce, the performance of these transactions to create, update and transfer ownership would make a good user experience all but impossible.

JasonsGame represents just one of many possible architectures for using the Tupelo DLT to power a compelling blockchain driven game experience. In addition games represent just one of many use cases for a flexible, fast and simple DLT. If you have any interest in exploring a potential use case please reach out and work with us to discover new use cases for this flexible and powerful platform.