Before start
mud2048.fun represents our exploration into the microsensory aspects of fully on-chain game development. The initiative aims to provide a firsthand experience of the temperature of fully on-chain game development by closely replicating the original 2048 game experience (play2048.co) in a fully on-chain version. This endeavor allows us to immerse ourselves in the development of fully on-chain games and gain a frontline understanding through a faithful recreation of the iconic 2048 game on the blockchain platform.
This article is a summary of the experiences gained and reflections unfolded during the development process. It serves as a humble contribution, inviting readers to partake in the insights and reflections derived from this development journey.
This is probably the simplest attempt to develop Fully On-chain Games. Before this, we tried to implement a fully on-chain version of the Chrome Offline Dinosaur Game (Chrome Dino Game), but later found that it was not native to the blockchain. Without the support of the game’s Tick mechanism, it is difficult to reproduce a fully on-chain version that is close to the original game experience.
This may involve a common misunderstanding: it is easier to implement a fully on-chain version of simple games. In fact, this is not the case, because the transaction confirmation time of the blockchain (even mainstream Layer 2 of Ethereum) 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 fully on-chain versions. This also explains to a certain extent the current divisions of the fully on-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.
Why choose MUD?
MUD is the first fully on-chain game engine in the EVM ecosystem (and the first application development framework in the EVM ecosystem). The engine’s built-in Session wallets 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.
Now, let’s delve into the main topic and discuss some insights and experiences we’ve gained while using the MUD. These reflections span both the macro-level, offering a broad industry perspective, and the micro-level, providing practical insights for engineering operations. The intended audience varies, so readers are encouraged to selectively engage with the content based on their interests, skipping sections that may not resonate with their focus.
Engineering
What is MUD in general?
MUD = on-chain relational database + on-chain application development framework.
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, in order for blockchain products to gain wider acceptance, it remains crucial to attract a larger user base from the internet domain. Therefore, it’s advisable to commence our analysis from the perspective of the internet.
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 fundamentally centered around databases, a paradigm we can colloquially refer to as “Database-centric”.
So let’s see if the design of the MUD also follows the “Database-centric” idea. From the design perspective of the MUD, it solves three core problems:
1. How to make data on chain easy to read and write and store in an economic 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 can data on chain be easily read and written and stored in an economical way ?”
This question 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.
Therefore, the solution of MUD is to implement a “ relational database “ on top of chained storage (corresponding to the Table under Store in the MUD). 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 develop the fully on-chain 2048 based on MUD.
The concept of “economic storage” can be analyzed from the perspective of Ethereum, often referred to as the “World computer.”
Modern computers all conform to the “ Von Neumann structure “, which is divided into five parts: Input, Output, Operation, Control, and Sorage (see the figure below).
From the perspective of the fully on-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 What doing. As a “basic application software” running on this “World computer”, the fully on-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 picture below shows a specific case of storage optimization by MUD. For details, see “MUD FROM ZERO TO V2”.
To sum up, for question one, MUD mainly solves the problem from the perspective of “Database-centric”.
Now we come to the second question: “Automatic data synchronization between on-chain/clients”.
This is also a core function provided by the MUD, 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 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 fully on-chain game client).
For developers, having an on-chain database with a user experience closely resembling a local database is an initial achievement. However, in the current implementation of MUD, certain functionalities, such as generating a global leaderboard, are challenging to implement on the client side. Additionally, having each client generate a global leaderboard is not an economical approach.
At this point, many may wonder: why not generate the global leaderboard on-chain? The reason is that, while the MUD has achieved a basic implementation of a relational database, it currently lacks support for common functionalities found in relational databases, such as summation, averaging, and finding maximum and minimum values.
Therefore, in mud2048.fun , we build a Indexer node on a centralized server to generate global player rankings in a relatively balanced cost-benefit manner (see the figure below).
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. However, in my view, these solutions are temporary and do not fully address the issue of increasing on-chain data that needs to be synchronized over time.
This problem seems unsolvable for the time being (it is 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: “ General complexity management of 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 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.
For complex application development, access control (or routing) is a crucial factor that significantly influences the overall engineering effort. The quality of access control design directly determines the complexity and maintainability of application development. Clearly, MUD also places great importance on this aspect, as depicted in the following illustration showing the optimization of the access control module in both MUD v1 and v2.
The above are some of our engineering thoughts and experiences in the process of developing mud2048.fun using MUD. Overall, the MUD also follows the “Database-centric” idea, which is highly consistent with the methodology of Internet application development. Therefore , the MUD will not feel strange to Internet application developers. Next, we will discuss our thoughts on the fully on-chain gaming industry.
Industry
When we enter the field of fully on-chain games, three questions we constantly ask ourselves are:
1. Why is a fully on-chain game needed ?
2. What kind of games are suitable for fully on-chain?
3. What is the relationship between ‘Fully On-chain’ and ‘Crypto native’?
Next, we discuss one by one:
For the first question: Why do we need fully on-chain games ?
This question can be further decomposed into two sub-questions:
1> Why does the blockchain industry need fully on-chain games?
2> Why does the Crypto market need fully on-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’s Support for the fully on-chain games. From an internal logic point of view, without porcelain work, diamonds cannot be made. Layer 2 needs the porcelain work of the fully on-chain game to achieve itself.
There has been no new paradigm in the NFT field to promote its development after the PFP bubble. The difference between NFT and ERC-20 is composability, and the game scene is the natural place for NFT’s composability.
The ultimate goal of fully on-chain games, “Autonomous World” is another elaboration of the ultimate form of the digital world (the last elaboration was the “Metaverse” that was ruined by over-marketing). The Autonomous World has great appeal as a common imagination of mankind for a better future, and fully on-chain games are also highly anticipated as an important way to achieve this goal.
From the Crypto market:
Looking back at the history of the development of the Internet, games are always the first to adopt new technology areas. Games belong to Consumer Apps, making it 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 fully on-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, challenges such as insufficient innovation, unclear business models, and the inability to effectively meet user demands remain persistent issues 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 fully on-chain game PixeLAW.
The interoperability between games may remain a somewhat elusive proposition for quite some time. While fully on-chain games inherit the interoperability aspects of blockchain, from a business/product/ecosystem perspective, it is challenging to envision the short-term development of interoperability between two independent products. This point has also been to some extent disproven during the previous “metaverse” cycle.
Now let’s talk about the third question: What is the relationship between ‘Fully On-chain’ and ‘Crypto native’?
First of all, over-emphasizing “fully on-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 chain. In addition, GubSheep, the founder of “Dark Forest” , originally proposed “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 GubSheep’s original text.
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 is the epitome of Crypto native;
In 2020, CryptoArt is the epitome of Crypto native;
In 2021, DAO is the epitome of Crypto native;
By 2023, Fully On-chain Games with data and logic on chain will be seen as a model of Crypto native.
Fundamentally, Crypto native is more of a philosophy than a dogma.
Fully on-chain is a methodology for embracing the Crypto native philosophy, but one should not bind oneself too tightly to this concept. Similar to centralization/decentralization or revolution/counter-revolution, these are relative concepts. Getting overly fixated on the literal interpretation can lead to dead ends.
So, whether it is fully on-chain games or crypto-native games, what new possibilities do they bring?
I think that after the game logic/rules are made transparent through on-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).
In addition, a fully on-chain game engine like MUD (in fact, it is more appropriate to call it a fully on-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 are blockchain-native Token mechanisms and developer royalty plans like EIP-6969 , which can help developers of these fair items capture value in an external way. This is where blockchain is better than Web2. point.
“Consensus” is not only 51% of the computing power, but also the shared values that exist among societies/groups. In this sense, Crypto-native is a set of values.
Appendix:
1. MUD 2048 website: https://www.mud2048.fun/
2. MUD 2048 project: https://github.com/themetacat/MUD2048
3. MUD website: https://mud.dev/
4. Autonomous Worlds Bible website: https://aw.network/
5. GubSheep’s crypto gaming thesis: https://gubsheep.substack.com/p/the-strongest-crypto-gaming-thesis
