IOSG Ventures: Network effects of Web3 game engines

IOSG Ventures: Web3 game engines' network effects

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. While game engines like MUD and Dojo can already be 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 functionality 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 issues with the help of the community, the stickiness of the engine also grows exponentially.

• In-depth explanation of the ERC6551 token binding account protocol, which has recently gained popularity
• Gemini co-founder publishes open letter condemning DCG founder: “Scammer, return the money, or face legal action from both DCG and me.”
• Foresight Ventures: Can Asgard NFT AMM build a new rainbow bridge?

If we imagine the evolution of the game engine ecosystem, their network effects and value accumulation layers may look like the following. The module/validator market is easily swallowed up by engine layers like 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.

With that said, let’s delve into the key challenges of online game development and how game engines are addressing these issues. Challenges faced by blockchain game engines:

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 chain, namely Flow, Ronin, and Loot Chain. On-chain games require more computing resources, and all games will compete for block space. As a result, well-funded commercial teams will naturally choose to build their own application-specific L2 scaling layers. 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 the 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.

Number of requests that caused network congestion when CryptoKitties was released in December.

Argus also introduced their new product – EVM Layer 2 with an insertable data layer. This is the basic shard. We don’t know more about it, but it reminds us of Len’s Momoka. The EVM base layer will allow other game developers to build highly customizable execution layers, 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 contract state will only change after 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 would be 15 seconds until the block is resolved, and another 30-45 seconds to overcome the reorganization risk.

By using ticks, the state of the game can automatically change 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 usually 20-30 seconds, and the tick rate for RTS games can be as high as 60 seconds. Now most game developers are making MMO games, so a 20-second tick frequency is ideal. The average block time on rollups is 1-2 seconds (Momoka’s connection to Polygon PoS is every 2 seconds), and Argus’s new solution has a tick frequency of 20 ticks/second, which is the fastest in the industry.

0x Curio 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 the OP Stack and may release it with their games (such as treaty.earth).

Discussion on the average tick frequency of games on the network

The 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 has encountered the same backend issues. So they decided to create a universally adopted 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 rewriting 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 that are all 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 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 rather than compiler-driven storage is the upgradability of contract data and the large-scale gas cost.

State updates also automatically emit events, so the automatic indexer does not need to be custom-configured to index the entire state. Compared to static data in Solidity, new data (tables) can be added at runtime, enabling upgradability. The storage cost is comparable to manually issuing events for each state, but MUD packs data more efficiently than native Solidity, making it cheaper in the long run.

Store: Another storage solution that uses the compiler Solid. Storing data in a contract consumes Gas and is static/inscrutable in Solidity, meaning that interfaces/applications must assume that the calls they make are correct. With 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 benefits of using Store are 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 the 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 an improved set of developer tools. Each new plugin introduced by MUD adds value to the framework and engine for the next developer to join.

Some examples:

• Endless Quest: generates consistent narratives, metadata, and art on AW

• MUDVRF: MUD module that generates on-chain random numbers in games

• DeFi Wonderland: account management module for wallets using burner client

• MUD Scan: leaderboard billboard 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 game engines.

In this case, verifiability means that the same game loop can be proven on the sequence of the rollup or the local client (such as a browser). With dojo, users can write proof logic to execute clients, and only verify on the chain, at a low cost. This also makes features such as anti-cheating and optimistic updates possible, even if the sequencer is still verifying player transactions and the logic is implemented on the player’s browser.

Their data storage scheme is similar to MUD’s Store, but customized for the properties of provability and efficiency proofs. They use Torii to provide automatically verifiable indexing. The index is achieved using storage difference, providing O(1) indexing, and supporting client verifiability of the world state using storage proof. Dojo supports deployment to Starknet as well as high-performance third-layer sequencers such as Katana and Madara. Dojo offers Katana (a local development network), Sozo (a command-line interface for deployment, updates, and interaction with the game), and Torii (a verifiable indexer). Dojo provides a Rust SDK that can be compiled to WASM for use in Rust-based games (i.e. using Bevy) as well as bindings for Unity and Unreal (coming soon).

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 native war fog mechanisms using zkps without writing code in Circom on Solidity.

Argus Labs:

Argus Labs, founded by Scott, one of the co-founders of Dark Forest, has recently released its latest (and only) update. It is an ambitious project that aims to become the infrastructure for creating games (studios), game engines, and 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.

Conclusion:

Nowadays, all the major engines are trying to improve the tick rate and expand the network to enable blockchain to carry more complex game interactions. This reminds me of the competition in the VR game device market a few years ago, where new technologies emerged and hardware manufacturers fought over the transmission bandwidth of VR headsets. Developers rushed to make versions of all kinds of games for VR/AR under the call of hardware manufacturers. However, as the market was tested, people found that only a few fixed game categories were suitable for VR, and the bandwidth problem was not crucial. Similarly, the competition among all-chain engines will be the result of a complex system game, but it is foreseeable that those who find the PMF (output of the whole-chain explosion models on the content side) first will have a significant 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 real-world scenarios. We still have a long way to go before we figure out who is the unreal and unity in the on-chain world.

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