IOSG Ventures: The Network Effects of Web3 Game Engines
Original author: Ishanee, IOSG Ventures
Summary:
In the first part of the FOG series, we provided an overview of blockchain games and game engines. Thanks to Sylve, Tarrence, Andy, Alvirus, Kevin & Iain for their support in this article.
Blockchain games and engines are still in the early stages. Game engines like MUD and Dojo are already being used for product development and there are developers in the ecosystem, but there is still a long way to go. Game engines usually experience strong network effects, as many games are built on their frameworks and add functionalities to them.
In the blockchain game ecosystem, the biggest 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 problems with community support, the stickiness of the engine also grows exponentially.
If we imagine the evolution of the game engine ecosystem, their network effects and value accumulation layers could be as shown in the diagram. The modulator/validator market can easily be engulfed by engine layers similar to Gnosis Safe modules. By default, the AW layer is composable, but this depends on the choices of game developers and players regarding the level of composability. Many companies are trying to capture 2 layers or more within this stack.
Now, let's delve into the major challenges of online game development and how game engines address these issues. Problems faced by blockchain game engines:
Network congestion
Crypto Kitties, Axie Infinity, and Loot Realms caused congestion across the entire network when they were released. How did they solve it? They each created their own chains, namely Flow, Ronin, and Loot Chain. Blockchain games require more computational resources, and all games will compete for block space. Therefore, naturally, commercially-funded teams choose to build their own application-specific L2 scaling solutions. They collaborate with RaaS (Rollup as a Service) providers such as Caldera, Conduit, Eclipse, Alt Layer, etc. Currently, the popular L2 framework seems to be the OP Stack, but we expect this situation to change with the maturity and availability for production use of technologies like Arbitrum Orbit, Starkware L3, and ZkSync Hyperchains.
Number of requests causing network congestion during the release of CryptoKitties in December
Argus also introduced their new product - EVM Layer 2 with data insertion capability. 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 enable 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.
The slowness of blockchain
On the blockchain, the contract state only changes after the transaction is confirmed. If you want f(a) to trigger f(b), you can only wait for this process. Therefore, latency in games seems inevitable. On Ethereum, this would be 15 seconds until the block is resolved, and an additional 30-45 seconds to overcome reorganization risk.
By using ticks, the game state can automatically change without waiting for the completion of transactions. The tick frequency can be understood as the update frequency. 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. Nowadays, most game developers are making MMO games, so a 20-second tick frequency is considered ideal. On Rollups, the average block time is 1-2 seconds (Momoka connects to Polygon PoS every 2 seconds), and Argus' new solution has a tick frequency of 20 ticks per second, which is currently the fastest in the industry.
0x Curio team is the first commercial team to use custom L2s (through Caldera) to optimize faster tick rates. They have created the first tick-chain application on the OP Stack and may release it alongside their game, such as treaty.earth.
Discussion on average tick frequency in gaming communities
Developer experience still needs improvement
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 an on-chain game development framework that can be widely adopted. In addition to composability, there are two key challenges: faster state synchronization between contracts and player clients, and ease of upgrades (modification/updates) without having to rewrite 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 have composability.
Introduction to game engine
This article will introduce four projects, all of which are competing 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 that provides 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 advantage of using Store instead of compiler-driven storage is the upgradability of contract data and the scalability of gas costs.
State updates are also automatically emitted as events, so automatic indexers can index the entire state without custom configuration. New data (tables) can be added at runtime, enabling upgradability compared to static data in Solidity. Storage costs are equivalent to manually emitting events for each state, but MUD packs data more efficiently than native Solidity, making it cheaper in the long run.
Store: Another solution for storing data using the Solid compiler. Storing data in a contract consumes gas and is static/non-inspectable in Solidity, which means interfaces/applications must assume that the calls they make are correct. With the on-chain database of Store, the contract storage of an 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 gas costs on a large scale.
Mode: This is an off-chain indexer that uses PostgresDB. It can index any MUD application on EVM, primarily for faster state synchronization with MUD clients.
World: A framework that includes storage, systems, permissionless creation, access control, modules, etc. In conclusion, 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 to MUD adds value to the framework and engine for the next developer to join.
Some examples:
Endless Quest: Can generate consistent narratives, metadata, and art in AW
MUDVRF: MUD module for generating on-chain random numbers in games
DeFi Wonderland: Account management module for wallets using a burner client
MUD Scan: Leaderboard 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 context, verifiability means that the same game loop can be proven on the sequencer of a rollup or a local client (such as a browser). With Dojo, users can write proof logic to execute on the client and only validate on-chain, resulting in low costs. This also enables features like anti-cheating and optimistic updates, where the logic is implemented on the player's browser even while the sequencer is still validating the player's transactions.
Their data storage scheme is similar to MUD's Store but customized for the features of verifiability and proofs of validity. They use Torii to provide automatically verifiable indices. Indices are 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 a rust SDK that can be compiled into WASM for use in rust-based games (such as using Bevy), and provides bindings for Unity and Unreal (currently under development).
Game developers are encouraged to write applications in Cairo, a language similar to rust used for creating verifiable programs for general computation. One advantage of building on Dojo is that you can introduce war fog mechanisms native to zkps without having to write code in Circom on Solidity.
Argus Labs:
Argus Labs, founded by Scott, one of the co-founders of Dark Forest, has recently released their latest (and only) update. This is an ambitious project aiming to be the infrastructure for creating games (studios), game engines, and for other developers to extend and deploy their own projects. It is currently a closed-source project, but their blog promises it will be open-sourced upon release.
As described in the previous content, it is a customized L2 with basic sharding and personalized game sharding. With the World Engine (proprietary game engine), game developers can create unique execution environments using custom parameters (such as higher tick rates, local AA with customizable gas, ECS database, and compatibility with clients like Unity, Unreal, JS). They also provide automatic indexers similar to other game engines. They optimize the L2 & World Engine, making content written in Solidity more abstract and 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++.
Scott hinted at a unique value proposition in his recent speech, which is location-based sharding (such as "Asia server," "Europe server") that 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 optimized for latency, not synchronous composability and atomic bundling. It does not block the runtime lock - supports multiple shards and is not blocked by each other, nor does it enforce total ordering.
Cardinal Shard is the first game shard implemented by the company, with 20 ticks per second, equivalent to traditional games.
Keystone:
The Curio team is the first commercial team to attempt using a custom L2 and eventually collaborate with Caldera to implement their custom OP Stack. They embed ECS structure into their tick chain and will provide features such as automatic indexing, Unity client support, etc. This is a development project and a result of their efforts to establish 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 like 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 major engines are trying their best to improve the tick rate and expand the network, aiming to enable blockchain to support more complex game interactions. This reminds me of the competition pattern of VR game devices in earlier years. With the emergence of new technologies, various manufacturers fought over the transmission bandwidth of VR headsets for a while. With the call from hardware manufacturers, developers rushed to create VR/AR versions of various game categories. However, as the market tested them, people found that only certain fixed categories are suitable for VR, and the bandwidth issue of the headset is not crucial. Similarly, the process of determining the winner among all-chain engines will be the result of a complex system game. But it can be foreseen that those who find the product-market fit (having explosive output 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. Except for MUD v2 and Dojo, the others have not been tested in actual combat. Before we figure out who is the unreal and unity of the on-chain world, we still have a long way to go.
