Gaming Infrastructure Part 1: Defining On-chain Gaming

Background

Gaming has long been touted as a potential core use case for crypto. Built around natively digital assets and serving global audiences, games are in many ways the perfect candidate to leverage on-chain verifiable attestation, ownership, and global payment rails. As with any new innovation, however, the first version often leaves much to be desired. The first cohort of games was naturally clunky, gimmicky and turned off many true gamers by hyper-financializing the experience.

The next cohort of games being built on-chain, however, looks to leverage verifiable attestation, ownership, and asset programmability, while focusing on game loops built around genuine user acquisition and retention versus token speculation; more importantly, this cohort is being built by experienced game developers. In addition to a new genre of games enabled by shared-state serverless compute, we are starting to see IP from some of the largest game studios in the world beginning to come on-chain.

While a healthy level of skepticism remains around on-chain gaming by crypto natives and gamers alike, the ingredients for exciting and engaging on-chain games are very much in place. The final ingredient required is robust infrastructure that can make the gaming experience on-chain as frictionless for users as traditional gaming is today.

In this series of articles, we will cover everything from types of on-chain games to types of infrastructure required to realize each version of on-chain games.

We begin by defining the types of on-chain games that could exist.

Types of “On-Chain Games"

Broadly speaking, the phrase “on-chain gaming” has been used to describe a spectrum of game types where the degree of the game that lives on-chain can range from state updates for every move to one-off optional cosmetic mints for assets. Below is a rough overview of each game type on this spectrum.

Approach #1: Fully on-chain (FOC)

Fully on-chain games have been the focus of most of the recent discourse around on-chain gaming. Under this approach, the blockchain is used as an alternative to a centralized game server, with all players indexing from and writing to a shared state on-chain.

The shared state captures data related not only to assets but all aspects of game state. E.g. in a chess game, the shared state on-chain would capture details around the position of each piece for both black and white after every move made by a player. This approach enables features such as persistence (i.e. games can continue to survive even without continued contribution form the original creator), censorship resistance, and community-owned development.

While this enables the creation of new game types, this approach is currently well suited only for certain subset of turn-based games, given that each move must be submitted to the blockchain as a transaction that must go through consensus and reach finality before the next move can be made. Specifically, this is well suited for games with relatively few state updates per session either as a function of fewer players or fewer moves per player per session. Examples of games that have successfully adopted this approach include Dark Forest and 0xMonaco. Genres such as 18xx, which have been well documented in AllianceDAO blogs, are also well suited to this approach.

As game complexity increases, either in the form of simultaneous play or more frequent state updates per session, required state transitions may expand to include not only player inputs, like moves in a chess game, but also trivial mechanics (e.g. passive regeneration of hit points in an RPG). Requiring continuous “crank” (and accompanying gas fees) for these game mechanics therefore limits the practical game design space. Given the current state of blockchain architecture, these game types may be better suited to a hybrid on-chain/off-chain approach.

Approach #2: On-chain assets (OCA)

Under this model, user assets live on-chain while game loops live off-chain. On-chain asset state is indexed by the game server at the start of a session and state transitions are recorded off-chain on the game server. State is only relayed back on-chain from the game server at the end of a session or when game loop outcomes materially impact asset state. Perhaps a user could opt to “save state” and pay the associated gas cost. This approach makes tradeoffs around trustlessness for speed and performance.

Let’s consider a PvP combat game like Street Fighter. Users can own their Ryu avatar on-chain and attest to their ownership to initiate a game session off-chain. However, unlike the first approach, the state after every move (e.g. how much energy the character has lost after each move) will remain local to the game server. State will only be updated on-chain when a winner is declared if there are any implications to the assets living on-chain. For example, if the character has achieved a level-up that warrants a change in the NFT metadata, or if two players were part of a cash-incentivized tournament for which a smart contract needs to be settled. This approach is better suited to feature-rich games with greater frequency of moves per player, such as MMORPGs and FPS games.

This approach requires performant infrastructure. Some requirements include rapid indexing, metadata updatable asset standards on-chain, data relay infrastructure to communicate off-chain state on-chain, and automatic on-chain execution based on relayed data. Without these, user friction will be high and developer adoption low.

Approach #3: Optional Cosmetic Mints (OCM)

Under this approach, games look exactly like they do today where asset ownership and state updates are recorded in the off-chain game database. The only difference versus existing games is that users have the option to mint the current version of character assets as NFTs on-chain and trade them there if they so choose. Additionally, the game may have some sort of loyalty/season pass that lives as an NFT on-chain and facilitates access control within the game based on ownership. While appropriate infrastructure for approaches #1 and #2 is being built out, this path likely has the least friction for users.

Conclusion

Each approach above solves a different problem.

Approach #1, for example, solves game server trust. By indexing and writing to a shared state on-chain, this approach circumvents the need for game servers. This opens a new design space for fully on-chain games and may be well suited for a certain subset of turn-based games.

Approach #2 solves verifiable asset ownership and asset programmability. This approach limits trustlessness requirements to the asset layer rather than to all aspects of game state. This also enables the creation of verifiable economies around game assets by introducing trustlessness to secondary sales.

Approach #3 solves user experience. This approach argues that, under the current state of infrastructure, both aforementioned approaches introduce too much friction for gamers and therefore on-chain components should be optional and limited.

We argue that, with the right infrastructure, approach #1 and #2 could offer a similar user experience to approach #3 with the added benefit of having varying parts of game state on-chain. This would require standards that make communication, inventory management, and state transition automation seamless.

In the following articles we will highlight some of this infrastructure, along with potential design constraints and decisions that could make this infrastructure performant. In the next article, for example, we will explore a framework for updatable on-chain assets called ARC (Action Registry Core) built around an architectural pattern known in traditional gaming as ECS (Entity Component System).

Stay tuned!