In-depth explanation of Web3 game engine: Origins and development status of racing tracks, as well as network effects.

Web3 game engine: Overview of racing tracks' origins, development, and network effects.

Author: Ishanee @IOSG Ventures Summary:

In the first part of the FOG series, we gave an overview of on-chain games and game engines. Thanks to Sylve, Tarrence, Andy, Alvirus, Kevin & Iain for their support of this article.

On-chain games and engines are still in their early stages. Although game engines such as MUD and Dojo are already being used for product development and there are developers using them in the ecosystem, there is still a long way to go. Game engines typically experience huge network effects as many games are based on their frameworks and add features to the frameworks.

In the on-chain game ecosystem, the biggest network effects come from the composability and scalability of games, as well as the combination of game assets with other games based on the same ecosystem and engine. With open-source libraries allowing developers to solve technical problems with the help of the community, the stickiness of the engine is also growing exponentially.

• An Explanation of Loopring L3: A Specific Application Rollup Deployed on a Universal Rollup
• Decoding ERC-6551: Using NFT as a linked governing smart contract
• Full Chain Online Game: Inheritance of Will MUD & Dojo

If we imagine the evolution of the game engine ecosystem, their network effects and value accumulation layers may look like the figure below. The module/validator market is easily engulfed by the engine layer, similar to Gnosis Safe modules. By default, the AW layer is composable, but this depends on the level of composability chosen by game developers and players. Many companies are trying to capture two or more layers in this stack.

So let’s delve into the main challenges of online game development and how game engines solve these problems. Challenges faced by blockchain game engines:

Network congestion

When Crypto Kitties, Axie Infinity, and Loot Realms were released, they all caused congestion on the entire network. How did they solve it? They each created their own chain, Flow, Ronin, and Loot Chain, respectively. On-chain games require more computing resources, and all games will compete for block space. Therefore, well-funded commercial teams naturally choose to build their own application-specific L2 scaling layer. They work with RaaS (Rollup as a Service) providers such as Caldera, Conduit, Eclipse, and Alt Layer. The currently popular L2 framework seems to be OP Stack, and we expect this situation to change as technologies such as Arbitrum Orbit, Starkware L3, and ZkSync Hyperchains mature and become production-ready.

The number of requests that caused network congestion during the release of CryptoKitties in December

Argus also introduced their new product, the EVM Layer 2 with insertable data. This is the base shard. We don’t know much about its details, but it reminds us of Len’s Momoka. The EVM base layer will enable other game developers to build highly customizable execution layers called game shards for their games, and the base shard will become the layer that brings composability to the entire Argus L2.

The Slowness of Blockchain

On the blockchain, contract states only change after transactions are confirmed. If you want f(a) to trigger f(b), you have to wait for this process. Therefore, delays in games seem inevitable. On Ethereum, this will be 15 seconds until blocks are resolved, and an additional 30-45 seconds to overcome reorganization risks.

By using ticks, the state in the game can be automatically changed without waiting for transaction completion. The tick frequency can be understood as the update frequency. The tick rate for competitive MMO games is usually 20-30 seconds, while for RTS games it can be up to 60 seconds. Now, most game developers are making MMO games, so a 20-second tick frequency is quite ideal. The average block time on rollups is 1-2 seconds (Momoka connects to Polygon PoS every 2 seconds), and Argus’ new solution has a tick frequency of 20 ticks/second, making it the fastest in the industry.

The 0xCurio team is the first commercial team to use custom L2s (via Caldera) to optimize faster tick rates. They have already created the first tick chain application on the OP stack and may release it with their game (such as treaty.earth).

Discussion of the average tick frequency of games on the network

Developer Experience Still Needs Improvement

The story behind MUD is that the Lattice team has been trying to create new on-chain games and has encountered the same backend problem. So they decided to create a universally adoptable on-chain game development framework. In addition to composability, there are two key challenges: faster state synchronization between contracts and player clients, and ease of upgrading (modifying/updating content) without having to rewrite the indexer (automatic indexer) every time an upgrade is made.

In this article, we will assume that all applications built on the same game engine framework are composable.

Game Engine Introduction

This article will introduce four projects, all vying for the position of the dominant blockchain game engine standard. Two are public products, and two are built by commercial teams that have raised funds in the past. Let’s delve into some more advanced issues and how the teams are addressing them.

MUD v2：

MUD is the most popular game engine, providing game engines for over 95% of online games on EVM. Lattice’s game engine introduces Store, which can represent on-chain data in a way similar to a relational database. The advantage of using Store instead of compiler-driven storage is the upgradability of contract data and the large-scale gas cost.

State updates also automatically emit events, so automatic indexers can index the entire state without custom configuration. Compared to static data in Solidity, new data (tables) can be added at runtime, thus achieving upgradability. The storage cost is comparable to manually emitting events for each state, but MUD packs data more efficiently than native Solidity, so it is cheaper in the long run.

Store: is another solution that uses the Solid compiler-driven storage. Storing data in a contract consumes Gas and is static / non-inspectable in Solidity, meaning that interfaces / applications must assume that the calls they make are correct. Through the on-chain database of Store, the contract storage of the application can now be indexed by off-chain indexers, front-ends, or another contract. The advantage of using Store is the upgradability of contract data and the consideration of large-scale gas costs.

Mode: This is an off-chain indexer that uses PostgresDB. It can index any MUD application on EVM and is mainly used for faster state synchronization with MUD clients.

World: is a framework that includes storage, systems, no permission creation, access control, modules, etc. In summary, the World contract is a single contract with centralized state and contract logic. It can be extended with on-chain plugins and a set of improved developer tools. Each new plugin introduced into MUD adds value to the framework and engine for the next developer to join.

Some examples:

• Endless Quest: Consistent storytelling, metadata, and art that can be generated on Arweave

• MUDVRF: A MUD module for generating on-chain random numbers in games

• DeFi Wonderland: An account management module for wallets that uses a burner client

• MUD Scan: A leaderboard for MUD games

Dojo Engine:

The Dojo Engine is a public game engine developed by the developers of Starknet. It is the only verifiable game engine, and its verification is born out of the architecture and tools of the game engine.

In this case, verifiability means that the same game loop can be proven on both the rollup sequencer and the local client (such as a browser). With Dojo, users can write proof logic to execute on the client and only verify on-chain, which is cost-effective. This also makes features like anti-cheat and optimistic updates possible, with the logic implemented on the player’s browser even as the sequencer still verifies their transactions.

Their data storage scheme is similar to the Store of MUD, but has been customized for the verifiability and efficiency properties of proofs. They use Torii to provide automatically verifiable indexing. The index is completed using storage diffs, providing O(1) indexing, and supports client verifiability of the world state using storage proofs. Dojo supports deployment to Starknet as well as high-performance Layer 3 sequencers like Katana and Madara. Dojo provides Katana (a local development network), Sozo (a command-line interface for deploying, updating, and interacting with games), and Torii (a verifiable indexer). Dojo provides a Rust SDK that can be compiled into WASM for use in Rust-based games (i.e., using Bevy) for browsers, and provides bindings for Unity and Unreal (under development).

Game developers are encouraged to write applications in Cairo. Cairo is a Rust-like language for creating verifiable programs for general computation. One advantage of building on Dojo is that you can introduce fog-of-war mechanisms that use zkps natively, without having to write code in Circom on Solidity.

Argus Labs:

Argus Labs was founded by Scott, one of the co-founders of Dark Forest, and recently released their latest (and only) update. It’s an ambitious project that aims to be an infrastructure for creating games (studios), game engines, and for other developers to extend and deploy. It’s currently a closed-source project, but their blog promises that it will be open-sourced upon release.

As described in previous shared content, it is a custom L2 with basic sharding and personally customizable game shards. With the World Engine (proprietary game engine), game developers can create unique execution environments with custom parameters (such as higher tick rates, local AA with gas customization, ECS database, and compatibility with clients such as Unity, Unreal, JS). They also provide an automatic indexer similar to other game engines. They optimized L2 & world engine, which makes content written in Solidity abstract and encourages game development with Go. In traditional game development, while Go is a perfect programming language, it is not the preferred language as most engines and libraries support C, C++ and C++.

Scott hinted at a unique value proposition in his recent speech, which is location-based sharding (such as “Asia server”, “Europe server”), which can further improve game latency. For example, most sequencers are located in the United States, and Asian players usually face at least 300 milliseconds of latency, which is a long time in the game. The entire structure is supported by a shared sequencer, which is customized to optimize latency rather than synchronous composability and atomic bundling. It does not block the lock of the runtime-supports multiple shards and is not blocked by each other or forced to enforce total ordering.

Cardinal Shard is the company’s first game Shard, which ticks 20 times per second, which is equivalent to traditional games.

Keystone:

The Curio team is the first commercial team to try using a custom L2 and eventually worked with Caldera to implement their custom OP Stack. They embedded the ECS structure into their tick chain and will provide features such as automatic indexing, Unity client support, etc. This is a R&D project and a result of their efforts to build Treaty.earth. More content may be shared with the public when the team is better prepared.

Other attempts:

While these four are the most cutting-edge and well-known custom game engines in the EVM/Ethereum ecosystem, several other custom game engines are being built by teams such as Playmint and Solana (Arc by Jump Crypto). Topology is another explorer at the forefront of online games and has launched Isaac based on its proprietary game engine on Starknet, and their latest game Shoshin will be launched soon.

Conclusion:

Today, various engines are trying to improve tick rates and expand networks in order to enable blockchain to support more complex game interactions. This reminds me of the competition among VR game devices in the earlier years. With the emergence of new technology, each company fought over the transmission bandwidth of VR headsets. Under the call of hardware manufacturers, developers rushed to try to make various types of games into VR/AR versions. However, as the market validated, people found that only certain fixed categories were suitable for VR, and the bandwidth problem of the headset was not critical. Similarly, the process of determining the winner among the whole-chain engines will be the result of a complex system game, but it can be foreseen that the one who finds the PMF (which has a full-chain explosive output on the content side) will have a greater competitive advantage.

We are pleased to see the development process of each layer, the release of new games, and the emergence of new engines. Except for MUD v2 and Dojo, none of the others have been tested in actual combat. Before we figure out who is the Unreal and Unity of the chain world, we still have a long way to go.

We will continue to update Blocking; if you have any questions or suggestions, please contact us!