Gaming Infrastructure Part 3: Benefits of Building Games On-Chain
Shanav K Mehta
In the last piece, we proposed a framework for building games on-chain called ARC. Before diving into the intricacies of ARC, it makes sense to take a step back and make the case for building games on-chain in the first place. There has been warranted skepticism among both the gaming and crypto communities around the virtue of having any part of a game state stored on-chain, in the wake of the hyper-financialized first versions of on-chain games.
In this piece, we argue that the unique constraints and properties of decentralized network deployment open up an interesting set of game design primitives that lend themselves to both newer experiences within existing game loops and new genres of games. Some of the arguments are extensions of the well-documented arguments around verifiable ownership and asset programmability, while others explore novel benefits of on-chain game state. Here we explore the achievable outcomes and benefits for both fully on-chain games and on-chain asset layers.
Note: All benefits of on-chain assets covered in this piece extend to fully on-chain games, but the benefits of fully on-chain games do not necessarily extend to games supporting only on-chain assets.
Benefits of On-Chain Assets
Player Driven Economies
This is an extension of the original asset ownership argument that has been around since the inception of Ethereum. Think World of Warcraft but without assets being stored on Blizzard’s centralized servers. In an MMORPG, you could verify exactly the rarity of items and their mint rate in the world, without worrying about the existence of large stacks of these items in treasuries of companies or players that might devalue them.
By placing games in an open context, such as a blockchain, you allow for different games and projects to lean on one another. For example, a group of game devs could decide to use the same “player profile” or avatar and have a variety of different games in which the player levels up and have that be reflected throughout all the games within their collection because of open read/write permissions. You could also permissionlessly use another game’s state (for example if you’re someone who’s gotten a ‘legendary’ status in Game 1, you could unlock hidden areas in your game. This kind of composability is exciting because it opens up the doors for decentralized publishers where the lore of a universe could be maintained by a group of independent game developers that each have their own instance of the lore, and all changes to lore or standards be proposed and voted on by the game devs that produce games themselves (maybe gated by how well their games do).
Potential for UGC (User Generated Content)
This is an extension of the composability argument, but when game assets live on-chain there is a degree of permissionlessness around who can build around them. In traditional gaming, there are a handful of environments like Roblox that enable and encourage UGC. Most other platforms are built around walled gardens where assets are built and maintained by the game creator. Having a games asset layer built in an open source manner with user-level ownership increases the potential to create user-generated game loops around those assets. From the game developer’s perspective, this increases distribution that could feed back into the original game loop, and from the users’ perspective, this creates more playable loops. This opportunity is compounded in fully on-chain games when the original game’s rule set and code base is open sourced.
Additional benefits of fully on-chain games
Serverless, Continuous Deployment
This is a huge boon for developers that alleviates operational concerns related to server scalability, and maintenance. By pushing all server logic to a decentralized consensus, developers can just build the game and deploy it. Players can play it long after developers are gone, with the game scaling to as many operations as permitted by the underlying blockchain. This solves a problem that is fairly persistent with traditional multiplayer games with centrally hosted servers that are often shut down a few years after launch.
You can (not necessarily must) have separation between the game deployment and its maintenance. After a creator develops a set of rules, governance over those rules can be delegated to the players, allowing for infinite growth potential as players grow and maintain it. If a developer proposes a new rule the player base is not a fan of, they could theoretically continue playing with the old rules instead.
Verifiably Secure State Transitions
Using advanced cryptography techniques like zero-knowledge proofs, one can prove things like: “I made a valid set of moves” without revealing the moves themselves. This is a valuable property for fully on-chain games that, by virtue, do not want to have a central authority that keeps track of and attests to game state but need to maintain knowledge siloes around player moves in order to operate. An interesting case study of a game that uses this property is Dark Forest, an entirely on-chain RTS. It’s a simple game to learn, but all the moves made in the game are published to a public ledger to provide anonymity to the moves.
Having game loops, or even game assets, live on-chain extends meaningful benefits to developers and users. Ultimately, the decision matrix for game developers will be informed by the tradeoffs in user experience required to attain these benefits. Today, this cost is substantial with the current state of infrastructure.
In the next article, we will discuss the infrastructure that might be required in addition to an ARC-based games backend to create a user experience that is similar to that of traditional games.
Stay up to date with the latest from Jump_
SAFU: Creating a Standard for Whitehats
Whitehats and DeFi protocols need a shared understanding of security policy. We propose the SAFU - Simple Arrangement for Funding Upload - as a versatile and credible way to let whitehats know what to...
Oct 24 2022 _ 17 min
Huckleberry: IBC Event Hallucinations
This blog post describes a vulnerability in ibc-go, the reference implementation of the Interblockchain Communication Protocol (IBC) used by most Cosmos blockchains
Sep 06 2023 _ 4 min
The information on this website and on the Brick by Brick podcast or Ship Show Twitter spaces is provided for informational, educational, and entertainment purposes only. This information is not intended to be and does not constitute financial advice, investment advice, trading advice, or any other type of advice. You should not make any decision – financial, investment, trading or otherwise – based on any of the information presented here without undertaking your own due diligence and consulting with a financial adviser. Trading, including that of digital assets or cryptocurrency, has potential rewards as well as potential risks involved. Trading may not be suitable for all individuals. Recordings of podcast episodes or Twitter spaces events may be used in the future.