On-Chain Games / Autonomous Worlds (FOG/AW): Game State Synchronization and Technical Challenges
TechFlow Selected TechFlow Selected
On-Chain Games / Autonomous Worlds (FOG/AW): Game State Synchronization and Technical Challenges
For fully on-chain games, the blockchain serves as the game server and acts as a decentralized source of truth for the game state.
Navigating Web3 tides with focused insightsAuthor: Fiona, IOSG Ventures
TL;DR
-
Fully on-chain games / autonomous worlds ("FOG/AW") represent one of the few significant narratives around Web3. Unlike Web2.5 applications that only connect to Web3 via NFTs, FOG/AW moves game logic onto the blockchain as well. It leverages blockchain as the game server and decentralized source of truth for game state. This brings benefits like persistence, censorship resistance, and composability, but also limits the diversity and complexity of games built atop it.
-
As game complexity and playability demands increase, engine architectures face greater challenges—such as frame latency, randomness generation, health regeneration, continuous passive effects, timers, and more. The concept of time and tick units differs fundamentally on blockchains. Mud offers various approaches to simulate time progression and passive recovery mechanics. For example, when a player moves through a room, the transaction can carry instructions to move all items in that room according to predefined rules, thereby simulating perception of time and state changes.
-
The FOG/AW tech stack can be abstracted as follows: developers write frontend and backend code for UI/UX and core game logic, then synchronize all changes through a game state loop, with indexers finally reflecting new states to local devices on the frontend.
-
Many game genres, such as RTS, require high tickrates. However, consensus-based blockchains are limited by block times, making tickrate a major challenge. Curio and Argus are leading innovators exploring ways to increase game tickrates at the chain level. Mud aims for maximum on-chain completeness, storing the entire application state within the EVM, without compromising decentralization or introducing off-chain hybrid solutions to achieve higher tickrates.
-
Regarding chain selection, Dojo is pioneering the full on-chain ecosystem on Starknet. As @tarrenceva describes, Starknet uses state diffs, unlike optimistic rollups which focus on inputs rather than execution outputs. This difference could significantly optimize costs—for example, in a three-minute chess game involving 50 moves, state diffs allow proving the final "output" with a single proof and end state, whereas optimistic rollups would require recording all intermediate "inputs."
Defining FOG/AW: How Game State Is Synchronized
I believe the benchmark for determining whether something qualifies as FOG lies in how game state is synchronized—the source of truth.
In Web2.5 or traditional multiplayer games, a centralized server defines the current game state. When players send actions, the server compiles these inputs and returns updated results to each connected player’s device. The server processes all inputs (ticks), resolves inconsistencies, and periodically broadcasts snapshots of the game world to players, updating the game state with every tick. Game state ("game state or tick") refers to a time-snapshot of attributes of every object in the game world. Tickrate is the number of times per second the game server computes and broadcasts updated game states. Higher tickrate leads to more precise and higher-fidelity gameplay experiences. Real-time strategy or action games generally require high tickrates, while turn-based games like card games do not.
In fully on-chain games, the blockchain serves as the game server and acts as the decentralized source of truth for game state. In this model, not only do NFTs or tokens have true ownership, but player actions (ticks) and game logic are also executed on-chain. This enables true ownership, persistence, censorship resistance, and composability. Ideally, every player action should be submitted to the blockchain, and after consensus is reached, the game state is updated and reflected back to local devices. Naturally, game types requiring fewer ticks are better suited for full on-chain implementation.
Addressing Challenges Around Latency and Time in Games
As game complexity and playability demands rise, engine architectures face increasing challenges—including frame latency, randomness generation, health regeneration, continuous passive effects, timers, and more.
Frame latency is common even in Web2 environments, arising from client-side rendering and user input delays. In high-tickrate games like FPS, latency severely impacts player experience. One solution in Web2 is lockstep state updates, synchronizing all players based on the highest-latency participant to ensure fairness. With blockchain, where transactions must wait for confirmation, this delay can worsen. To mitigate this, Mud has adopted optimistic rendering—a technique commonly used in games—where user actions are assumed successful and rendered on the client side before server (or in this case, transaction) confirmation.
On-chain random number generation is a frequently discussed topic. Mud suggests using player actions as inputs to generate random outcomes upon interaction.
The concept of time and tick units functions differently on blockchains. @SebastienGllmt notes that chains using fraud proofs (e.g., Optimism) struggle with timers because errors would require rollbacks, resulting in poor gameplay experiences. Mud proposes several methods to simulate time passage and passive recovery skills. For instance, gold accumulation over time can be calculated based on a player’s previous balance, last refresh timestamp, and accrual rate whenever a gold-spending action occurs. Similarly, when a player moves through a room, the transaction may include instructions to update all objects in the room according to predefined logic, enabling perception of time and state change.
Scripting or "cheating" might not be an issue. @BriefKandle argues that MEV on game systems shouldn't necessarily be considered cheating. Preventing simple MEV exploits is something game teams must design for. Web2 game development mindsets need to shift—well-designed MEV bots can function as NPCs within the game.
Some of these features have already been implemented in recently launched on-chain games. For example, Rhascau uses timers and continuous passive effects, largely relying on block timestamps as ticks (on current L2s, block time = tickrate).
FOG/AW Tech Stack
A FOG/AW engine framework is a developer toolstack enabling creators to build games using blockchain as both server and trust source. Additionally, it addresses current pain points:
-
Inefficient development due to lack of standard or ready-made frameworks;
-
Lack of modularity and code reusability;
-
Limited composability. As FOG/AW engines evolve, on-chain games can become more engaging and imaginative.
For clarity, the simplified technical flow typically involves: developers writing frontend and backend code for UI/UX and core game logic, synchronizing all changes via a game state loop, and finally having indexers reflect new states to local frontend devices.
To enable smooth operation of this cycle on blockchains, projects like Mud, Dojo, Curio, Argus, Paima Engine, and Lootchain are developing their own tech stacks. These stacks consist of three key components: chain, core development stack, and game frontend. Each introduces innovations while balancing decentralization and game complexity.
-
Game Frontend: Includes traditional engines like Unity, Unreal, and languages/tools like React/Three.js that provide rendering capabilities—essential for enhancing playability and user experience. Most of these projects offer SDKs for developers.
-
Core Development Stack: A framework enabling game logic to run on-chain and stay synchronized with the frontend. Key components include suitable database structures (defining game behaviors and logic) and mechanisms for syncing and returning game states.
-
Chain: Most projects are built on Ethereum, Optimism, or Starknet.
The diagram below illustrates how different protocols design their respective tech stacks. Taking Mud V2 as an example, here's how it works:
-
A developer uses Web2 frontend tools supported by Mud to write code, leveraging powerful rendering features to make the game visually appealing and engaging;
-
Simultaneously, the developer writes character definitions, item properties, and specific game logic using Mud’s smart contract framework (Mud World)—for example, defining probabilities and conditions under which Hero A can successfully conquer Tile Y after moving from X;
-
These actions and game states are recorded in Mud Store, an on-chain database serving as the global source of truth for game state;
-
When Hero A attacks Tile Y, this corresponds to a player clicking a button on the local frontend and submitting the command on-chain. Based on the game design logic and current state stored in Mud Store, the system produces an outcome, which updates the global game state and gets synced on-chain;
-
Mud-based games support various frontends including Web and Mobile, though they may face complex indexing needs—Mode was developed specifically as an off-chain indexer for this purpose.
Now let’s examine the commonalities and differences among these core frameworks.
-
Most follow the Mud v1 design and use ECS as the data structure for game development—this defines how game logic is written and represented. Mud V2 improves upon this by organizing data into Tables and Systems, allowing flexibility beyond strict ECS modeling standards, giving developers more options and making the framework more inclusive.
-
Most use decentralized databases since blockchains naturally serve as trusted sources for game state and storage. Mud strives for maximal on-chain execution, keeping the entire application state within the EVM, without sacrificing decentralization or adopting off-chain hybrids to boost tickrates.
-
Since many game types like FPS require high tickrates, and consensus-based blockchains are constrained by block intervals, tickrate remains a critical challenge. Curio and Argus are innovating at the chain layer to increase tickrates directly.
-
Regarding chain choices, both Curio and Loot leverage Caldera to build OP Stack chains. Meanwhile, Dojo is leading the full on-chain ecosystem on Starknet. As @tarrenceva explains, Starknet uses state diffs—unlike optimistic rollups, which emphasize input validation over output. This could greatly reduce costs—for example, in a 3-minute chess match with 50 moves, state diffs allow verifying the “output” via a single proof and final state, whereas optimistic rollups require validating all intermediate “inputs.”
Several games have already been built on these engines. Mud and Dojo host hackathons to attract developers, and Curio recently unveiled a Warcraft mini-game demo at ETHCC.
Clearly, FOG/AW is becoming a key battleground for public chains. The Autonomous World (AW) concept proposed by Lattice is broad, extending beyond gaming to include social, financial, and other dimensions. Thus, what's being built is a highly imaginative virtual world—essentially, a Metaverse. We can look forward to novel hybrid applications blending gaming, social interaction, finance, and more.
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
