On-chain game technology stack: How to synchronize game state?

Written by: Fiona, IOSG Ventures

Thanks to @BriefKandle Creator of @netherscape_xyz, @stokasz CEO@rhascau @mintersworld, @0xcurio team, @SebastienGllmt cofounder@PaimaStudios, @hiCaptainZ, and @SerenaTaN5 for their help and valuable feedback!

TL;DR

• Full-chain games / Autonomous Worlds ("FOG/AW") are one of the few important narratives surrounding Web 3. Unlike Web2.5 applications that connect to Web3 solely through NFTs, FOG/AW places game logic on-chain as well. It uses the blockchain as a game server, becoming a decentralized trust source for game state. This brings advantages such as persistence, censorship resistance, and composability, but also limits the diversity and complexity of games built on it.
• With increasing demands for game complexity and playability, more challenges are posed to engine architecture: such as frame delay, random numbers, health recovery, continuous passive effects, timers, etc. The concept of time and the unit of Ticks are different on the blockchain. Mud provides several ideas to simulate the passage of time and passive recovery skills. For example, when players move in a room, transactions include moving all items in the room based on some predefined designs. This perceives changes in time and state.
• The FOG/AW tech stack can be abstracted as: developers write front-end and back-end code for UI/UX and core game logic, then synchronize all changes through a loop of game states, finally reflecting the new state on the local devices of the front end via an indexer.
• Many game types, such as RTS, require high tick rates, while blockchains generated by consensus can only handle changes in block time; tick rate is a significant issue to be resolved here. Curio and Argus are leaders in this area, exploring ways to increase game tick rates at the chain level. Mud is attempting to achieve full-chain status, with the entire application state stored in the EVM. It has not introduced off-chain solutions to achieve higher game tick rates.
• Regarding the choice of different chains, Dojo is leading the full-chain ecosystem of Starknet. According to @tarrenceva, Starknet has State diffs, which differ from optimistic rollups, focusing on execution outputs rather than inputs. The impact on games may mainly be in optimizing costs, for example, in a chess game: in a three-minute game, there may be 50 moves. Through state differences, a single proof and final state can prove the "output." In contrast, optimistic rollups require all intermediate states as "inputs."

Defining FOG/AW: How Game State is Synchronized

I believe the benchmark for determining whether it is FOG is how the game state is synchronized (source of truth).

For Web 2.5 games or traditional multiplayer games, there is a centralized server that defines the current game state. When players send actions, the server compiles these inputs and returns the updated results to each connected player's device. The server processes all inputs (ticks), resolves inconsistencies, and periodically sends updates to players, providing snapshots of all elements in the game, updating the game state with each tick. Game state ("game state or tick") is a time snapshot of the properties of each object in the game world. Tick rate refers to how many times the game server calculates and broadcasts updates to the game state per second. The higher the tick rate, the more precise and high-fidelity the gaming experience. Generally, real-time strategy or action games require high tick rates, while turn-based games like card games do not.

Source: https://www.gabrielgambetta.com/client-server-game-architecture.html

For games fully running on-chain, the blockchain acts as the game server and serves as a decentralized trust source for game state. In this case, not only do NFTs or tokens have true ownership, but even the players' ticks and game logic are on-chain. This is why true ownership, persistence, censorship resistance, and composability can be achieved. Ideally, every action of the player should be submitted to the blockchain, and after reaching consensus, the game state is updated and returned to the local device. Therefore, naturally, game types that require fewer tick rates are more suitable for being fully on-chain.

Addressing Challenges of Game Latency, Time, etc.

As the demands for game complexity and playability increase, more challenges are posed to engine architecture: such as frame delay, random numbers, health recovery, continuous passive effects, timers, etc.

Frame delay is actually very common in the Web2 world, arising from delays in client rendering and user operations. Especially in high tick rate games like FPS, once there is a delay, the player experience can be severely impacted. One solution in Web2 is lockstep state update, which synchronizes all players according to the highest delay among players to ensure fairness in player experience. When blockchain is introduced and transaction confirmation is required, this delay may become even more severe. To address this, Mud has also introduced the optimistic rendering mechanism commonly used in games, assuming user operations are successful and rendering them on the client before server approval (or in this case, before transaction confirmation).

Generating random numbers on-chain is a frequently discussed topic. Mud believes that user behavior can be used as input for random results, generated after interactions occur.

The concept of time and Ticks is different on the blockchain. @SebastienGllmt believes that using a timer on chains with fraud proof concepts (like Op) is difficult because if an error occurs, it will require a rollback, and if a timer is used in the game, the experience will be poor. Mud provides several ideas to simulate the passage of time and passive recovery skills. For example, increasing gold over time, calculating the player's gold amount based on their previous gold count, the last refresh amount, and refresh rate whenever the player performs an action that requires gold. Another example is when players move in a room, transactions include moving all items in the room based on some predefined designs. This perceives changes in time and state.

Scripting "cheating" may not be a problem. @BriefKandle does not consider MEV on game systems as cheating; preventing scripts from easily achieving MEV is something game teams need to consider. Web2 game development needs to shift its mindset; a good MEV bot is an NPC within the game.

Some features have already been implemented in recently launched on-chain games, such as in Rhascau, where they used timers and continuous passive effects. Essentially, they use block time as a scale. (In the current L2, block time = tick rate).

FOG/AW Tech Stack

The FOG/AW engine framework is a developer tool stack that allows developers to build games using the blockchain as a server and trust source. Additionally, it can address some current issues:

• Due to the lack of standards / ready-made frameworks, building on-chain FOG/AW is inefficient;
• Lack of modularity and code reusability;
• Lack of composability. As the FOG/AW engine develops, on-chain games can become more interesting and imaginative.

To facilitate understanding, the simplified technical process of such engines is: developers write front-end and back-end code for UI/UX and core game logic, then synchronize all changes through a loop of game states, finally reflecting the new state on the local devices of the front end via an indexer.

To ensure that games running on the blockchain can smoothly operate this loop, Mud, Dojo, Curio, Argus, Paima engine, and Lootchain are all developing their respective tech stacks for this purpose. The tech stack consists of three key parts: chain, core development stack, and game front end. They all have their innovations, making trade-offs between decentralization and game complexity.

• Game Front End: Includes traditional engines like Unity, Unreal, and languages and powerful tools like React/Three.js that provide rendering capabilities, which are essential for enhancing game playability and experience. Most of the above projects can provide relevant SDKs for developers to use.
• Core Development Stack: Designs a solution that allows game logic to run on the blockchain and can be synchronized to the front end in a timely manner. Key components include appropriate database structures (defining game behaviors and logic) and synchronization and return of game states.
• Chain: Most have chosen to build on Ethereum, Optimism, and Starknet.

The following diagram illustrates how different protocols design their respective tech stacks. Taking Mud V2 as an example, here is how it operates:

1. A developer will call some Web2 front-end tools in Mud to write code, utilizing these powerful features like rendering to make the game more visual and enjoyable;
2. At the same time, the developer will write characters, items, and specific operational logic for the game based on Mud's smart contract framework (Mud World), for example, when Hero A moves from X to Y and initiates an attack on the Y tile, what is the probability or under what circumstances can they successfully occupy that tile;
3. The above actions and game states will be recorded in Mud Store, which is an on-chain database responsible for the global game state and serves as the trust source for game state synchronization;
4. When Hero A attacks Y, it is actually the player clicking the mouse on their front-end machine and submitting that command to the chain. This command, based on the developer's game design logic and the current game state in the Store, results in an outcome that updates to the new global game state and is synchronized on-chain;
5. Games on Mud support various front ends such as Web and Mobile, but may face complex indexing requirements, which is precisely what Mode was developed for as an off-chain indexer.

Now, let's discuss the common and different designs of these core frameworks.

• Most of them follow the Mud v1 design and utilize ECS as the data structure for game development. This is the way game logic is written and presented. Mud V2 has improved this, with data defined in Tables and Systems, allowing for other data standards (not necessarily adhering to the ECS data modeling standards of V1), giving developers more options and making it more inclusive.
• Most use decentralized databases, as the blockchain naturally serves as the trust source for game state and databases. Mud is attempting to achieve full-chain status, with the entire application state stored in the EVM. It has not sacrificed decentralization or introduced off-chain solutions to achieve higher tick rates for games.
• Many game types, such as FPS, require high tick rates, while blockchains generated by consensus can only handle changes in block time; tick rate is a significant issue to be resolved here. Curio and Argus, in their innovative designs, are leading the way in increasing tick rates at the chain level.
• Regarding the choice of different chains, Curio and Loot both utilize Caldera to build the Op stack chain. In addition, Dojo is leading the full-chain ecosystem of Starknet. According to @tarrenceva, Starknet has State diffs, which differ from optimistic rollups, focusing on execution outputs rather than inputs. The impact on games may mainly be in optimizing costs, for example, in a chess game: in a three-minute game, there may be 50 moves. Through state differences, a single proof and final state can prove the "output." In contrast, optimistic rollups require all intermediate states as "inputs."

Currently, some games are already built on these engines, and both Mud and Dojo are hosting hackathons to attract developers to build applications. Curio has also just released a minigame demo of Warcraft at ETHCC.

It is clear that FOG/AW is becoming a key ecosystem in the competition for public chains. The AW (Autonomous Worlds) proposed by Lattice is a vast concept, not limited to games but also encompassing social, financial, and many other attributes. Therefore, building on this is a virtual world full of imagination, namely the Metaverse. We can expect some new forms of games, social interactions, financial integrations, and more.

Reference:

1. https://mirror.xyz/matchboxdao.eth/d3lVAOa9Bi0kY-caoUT3lDC6E61mWJqtP1q6tME4xGY

2. https://jumpcrypto.com/writing/defining-on-chain-gaming/

3. https://www.oneqode.com/what-is-a-game-server/

4. https://medium.com/@qingweilim/how-do-multiplayer-game-sync-their-state-part-2-d746fa303950

5. https://latticexyz.notion.site/Building-Autonomous-Worlds-with-MUD-39d5eb5d31034589bc54a2053efb4c56

6. https://twitter.com/tarrenceva/status/1660686571270705152

7. https://book.dojoengine.org/framework/sozo/overview.html

8. https://www.youtube.com/watch?v=A0OXif6r-Qk