Detailed explanation of Web3 game engine: the origin of the track, development status and network effect

By Ishanee @IOSG Ventures

Summary of prerequisites:

We gave an overview of on-chain games and game engines in part 1 of the FOG series, thanks to Sylve, Tarrence, Andy, Alvirus, Kevin & Iain for their support on this article.

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

In the game ecosystem on the chain, the biggest network effect comes from the composability and scalability of the game, as well as the combination of game assets and other games based on the same ecosystem and engine. The stickiness of the engine has grown exponentially as open-source libraries allow developers to solve technical problems with the help of the community.

If we imagine the evolution of game engine ecosystems, their network effects and value accumulating layers might be as shown in the diagram. The module/validator market is easily swallowed by an engine layer similar to Gnosis Safe modules. By default, AW layers are composable, but this depends on the choice of composability level by game developers and players. Many companies are trying to capture 2 or more layers in this stack.

With this in mind, let's dive into the main challenges of online game development and how game engines can address them. Problems faced by blockchain game engines:

Network Congestion

When Crypto Kitties, Axie Infinity, and Loot Realms were released, they all caused the congestion of the entire network. How did they solve it? They created their own chains, namely Flow, Ronin, and Loot Chain, respectively. On-chain games require more computing resources, and all games will compete for block space. Therefore, it is a natural choice for commercialization teams with financial backing to build their own application-specific L2 scaling layers. They cooperate with RaaS (Rollup as a Service) providers such as Caldera, Conduit, Eclipse, Alt Layer, etc. The current popular L2 framework appears to be the OP Stack, and we expect this to change as technologies such as Arbitrum Orbit, Starkware L3, and ZkSync Hyperchains mature and are ready for production use.

The number of requests that caused network congestion when CryptoKitties was released in December

Argus also introduced their new product - EVM layer 2 plugged into the data availability layer. This is the base shard. We don't know any more details about it, but it reminds us of Len's Momoka. The EVM base layer will enable other game developers to build highly customizable execution layer game Shards for their games, and the base shard will be the layer that brings composability to the entire Argus L2.

Low Speed of Blockchain

On the blockchain, the state of the contract will only change after the transaction is confirmed. If you want f(a) to trigger f(b), the process can only wait. As such, lag in games seems inevitable. On Ethereum, this would be 15 seconds until the block is resolved, and another 30-45 seconds to overcome reorganization risk.

By using ticks, the state of the game can be changed automatically without waiting for the transaction to complete. Tick frequency can be understood as the update frequency. Tick rates are typically 20-30 seconds for competitive MMO games, and can be as high as 60 seconds for RTS games. Most game developers are now making MMO games, so a tick frequency of 20 seconds is 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, which is currently the fastest in the industry.

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

Discussion on the average tick frequency of games on the Internet

Developer experience still needs to be improved*

The story behind the MUD is that the Lattice team has been trying to create a new on-chain game and ran into the same backend issue. So they decided to create an on-chain game development framework that can be generally adopted. In addition to composability, there are two key challenges: faster state synchronization between contracts and player clients and easy upgrades (modify/update content) without rewriting the indexer on every upgrade (auto-indexer) .

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 of which are vying for the position of the largest blockchain game engine standard. Two of them are public goods and the other two were built by commercial teams that raised funds in the past. Let's dive into some more advanced issues and how the team can solve them.

MUD v2：

MUD is the most popular game engine, providing the game engine for more than 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 benefits of using Store instead of compiler-driven storage are contract data scalability and large-scale gas costs.

State updates also emit events automatically, so the autoindexer can index the entire state without custom configuration. Compared to Solidity's static data, new data (tables) can be added at runtime, enabling upgradability. Storage costs are comparable to manually emitting events for each state, but MUDs pack data more efficiently than native Solidity, so are cheaper in the long run.

Store: is another solution to use solid's compiler-driven storage. Storing data in contracts is gas expensive and is static/uninspectable in Solidity, which means interfaces/applications must assume that the calls they make are correct. With the Store's on-chain database, an application's contract storage can now be indexed by an off-chain indexer, frontend, or another contract. The advantage of using Store is the scalability of contract data and the consideration of large-scale gas costs.

Mode: This is an off-chain indexer, using PostgresDB. It can index any MUD application on the EVM, mainly for faster state synchronization with MUD clients.

World: is a framework, including the use of storage, system, creation without permission, access control, modules, etc. To sum up, the World contract is a single contract with centralized state and contract logic. It can be extended with the help of on-chain plugins and an improved set of developer tools. Every new plugin introduced to a MUD adds value to the framework and engine for the next developer who joins.

Some examples:

• Endless Quest: Consistent narrative, metadata and art can be generated in AW
• MUDVRF: MUD module that generates random numbers on the chain in the game
• DeFi Wonderland: Use the account management module of the wallet through the burner client
• MUD Scan: leader board for MUD games

Dojo Engine:

Dojo Engine is a public game engine developed by Starknet developers. This is the only game engine that can be verified, and its verification is born for the architecture and tools of the game engine.

Provability in this context means that the same game loop can be proven on a rollup's sequencer or on a native client such as a browser. With dojo, users can write proof logic to execute client-side and only verify it on-chain, at very low cost. This also enables features like anti-cheat and optimistic updates, where the logic is implemented on the player's browser even if the sequencer is still validating the player's transactions.

Their data storage scheme is similar to MUD's Store, but customized for the properties of provability and validity proof. They use Torii to provide automatic verifiable indexing. Indexing is done using stored diffs, providing O(1) indexing, and using stored proofs to support client-side verifiability of the world state. Dojo supports deployment to Starknet as well as high-performance layer 3 sequencers such as 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 to WASM for the browser, used in rust-based games (i.e. using Bevy), and provides bindings for Unity and Unreal (in development).

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

Argus Labs:

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

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

Scott hinted at a unique value proposition in his recent presentation, namely location-based sharding (like "Asian server", "European server"), which could further improve latency in games. As an example, most sequencers are located in the US, and Asian players typically face latency of at least 300ms, which is a long time in games. The entire structure is backed by a shared sequencer tailored to optimize latency rather than synchronous composability and atomic bundling. It has no locks that block the runtime - multiple shards are supported and will not be blocked by each other, nor will a total ordering be enforced.

Cardinal Shard is the first game shard implemented by the company, with 20 ticks per second, comparable to traditional games.

Keystone:

The Curio team was the first commercial team to experiment with a custom L2 and eventually partnered with Caldera to implement their custom OP Stack. They embed the ECS structure into their tick chains and will provide features like automatic indexing, Unity's client support, etc. This is a research and development project, the result of their efforts to build Treaty.earth. More content may be shared with the public when the team is more prepared.

Other attempts:

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

in conclusion:

Today's various engines are trying to increase the tick rate and expand the network, aiming to allow the blockchain to carry more complex game interactions-this reminds me of the competitive landscape of VR game devices in the early years, when new technologies emerged , various companies fought for a long time around the transmission bandwidth of vr headsets. Under the call of hardware manufacturers, developers flocked to try to make a vr/ar version of various games. However, with the inspection of the market, People found that only certain fixed categories are suitable for VR, and the bandwidth problem of the title is not critical. Similarly, the winning process of the full-chain engines will be the result of a complex system game, but it is foreseeable that the one who finds the pmf first (the one with the full-chain blockbuster output on the content side above the engine) will have a greater Competitive Advantage.

We're excited to see the evolution of each layer, the release of new games and the emergence of new engines. Except for MUD v2 and Dojo, none of them have been battle-tested yet, and we still have a long way to go before we figure out who is the unreal and unity of the on-chain world.