For a long time, when we talked about blockchain games, we were based on smart contract platforms like ETH. The reason is obvious: either follow the GameFi route of asset on-chain or the full-chain game route of state on-chain. Regardless of the route, using smart contracts is the simplest implementation method. However, the emergence of inscriptions has led to a different technical implementation method that combines the BTC ecosystem with indexers on non-smart contract platforms. This article will provide a technical summary of the exploration of games, metaverse, and autonomous worlds in the BTC ecosystem, to see how inscriptions and blockchain games are combined.
Another Implementation of Full-Chain Games#
For a typical GameFi game that puts assets on-chain, whether issuing NFTs or FT tokens, smart contract platforms are still the best choice without any hassle. So, can the popular full-chain games from last year be placed on the BTC chain? This question may sound strange: the definition of full-chain games is to write both game logic and assets onto the chain (logic written into the smart contract virtual machine while assets use smart contracts to issue tokens). Since you don't have smart contract functionality, how can you do it?
When I first saw Ordz Game (@OrdzGames) claim to be a fully on-chain game based on BTC, I was curious. In previous articles, we mentioned that inscriptions can upload any file to the BTC segregated witness space, with a size limit of 4M. As a result, domo uploaded "a segment of JSON format code for issuing tokens," creating a market worth billions of dollars for BRC20. So, what if we upload a segment of game code to the chain? Ordz is doing just that.
For web-based mini-games, when players access the game webpage, the code is downloaded to the local browser files and then runs the entire game directly in the browser. Therefore, the "inscription version of full-chain games" only needs to provide an online storage space that can download the game code, and the BTC segregated witness space provides such a DA layer. The principle is as follows:
-
Development: Mini-games are usually developed using HTML, CSS, and JavaScript (JS). HTML is responsible for the structure of the page, CSS handles styles and layouts, while JavaScript is the core responsible for game logic, animations, and user interactions.
-
Hosting: The completed game code and resource files (such as images, audio, etc.) are uploaded to the BTC segregated witness space. This way, users can load the game by accessing a specific URL through their browser. Although the game's logic and execution are entirely completed on the client side (i.e., the user's browser), the game's files still need to be downloaded from the chain to the client.
-
Loading: When users access the game's webpage, the browser downloads the HTML, CSS, and JavaScript files. These files contain all or most of the game's code.
-
Execution: After the download is complete, the browser parses the HTML and CSS, constructing the structure and style of the page. At the same time, the JavaScript code is executed in the browser's JavaScript engine.
-
Interaction: User interactions with the game (such as clicks, drags, etc.) are handled through JavaScript, and the game updates its state and visuals based on these interactions. Since these processes are all completed on the user's device, the response speed is fast, providing a smooth gaming experience.
In summary, while Ordz has indeed uploaded the game code to the chain, it does not strictly meet the definition of a "fully on-chain game," as all game logic is executed off-chain. However, as a GameFi type of inscription mini-game, it has its unique aspects and has issued its own inscription BRC20 token as a utility token (ORDG).
Bitmap as a Metaverse Map#
Bitmap (@bitmapdev) claims to be the first metaverse project in the Bitcoin ecosystem, proposed by Twitter user @blockamoto on June 13, 2023, and subsequently received attention and promotion from some media outlets. Bitmap is based on ordinal theory and bitmap theory. Ordinal theory assigns a serial number to each sat, while bitmap theory simply views each block generated by Bitcoin every ten minutes as a map data structure defined by certain parameters. The combination of the two means treating each block as a map NFT and binding this NFT to a specific sat using ordinals.
The bitmap theory itself only specifies two basic rules:
-
Each block is defined as a "district," represented by the block height.
-
Each transaction within the block is defined as a "parcel," counted sequentially starting from 0.
So-called "inscription" means uploading the district and parcel serial numbers according to the format to the segregated witness space and binding them to sat. For example, for block height 31209, the text (31209.bitmap) needs to be bound to sat to declare ownership. For the 5th transaction in block 31209, the text (5.31209.bitmap) needs to be bound to sat. However, currently, only the owner of the "district" can inscribe the ownership of the "parcel."
Other sub-rules, including the meanings represented by input/output, the number of transactions in the block, etc., can be defined separately by different projects, leading to 2D maps, 3D maps, VR maps, etc.
The well-known protocol BRC420 initially created an avatar and bitmap NFT interaction protocol (using recursive inscription technology and exploring token conversion), forming the product bitmap.game, which is the most famous development team in the bitmap ecosystem. Subsequently, the team created a recursive inscription avatar generation platform (rcsv.io) and the BTC Layer 2 network Merlin Chain, and changed the company name to Bitmap Tech. So, it is important to note that Bitmap Tech and the Bitmap protocol are entirely different things.
During the genesis issuance phase, the total amount of Bitmap that can be minted is equal to the Bitcoin block height. When the Bitmap standard was released, there were already over 700,000 historical blocks. For historical blocks, users can freely choose to inscribe as long as they pay the miner's fee. Within two months of the founder's release, over 700,000 historical blocks were registered.
The total amount of Bitmap is linked to the current Bitcoin block, with Bitcoin producing a block approximately every ten minutes. Therefore, in theory, the total amount is infinite. Each time Bitcoin generates a new block, a new bitmap becomes available for registration (according to the rules, only inscriptions initiated after the block is mined are valid), following a first-come, first-served principle, allowing anyone to inscribe the block number.bitmap as a plain text ordinals inscription to claim ownership of that block. Thus, 144 new blocks are mined daily and available for registration. Currently, mainstream NFT exchanges also update the total amount of BITMAP in real-time.
In terms of total amount, bitmap NFTs do not possess scarcity, so current speculation revolves around some special maps. For example,
-
Special numbers, similar to 888.bitmap
-
Maps generated with special patterns based on official visualization data, similar to Cryptopunk
- Blocks containing important historical events, such as the genesis block, pizza transaction block, etc.
In terms of infrastructure, more exploration comes from front-end rendering based on block data. As shown in the following images:
In summary, bitmap is actually an asset marking protocol that maps unowned assets, "Bitcoin blocks," into NFTs through the Ordinal protocol and bitmap protocol, thereby activating the asset properties of the blocks and generating circulation and collectible value.
LOOT in the Bitcoin Ecosystem#
If bitmap approaches the metaverse from the perspective of parcels, then rootverse (@ordinals_root) and BRC1024 (brc1024_pro) attempt to approach the metaverse from the perspective of characters and equipment, with gameplay similar to LOOT.
We are familiar with Ethereum's LOOT, which is a set of randomly combined text-based NFTs. This set of text descriptions defines the attributes of a piece of equipment, thereby establishing a foundational rule for a metaverse. Others can derive combinability based on these text NFTs, such as 2D image presentations, 3D image presentations, story presentations, etc.
BRC1024 is similar overall, as it defines certain parameters to define components of the metaverse, as shown in the image below, indicating that the ROOT metaverse has a component called "character," with a sub-component called "warrior," which has a maximum quantity of 20,000, and elements representing several attributes of this sub-component, some of which even have multiple options, such as the "skin color" attribute having both white and bronze options.
ROOT (officially named Rootverse) is the first metaverse established by the project team using BRC1024, which specifies 21 tribes (i.e., races and corresponding sub-races), with different quantities for each sub-race, allowing players to mint a total of 210,000 character NFTs for free. As shown in the image below:
In summary, if BRC20 inscribes the "code for issuing FT tokens" into the segregated witness space to achieve FT code issuance, then BRC1024 inscribes the "code for issuing metaverse components" into the segregated witness space to achieve the issuance of metaverse components, while ROOT inscribes the "character race" component. This reflects the combinability of inscriptions.
General State Machine for On-Chain Games#
With the metaverse map, characters, and equipment in place, can we create a complete blockchain game based on the BTC chain? If we only follow the GameFi route of putting assets (including NFT assets and FT assets) on-chain, the current infrastructure is sufficient. However, for more crypto-native on-chain games (autonomous worlds), it is not enough.
The Dojo in the Ethereum ecosystem first proposed the concept of "provable on-chain games." Dojo is a framework for developing on-chain games. It is a community-built, verifiable game engine and toolchain for constructing on-chain games and autonomous worlds. Dojo allows for the verification of game states and computations without a large consensus scheme. Games written in languages like Cairo and Noir or running on RISC-Zero can operate independently on a browser-like standalone zkVM, with verifiable outputs ensuring real execution. In other words, it uses efficient VMs for off-chain computation, while the on-chain part only verifies data to ensure the results are real and valid, achieving "trustlessness" and "decentralization."
Redux Protocol (@AutonomousRedux) referenced the concept of verifiable on-chain games from Dojo and, using ordinal theory, implemented a framework for developing on-chain games in the BTC ecosystem. Although the BTC chain has a block time of up to 10 minutes and lacks smart contract functionality, to realize on-chain game development in the BTC ecosystem, it can only be done through off-chain computation and on-chain verification.
Interestingly, Redux has expanded the use cases of "inscriptions." As is well known, previous inscriptions were mainly used for issuing tokens, either as Ordinal NFT tokens or FT tokens like BRC20. Redux combines Merkle trees with inscriptions to propose the concept of stateful inscriptions. This means modeling and storing character and equipment attributes in the game using a Merkle tree structure, ensuring data immutability. If any part changes, the root hash will change.
The specific approach divides stateful inscriptions into two parts: one part is "immutable state," such as weapon health, armor value, attack value, etc. This part is recorded on the BTC blockchain as inscriptions. The other part is "mutable state," such as the specific data of health, armor value, and attack value mentioned earlier, which changes as the game progresses. This data is computed and processed by off-chain indexers. The "inscription" itself actually stores a pointer that points to the set of mutable states of that inscription.
Developers are responsible for constructing the basic framework of the world and its state inscriptions. This includes defining which states are immutable (static) and which are mutable (dynamic), while establishing the logic for user interaction with state inscriptions. The Redux protocol provides an operating environment that allows developers to customize how players interact with state inscriptions. Players experience the game by interacting with state inscriptions.
From a technical perspective, it is somewhat similar to Dojo or Paima. Dojo uses ZKP to create verifiable on-chain games, Paima uses NFT state compression to create verifiable on-chain games, while Redux uses stateful inscriptions (utilizing Merkle trees) to create verifiable on-chain games. Another difference is that Dojo uses Starknet as the DA layer, Paima uses its own sovereign rollup as the DA layer, while Redux uses the DA layer of the BTC ecosystem.
In summary, we find that the above projects explore different aspects of games using the Ordinal protocol: Ordz inscribes the code of web games on-chain, Bitmap maps BTC blocks as random data sources into map NFTs, ROOT inscribes character roles and equipment in code form on-chain, while Redux inscribes verifiable data of state machines on-chain. If we must draw analogies with Ethereum ecosystem projects, Ordz is comparable to TreasureDAO, Bitmap is comparable to SandBox and DecentraLand, ROOT is comparable to LOOT, and Redux is comparable to Dojo and Argus.
References
https://www.panewslab.com/zh/articledetails/leqfrx2o.html
https://rcsv.gitbook.io/brc-420/
https://www.panewslab.com/zh/articledetails/22531q6583yt.html