IOSG Ventures: Analyzing the Network Effects of Web3 Game Engines.

Original Title: "Network Effects of Web3 Game Engines"

Original Source:  IOSG Ventures

This article is original content from IOSG and is only for industry learning and communication. The projects mentioned in the article have no relationship with IOSG's interests and do not provide any investment advice. Please keep an objective attitude and carefully identify information when reading this article. If readers need to reprint or quote the content of this article, please contact the IOSG team to obtain authorization and reprint instructions. Thanks to the hard work and cooperation of IOSG Ventures' investment research and post-investment teams!

Summary of Premise

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

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

In the on-chain gaming ecosystem, the biggest network effect comes from the composability and scalability of the 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.

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

At this point, let's delve into the main challenges of online game development and how game engines solve these problems. The challenges faced by blockchain game engines:

Network congestion

Crypto Kitties, Axie Infinity, and Loot Realms caused network congestion upon release. 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. Therefore, well-funded commercial teams naturally choose to establish their own application-specific L2 scaling solutions. They collaborate 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 to change as technologies such as Arbitrum Orbit, Starkware L3, and ZkSync Hyperchains mature and become production-ready.

Number of requests causing network congestion during the December CryptoKitties release

Argus also introduced their new product - EVM Layer 2 with insertable data layer. This is the base shard. We don't know more about its details, 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 become a layer of composability for the entire Argus L2.

Blockchain's Slow Speed

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

By using ticks, the status in the game can automatically change without waiting for the completion of transactions. The tick frequency can be understood as the update frequency. The tick rate of competitive MMO games is usually 20-30 seconds, and the tick rate of RTS games can be as high as 60 seconds. Nowadays, most game developers are making MMO games, so a tick frequency of 20 seconds 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, which is currently the fastest in the industry.

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 the OP Stack and may release it with their games (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 issues. 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.

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 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 engine for over 95% of online games on EVM. Lattice's game engine introduces Store, which represents 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 scalability of gas costs.

The state update also automatically triggers an event, so the automatic indexer can index the entire state without custom configuration. Compared to Solidity's static data, new data (tables) can be added at runtime, achieving upgradability. The storage cost is equivalent to manually triggering an event for each state, but MUD packs data more efficiently than native Solidity, making it cheaper in the long run.

Store: is another solution for storing data using the Solidity compiler driver. Storing data in contracts consumes Gas and is static/non-inspectable in Solidity, which means that interfaces/applications must assume that the calls they make are correct. With Store's on-chain database, contract storage for applications 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 consideration for large-scale gas costs.

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

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

Some examples:

Endless Quest: Can generate consistent narrative, metadata, and art in AW.

MUDVRF: The MUD module for generating on-chain random numbers in games.

DeFi Wonderland: Using the wallet's account management module through a burner client.

MUD Scan: Leaderboard bulletin board for MUD games.

Dojo Engine

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

In this case, provable means that the same game loop can be proven on the sequencer of rollup or on a 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 anti-cheating and optimistic updates possible, even if the sequencer is still verifying player transactions, the logic will be implemented on the player's browser.

Their data storage solution is similar to MUD's Store, but customized for provability and validity proofs. They use Torii to provide automatically verifiable indexes. The indexes are achieved through storage differences, providing O(1) indexing, and supporting client verifiability of the world state through 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 deployment, updates, and game interaction), and Torii (a verifiable indexer). Dojo also provides a Rust SDK that can be compiled to WASM for use in Rust-based games (i.e. using Bevy), and bindings for Unity and Unreal (currently in development).

Game developers are encouraged to use Cairo to write applications. Cairo is a language similar to Rust that is used to create verifiable programs for general computation. One advantage of building on Dojo is that you can introduce the use of zkps' native war fog mechanism 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. They recently released their latest (and only) update. This is an ambitious project that aims to become the infrastructure for creating game 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.

As described in previous content, it is a customized L2 with basic sharding and personal customizable game sharding. With the World Engine (proprietary game engine), game developers can create unique execution environments using custom parameters (such as higher tick rates, locally customized gas AA, ECS databases, and compatibility with clients such as Unity, Unreal, and JS). They also provide an automatic indexer similar to other game engines. They optimize L2 & world engine, making content written in Solidity abstract and encouraging game development using 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++.

Scott hinted at a unique value proposition in his recent speech, which is location-based sharding (such as "Asian servers" and "European servers"), which can further improve game latency. For example, most sequencers are located in the United States, and Asian players typically 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 for optimizing latency rather than synchronous composability and atomic bundling. It does not block the lock of the runtime-supports multiple shards, does not block each other, and does not enforce total ordering.

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

Keystone

Curio team is the first commercial team to attempt using a custom L2, and eventually partnered with Caldera to implement their custom OP Stack. They embedded ECS structure into their tick chain and will provide features such as automatic indexing, Unity client support, etc. This is a research and development project, and 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

Although 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 its proprietary game engine on Starknet. Their latest game, Shoshin, is also about to be released.

Conclusion

Nowadays, all blockchain engines are trying their best to improve tick rate and expand their networks, aiming to enable blockchain to support more complex game interactions. This reminds me of the competition pattern of VR game devices in the early years. With the emergence of new technologies, hardware manufacturers rallied developers to make various types of games into VR/AR versions, focusing on the transmission bandwidth of VR headsets. However, as the market was tested, people found that only certain fixed types of games were suitable for VR, and the bandwidth issue of the headset was not crucial. Similarly, the competition among various full-chain engines will be the result of a complex system game, but it can be foreseen that those who first find the PMF (having a full-chain explosive output on the content side above the engine) 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, the others have not yet been tested in practice. Before we figure out who the unreal and unity of the on-chain world are, we still have a long way to go.

Original article link

Welcome to join the official BlockBeats community:

Telegram Subscription Group: https://t.me/theblockbeats

Telegram Discussion Group: https://t.me/BlockBeats_App

Official Twitter Account: https://twitter.com/BlockBeatsAsia