Network Effects in Web3 Game Engines
We cover basics of onchain games & game engines in Part 1 of the FOG series. Special thanks to Alvarius, Andy, Iain, Kevin, Sylve, Tarrence & BladeDAO for their insightful comments that helped shape this article.
Onchain games & engines are their early days. Production ready engines like MUD and Dojo are useful enough that ecosystem developers use them already but at the same time have a long way to go. Game engines in general will experience a massive network effect as multiple games build on their frameworks and add features to the framework.
In onchain gaming, the biggest network effect comes from composability & extensibility of the game and assets in it with other games which are also built in the same ecosystem and engine. Stickiness of the engine also grows exponentially as open-source libraries allow developers to solve technical problems with the help of a community.
The Onchain Game Stack
- The blockchain stack is the fundamental settlement layer of any AW / game. A game developer needs to decide how this will work — directly on Ethereum (expensive), on an L2 (requires RaaS / blockchain dev) or an L3 (requires blockchain dev / RaaS in the future).
- The game engine stack will likely influence which blockchain the developer selects. More repos / libs available for devs to reduce their workload, more convinced they will be to select the blockchains the engine supports.
- The module or prover market are the plugins built by 3rd party developers who will build specific niche tools like leaderboard ranking, VRF etc on existing game engines. The engines will likely build the most popular plugins themselves. We can think of this as the “apps” on the “app store” model.
- The AWs / Games are applications that own the relationship with players. They determine the physics of the world and maintain the frontends. The game assets can be modified by players as long as they obey the laws of nature in the world. And various AWs are composable by default if they run on the same game engine. Degrees of composability will be decided by the community / devs.
- The final stack are trading, staking, betting markets that complement the AW’s token (and business) models. Player guilds like DFDAO and smart contract players like Astral Colossus etc.
If we imagine the game engine ecosystem evolving, their network effects & value accrual layers can be categorised into 2 parts: the engine & the application. The module / prover market can be easily engulfed by the engine layer similar to Gnosis Safe Modules.
With that said, let’s dive into key challenges with onchain game development and how game engines are solving these problems!
#1 Network Congestion
When Crypto Kitties, Axie Infinity, Loot Realms launched; they congested the entire network. What did they do? They created their own chains Flow, Ronin & Loot Chain respectively. Onchain games are computationally heavy and all games battle for block space. So a natural choice for commercially motivated teams has been to build their own app-specific L2 rollup. They partner with RaaS like Caldera, Conduit, Eclipse, Alt Layer etc and the popular L2 framework appears to be OP Stack thus far. We do expect this to change as Arbitrum Orbit, Starkware L3s and ZkSync Hyperchains become more mature and production-ready.
Argus also introduced their new product — an EVM Layer 2 plugged to a data availability layer. This is the base shard. We don’t have a lot of details on it but it reminds us of Len’s Momoka. The EVM base layer will enable other game developers to build Game Shards which are highly customizable execution layers for their game and the Base Shard becomes the layer that brings composability to the entire hyperstructure of Argus L2.
#2 Blockchains are Slow
On the blockchain, the contract state doesn’t change without a valid transaction. As a result, if you wanted f(a) to trigger f(b), it would be impossible to do so without waiting for finality. On Ethereum that would be 15s till the block is settled and another 30–45s to get past reorg risk.
With ticks, the game state can be advanced without having to run a transaction and it does so automatically. Tick rate is the frequency with which an update can happen. A competitive MMO game typically has a tick rate of 20–30/s and an RTS can be as high as 60/s. Most game developers are building MMO games today so a 20/s tick rate would be the one to beat (for now)! Average block times on rollups are 1–2s (Momoka settles to Polygon PoS every 2s) and Argus’ new solution boasts a 20 ticks/s tick rate which would be the industry fastest.
The 0xCurio team was the first commercial team to tinker with the idea of using custom L2s (via Caldera) to optimise for faster tick rate. They’ve built the first ticking chain implementation on OP Stack and will likely launch with their game launches like treaty.earth.
#3 Improved DevX
The story behind MUD was that the Lattice team kept trying to build new onchain games and ran into the same backend issues. So they decided to create a framework for onchain game development which could be universally adopted. Besides composability — faster state sync between contract & client (gamer’s frontend) and easy upgradability (to modify / update content) without having to rewrite indexers with every upgrade (hello automatic indexers) — were the two key challenges.
Welcome to the Game Engine World
We know four projects today who are all battling for their position as the biggest game engine standard. Two of them are public goods and the other two are built by commercial teams who have fundraised in the past. Let’s deep dive into what are some of the high level problems and how the teams are solving them.
MUD v2
MUD is the most popular game engine and powers >95% of onchain games on the EVM. Game engine by Lattice introduced the Store which can represent onchain data in a way similar to relational databases.
Store is an alternative to using solidity’s compiler-driven storage. Storage in contracts are gas-intensive and in solidity are static / non-introspectable which means that interface / application must assume the calls they’re making are correct. With Store’s on-chain database, contract storage of an app is now indexable by an off-chain indexer, frontend, or another contract. The key benefits of using Store are upgradeability of the contract data and gas costs at scale.
State updates are also automatically emitting events so automatic indexers can index the entire state without custom configurations. New data (tables) can be added at runtime compared to Solidity’s static data which enables the upgradeability. Store cost is comparable to manually emitting events for each state but MUD packs data more efficiently than native Solidity and will be cheaper in the long run.
Mode is an off-chain indexer and uses PostgresDB. It can index any MUD app on EVM and is mainly used for automatic state syncs with MUD clients to speed up initial loading time.
World is the framework that includes using Store, systems, permissionless creation, access control, modules etc. To sum it up, the World contract is a single contract with a centralised state and logic of a contract which can be extended with the help of onchain plugins and a suite of tools for an improved DevX. Every new plugin introduced to MUD increases the value of the framework & engine for the next developer to join. Some examples:
- Endless Quest — enables generation of consistent narrative, metadata and art within AW.
- MUDVRF — MUD module to generate onchain randomness in your game.
- DeFi Wonderland — account management module to use your wallet via a burner client
- MUD Scan — leaderboard for all MUD games
Dojo Engine
Dojo Engine is a public good game engine built by Starknet builders. It’s the only provable game engine in the market and provability heavily inspires the architecture & tools built for the game engine.
Provability in this context means that the same game loop can be proved on a rollup’s sequencer or locally on the client side like your browser. With dojo you can write the proving logic to execute client side and only verify onchain, at a fraction of the cost. This also enables things like anti-cheat and optimistic updates where logic is implemented on your browser even though the sequencer is still verifying your transaction.
Their data storage scheme is similar to MUD’s Store but tailored to leverage the properties of provability & validity proofs. They provide automatic verifiable indexing using Torii. Indexing is done using storage diffs, providing O(1) indexing and enabling client side verifiability of world state using storage proofs. Dojo supports deployment to Starknet as well as high performance Layer 3 sequencers like Katana & 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 be compiled to WASM for the browser, using natively in rust-based games (i.e. using Bevy), and provides bindings for Unity and Unreal (in development).
Developers are encouraged to write their applications in Cairo. An advantage is that you can introduce Fog of War mechanisms which use zk-proofs natively without having to code in Circom on Solidity. As a developer you can imagine a future game-specific prover market on Dojo similar to MUD. Games built on Dojo and unlikely to be replicas of MUD games because Dojo can enable varying degrees of complexities in the game and gameplay which may be limiting due to the serialised nature of EVM.
Argus Labs
Argus is founded by Scott — one of the cofounders of Dark Forest and recently came out of the woods with their newest (and only) update. It’s an ambitious project building a game (studio), game engine and the infrastructure for other developers to scale & deploy. It’s currently a closed source project but their blog promises it will be open source at launch.
Shared earlier, it’s a customised L2 with a base shard and individual, customisable game shards. Paired with the World Engine — the proprietary game engine — game developers can create unique execution environments with custom parameters like higher tick rates, native AA with gas customisations, ECS database and compatibility with clients like Unity, Unreal, JS etc. They also provide automatic indexers similar to other game engines. They’ve optimised the L2 & world engine such that writing in Solidity is abstracted and game development in Go is encouraged. In traditional game development, while Go is a perfectly fine language to program in, it’s not the top choice as most engines & libraries which support C, C+ & C++.
A unique value proposition that Scott hinted at in his recent presentation was location based sharding (think “Asia server”, “Europe server”) which can further improve latency in the game. The example given was that most sequencers are based in the US and asian players often face a min. 300ms latency which is a long time in games. The entire structure is supported by their opinionated shared sequencer which is customised to optimise for latency instead of sync composability & atomic bundling. It has no locks that block runtime — multiple shards are supported & are not blocked by each other and do not enforce total ordering.
Cardinal Shard is the 1st implementation of a game shard built by the company and will have 20 ticks / second which is comparable to traditional games.
Keystone
Curio team was the first commercial team to tinker with the idea of using custom L2s and finalised a partnership with Caldera for their custom OP Stack implementations. They embedded ECS structure in their ticking chain and will provide comparable features like automatic indexing, client support for Unity, etc. It’s an R&D project that came out of their endeavours to build Treaty.earth and more details on it will likely be shared when the team is ready.
Other attempts
While these four are the forefront and most well-known in the EVM / Ethereum ecosystem, there are several other custom game engines being built by teams such as Playmint and on Solana (Arc by Jump Crypto). Topology is another behemoth that is at the bleeding edge of onchain gaming and introduced Isaac & their latest game Shoshin built on their proprietary game engine on Starknet.
Conclusions
We’re excited to see how each layer develops, all the new games that launch on the engines & new engines emerge. Besides MUD v2 & Dojo, others are yet to be battle-tested and we have ways to go before we figure out who is the unreal & unity of the onchain world.
Resources
- https://mud.dev/
- https://pitch.com/public/058f726e-d353-4151-a517-275d0def1410/17cdb1d0-2f60-45b0-9bca-cf46686319c8
- https://www.youtube.com/watch?v=A0OXif6r-Qk
- https://book.dojoengine.org/
- https://github.com/curio-research/keystone
- https://latticexyz.notion.site/Store-930ed995c2b14782ae9a949e1e3c8fe9
- https://twitter.com/0xtaetaehoho/status/1673715333860040705?s=20
