The tech stack of on-chain gaming: how the game state is synced

Published in

IOSG Ventures

7 min readJul 26, 2023

Special thanks to @BriefKandle Creator of @netherscape_xyz, @stokasz CEO@rhascau @mintersworld, @0xcurio team, @SebastienGllmt cofounder@PaimaStudios, @hiCaptainZ, and @SerenaTaN5 !

Takeaways

Fully on-chain gaming/Autonomous World(“FOG/AW”) is one of the few important narratives around Web 3. Unlike Web 2.5 applications that only connect to Web 3 via NFT, FOG/AW puts the game logic on the chain by utilizing the blockchain as a game server and the decentralized source of trust for the game state.
Latency, randomness, hit point regeneration, continuous passive effects, timer, etc. are challenges in a full-fledged FOG/AW. The concept of time and the unit of ticks are different for blockchains, where Mud provides a number of ideas to represent time passing and passive recovery effects. For example, when the player moves inside a room, the transaction comes with moving all the items in the room according to some predefined design.
The FOG/AW tech stack can be abstracted as follows: the developer writes the front-end and back-end code for UI/UX and the core game logic, then synchronizes all the changes by looping through the state of the game, and finally an indexer reflects the new state to the front-end’s local devices.
Tickrate = block time is a key limitation for RTS or high tickrate games since blockchain can only handle changes in block time. Curio and Argus are leaders in this area and are figuring out how to increase the game tickrate at the chain level. Mud, on the opposite, is trying to be as on-chain as possible, and has not introduced any off-chain hybrid solutions to achieve a higher tickrate for the game.
Dojo is leading FOG ecosystem on Starketnet with respect to the choice of different chains. According to @tarrenceva’s description, Starknet has State diffs, which, unlike optimistic rollups, focus on execution outputs rather than inputs. It could cost less. Consider a three-minute chess game with 50 moves that may occur, a single proof of final state diffs is needed only, while optimistic rollups require “inputs” from all intermediate states.

Define FOG/AW: how the game state is synced

I think the benchmark to determine a FOG/AW is how the game state is synchronized (source of truth).

For a Web 2.5 game or traditional multi-player game, there is a centralized server to define the current game state when players send actions and the server translates those inputs and returns the updated results back to each connected player’s device. The server processes all inputs (ticks), settles inconsistencies, and transmits regular updates to players, providing a stream of snapshots of all elements in the game, updating the game state every tick. The 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 an updated game state is calculated and broadcast by a game server to players every second. The higher the tickrate, the more precise, high-fidelity gaming experience. Generally, real-time strategy or action games require a high tickrate, while turn-based games like card games do not need that.

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

For fully on-chain games, blockchain is the game server acting as the decentralized source of trust in the game. In this case, not only do the NFTs or tokens have true ownership, but also gamers’ ticks as well as game logic are on-chain with decentralized infrastructure. That’s why true ownership, persistence, censorship resistance, composability, etc. can be realized. Ideally, each move of gamers should be submitted to the blockchain and after consensus, the game state is updated and returned to local devices. So naturally, game genres that require low tickrate are more suitable to be fully on-chain. The game tick can be written in the smart contract to automatically update the game state.

Solve challenges of latency, timing, etc.

Latency, randomness, hit point regeneration, continuous passive effects, timer, etc. are challenges in a full-fledged FOG/AW.

Latency is a common problem in the Web2 world, e.g. lag between user actions and client-side rendering, especially in high tickrate games like FPS. One of the solutions in Web2 is a lockstep state update, which can make all players have the same latency as the slowest. It can be even worse when blockchain is intervened as the need to wait for transaction confirmations. Thus, Mud adds optimistic rendering, a pattern commonly used in games, which assumes a successful user action and renders it to the client before the transaction is confirmed.

Generating on-chain randomness is a frequently discussed topic, and Mud suggests using user actions as a seed input for the randomness of events, which is generated after the transaction has occurred.

The concept of time and the unit of ticks are different for blockchains, where Mud provides a number of ideas to represent time passing and passive recovery effects. For example, when the player moves inside a room, the transaction comes with moving all the items in the room according to some predefined design. In-game currencies can also be generated linearly for each player. @SebastienGllmt argued that it would be difficult to use timers on chains that use fraud proofs (e.g. Op) because if something goes wrong, it will need to be rolled back.

Writing scripts to “cheat” might not be an issue. @BriefKandle doesn’t see MEV as cheating and argues that game devs need to change their mindset as good MEV bots can also be in-game NPCs to stimulate activities.

Some of the features above have already been implemented in some recently launched on-chain games, such as Rhascau, where they use timers and continuous passive effects with blocks as ticks. (In current L2, block time = tickrate).

The FOG/AW tech stack

The FOG/AW tech stack allows developers to build games utilizing blockchain as a server and source of trust. In addition, it can solve some of the current problems:

poor efficiency in building on-chain games with no standard/ready-to-go framework;
lack of composability. With the development of the fully on-chain game engine, on-chain gaming can be more fun and imaginative.

To make it easier to understand, the simplified technical flow is: developers write front-end and back-end code for UI/UX and core game logic, then the system synchronizes all the changes/ticks by looping through the game state, and finally the indexer reflects the new state to the local device on the front-end.

Mud, Dojo, Curio, Argus, Paima engine, and Lootchain are developing their own innovative solutions to make trade-offs between decentralization and performance. The following diagram depicts how the different protocols have designed their respective technology stacks. Let’s take Mud V2 as an example to see the tech flow:

A developer will invoke some of the front-end tools in Mud to use powerful features such as rendering to make the game more visual;
What’s more, the developer can follow the smart contract framework (Mud World) to create the characters, items, and specific in-game logic, such as when Hero A moves from X plot to Y plot and submit a crusade against plot Y, what is the probability and/or under what circumstances Hero A will succeed;
The above actions and game state will be recorded in the Mud Store, which is an on-chain database responsible for the global game state and a trusted source of game state synchronization;
When Hero A makes a crusade against Y plot, it is actually the player who clicks the mouse on the front-end local machine and submits the command to on chain. Then under specific logic designed by the developer, this player action, along with the current game state in the Mud Store, results in a new global state of the game.
Mud supports a variety of front-ends such as Web, Mobile, etc., and thus could face complex indexing requirements. Mode is an off-chain indexer developed precisely for this purpose.

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

Some of them follow Mud v1 design and utilize ECS as the data structure for game development. Mud V2 improves on this, with data being defined in Tables and Systems, which allows for other data standards (without having to adhere to the ECS data modeling standard as V1 did), which gives developers more options and makes it more inclusive.
Most of them use the decentralized database as blockchain is naturally the game state and database for the source of truth. Mud is trying to be maximally on-chain, and has not introduced any off-chain hybrid solutions to achieve a higher tickrate for the game.
As many game genres such as FPS, require high tickrate, while blockchain can only handle changes in block time, tickrate is a big problem to be solved here. Curio and Argus are pioneering their own innovative designs that add tickrate at the chain level.
Regarding different chains, both Curio and Loot are utilizing Caldera to build Op stack chains. Dojo is leading FOG ecosystem on Starketnet though. According to @tarrenceva’s description, Starknet has State diffs, which, unlike optimistic rollups, focus on execution outputs rather than inputs. It could cost less. Consider a three-minute chess game with 50 moves that may occur, a single proof of final state diffs is needed only, while optimistic rollups require “inputs” from all intermediate states.

There are already a number of games built on top of these engines, with Mud and Dojo both hosting hackathons to entice developers to build apps, and Curio just released an eye-catching Warcraft minigame demo at ETHCC.

The tech stack of on-chain gaming: how the game state is synced

Takeaways

Define FOG/AW: how the game state is synced

Solve challenges of latency, timing, etc.

The FOG/AW tech stack

References

Written by FionaHe