Original author: Fiona, IOSG Ventures

Thanks @BriefKandle Creator of @netherscape_xyz, @stokasz CEO@rhascau @mintersworld, @0x curio team, @SebastienGllmt cofounder@PaimaStudios, @hiCaptainZ, and @SerenaTaN 5 for their help and valuable advice!

TL;DR

• The full-chain game / autonomous world ("FOG/AW") is one of the few important narratives around Web 3. Unlike Web2.5 applications that only connect to Web3 through NFT, FOG/AW also puts game logic on the chain. It uses blockchain as the game server and becomes a decentralized trust source for game state. This brings advantages such as persistence, censorship resistance, and composability, but it also limits game diversity and complexity built on top of it.

• With the increasing demands for game complexity and playability, more challenges are posed to engine architecture: such as frame latency, random numbers, life value recovery, continuous passive effects, timers, and so on. The concept of time and the unit of Ticks are different on the blockchain. Mud offers many ideas to simulate the passage of time and passive recovery skills. For example, when a player moves in a room, the transaction includes moving all the items in the room according to some predefined design. In this way, the change in time and state is perceived.

• The FOG/AW technology stack can be abstracted as follows: developers write frontend and backend code for UI/UX and game core logic, and then synchronize all changes through the game state loop, finally reflecting the new state to the frontend's local device through the indexer.

• Since many game types, such as RTS, require high tickrates, while the blockchain generated by consensus can only handle changes in block time, tickrate is a major problem to be solved here. Curio and Argus are leaders in this regard, as they are exploring ways to increase the game tickrate at the level of the chain. Mud is trying to achieve full-chain, where the entire application state is stored in EVM, without introducing off-chain solutions for higher tickrate implementation in games.

• For the selection of different chains, Dojo leads the full-chain ecosystem of Starknet. According to @tarrenceva's description, Starknet has state diffs, which are different from optimistic rollups, focusing on executing outputs rather than inputs. The main impact on games may be in optimizing costs, such as chess games: in a three-minute game, there may be 50 moves. Through state diffs, a single proof and the final state can prove the "output." Optimistic rollups, on the other hand, require the "input" of all intermediate states.

Defining FOG/AW: How game states are synchronized

I believe that the benchmark for determining whether it is FOG is how game states are 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 handles all inputs (ticks), resolves inconsistencies, and periodically sends updates to players, providing a snapshot of all elements in the game. The game state ("game state or tick") is a time snapshot of the properties of each object in the game world. Tickrate refers to the number of times the game server calculates and broadcasts updates to the game state per second. The higher the tickrate, the more precise and high-fidelity the gaming experience. Generally, real-time strategy or action games require a high tickrate, while turn-based games like card games do not.

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

For games running entirely on the blockchain, the blockchain serves as the game server and a decentralized trust source for the game state. In this case, not only NFTs or tokens have true ownership, but also the players' ticks and game logic exist on the chain. This is why true ownership, persistence, censorship resistance, and composability can be achieved. Ideally, every action by players should be submitted to the blockchain, and after consensus is reached, the game state is updated and returned to the local device. Therefore, naturally, game types that require a lower tickrate are more suitable for running entirely on the chain.

Solving the challenges of game latency and time

As the complexity and playability requirements of games increase, more challenges are posed to the engine architecture, such as frame rate delay, random numbers, life value recovery, continuous passive effects, timers, etc.

Frame rate delay is actually very common in the Web 2.0 world, stemming from both client-side rendering and user interaction delays. Especially in high tickrate games like FPS, once there is delay, the player experience will be very poor. One of the solutions in Web 2.0 is lockstep state update, synchronizing all players based on the highest delay among them, ensuring fair gameplay. When introducing blockchain and the need to wait for transaction confirmation, this delay could become even more severe. Therefore, Mud has also added the commonly used mechanism of optimistic rendering in games, assuming the user's action is successful and rendering it on the client-side before server agreement (or in this case, transaction confirmation) takes place.

Generating random numbers on-chain is a frequently discussed topic. Mud believes that user behavior can be used as input for generating random results after interaction occurs.

The concept of time and the unit of Ticks are different on the blockchain. @SebastienGllmt believes that using timers is difficult on a fraud-proof concept chain (such as Op) because any mistakes would require a rollback, leading to a poor game experience if timers are used. Mud provides many ideas for simulating the passage of time and passive recovery skills, such as increasing gold coins with the passage of time. Each time a player performs an action that requires gold coins, their number is calculated based on their previous gold coin count, the most recent refresh quantity, and the refresh rate. Another example is when a player moves in a room, the transaction includes moving all items in the room according to some predefined design, thus perceiving the changes in time and state.

Writing scripts to "cheat" may not be a problem. @BriefKandle believes that MEV in game systems is not considered cheating, and preventing scriptable MEV is something game teams need to consider. Game development in Web 2.0 requires a mindset shift, where good MEV bots become NPCs within the game.

Some of these features have been implemented in recent blockchain games. For example, in Rhascau, they use timers and continuous passive effects. Essentially, they use blockchain time as the scale (in the current L2, block time = tickrate).

FOG/AW Technology Stack

The FOG/AW engine framework is a developer toolkit that allows developers to build games utilizing the blockchain as the server and source of trust. In addition, it can address some of the current issues:

• The efficiency of building on-chain FOG/AW is low due to the lack of standard/pre-existing frameworks;

• Lack of modularity and code reusability;

• Lack of composability. With the development of the FOG/AW engine, blockchain games can become more interesting and imaginative.

In order to facilitate understanding, the general simplified technical process of such engines is as follows: developers write frontend and backend code for UI/UX and game core logic, and then synchronize all changes through the game state loop. Finally, the indexer reflects the new state to the frontend's local device.

To ensure that games running on the blockchain can also run smoothly, Mud, Dojo, Curio, Argus, Paima Engine, and Lootchain are developing their own technology stacks for this purpose. The technology stack consists of three key parts: chain, core development stack, and game frontend. They all have their own innovations and strike a balance between decentralization and game complexity.

• Game frontend: It includes traditional engines such as Unity, Unreal, as well as languages like React/Three.js and powerful tools to provide rendering and other functions, which are essential for enhancing game playability and user experience. Most of these projects provide related SDKs for developers to use.

• Core development stack: Designing a solution that allows game logic to run on the blockchain and synchronize with the frontend in a timely manner. Key components include a suitable database structure (defining game behaviors and logic) and synchronization and return of game state.

• Chain: Most choose to build on Ethereum, Optimism, and Starknet.

The following diagram illustrates how different protocols design their respective technology stacks. Taking Mud V2 as an example, let's look at its workflow:

• A developer will use some Web2 frontend tools in Mud to write code, leveraging powerful features such as rendering to make the game more visually appealing and enjoyable.

• At the same time, the developer will use Mud's smart contract framework (Mud World) to write game characters, items, and specific operational logic. For example, when hero A moves from location X to location Y and launches an attack on tile Y, what is the probability or under what conditions can successfully occupy that tile?

• The above actions and game states are recorded in the Mud Store, which is an on-chain database responsible for the global game state and serves as the trusted source for game state synchronization.

• When Hero A launches an attack on Y, it is actually the player clicking the mouse on the frontend and submitting the command to the chain. This command, based on the game design logic of the developer and the current game state in the Store, results in an outcome. The outcome is updated in the new game global state and synchronized to the chain.

• The game on Mud supports various frontends such as Web and Mobile, but it may face complex indexing needs. Mode is a off-chain indexer developed for this purpose.

Now, let's talk about the commonalities and differences in the design of these core frameworks.

• Most of them follow the Mud v1 design and use ECS as the data structure for game development. This is the way the game logic is written and presented. Mud v2 improves on this by defining data in Tables and Systems, allowing for other data standards (not necessarily complying with the ECS data modeling standard like v1) and giving developers more choices and greater inclusivity.

• Most of them use decentralized databases because the blockchain naturally serves as the trusted source for game state and database. Mud aims to achieve full on-chain to the greatest extent possible, with the entire application state stored in the EVM. There is no compromise on decentralization or introduction of off-chain integration to achieve a higher tickrate for the game.

• Since many game genres, such as FPS, require high tickrates, while the blockchain generated by consensus can only handle changes in block time, tickrate is a major challenge to solve here. Curio and Argus are leading the way in their innovative designs, hoping to increase tickrates at the level of the chain itself.

• In terms of chain selection, Curio and Loot both utilize Caldera to build an Op stack chain. In addition, Dojo is leading the full-chain ecosystem of Starknet. According to @tarrenceva's description, Starknet has state diffs, which are different from optimistic rollups, with the focus on executing outputs rather than inputs. The main impact on the game may be optimization costs, for example, in a chess game: in a three-minute game, there may be 50 moves. Through state diffs, a single proof and the final state can prove the "outputs". Optimistic rollups, on the other hand, require the "inputs" of all intermediate states.

Currently, some games are built on these engines. Mud and Dojo are hosting hackathons to attract developers to build applications. Curio also recently released a Warcraft mini-game demo at ETHCC.

Clearly, FOG/AW is becoming a key ecosystem in the competition of public chains. AW (Autonomous World) proposed by Lattice is a grand concept that goes beyond games and includes various attributes such as social and financial. Therefore, building on this is an imaginative virtual world, namely the Metaverse. We can expect new forms of integrated applications in gaming, socializing, finance, and more.

Reference:

1.https://mirror.xyz/matchboxdao.eth/d3lVAOa9Bi0kY- caoUT 3 lDC 6 E 61 mWJqtP 1 q 6 tME 4 xGY 

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