Full Chain Version 2048: What have we learned from using MUD engines?

TL; DR

• The design of the MUD engine follows “database-oriented”
• The AMM moment for full-chain games has not yet come
• Crypto-native is a value

before the start

mud2048.fun is our exploration to gain a microscopic sense of full-chain game development. It aims to experience the full-chain version of the original 2048 game (play2048.co) by replicating it to experience the full-chain game development experience. Water temperature, get a first-line body feeling.

This article is a summary of the experiences and thoughts gained during this development process, and is intended to inspire readers.

This is probably the simplest attempt to develop Fully On-chain Games. Before this, we tried to implement a full-chain version of the Chrome Offline Dinosaur Game (Chrome Dino Game), but later found that it was not native to the blockchain. With the support of the game’s Tick mechanism, it is difficult to reproduce a full-chain version that is close to the original game experience.

Online version of Chrome Dino Game at:https://dinorunner.com/

This may involve a common misunderstanding: it is easier to implement a full-chain version of simple games. In fact, this is not the case, because the transaction confirmation time of the blockchain (even mainstream Layer 2) has not yet reached the level of the interface response time of the centralized server; in addition, after the game logic is uploaded to the chain, it brings engineering complexity that has not appeared in the centralized scenario. , leading to the fact that not all simple casual games can easily implement full-chain versions. This also explains to a certain extent the current divisions of the full-chain game ecology:

Mainly RTS (real-time strategy games), such as: Loot Survivor, Primodium, Sky Strife, Cellula, etc., supplemented by Meta Rules (meta-rules games/sandbox games), such as: PixeLAW, Briq, OpCraft, etc. Both types of games avoid the disadvantages caused by the long confirmation time of blockchain transactions in terms of game form.

The picture shows the startup interface of Sky Strife, URL:https://playtest.skystrife.xyz/

Why choose MUD engine?

MUD is the first full-chain game engine in the EVM ecosystem (and the first application development framework in the EVM ecosystem). The engine’s built-in Session wallet and the test chain Faucet that can be called through API can lower the entry barrier for players.

Another reason is that MUD is open source, has many documents and community materials, and is easy to get started. Whether the game engine is open source involves business model issues that will be discussed specifically below.

Introduction to MUDs. source:https://github.com/latticexyz/mud

Now let’s get to the point. We will talk about some of our experiences in using the MUD engine. There are macro-perceptual industry levels and micro-rational engineering practical levels. They are aimed at different audience groups. You can use them yourself (skip directly). part that is not interesting).

Engineering

What is a MUD engine in general?

MUD engine = on-chain relational database + on-chain application development framework.

MUD Features. source:https://github.com/latticexyz/mud

This is a perspective of looking at the blockchain field from the Internet field (somewhat similar to looking at sea power from the perspective of land power). It is definitely not the most appropriate perspective, but considering that the blockchain has not yet achieved Mass Adoption, blockchain products have to be released. circle, we still need to attract more users in the Internet field, so we might as well look at the analysis from the perspective of the Internet first.

Whether it is “on-chain relational database” or “on-chain application development framework”, they are crucial to the development of Ethereum, the “world computer”。

We learned from Internet application development: the ease of use of the database software/the reasonableness of the database table structure design largely determines the complexity of the entire project development. in other words,Internet application development is carried out with the database as the core, let’s call it “database-based”。

So let’s see if the design of the MUD engine also follows the “database-based” idea. From the design perspective of the MUD engine, it solves three core problems:

1. How to make data on the chain easy to read and write and store in an economical way,

2. Automatic data synchronization between on-chain/clients,

3. General complexity management of application development.

Let’s look at the first question first: “How data on the chain can be easily read, written and stored economically”。

This problem can be broken down into two elements:

1> Easy to read and write

2> Economic storage

After decades of practice in the Internet field, “easiness to read and write”, “relational database” is considered to be the optimal solution. Although the blockchain is a chain storage model that is very different from the traditional database storage model (see the figure below), this model is not friendly even for simple operations in a single scenario (such as summing/averaging the transaction amount of a certain NFT Collection) / find the maximum and minimum values, etc.), not to mention further complex scenarios.

Image Source:https://mempool.space/mining

Therefore, the solution for MUD is to implement a “relational database” on top of chained storage (corresponding to the Table under Store in the MUD engine). For developers, the usage experience is the same as operating common relational databases (such as MySQL, SQL Server, PostgreSQL, SQLite, etc.). This is indeed more friendly to the majority of Internet developers. The figure below shows the corresponding table structure when we developed the full-chain version 2048 based on the MUD engine.

Source:https://github.com/themetacat/MUD2048/blob/main/packages/contracts/mud.config.ts

We can analyze the point of “economic storage” from the perspective of Ethereum, the world computer.

Modern computers all conform to the “Von Neumann structure”, which is divided into five parts: input, output, operation, control, and storage (see the figure below).

Pictures come from the Internet

From the perspective of the full-chain game engine itself, it can only optimize “storage”, because “input” and “output” are on its upper layer and cannot be controlled; “operation” and “control” are the Ethereum blockchain What you are doing. As a “basic application software” running on this “world computer”, the full-chain game engine can only optimize the “storage” input through it.

The specific solution for storage optimization is to implement very efficient and compact “bitpacking” for input data. Since data storage on the blockchain is charged based on data volume, smaller data volume means more Low storage costs. Fully optimized storage costs are the prerequisite for the emergence of large-scale complex on-chain applications. The figure below shows a specific case of storage optimization by MUD. For details, see“Full-chain game engine MUD from 0 to V2”。

Image Source:https://lattice.xyz/blog/mud-zero-to-v2

To sum up, for question one, MUD mainly solves the problem from the perspective of “database-based”.

Now we come to the second question: “Automatic data synchronization between on-chain/clients”。

This is also a core function provided by the MUD engine, which helps developers save themselves the heavy work of managing complex state synchronization.. The specific implementation plan is: real-time synchronization of the on-chain database on the client. In other words, each client has a built-in local copy that is synchronized with the on-chain database in real time.

This is mainly achieved through the Indexer in the MUD engine. The picture below is MUD’s official introduction to Indexer, which is mainly for scenarios where you want to build and run it on the project server (of course, this description also applies to Indexer that automatically runs in the full-chain game client).

Image Source:https://mud.dev/services/indexer

For developers, they initially have an on-chain database with a user experience close to that of a local database. However, with regard to the current implementation of MUD, it is difficult for the client to implement functions such as generating a global list; in addition, it is not an economical approach for each client to generate a global list.

Speaking of which, everyone will definitely ask: Why not generate a global list on the chain? The reason is that although the MUD engine has implemented a preliminary relational database, MUD has not yet supported common functions such as summing/averaging/maximum and minimum values ​​in relational databases.

Therefore, in mud2048.fun, we build a MUD Indexer node on a centralized server to generate a global player ranking in a relatively cost-benefit manner (see the figure below).

URL:https://www.mud2048.fun/

However, allowing each client to have a real-time copy of the on-chain database also has drawbacks. For example, before the application is started, data needs to be synchronized from the chain to establish the latest copy of the chain database locally, which will increase the waiting time for players to enter the game. MUD officials are also aware of this problem and mentioned related optimization solutions (segmented data synchronization and client caching) in the MUD V2 version. However, in my opinion, they are temporary solutions and cannot completely solve the problem of chain to be synchronized over time. There are more and more problems with data.

This problem seems unsolvable for the time being (it will be difficult to achieve major breakthroughs in public network data transmission efficiency and chained data retrieval in the short term). We hope that with the iteration of MUD, a more appropriate solution can be found. If this problem is solved well, it will also pave the way for the birth of complex applications on other chains.

Now we come to question three: “Common complexity management for application development”。

Prior to this, most on-chain applications in the Ethereum ecosystem were relatively simple (an objective indicator is that the number of contracts involved in a single DeFi/NFT/DAO product is limited, and in most cases the possibility of updating after deployment is very small). But for complex application development, logic updates, access control, and permission management are all repetitive tasks that need to be done from scratch. Therefore, there is a great need for a universal framework/engine that can help developers deal with these problems in a unified way, so that developers can devote themselves to application development.

Another core function provided by the MUD engine is to help developers save time in dealing with the above problems through the World module. Specifically, World provides logic and access control on top of the Store. The following figure shows the official website of MUD for World. Description, this is a function provided by general application development frameworks, so I won’t go into details here.

Image Source:https://mud.dev/world/introduction

For complex application development, access control (or routing) is an important link in determining the overall project volume. The quality of access control design directly determines the complexity and ease of maintenance of application development. MUD obviously attaches great importance to this. The figure below shows the optimization of its access control module in MUD v1 and v2 versions.

Image Source:https://lattice.xyz/blog/mud-zero-to-v2

The above are some of our engineering thoughts and experiences in the process of developing mud2048.fun using the MUD engine. Generally speaking, MUD engines also follow the “database-based” idea, which is highly consistent with the methodology of Internet application development. Therefore, MUD engines will not feel strange to Internet application developers. Next, we will discuss our thoughts on the full-chain gaming industry.

Industry

When we enter the field of full-chain games, the three questions we constantly ask ourselves are:

1. Why is a full-chain game needed?

2. What kind of games are suitable for the entire chain?

3. What is the relationship between Fully on-Chain and Crypto native?

Next we discuss one by one:

For the first question:Why we need full-chain games？

This problem can be further decomposed into two sub-problems:

1> Why does the blockchain industry need full-chain games?

2> Why does the Crypto market need full-chain games?

From the perspective of the blockchain industry:

The Ethereum ecosystem has developed to a stage that requires the emergence of complex on-chain applications (in the past, on-chain applications DeFi/DAO/NFT were relatively simple, as can be seen from the number of contracts supporting an application). Another reverse example is the Ethereum Layer 2 pair Support for the entire chain of games. From an internal logic point of view, without porcelain work, diamonds cannot be made. Layer 2 needs all the porcelain work in the whole chain of games to achieve itself.

The NFT field has not had a new paradigm to promote its development after the PFP bubble. The point that distinguishes NFT from ERC-20 is composability, and the game scene is the natural place for NFT composability.

The ultimate goal of the whole chain game”autonomous world” is another elaboration of the ultimate form of the digital world (the last elaboration was the “Metaverse” that became a mess after being over-marketed). As a common imagination of mankind for a better future, the autonomous world has great appeal, and the entire world As an important way to achieve this goal, chain games also have high hopes.

Autonomous Worlds official website:https://aw.network/

Looking at the Crypto market:

Looking back at the history of the development of the Internet, games are always the first to adopt new technology fields. Games are consumer apps and are easier to reach end users.

The blockchain game/GameFi model has been temporarily falsified, and the exploration of blockchain games has returned to the origin of games: gameplay. Blockchain-based gameplay (which fully inherits the advantages and disadvantages of blockchain) promises to provide new experiences and paradigms not available in the past, thus attracting users.

We come to the second question:What kind of games are suitable for the whole chain?？

At present, the industry/market has not yet reached a consensus on this point. From an inductive perspective, the two categories mentioned above are the real-time strategy (RTS) and meta rules (Meta Rules). However, problems such as insufficient innovation, unclear business models, and failure to match users well are still unavoidable problems in this field.

Personally, I think that the Meta Rules class has relatively more potential, because at least it has more native possibilities at the rule level and interoperability level. However, it is still very early and it is difficult to evaluate its certainty. The picture below is The interface of the meta-rules full-chain game PixeLAW.

Image Source:https://twitter.com/0xPixeLAW/status/1704375844674912515

Interoperability between games may be a false proposition for a long time. Although full-chain games inherit the interoperability of blockchain, from a business/product/ecological perspective, it is difficult to imagine two independent products being developed for interoperability in the short term, and this point has also been in the previous “Metaverse” cycle. It has been falsified to a certain extent.

Now let’s talk about the third question:What is the relationship between Fully on-Chain and Crypto native?？

First of all, over-emphasizing “on the whole chain” will make people fall into the vicious circle of fundamentalism. The current infrastructure of the blockchain cannot support a wide range of games to put all data/logic on the chain. In addition, GubSheep, the founder of “Dark Forest”,initial formulationis “Crypto-Native Games”, in order to think about how games can promote the development of the blockchain industry to the greatest extent from the perspective of Crypto-Native. The picture below shows part of the original text of GubSheep.

source:https://gubsheep.substack.com/p/the-strongest-crypto-gaming-thesis

Crypto native is a concept with ever-changing connotations and relatively blurred boundaries.There are different interpretations at different stages of blockchain development.

In 2017, CryptoKitties was considered the epitome of crypto-native;

In 2018, Uniswap was the epitome of crypto-native;

In 2020, CryptoArt is the epitome of crypto-native;

In 2021, The DAO is the epitome of crypto-native;

By 2023, full-chain games, where data and logic are on the chain, are seen as a model of crypto-native.

But essentially encryption is an idea, not a dogma。

Fully on-Chain is a methodology that implements Crypto native, but we cannot be constrained by it., just like centralization/decentralization, revolution/counterrevolution, are all relative concepts, and it is easy to lead to a dead end if you get too entangled with the literal meaning.

So, whether it is full-chain games or crypto-native games, what new possibilities do they bring?

I think that after the game logic/rules are made transparent through the chain, all game strategies can truly compete fairly. Of course, we need to find a scenario that can reflect this advantage. For example, because the game logic is on the chain, you can directly write contract code to play the game, coupled with AI-generated gameplay strategies, it may allow us to have an above-average/sleepless virtual player agent (this idea is inspired by Shoshin inspired).

In addition, a full-chain game engine like MUD (actually, it is more appropriate to call it a full-chain application development framework), as a combination of database + application development framework, is of self-evident importance in the EVMs ecosystem. However, database/application development frameworks are public goods and have no business model at all. Fortunately, there is a native Token mechanism of the blockchain, as well asEIP-6969 Such a developer royalty scheme can help developers of these fair items capture value in an external way. This is the point where blockchain is superior to Web2.

“Consensus” is not only 51% of the computing power, but also the shared values ​​​​that exist among societies/groups. In this sense, cryptography is a kind of value.

appendix:

1. MUD 2048 official website:https://www.mud2048.fun/

2. MUD 2048 project code:https://github.com/themetacat/MUD2048

3. MUD engine official website: https://mud.dev/

4. Autonomous Worlds Bible official website:https://aw.network/

5. GubSheep encrypted native game theory:https://gubsheep.substack.com/p/the-strongest-crypto-gaming-thesis

Disclaimer：

1. This article is reprinted from [MetaCat]. All copyrights belong to the original author [CK]. If there are objections to this reprint, please contact the Gate Learn team, and they will handle it promptly.
2. Liability Disclaimer: The views and opinions expressed in this article are solely those of the author and do not constitute any investment advice.
3. Translations of the article into other languages are done by the Gate Learn team. Unless mentioned, copying, distributing, or plagiarizing the translated articles is prohibited.