Network Effects of Web3 Game Engines

***Author: *Ishanee, IOSG Ventures

Network Effects of Web3 Game Engines

Premise Summary: In the first part of the FOG series, we provided an overview of on-chain games and game engines, thanks to the support of Sylve, Tarrence, Andy, Alvirus, Kevin & Iain for this article.

On-chain games and engines are still in their early stages. Game engines like MUD and Dojo, while already usable for product development, have developers in the ecosystem using them, but there is still a long way to go. Game engines typically experience significant network effects as many games are built on their frameworks and add functionalities to them.

In the on-chain gaming ecosystem, the largest network effects come from the composability and scalability of games, as well as the integration of game assets with other games based on the same ecosystem and engine. As open-source libraries allow developers to solve technical issues with community assistance, the stickiness of engines also grows exponentially.

If we imagine the evolution of the game engine ecosystem, their network effects and value accumulation layers might look like the diagram. The module/verifier market could easily be swallowed by engine layers similar to Gnosis Safe modules. By default, the AW layer is composable, but this depends on the choices made by game developers and players regarding the level of composability. Many companies are trying to capture two or more layers in this stack.

Now, let’s delve into the main challenges of online game development and how game engines can address these issues. The problems faced by blockchain game engines include:

Network Congestion

When Crypto Kitties, Axie Infinity, and Loot Realms were released, they all caused congestion across the entire network. How did they solve this? They each created their own chains, namely Flow, Ronin, and Loot Chain. On-chain games require more computational resources, and all games will compete for block space. Therefore, commercially funded teams naturally choose to build their own application-specific L2 scaling layers. They collaborate with RaaS (Rollup as a Service) providers like 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 like Arbitrum Orbit, Starkware L3, and ZkSync Hyperchains mature and become production-ready.

Argus also introduced their new product—an EVM Layer 2 that inserts a data availability layer. This is the base shard. We don’t know more details about it, but it reminds us of Len's Momoka. The EVM base layer will allow other game developers to build highly customizable execution layer game Shards, and the base Shard will become the layer that brings composability to the entire Argus L2.

Slow Blockchain

On the blockchain, the contract state only changes after a transaction is confirmed. If you want f(a) to trigger f(b), the process can only wait. Thus, delays in games seem inevitable. On Ethereum, this would be 15 seconds until the block is resolved, plus an additional 30-45 seconds to overcome reorganization risks.

By using ticks, the state in the game can change automatically without waiting for the transaction to complete. Tick frequency can be understood as the frequency of updates. The tick rate for competitive MMO games is typically 20-30 seconds, while RTS games can have tick rates of up to 60 seconds. Currently, most game developers are making MMO games, so a 20-second tick frequency is relatively ideal. The average block time on rollups is 1-2 seconds (Momoka connects to Polygon PoS every 2 seconds), and Argus's new solution boasts 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 created the first tick chain application on OP Stack and may release it alongside their game (such as treaty.earth).

Developer Experience Needs Improvement

The story behind MUD is that the Lattice team has been trying to create new on-chain games and encountered the same backend issues. So they decided to create a universally adoptable on-chain game development framework. Besides composability, there are two key challenges: faster state synchronization between contracts and player clients, and easy upgrades (modifications/updates) without having to rewrite the indexer (auto-indexer) every time an upgrade occurs.

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

Introduction to Game Engines

This article will introduce four projects that are vying for the position of the leading blockchain game engine standard. Two of them are public goods, while the other two are built by commercial teams that have raised funds in the past. Let’s delve into some higher-level issues and how the teams are addressing them.

MUD v2:

MUD is the most popular game engine, powering over 95% of online games on EVM. The Lattice game engine introduces Store, which can represent on-chain data in a relational database-like manner. The advantage of using Store instead of compiler-driven storage is the upgradability of contract data and large-scale gas costs.

State updates also automatically emit events, allowing the auto-indexer to 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 MUD packs data more efficiently than native Solidity, making it cheaper in the long run.

Store: This is another solution using solid's compiler-driven storage. Storing data in contracts consumes gas and is static/non-inspectable in Solidity, meaning interfaces/applications must assume that their calls are correct. With Store's on-chain database, the contract storage of applications can now be indexed by off-chain indexers, frontends, or another contract. The benefits of using Store include the upgradability of contract data and considerations for large-scale gas costs.

Mode: This is an off-chain indexer that uses PostgresDB. It can index any MUD application on EVM, primarily used for faster state synchronization with the MUD client.

World: This is a framework that includes storage, systems, permissionless 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 the help of on-chain plugins and a set of improved developer tools. Each new plugin introduced to MUD adds value to the framework and engine for the next developer who joins.

Some examples:

• Endless Quest: Generates consistent narratives, metadata, and art in AW
• MUDVRF: A MUD module that generates on-chain random numbers in games
• DeFi Wonderland: Account management module for wallets via burner client
• MUD Scan: Leaderboard dashboard for MUD games

Dojo Engine:

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

In this case, provability means that the same game loop can be proven on the rollup's sequencer or a local client (like a browser). Using Dojo, users can write proof logic to execute on the client, with verification done only on-chain at a low cost. This also enables features like anti-cheat and optimistic updates, allowing logic to be implemented in the player's browser even while the sequencer is still verifying player transactions.

Their data storage solution is similar to MUD's Store but customized for the characteristics of provability and validity proofs. They use Torii to provide automatically verifiable indexing. The indexing is completed using storage differences, providing O(1) indexing and supporting client verifiability of 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 deployment, updates, and interaction with games), and Torii (a verifiable indexer). Dojo offers a Rust SDK that can be compiled into WASM for use 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 a native fog of war mechanism using zkps 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, who recently released their latest (and only) update. It is an ambitious project aiming to create games (studios), game engines, and infrastructure for other developers to extend and deploy. It is currently a closed-source project, but their blog promises that it will be open-sourced upon release.

As previously shared, it is a custom L2 with base sharding and individually customizable game shards. Along with the World Engine (a proprietary game engine), game developers can create unique execution environments using custom parameters (such as higher tick rates, locally customized AA with gas, ECS databases, and compatibility with clients like Unity, Unreal, JS, etc.). They also provide auto-indexers similar to other game engines. They have optimized the L2 & world engine, abstracting content written in Solidity and encouraging game development in 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 talk, which is location-based sharding (such as "Asian server," "European server"), which can further improve game latency. For example, most sequencers are located in the US, while Asian players typically face at least 300 milliseconds of latency, which is a long time in gaming. The entire structure is supported by shared sequencers, which are customized for optimizing latency rather than synchronizing composability and atomic bundling. It does not block the runtime's locks—supporting multiple shards without blocking each other and without enforcing total ordering.

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

Keystone:

The Curio team is the first commercial team to attempt using custom L2 and ultimately collaborated with Caldera to implement their custom OP Stack. They embedded the ECS structure into their tick chain and will provide features like automatic indexing, Unity client support, etc. This is a research and development project that is the 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 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, launching Isaac based on its proprietary game engine on Starknet, with their latest game Shoshin also set to launch soon.

Conclusion:

Today, various engines are striving to enhance tick rates and scale networks, aiming to enable blockchain to support more complex game interactions—this reminds me of the competitive landscape of VR gaming devices from years ago, where new technologies emerged, and companies fought over the transmission bandwidth of VR headsets. Under the call of hardware manufacturers, developers flocked to create VR/AR versions of various game genres. However, as the market was tested, people found that only a few fixed genres were suitable for VR, and the bandwidth issue of headsets was not critical. Similarly, the process of determining the winner among full-chain engines will be the result of a complex system game, but it is foreseeable that those who first find PMF (where there are full-chain blockbuster outputs on the content side above the engine) will have a significant competitive advantage.

We are excited to see the development process of each layer, the release of new games, and the emergence of new engines. Besides MUD v2 and Dojo, the others have not yet been tested in real combat, and we still have a long way to go before we figure out who the Unreal and Unity of the on-chain world are.