By Ishanee @IOSG Ventures

Premise Summary:

We gave an overview of on-chain games and game engines in the first part 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. Game engines like MUD and Dojo are already able to be used for product development and are already being used by developers in the ecosystem, but there is still a long way to go. Game engines often experience huge network effects because many games are based on their frameworks and add features to them.

In the on-chain gaming ecosystem, the biggest network effect comes from the composability and scalability of games, and the combination of game assets with other games based on the same ecosystem and engine. The stickiness of the engine also grows 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 accumulation layers may look like this. The module/validator market could easily be swallowed by an engine layer similar to the Gnosis Safe module. The AW layer is composable by default, but it is up to game developers and players to choose the level of composability. Many companies are trying to capture 2 or more layers in this stack.

At this point, let’s dive into the main challenges of online game development and how game engines can solve these problems. Problems 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 created their own chains, namely Flow, Ronin, and Loot Chain. On-chain games require more computing resources, and all games will compete for block space. Therefore, it is natural for commercial teams with financial support to choose to build their own application-specific L2 extension layer. They work with RaaS (Rollup as a Service) providers such as Caldera, Conduit, Eclipse, Alt Layer, etc. The current popular L2 framework seems to be OP Stack, and we expect this to change as technologies such as Arbitrum Orbit, Starkware L3, and ZkSync Hyperchains mature and become available for production use.

Number of requests that caused network congestion during the CryptoKitties launch in December

Argus also introduced their new product - EVM layer 2 that plugs into the 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 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.

The slow speed of blockchain

On the blockchain, the state of a contract will not change until the transaction is confirmed. If you want f(a) to trigger f(b), this process can only wait. Therefore, delays in the game seem inevitable. On Ethereum, this will be 15 seconds until the block is resolved, and another 30-45 seconds to overcome the risk of reorganization.

By using ticks, the state in the game can be changed automatically without waiting for transactions to complete. Tick frequency can be understood as the frequency of updates. Competitive MMO games usually have a tick rate of 20-30 seconds, and RTS games can have a tick rate of up to 60 seconds. 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's 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 already created the first tickchain application on the OP Stack and may release it with their game (such as treaty.earth).

Discussion on the average tick frequency of games on the Internet Developer experience still needs to be improved

The story behind MUD is that the Lattice team has been trying to create new on-chain games and encountered the same backend problems. So they decided to create an on-chain game development framework that can be universally 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 each 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 that are vying for the position of the largest blockchain game engine standard. Two of them are public products, and the other two are built by commercial teams that have raised funds in the past. Let's take a deep dive into some of the more advanced problems and how the teams are solving them.

MUD v2：

MUD is the most popular game engine, providing game engines 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 the upgradability of contract data and large-scale gas costs.

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

Store: is another solution that uses solid's compiler-driven storage. Storing data in a contract consumes Gas and is static/uninspectable in Solidity, which means that interfaces/applications must assume that the calls they make are correct. With Store's on-chain database, the application's contract storage can now be indexed by an off-chain indexer, front end, or another contract. The benefits of using Store are the upgradability of contract data and large-scale gas cost considerations.

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

World: is a framework that includes the use of 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 an improved set of developer tools. Each new plugin introduced to MUD increases the value of the framework and engine for the next developer who joins.

Some examples:

Endless Quest: Generate consistent narrative, metadata and art in AW

MUDVRF: A MUD module that generates random numbers on the chain in the game

DeFi Wonderland: Using the wallet account management module through the burner client

MUD Scan: MUD game ranking board

Dojo Engine:

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

In this case, provability means that the same game loop can be proven on the rollup sequencer or on a local client (such as a browser). With dojo, users can write proof logic to execute client-side and only verify it on-chain, which is very cheap. This also makes features such as anti-cheat and optimistic updates possible, as the logic is implemented on the player's browser even when the sequencer is still verifying the player's transactions.

Their data storage scheme is similar to MUD's Store, but customized for the features of provability and validity proofs. They use Torii to provide automatically verifiable indexing. Indexing is done using storage differences, providing O(1) indexing, and supports client-side verifiability of world state using storage proofs. 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 compile to WASM for browsers, 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, a Rust-like language for creating provable programs for general computation. One advantage of building on Dojo is that you can introduce a fog of war mechanism that uses zkps natively without having to write 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. It's an ambitious project that wants to be the foundation for creating games (studios), game engines, and infrastructure for other developers to scale and deploy. It's currently a closed source project, but their blog promises that it will be open source when released.

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

A unique value proposition that Scott hinted at in his recent talk is location-based sharding (e.g. "Asia servers", "Europe servers"), which can further improve latency in games. As an example, most sequencers are located in the United States, and Asian players often face at least 300 milliseconds of latency, which is a long time in a game. The entire structure is supported by a shared sequencer that is custom-built to optimize latency, rather than synchronize composability and atomic bundles. It has no locks that block the runtime - multiple shards are supported without being blocked by each other and without enforcing total ordering.

Cardinal Shard is the company's first game shard, ticking 20 times per second, comparable to traditional games.

Keystone:

The Curio team was the first commercial team to try 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 like automatic indexing, Unity client support, etc. This is an R&D project and is the result of their efforts to build Treaty.earth. More content may be shared with the public when the team is more ready.

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 such as Playmint and Solana (Arc by Jump Crypto). Topology is another explorer at the forefront of online gaming and has launched Isaac based on their proprietary game engine on Starknet, and their latest game Shoshin is coming soon.

in conclusion:

Today, all engines are trying to improve the tick rate and expand the network, aiming to enable blockchain to carry more complex game interactions. This reminds me of the competitive landscape of VR gaming devices in the early years. With the emergence of new technologies, various companies fought for a long time around the transmission bandwidth of VR headsets. At the call of hardware manufacturers, developers flocked to try to make a VR/AR version of various categories of games. However, with the market test, people found that only certain fixed categories are suitable for VR, and the bandwidth problem of titles is not critical. Similarly, the process of winning the full-chain engine will be the result of a complex system game, but it is foreseeable that those who first find pmf (full-chain explosive output on the content side above the engine) will have a greater competitive advantage.

We are excited to see how each layer develops, new games are released, and new engines emerge. With the exception of MUD v2 and Dojo, none of the others have been battle-tested yet, and we still have a long way to go before we can figure out who is the Unreal and Unity of the on-chain world.