How to synchronize the "state" of the whole chain game?

By Fiona, IOSG Ventures

TL;DR

*Full chain of games/autonomous worlds ("FOG/AW") is one of the few important narratives surrounding Web 3. Compared with Web2.5 applications that only connect to Web3 through NFT, FOG/AW puts the game logic on the chain. It utilizes the blockchain as a game server, becoming a decentralized source of trust for the state of the game. This brings advantages such as persistence, censorship resistance, composability, etc., but also limits the variety and complexity of games built on top of it.

• With the increasing complexity and playability requirements of the game, more challenges are put forward for the engine architecture: such as frame delay, random number, health recovery, continuous passive effect, timer, etc. The concept of time and Ticks units are different on the blockchain. Mud provides a lot of ideas to simulate the passage of time and passive recovery skills. For example, when the player moves in the room, the transaction comes with moving all the items in the room according to some predefined design. Use this to perceive changes in time and state.
• The FOG/AW technology stack can be abstracted as: developers write front-end and back-end codes for ui/ux and game core logic, then synchronize all changes through the game state loop, and finally reflect the new state to the front-end local device by the indexer.
• Since many game types, such as RTS, require high tickrates, and blockchains produced by consensus can only handle changes in block times, tickrate is a big problem to be solved here. Curio and Argus are leaders in this regard, and they are increasing game tickrate at the fumble chain level. Mud is trying to maximize the full chain, and the entire application state is stored in the EVM. There is no plan to introduce off-chain integration to achieve a higher tickrate for the game.
• For the selection of different chains, Dojo is leading the entire chain ecology of Starknet. According to @tarrenceva's description, Starknet has State diffs state differences, which are different from optimistic rollups and focus on execution output rather than input. The impact on games is likely primarily to optimize cost, for example a game of chess: in a three minute game, 50 moves may occur. Through state differences, a single proof and final state can prove the "output". Optimistic rollups, on the other hand, require "inputs" from all intermediate states.

Define FOG/AW: how the game state is synchronized

I think to judge whether it is FOG, the benchmark 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, and when players send actions, the server compiles these inputs and returns updated results to each connected player's device. The server handles all input (ticks), resolves inconsistencies, and periodically sends updates to the player, providing a snapshot of all elements in the game, updating the game state every tick. The **game state ("game state or tick") is a snapshot in time of the properties of every object in the game world. Tickrate is the number of times per second that the game server calculates and broadcasts updated game state to players. The higher the Tickrate, the more precise and high fidelity the gaming experience will be. In general, real-time strategy or action games require high. tickrate, while turn-based games such as card games do not.

Source：

For games that run entirely on-chain, the blockchain is the game server and acts as a decentralized source of trust for the game state. In this case, not only NFTs or tokens have real ownership, but even the player's ticks and game logic are on-chain. This is why true ownership, persistence, censorship resistance, composability, and more are possible. Ideally, every action of a player should be submitted to the blockchain, and after a consensus is reached, the game state is updated and returned to the local device. So, naturally, game types that require less tickrate are better suited to be played entirely on-chain.

** Solve the challenges of game delay, time, etc.**

With the increase in game complexity and playability requirements, more challenges are put forward for the engine architecture: such as frame delay, random numbers, life recovery, continuous passive effects, timers, etc.

Frame number delay In fact, it is also very common in the Web2 world, including delays in client rendering and user operations. Especially for high tickrate games like FPS, once there is a delay, the player experience will be very poor. One of the solutions in Web2 is lockstep state update, which allows all players to be synchronized according to the highest delay standard among players, so as to solve the player's fair experience. This delay can be even worse when the blockchain is introduced and transactions need to be confirmed. To this end, Mud also adds the optimistic rendering mechanism commonly used in games, assuming that the user's operation is successful, and render it in the client before the server agrees (or in this case, before the transaction is confirmed).

Generating random numbers on the chain is a topic that is often discussed. Mud believes that user behavior can be used as the input of random results, which can be generated after the interaction occurs.

The concept of time and Ticks units are different on the blockchain. @SebastienGllmt thinks that it is difficult to use timers on chains that use fraud proof concepts (such as Op), because once something goes wrong, it will need to be rolled back. If timers are used in the game, the experience will be poor. Mud provides a lot of ideas to simulate the passage of time and passive recovery skills. For example, increasing gold coins over time, each time the player performs an operation that requires gold coins, calculate the player's gold coin amount based on the player's previous gold coin count, the latest refresh count, and the refresh rate. For another example, when the player moves in the room, the transaction comes with moving all the items in the room according to some predefined design. Use this to perceive changes in time and state.

** Writing scripts to "cheat" may not be a problem. **@BriefKandle does not think MEV of the game system is cheating. Preventing MEV with simple scripts is something the game team needs to consider. Web2 game development needs to change the way of thinking. A good MEV bot is an NPC in the game.

Some of this functionality has been implemented in some recently launched on-chain games, such as Rhascau, where they use timers and continuous passive effects. Basically using the block time as a tick. (In current L2, block time = tickrate).

FOG/AW technology stack

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

• Inefficiency in building FOG/AW on-chain due to lack of standard/ready-made framework;
• Lack of modularity and code reuse;
• Lack of composability. With the development of FOG/AW engine, on-chain games can be more interesting and imaginative.

For ease of understanding, the generally simplified technical process of this type of engine is: developers write front-end and back-end codes for ui/ux and game core logic, and then synchronize all changes through the loop of the game state, and finally reflect the new state to the front-end local device by the indexer.

In order to make games running on the blockchain run smoothly, Mud, Dojo, Curio, Argus, Paima engine, and Lootchain are developing their own technology stacks for this purpose. The technology stack consists of 3 key parts: chain, core development stack and game front end. They all have their own innovations, making trade-offs between decentralization and game complexity.

• Game front-end: Contains traditional engines such as Unity, Unreal, etc., as well as react/Threejs and other languages, and powerful tools to provide rendering and other functions, which is an indispensable part of enhancing game playability and experience. The above projects can basically provide relevant SDKs for developers to use.
• Core development stack: Design a set of solutions to allow the game logic to run on the blockchain and synchronize to the front end on time. Key components include an appropriate database structure (defining game behavior and logic), and synchronization and return of game state.
• Chain: Most of them choose to build on Ethereum, Optimism and Starknet.

The figure below depicts how different protocols design their respective technology stacks. Take Mud V2 as an example to see its operation flow:

1. A developer will call some Web2 front-end tools in Mud to write code, and use these powerful functions such as rendering to make the game more visual and more fun;
2. At the same time, developers will write the characters, items and specific operation logic of the game according to Mud's smart contract framework (Mud World), such as when hero A moves from X to Y and initiates a crusade against Y land, what probability or under what circumstances can the land be successfully occupied;
3. The above actions and game state will be recorded in Mud Store, which is an on-chain database responsible for the global game state and a source of trust for game state synchronization;
4. When hero A attacks Y, the player actually clicks the mouse on the front-end local machine and submits the command to be uploaded to the chain. The command is based on the developer’s game design logic and the current game state in the Store, resulting in a result. The result is updated to the new game global state and synchronized to the chain;
5. Games on Mud support various front-ends such as Web and Mobile, but may face complex indexing requirements. Mode is an off-chain indexer developed for this purpose.

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

• Most of them follow the Mud v1 design and utilize ECS as a data structure for game development. This is how the game logic is written and presented. Mud V2 has improved it, and data is defined in Tables and s, which allows other data standards (it does not have to comply with the ECS data modeling standard like V1), which gives developers more choices and makes it more inclusive.
• Most use decentralized databases, as the blockchain is naturally the source of trust for the game state and database. Mud is trying to maximize the full chain, and the entire application state is stored in the EVM. There is no sacrifice of decentralization or the introduction of off-chain integration schemes to achieve a higher tickrate for the game.
• Since many game types, such as FPS, require high tickrates, and blockchains produced by consensus can only handle changes in block times, tickrate is a big problem to be solved here. In their innovative designs, Curio and Argus are the first to hope to increase tickrates at the chain level.
• For the selection of different chains, both Curio and Loot use Caldera to build Op stack chains. In addition, Dojo is leading the entire chain ecology of Starknet. According to @tarrenceva's description, Starknet has State diffs state differences, which are different from optimistic rollups and focus on execution output rather than input. The impact on games is likely primarily to optimize cost, for example a game of chess: in a three minute game, 50 moves may occur. Through state differences, a single proof and final state can prove the "output". Optimistic rollups, on the other hand, require "inputs" from all intermediate states.

There are already some games built on these engines. Both Mud and Dojo are holding hackathons to attract developers to build applications. Curio has just released the minigame demo of Warcraft at ETHCC.

Obviously, FOG/AW is becoming a key ecology for public chain competition. The AW (Autonomous World) proposed by Lattice is a big concept, not limited to games, but also includes many attributes such as social and financial. So, built on top of that is an imaginative virtual world, the Metaverse. We can look forward to some new forms of integrated applications such as games, social networking, and finance.

Reference: