A Brief Analysis of the Challenges Facing Online Game Development and the Network Effects of Web3 Game Engines
TechFlow Selected TechFlow Selected
A Brief Analysis of the Challenges Facing Online Game Development and the Network Effects of Web3 Game Engines
Nowadays, various engines are striving to increase tick rates and expand network capacity, aiming to enable blockchains to support more complex game interactions.
Navigating Web3 tides with focused insightsAuthor: Ishanee @IOSG Ventures
Premise Summary:
In the first part of our FOG series, we provided an overview of on-chain gaming and game engines. Special thanks to Sylve, Tarrence, Andy, Alvirus, Kevin & Iain for their support on this article.
On-chain games and engines are still in early stages. While game engines like MUD and Dojo are already usable for product development—with developers actively building on them—there’s still a long way to go. Game engines typically experience strong network effects, as many games are built on their frameworks and contribute new functionalities back into them.
In the on-chain gaming ecosystem, the largest network effects come from game composability and extensibility, along with the integration of game assets across other games based on the same ecosystem and engine. As open-source libraries allow developers to solve technical challenges with community support, the stickiness of engines grows exponentially.
If we imagine the evolution of a game engine ecosystem, their network effects and value accumulation layers might look as shown in the diagram. Module/validator markets can easily be absorbed into the engine layer, similar to Gnosis Safe modules. The AW layer is composable by default, but the degree of composability depends on choices made by game developers and players. Many companies are attempting to capture two or more layers within this stack.
With that context, let’s dive into the main challenges of online game development and how game engines aim to solve them. Challenges facing blockchain game engines:
Network Congestion
CryptoKitties, Axie Infinity, and Loot Realms each caused significant network congestion upon launch. How did they respond? Each created its own chain—Flow, Ronin, and Loot Chain respectively. On-chain games require substantial computational resources, and all such games compete for block space. Naturally, well-funded commercial teams opt to build application-specific L2 scaling solutions. They partner with RaaS (Rollup-as-a-Service) providers such as Caldera, Conduit, Eclipse, and Alt Layer. Currently, OP Stack appears to be the dominant L2 framework, though we expect this to shift as technologies like Arbitrum Orbit, Starkware L3, and ZkSync Hyperchains mature and become production-ready.
Number of requests during CryptoKitties’ December launch that caused network congestion
Argus has also introduced a new product—an EVM Layer 2 that plugs into a data availability layer. This serves as the base shard. Details remain scarce, 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—and the base shard will serve as the layer enabling composability across the entire Argus L2.
Slow Blockchain Speeds
On blockchains, contract states only change after transaction confirmation. If you want f(a) to trigger f(b), the process must wait. Thus, latency in games seems unavoidable. On Ethereum, this means waiting 15 seconds for block finalization, plus another 30–45 seconds to mitigate reorg risks.
By using ticks, game states can update automatically without waiting for transactions to complete. Tick frequency refers to the update rate. Competitive MMO games typically use tick rates of 20–30 Hz, while RTS games may go as high as 60 Hz. Since most current developers are building MMOs, a 20 Hz tick frequency is ideal. Rollups average 1–2 second block times (Momoka connects to Polygon PoS every 2 seconds), while Argus’s new solution achieves 20 ticks per second—the fastest in the industry today.
The 0xCurio team was the first commercial team to use custom L2s (via Caldera) to optimize for faster tick rates. They’ve already built the first tick-chain application on OP Stack and may release it alongside their game (e.g., treaty.earth).
Online discussion about average tick frequencies in games
Developer Experience Needs Improvement
The story behind MUD is that the Lattice team kept running into the same backend issues while developing new on-chain games. So they decided to create a universally adoptable on-chain game development framework. Beyond composability, two key challenges remain: faster state synchronization between contracts and player clients, and easy upgradability (modifying/updating content) without rewriting indexers each time (auto-indexing).
In this article, we assume that all applications built on the same game engine framework are composable.
Game Engine Overview
This article covers four projects competing to become the leading blockchain game engine standard. Two are public goods, while the other two are developed by funded commercial teams. Let’s explore some advanced challenges and how these teams are addressing them.
MUD v2:
MUD is the most popular game engine, powering over 95% of online games on EVM. Lattice’s game engine introduced Store, which represents on-chain data in a manner similar to relational databases. Compared to compiler-driven storage, using Store offers benefits in contract data upgradability and massive gas savings.
State updates automatically emit events, so auto-indexers can index the full state without custom configuration. Unlike Solidity’s static data, new data (tables) can be added at runtime, enabling upgradability. Storage costs are comparable to manually emitting events for each state, but MUD packs data more efficiently than native Solidity, making it cheaper in the long run.
Store: An alternative to Solidity’s compiler-driven storage. Storing data in contracts consumes gas and is static/non-discoverable in Solidity, meaning interfaces/apps must assume their calls are correct. With Store’s on-chain database, contract storage can now be indexed by off-chain indexers, frontends, or other contracts. Benefits include data upgradability and significant gas cost reductions.
Mode: An off-chain indexer using PostgresDB. It can index any MUD application on EVM and is primarily used for faster state synchronization with MUD clients.
World: A framework including storage, systems, permissionless creation, access control, modules, etc. In short, the World contract is a single contract with centralized state and logic. It can be extended with on-chain plugins and enhanced developer tools. Each new plugin added to MUD increases the value of the framework and engine for the next developer.
Examples:
-
Endless Quest: Generates consistent narratives, metadata, and art in AW
-
MUDVRF: A MUD module for generating on-chain randomness in games
-
DeFi Wonderland: Wallet account management module via burner client
-
MUD Scan: Leaderboard dashboard for MUD games
Dojo Engine:
Dojo Engine is a public game engine developed by Starknet contributors. It is the only provable game engine, with verification built specifically for its architecture and tooling.
Here, provability means the same game loop can be proven on a rollup’s sequencer or locally on a client (e.g., browser). With Dojo, users can write proof logic executed on the client, with only verification occurring on-chain at low cost. This enables anti-cheat mechanisms and optimistic updates—logic runs in the player’s browser even while the sequencer validates transactions.
Their data storage approach resembles MUD’s Store but is customized for provability and validity proofs. They use Torii for auto-verifiable indexing. Indexing uses storage diffs for O(1) performance and supports client-side verifiability of world states via storage proofs. Dojo supports deployment to Starknet and high-performance L3 sequencers like Katana and Madara. It provides Katana (a local devnet), Sozo (a CLI for deploying, updating, and interacting with games), and Torii (a verifiable indexer). Dojo offers a Rust SDK compilable to WASM for browsers, usable in Rust-based games (e.g., with Bevy), and bindings for Unity and Unreal (in development).
Game developers are encouraged to write apps in Cairo—a Rust-like language for creating provable programs for general computation. A key advantage of building on Dojo is the ability to natively implement fog-of-war mechanics using zkps, without needing to write code in Circom atop Solidity.
Argus Labs:
Founded by Scott, co-creator of Dark Forest, Argus Labs recently released its latest (and only) update. It’s an ambitious project aiming to become a full-stack solution encompassing game studios, game engines, and infrastructure for developers to extend and deploy on. It’s currently closed-source, but the team promises to open-source it upon release.
As previously described, it’s a custom L2 featuring a base shard and individually customizable game shards. Paired with the proprietary World Engine, game developers can create unique execution environments with custom parameters—such as higher tick rates, gas-customized local AA, ECS databases, and compatibility with Unity, Unreal, JS, and other clients. They also provide an auto-indexer similar to other engines. Their optimized L2 and World Engine abstract away Solidity, encouraging game development in Go. While Go is a solid programming language, it’s not traditionally preferred in game development, where C, C++, and C# dominate due to widespread engine and library support.
In his recent talk, Scott hinted at a unique value proposition: location-based sharding (e.g., “Asia server,” “Europe server”), which could further reduce game latency. For example, most sequencers are located in the U.S., causing Asian players to face ~300ms delays—significant in gaming. The entire architecture is supported by a shared sequencer optimized for latency rather than atomic composability or bundling. It avoids runtime locks—supports multiple shards without mutual blocking or enforced total ordering.
Cardinal Shard is the company’s first implemented game shard, operating at 20 ticks per second—on par with traditional games.
Keystone:
The Curio team was the first commercial team to experiment with custom L2s, eventually partnering with Caldera to implement their custom OP Stack. They’ve embedded ECS structures into their tick chain and will offer features like auto-indexing and Unity client support. This is a research and development effort stemming from their work on Treaty.earth. More details may be shared publicly when the team is ready.
Other Efforts:
While these four lead the EVM/Ethereum ecosystem in visibility and advancement, several other custom game engines are being developed by teams like Playmint and Solana (Arc by Jump Crypto). Topology is another pioneer in on-chain gaming, having launched Isaac on Starknet using its proprietary engine, with their newest game Shoshin即将 launching soon.
Conclusion:
Today, every engine is racing to increase tick rates and scale networks, aiming to support increasingly complex on-chain game interactions—this reminds us of the early VR headset landscape, where new tech emerged and companies fiercely competed over transmission bandwidth. Under hardware makers’号召, developers rushed to port all kinds of games into VR/AR formats. Yet market validation revealed only certain genres truly suited for VR, and bandwidth concerns turned out less critical than expected. Similarly, the race among full-chain engines will result from complex system dynamics, but one thing is clear: whoever first achieves product-market fit—with breakout content built on their engine—will gain a significant competitive edge.
We’re excited to witness the evolution across every layer—new game launches and emerging engines. Aside from MUD v2 and Dojo, the others haven’t yet been battle-tested. We still have a long journey ahead before determining who will become the Unreal or Unity of the on-chain world.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
IOSG Ventures
