CaptainZ

Table of Contents#

1. Design for Emergence
   • Modularity
   • Open Economies
2. On-Chain Games
3. Open Questions
   • Technical constraints limit game design.
   • Composability is inherently financialized.
   • Meta-games tend to stagnate.
4. Should games be fully on-chain?
5. Conclusion
6. Acknowledgments

The intersection of gaming and cryptocurrency is filled with infinite possibilities. Vitalik's inspiration for creating Ethereum came from Blizzard's nerfing of his character's skills in World of Warcraft. While World of Warcraft is not "critical infrastructure," we expect virtual worlds to become critical infrastructure, containing trillions in assets and millions of job opportunities. It is hard to imagine they would exist under the control of centralized platforms.

Of course, in theory, decentralized applications sound appealing. The most attractive in practice are those that can only be realized through crypto: applications that can only exist on-chain. Despite strong narrative momentum, identifying the unique features of on-chain games has proven to be challenging.

Why put games on the blockchain?

This article reflects our current thoughts on this question.

Designing for Emergence#

Some games achieve long-term engagement by providing creatively rich tools for users to generate new content ("UGC"). The two main sources of UGC—modularity and open economies—are the breakthrough directions we believe on-chain games could achieve.

Modularity
Modularity allows third-party developers to create content beyond what the original game developers envisioned. Many groundbreaking games (like DoTA, LoL, PUBG) originated from mod versions of other games. Others, like Roblox, have transformed from games into mod development platforms. While game studios typically focus on production value, highly engaged mod communities bring diversity and novelty: akin to the comparison between Netflix and YouTube.

Minecraft is a great concrete example. Its simple game mechanics facilitate adjustments. Mods that extend these mechanics can recombine to create new functional experiences. Many popular Minecraft servers are entirely different from the original (like jailbreak, battle royale, etc.).

However, even Minecraft has a limitation: players cannot contribute new mods to existing servers. They must start a new server to introduce changes. Thus, Minecraft's "universe" is fragmented across many parallel, mostly non-interactive private servers.

Modern games achieve modularity like Minecraft primarily through instantiation (new servers) rather than scripting (existing servers) for good reason. Ensuring that player-contributed code is compatible with the native rule set is challenging (especially leveraging this is particularly difficult). Updates to the rule set can break mods built upon it. Limited computational resources require intelligent allocation.

However, instantiation leads to fragmentation. Every mod that creates a new server competes for players' attention with other servers. Mod developers must consider not only what is interesting to add to a world but also whether it is worth opening a new server for it.

Given that many potential mods may only be meaningful in context—i.e., added to an already existing world. For example, suppose you run a restaurant on a Minecraft server and want to add a new item to the menu. Starting a new server to achieve this makes no sense, as you would need to convince all your customers to switch to the new server, which they may not do because they have their own commitments and customers on the existing server.

Those fragmented game worlds lose the ability to expand gradually.

Open Economies
In-game economies represent another dimension of nearly limitless creativity. We will use EVE (the first game to employ full-time economists) as a teaching example.

In the informal combination of game systems and external infrastructure, EVE players produce and trade goods; declare, lease, and contest territories; and organize everything from industrial collectives to warring pirate factions. Even simple tasks like transporting resources have fully player-operated companies dedicated to completing them—complete with customer service, service level agreements, and employee benefits.

Players have been coming to EVE for over two decades, not because of new content from developers, but because of the rich social and economic world driven by other players.

However, even EVE's economy has some significant limitations:

1. Limited in-game primitives. Any transactions beyond the primitive set defined by developers (e.g., loan agreements) must rely on informal, unenforceable trust networks. This trust limits the complexity and scale of the economic structure.

2. Regulatory constraints. Due to compliance issues, the vast majority of games (including EVE) simply prevent players from transferring any assets or exchanging in-game goods or services for fiat currency. Only large compliance departments maintain such allowances under strict terms.

On-Chain Games#

There are many different potential forms of on-chain games. Our focus is on the most crypto-native: fully on-chain games, whose state and logic exist entirely on open smart contract platforms.

Equally important, on-chain game mods can be deployed as their own contracts alongside the base game logic without permission. Users only need to choose their client to select the mods they wish to participate in (rather than having decisions made for them by administrators).

So, why put games entirely on the blockchain? We believe the most compelling reasons are based on two points:

1. Composable modifications. Players can add mods to fully on-chain games without requesting permission or splitting their state. On-chain infrastructure and smart contract developers are already prepared for the challenges of allowing players to upload code without permission: security audits, access control, resource metering, etc. Traditional games do not adapt to this environment and are unlikely to reorganize around supporting composable mods.

2. Permissionless open economies. Players can use smart contracts to create an economy for a game, rather than being limited to a set of game primitives defined by the game's developers or having to rely on informal and unenforceable agreements. Additionally, players' sovereign custody of game assets eliminates compliance costs.

Composable mods are not "uniquely enabled" by fully on-chain games but are an innovation dependent on pathways. While traditional games could theoretically support composable mods, they currently do not and lack the incentive to change that. This model will only be explored out of necessity (i.e., in crypto).

The combination of composable mods and permissionless economies could produce large on-chain game worlds. Mod developers will expand upon a simple rule set base with new mod content. They will be able to use real currency, approach DeFi markets, and have the freedom to experiment. The resulting economy could be very complex and reflexively incentivize the creation of cumulative content. Once it becomes clear that there is money to be made, activity could explode, similar to the speculative-experimental cycles that birthed other crypto application ecosystems.

Most discussions about fully on-chain games delve into this more detailed optimistic future. We are more interested in specifically understanding the factors that hinder this future: open questions that need to be addressed for large-scale game worlds to emerge.

Open Questions#

Technical constraints limit game design.

It is widely believed that the primary reason no fully on-chain game has emerged is that the technical infrastructure is not yet ready, leaving most games in the proof-of-concept stage: simple gameplay, buggy clients, and limited participation from players and mod developers.

Existing infrastructure and developer tools are constrained. In particular, the EVM is slow and cumbersome, and the existing Solidity data model is not conducive to complex game development, with no mainnet chains suitable as deployment targets for games (given high costs and low scalability).

Fortunately, we have already seen pathways to address these issues. The scalability and cost-reduction progress of rollups has been widely accepted by much of the crypto community. Many teams are also developing infrastructure specifically for games. For example, Lattice is developing a system that combines the Solidity framework with compatible tools (indexing, state synchronization, etc.), which can simplify EVM game development. Teams like Dojo, Argus, and Curio are also developing infrastructure platforms.

Other issues are more related to the nature of fully on-chain games. In particular, certain attributes of permissioned chains hinder support for mainstream game design mechanisms:

1. Incomplete information: Key mechanisms in many games. Existing solutions have unacceptable flaws (e.g., DarkForest's cryptographic fog of war turning into a hardware mining race).
2. Automation and collusion: Fundamentally unpreventable. It is impossible to distinguish between bots and real players, nor can it be ensured that players are unique. Developers must build games that are not undermined by bot strategies or collusion.
3. Timing: Blockchains are driven by asynchronous transactions. Most traditional games are built around timing game loops unrelated to player interaction.

It is possible that these limitations will inspire creativity and game types we have never seen before, just as MakerDAO and Uniswap emerged from DeFi without borrowing from traditional financial models. However, traditional games face fewer technical and legal constraints than traditional finance—they have been able to explore more domains—so the likelihood of novel fully on-chain games emerging from the unknown seems low. We believe that improvements to these limitations are necessary to give fully on-chain games a chance at breakthrough success.

Research Directions

1. TEE. Although cumbersome for tasks, Trusted Execution Environments (TEEs) are the only practical option for performing permissioned private computation on public blockchains.

2. MACI. This is a mechanism originally designed by Vitalik Buterin to enhance the anti-collusion capabilities of on-chain voting systems; MACI could be adjusted for on-chain games and further improved through close integration with relevant game systems.

3. Custom Rollups. By modifying rollups to include global timing as part of their state transition function (without gas costs), it seems possible to achieve some form of traditional timing game loop on-chain. Other game-specific modifications may also be interesting.

Using ZKPs to enable private states is another existing research direction. However, we are skeptical about whether the non-programmable privacy they offer can unlock meaningful game mechanics. The current difficulty of writing circuits also limits their practicality.

Composability is Inherently Financialized#

In a system open to the whole world, incentives are not merely suggestions. Incentives are more like physical laws, such as gravity or entropy. If some aspect of the system does not align with the compatibility of incentives, it is only a matter of time before it is exploited.

— Nikolai Mushegian, bank.dev/principles

Smart contract blockchains are highly adversarial, financialized environments. This is not a product of the path dependency of decentralized culture: it is the mechanical result of permissionless composability. As primarily composable applications, fully on-chain games will be exposed to these incentives at a fundamental level.

In a vacuum, before considering the impact of modularity, fully on-chain game developers must contend with the inevitability of real currency markets, MEV (Miner Extractable Value), and economic exploitation. The threshold for designing a fully on-chain game that is compatible with incentives may be quite high; it may be akin to designing a secure DeFi product.

Secondary-level issues are trickier. Fully on-chain games are designed to be modifiable, and modularity will bring its own surges of incentives. Even if developers skillfully manage core game incentives, they do not know what layers will be built on top—or what incentives will be introduced. (In fact, allowing for this unpredictability is their goal.)

To draw another analogy with DeFi, consider an oracle. In a vacuum, an oracle may be economically secure (not prone to manipulation). However, oracles cannot predict which applications will integrate or combine with them. If a lending protocol uses an oracle to trigger liquidations, the oracle inherits the manipulation incentives—often fatal. Similarly, when a Minecraft mod introduces MEV incentives to mine a block first, it affects the gameplay of all players, even those clients that do not interpret that mod.

This is a difficult problem to solve. Attempting to permit or otherwise restrict who can develop mods for fully on-chain games directly contradicts the maximization of emergence (the very reason to build on-chain in the first place).

We suspect that the compatibility of incentives will be a decisive challenge in fully on-chain game design. Some traditional games avoid real-world currency markets because they are compliance nightmares; many more simply think they are not fun. Fully on-chain games need to figure out how to leverage financialized pressures without being consumed by them.

Research Directions

1. Antifragile Design. Core game mechanics can influence but not determine what kinds of mods will emerge on top of them. To what extent can fully on-chain games encourage social mods is an open question, as well as which game designs are least susceptible to N-th order incentive corruption.

2. Permissioning. Directly attacking financialization means controlling who can play fully on-chain games and who can deploy new code for them. There are clear trade-offs with emergence, but it may be necessary to experiment with games in closed gardens before exposing them to strict permissionlessness. Moreover, we can cleverly implement permissioning (not just simple whitelisting).

3. Order Flow Auctions. We can try to leverage them rather than attempting to prevent surges of incentives. For example, by forcing all game transactions through an order flow auction, the proceeds could be returned to the game's economic faucet. Any value created by mods would be reinjected into the game's economy (e.g., through repurchasing scarce goods). The downside is that underlying behaviors may still harm gameplay (e.g., players mining coal to fund solar energy).

Meta-Games Tend to Stagnate#

Fully on-chain games will inevitably have longer release cycles than traditional games. They hope to maximize novel experiences, while frequent disruptive updates will deter creators from investing in these worlds. Updates also require new audits. Many fully on-chain game developers view permissionless "autonomy"—no admin keys, no updates, infinite persistence—as a goal in itself.

Thus, for technical and philosophical reasons, fully on-chain games will exist within a range of autonomy between "never updating" and "infrequently updating."

The best-case scenario for maximally autonomous fully on-chain games is that the right rule set can inspire an active mod community and endless novel experiences. Experiences that may only be possible after decades of uninterrupted conditions.

However, most games are managed to prevent meta-game stagnation. Players have become very adept at finding optimal strategies for traditional games; now MEV will provide additional clear incentives. These strategies tend to be static and uninteresting. A truly autonomous world loses the ability to control the meta-game at any level—Vitalik may have been wrong to worry about his Warlock's issues.

Rather than being an inherent design goal, we suspect the key question will be: to what extent can successful fully on-chain games possess autonomy?

Research Directions

1. Seasonality. Many traditional games deploy upgrades on cycles of months to years (like WoW expansions). The main trade-off is that players lose motivation to build complex mods because they may become obsolete in future seasons. We believe this is one of the most promising approaches to iterative experimentation.
2. Automatic Feedback. Just as Bitcoin automatically adjusts its difficulty to respond to hash power, fully on-chain games could build redirection against stagnation into their core game mechanics. This is not specific to fully on-chain games—centralized games have a much stronger ability to do this—but they may innovate out of necessity.
3. New Governance Mechanisms. While we are generally governance minimalists, exploring non-token-based systems may present an interesting space. The ability to create new rules could even become part of the core game loop (e.g., the game Mao). There have already been some early attempts; for example, Topology tightly integrates a custom governance system into their fully on-chain game Isaac.

Should Games Be Fully On-Chain?#

There may be some accessible on-chain game designs that cleverly leverage permissionless composability. These worlds may thrive due to open economic incentives continually driving new content and could persist indefinitely on a censorship-resistant and neutrally governed blockchain.

But at the same time, there may not be enough uniqueness to justify navigating these open questions (which are no small matter). Again, compared to traditional finance, games have always been highly experimental. Thus, standard fully on-chain games should prove their value of existence to be greater than that of DeFi—the latter solves a previously closed market.

If fully on-chain games are not a viable approach, the reasons for excitement about them may be expressed in less "on-chain" ways. Viable games may simply minimize their use of smart contracts or not use them at all. GameFI games (Web2.5 games) with NFT assets and interoperability with DeFi may be the right practical focal point. Especially if certain elements of non-fully on-chain games (Web2.5 games) are controlled by on-chain assets, the smart contract-based coordination around assets may still be powerful.

Ultimately, whether games are fully on-chain or not, the patterns they explore—especially composable mods—may drive innovation in traditional game design. Traditional studios may see the potential and be willing to invest heavily in redesigning off-chain engines to support composable mods. They may coexist with, surpass, or spiritually succeed fully on-chain games.

Conclusion#

We see many difficult questions, but still intuitively believe that fully on-chain games can leverage blockchain to create peculiar, novel outcomes.

We are excited to explore all frontiers of crypto-native gaming alongside other builders. We are more interested in building games than infrastructure—the games we would play ourselves.

If this sounds exciting to you, please reach out to us: {charlie,doug}@paradigm.xyz

Acknowledgments#

Thanks to our colleague t11s for spending a lot of time providing feedback on this article, and to Matt Huang, Dan Robinson, Dave White, and Frankie for discussions and reviews.

Also, thanks to Will Robinson, GuiltyGyzoa, Rafael Morado, Scott Sunarto, and Robert Miller for their feedback, as well as discussions with Ludens, Phil Daian, and John Guibas.

Original authors: @_charlienoyes @dougfeagin
Original article link: https://www.paradigm.xyz/2023/08/onchain-games

Translated to the Chinese community by @hicaptainz

Follow the author to stay on track with fully on-chain games.