Gaming Infrastructure Part 4: Communication Infra in an ARC World

Overview

Now that we understand the motivations behind building games on-chain, we can return to exploring ARC architecture, which we argue is the optimal approach to building on-chain games and the surrounding infrastructure required for their operation.

To recap, ARC stands for Action Registry Core, which is a data-oriented approach to organizing information (as opposed to object-oriented). ARC is inspired by a traditional game architectural pattern called ECS, which stands for Entity Component System. The primary difference between traditional ECS and our on-chain implementation called ARC is that the latter accounts for the fact that blockchain architecture is push-based as opposed to traditional game systems, which are loop-based. Under the ARC approach, entities are data-less containers for components, components are plain data types without behavior that can be “attached” to entities, and actions are functions that can execute behavior related to components.

Actions are therefore responsible for on-chain state updates related to game progression. Specifically, they are responsible for two types of operations: i) read Entity PDA & deserialize components and ii) modify serialized components to be updated with the entity. To perform optimally, Actions require associated infrastructure that varies based on the pieces of the underlying game that live on-chain. Below, we cover what these pieces of infrastructure do as well as how requirements vary for fully on-chain games (FOC) versus games using on-chain assets (OCA).

Recommended reading before this piece: Gaming Infrastructure Part 2: Introduction to ARC

Types of Communication Infrastructure

The types of communication infrastructure required for the operation of ARC are relatively similar to the infrastructure required to interact with traditional databases. The codebase that engages in-game progression (game server for on-chain assets (OCA) and the client for fully on-chain games(FOC)) needs to be able to read state from and write state to the blockchain. As with traditional databases, the first piece can be solved by an indexer, and the second by some sort of data relay infrastructure. Below we cover each piece in detail, including the differences in requirements for on-chain assets (OCA) and fully on-chain (FOC) games.

Note: Some of this infrastructure is not unique to ARC and may also apply to object-oriented approaches, though we cover it in the context of ARC below.

1. Indexer

This piece of infrastructure is a common requirement across both approaches. Simply put, the codebase that engages in-game progression would need to know the current state from the blockchain in order to follow a single order of events. In the case of on-chain assets (OCA), this is the game server — and in the case of fully on-chain (FOC) games, this is the game client.

The primary difference between an indexer for games versus a traditional blockchain RPC node is the performance requirements. Regular RPC nodes can afford to take a handful of seconds to serve data because most user transactions are financial in nature and are single-use. For games, on the other hand, there could be multiple on-chain interactions per user session depending on the portion of the game that lives on-chain. Gamers also have a significantly lower tolerance for latency, which means data service times need to be sub-second. Another element that could be optimized for by game-specific indexers is query language. RPC nodes usually have a primitive API to query raw data, whereas indexers can be purpose-built to expose ergonomic APIs for querying human-readable state.

2. Data Relay - Actions for On-Chain Assets

Since an Action is just code that can execute behavior related to a component, it need not live on-chain. For games where the game loop lives off-chain and the asset layer lives on-chain, state updates need to be relayed semi-frequently to the blockchain. Under ARC architecture, Action logic can be pushed off-chain to the relay infrastructure level and smart contract update authority can be delegated to this infrastructure. This approach also serves to reduce latency, given that it introduces a degree of automation that is unavailable in an object-oriented approach, which would require a separate mechanic to crank changes in object state. For games that choose to minimize trust assumptions, there may also be the opportunity to add validity or zk proof-based attestation of game state. While relatively computationally expensive today and not a requirement for most games, this level of trustlessness could become feasible as proof generation cost and time come down.

3. Client SDK - Action bundles for Fully On-Chain Games

Similarly, for fully on-chain (FOC) games, Action-level logic can be part of the client SDK. Moves made by players would then directly influence state transitions on-chain. This modularity is unique to ARC in that data and intent are segregated, allowing Actions to live wherever the developer chooses.

Communications Infrastructure in Action

Example of State Updates for On-Chain Assets

Let’s take a naïve version of Street Fighter as an example. In the simple version of Street Fighter, a player must take control of a character and go through ten battles in order to complete the game. Player moves impact character health in each match and each match consists of three battles, where the first player to win two advances. Let’s say in an on-chain asset approach, that the primary character avatar (in this case, let’s say it’s the Ryu avatar) is stored as an asset on-chain. Theoretically, this asset could have multiple cosmetics as well as functional properties, but in this case, let’s focus on the property that matters (i.e. number of matches won). Below is a representation of what the on-chain ARC designation might look like:

Entity == Ryu character

Component #1 == Level / # of battles won

Component #2++ == {Some series of cosmetic attributes}

In this case, we are assuming that game loops continue to run off-chain, and data is only conveyed back on-chain at the end of a battle when our character beats another in a 2/3 majority match. At the start of a session, when a user connects their wallet, the game server would query the state of the components within the entity via an indexer.

Let’s say it recognizes that the character has won three matches; it will use this information to queue up the fourth battle. Now, let’s say our character wins two out of three interactions, the game server updates state internally to capture this. However, this information is yet to be reflected in the on-chain asset state.

This is where some sort of data relay/oracle infrastructure would come in. The game server would, based on some pre-defined trigger, pass a payload through this data relay that posts this data on-chain. Under the ARC architecture, it is ultimately the Action that influences state transitions for components within entities. In this case, the Action could either sit on-chain as a smart contract or within the data relay logic. In either case, once the information has been made available to the Action, it will deserialize component data and re-serialize it with the state update, such that the component state at the next epoch reflects the change in number of battles won.

Example of State Updates for Fully On-Chain Games

Let’s stick with the same example of Street Fighter. The only difference in the case of a fully on-chain (FOC) game would be that there is no off-chain database to handle any state changes, which means the blockchain must be the database of record for all game state transitions.

We can assume again that our entity is the character we play with (e.g. Ryu). As with the on-chain assets (OCA) approach, one component will be a ticker for the number of battles won. However, in the case of a fully on-chain (FOC) game, we would also need to record state updates related to health after every move in each match. Assuming we are playing a PvP version of the game, both players’ entities would need to be accessible within a shared contract for each battle that holds a shared state of matches within that battle.

Entity == Ryu character

Component #1 == Level / # of battles won

Component #2 == Health in Match #1 in Battle #1

Component #3 == Health in Match #2 in Battle #1

To start the game, Player 1’s client would query the state of both their character and that of the opponent from the shared contract. Player 1 would then make a move that would have some impact on the health of Player 2. Assuming this is built using ARC, Action logic could be shared with the client software and the Action would deserialize Component #2 within Player 2’s entity, which would lead to a state transition on-chain. Player 2’s client could then index the shared contract before making a move that impacts Player 1’s Component #2 state in a similar manner. This would continue until the match ends, after which Component #2 could be removed from both entities and Component #1 could be updated with # of battles won.

This example would be too computationally intensive for a fully on-chain (FOC) game, however, it does illustrate how the infrastructure would operate, in theory.

Note in this case, the Action also independently deserializes component data to avoid client-level trust assumptions.

Conclusion

ARC requires a specific set of peripheral infrastructures to operate in a performant manner. ARC provides incremental flexibility versus a traditional object-oriented model in that Actions within ARC can be embedded at various points within the peripheral infrastructure to make automation smoother. Once this peripheral infrastructure is built and optimized for speed, on-chain games could ultimately have a similar user experience as off-chain games, with the benefits that come with verifiable asset ownership and programmability.