Why put games on the blockchain? This article reflects our thoughts on this issue.

Author: Paradigm / Source: https://www.paradigm.xyz/2023/08/onchain-games

Translation: HuoHuo / Plain Language Blockchain

The intersection of games and cryptocurrencies feels full of possibilities. It is well known that Vitalik was inspired to create Ethereum after Blizzard weakened his "World of Warcraft". While "World of Warcraft" is not "critical infrastructure," we expect virtual worlds to emerge: accommodating trillions of assets and millions of jobs. It is hard to imagine them existing under the control of centralized platforms.

Of course, decentralized applications sound good in theory. The most notable in practice are applications uniquely supported by cryptographic technology: applications that can only appear on the chain. Despite many narrative motivations, it is difficult to accurately identify the unique features of on-chain games.

Why put games on the blockchain? This article reflects our thoughts on this issue.

1. Designed for emerging

Some games achieve persistent engagement by providing creative users with tools to generate new content ("UGC"). The two richest sources of UGC—mods and open economies—are the attack media for on-chain games that we see as reasonable cases.

1) Mods

Mods allow third-party developers to implement content beyond the original game developer's vision. Some defined types of games (such as DoTA, LoL, PUBG) originated from mod versions of other games. Other platforms, such as Roblox, have evolved from games to mod development platforms. While game studios typically focus on creating value, active mod communities bring diversity and novelty: Netflix vs. YouTube.

"Minecraft" is a good specific example. The simple game mechanics lend themselves to patching. Mods that extend these mechanics can recombine new experiences on the functionality. Many popular "Minecraft" servers feel completely different from the original version (jailbreak, battle royale, etc.).

However, even "Minecraft" has a limitation: players cannot contribute new mods to existing servers. They have to start a new server to introduce changes. As a result, the "universe" of "Minecraft" is fragmented across many parallel, mostly non-interactive private servers.

Most modern games achieve mods like "Minecraft" through instantiation (new servers) rather than scripting (existing servers), and there are good reasons for this. It is difficult to ensure that player-contributed code is compatible with the native rule set (exploiting vulnerabilities is particularly challenging). Rule set updates may break mods built on them. Limited computing resources require intelligent allocation.

Nevertheless, instantiation still leads to fragmentation. Each mod that generates a new server competes with all other servers to attract players' attention. Mod makers cannot just ask what new content in the world is interesting; they also have to ask if the changes are worth starting a new server.

Considering that many potential mods may only make sense in context—added to an already existing world. For example, suppose you run a restaurant in a Minecraft server and want to add new items to the menu. Starting a new server to do this is pointless because you need to convince all customers to migrate to the server, and they may not do so because they have their own customers and commitments on the existing server.

The fragmented game world loses the ability to expand gradually.

2) Open Economy

The in-game economy is another dimension with almost unlimited potential for player creativity. We will use "EVE" (the first game to employ full-time economists) as an inspiring example.

Through informal combinations of in-game systems and external infrastructure, EVE players manufacture and trade goods; assert, lease, and contest territories; and organize a variety of activities from industrial collectives to warlike pirate gangs. Even simple tasks like transporting resources have fully player-run companies dedicated to completing them—including customer service, SLAs, and employee benefits.

Players have been coming to EVE for over 20 years not because of new content provided by developers, but because of the rich emerging social and economic world driven by other players.

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

A. Limited in-game data. Any transactions not belonging to the developer-specified primitive set must rely on informal, non-executable trust networks. This trust limits the complexity and scale of emerging economic structures.

B. Regulatory restrictions. Due to compliance issues, the vast majority of games (including EVE) only allow players to close assets or exchange in-game goods or services for fiat currency. Those who allow this do so under cumbersome conditions and must maintain large compliance departments.

2. On-chain games

Cryptonative games have many different potential forms. Our focus is on the most cryptonative end: fully on-chain games, whose state and logic exist entirely on an open smart contract platform.

Equally important, on-chain game mods can be deployed as their own contracts alongside the base game logic without permission. Users choose which content to interpret by joining mods through their clients (rather than having administrators decide for them).

So, why put games on the blockchain? We believe the most compelling reasons are twofold:

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

2) Permissionless open economy. Players can use smart contracts to create game economies without being limited to the in-game primitive set defined by game developers and without relying on informal and non-executable protocols. In addition, player custody of game assets eliminates compliance costs.

Composable mods are not "uniquely enabled" by on-chain games but rather a path-dependent innovation. While traditional games theoretically could support composable mods, they currently do not and have no incentive to change this. The model is only explored when necessary (i.e., in cryptocurrencies).

The combination of composable mods and permissionless economy may lead to large-scale emerging on-chain game worlds. Mod makers will adopt a simple rule set base and expand it with new mod content. They will be able to earn real funds, access DeFi markets, and have the freedom to experiment. The resulting economy may be very complex and reflexively stimulate the creation of accumulated content. Once it is clear that money can be made, activities may erupt, as with the speculative experimental cycles that have spawned other cryptocurrency application ecosystems.

Most on-chain game discussions magnify an optimistic future with higher resolution. We are more interested in specifically understanding the obstacles: the openness issues that need to be addressed before large-scale game worlds emerge.

3. Unresolved issues

1) Technical limitations restrict game design.

The standard reason why on-chain games have not yet exploded is that the technical infrastructure is not ready, so most games are still in the concept verification stage: simple gameplay, client issues, and limited engagement of players and mod developers.

Existing infrastructure and developer tools are limited. In particular, the EVM is slow and cumbersome, the existing Solidity data model is not conducive to complex game development, and there is no mainnet chain that is a feasible deployment target for games (considering high costs and small scale).

Fortunately, we have the ability to solve most of the problems. The progress of Rollup's scalability and cost reduction is already obvious to most of the crypto community. Many teams are dedicated to game-specific infrastructure. For example, Lattice is developing Solidity frameworks and compatible tools (indexing, state synchronization, etc.) that can simplify EVM game development. Other companies such as Dojo, Argus, and Curio are also developing infrastructure platforms.

Other issues are more fundamental to the nature of on-chain games. In particular, certain properties of permissionless blockchains hinder support for mainstream game design mechanisms:

- Incomplete information: A critical mechanism in many games. Existing solutions have unacceptable drawbacks (e.g., DarkForest's encrypted war fog evolving into a hardware mining race).

- Automation and collusion: Fundamentally impossible to prevent. Bots cannot be distinguished from real players and unique players cannot be guaranteed. Developers must build games that cannot be disrupted by botnets or witch conspiracies.

- Ticking: Blockchains are driven by asynchronous transactions. Most traditional games are built around tick-based game loops, unrelated to player interaction.

These limitations may foster creativity and game types we have not seen before, similar to how MakerDAO and Uniswap emerged from DeFi without analogs in TradFi. However, compared to TradFi, traditional games have fewer technical and legal restrictions—they have already been able to explore more maps—so new on-chain games are less likely to emerge from unknown territories. We believe that progress may need to be made in addressing limitations to give on-chain games a chance for breakthrough success.

Research directions

- TEE: Although this task is very heavy, Trusted Execution Environments (TEE) are the only practical choice for permissionless private computation on public blockchains.

- MACI: MACI was originally designed by Vitalik Buterin to improve the resistance to collusion of on-chain voting systems, which could be applicable to on-chain games and may be improved through close integration with relevant game systems.

- Custom Rollup: It seems feasible to obtain some form of traditional tick-based game loop on-chain by modifying rollups to include global ticks as part of their state transition function (without gas costs). Other game-specific modifications may also be interesting.

Another existing research direction is to use ZKP to implement private states. However, we doubt that the achieved non-programmable privacy is sufficient to unlock meaningful game mechanisms. The current difficulty of writing circuits also limits their practicality.

2) The nature of composability is inherently financialized.

In a system open to the world, incentive measures are not just a suggestion. Incentives are more like physical laws, such as gravity or entropy. If some aspects of the system are incompatible with incentives, then it is only a matter of time before they are exploited.

— Nikolai Mushegian, bank.dev/principles

Smart contract blockchains are highly adversarial and financialized environments. This is not a product of the path dependence of degenerate culture: it is the mechanical result of permissionless composability. As applications are primarily premised on composability, on-chain games will be affected by these incentive measures at the raw level.

In a vacuum, on-chain game developers will need to address inevitable real-money markets, MEV (Miner Extractable Value), and economic exploitation before considering the impact of mods. The threshold for designing incentive-compatible on-chain games may be quite high; it may be akin to designing a secure DeFi product.

Second-order problems are even trickier. On-chain games are designed to be modifiable, and modifiers will have their own urgent incentive measures. Even developers skilled at managing core game incentive measures do not know what will be built on top of them—or what incentive measures will be introduced. (Achieving this unpredictability is actually their goal.)

Another analogy with DeFi, consider the oracle. Oracles may be economically secure in a vacuum (manipulation is not profitable). However, oracles cannot predict which applications will integrate or combine with them. If a lending protocol uses an oracle to trigger liquidation, the oracle inherits manipulation incentives—often fatal. Similarly, when "Minecraft" mods introduce MEV incentive measures to mine blocks first, it will affect gameplay for all players, even those who do not understand the mod.

This is a difficult problem to solve. Attempting to permit or otherwise restrict who can develop mods for on-chain games goes directly against maximizing emergence (the reason for building on-chain in the first place).

We suspect incentive compatibility will be a decisive challenge for on-chain game design. Some traditional games avoid real-world money markets due to compliance issues; more simply think they are not fun. On-chain games need to figure out how to harness financialized pressures without being consumed by them.

Research directions

- Antifragile design: Core game mechanisms can influence (but not determine) mods that appear on top of them. It is an open question to what extent on-chain games can encourage pro-social mods, and which types of game designs are least susceptible to Nth-order incentives.

- Permissioning: A direct attack on financialization is controlling who can play on-chain games and who can deploy new code into them. There are clear trade-offs that appear necessary, but at least it is necessary to try the game in a walled garden before exposing it to the harshness of permissionless. We can cleverly understand our permissioning (beyond simple whitelisting).

- Dutch auction flows: Instead of trying to prevent emergency incentives, we can try to harness them. For example, by forcing all game transactions to go through a Dutch auction, with the proceeds flowing into the game's economic faucet. Any value created by mods will be reinjected into the game economy (e.g., through repurchasing scarce goods). The downside is potential behaviors may still undermine gameplay (e.g., players mining coal to fund solar power).

3) Metaverse tends towards stagnation.

The release cycle of on-chain games is inevitably longer than traditional games. They aim to maximize emergence and frequent major updates will suppress creators' investment in the world. Updates also require new audits. Many on-chain game developers view "autonomy" (no admin keys, no updates, infinite persistence) as their own goal.

Therefore, for technical and philosophical reasons, on-chain games will be within the autonomous range of "never updated" and "not frequently updated."

The lunar case for maximally autonomous on-chain games is that the right rule set base can inspire an active mod community and endless new experiences. Even experiences that may take decades to permeate unchanged.

However, most games manage to prevent metagame stagnation. Players are already very good at finding the best strategies for traditional games; now, MEV will provide additional, explicit incentive measures. These strategies are often static and uninteresting. A truly autonomous world loses the ability to control the metagame at any level—Vitalik may be worried that his warlocks are asking the wrong questions.

We suspect the key issue is not inherent design goals, but: to what extent can successful on-chain games achieve autonomy?

Research directions

- Seasonality: Many traditional games deploy upgrades on a scale of months to years (e.g., "World of Warcraft" expansions). The main trade-off is preventing players from building complex mods that may be disrupted in future seasons. We believe this is one of the most promising iterative experimental approaches.

- Automatic feedback: Just as Bitcoin automatically adjusts its difficulty based on hash power, on-chain games can build anti-stagnation redirects in core game mechanisms. This is not unique to on-chain games—centralized games have more powerful capabilities—but they can innovate as needed.

- Novel governance mechanisms: Although we are usually governance minimalists, non-token-based systems may have an interesting space worth exploring. The ability to create new rules may even become part of the core game loop (e.g., Mao). Some early attempts already exist; for example, Topology closely integrates a custom governance system into their on-chain game Isaac.

4. Should games be fully on-chain?

There may be accessible on-chain game designs that can elegantly leverage permissionless composability. With open economic incentives continually driving new content and persisting indefinitely on a censorship-resistant and trust-neutral blockchain, these worlds may thrive.

However, it is also possible that there is not enough unique support to prove the rationality of solving unresolved problems (which is not trivial). Similarly, unlike traditional finance, games have always been highly experimental. Therefore, ironically, on-chain games must meet standards to prove their worth, feeling higher than DeFi— which solved previously closed markets.

If fully on-chain games are not a feasible approach, the reasons for excitement about them may be expressed in a less "on-chain" way. Effective games may minimally use smart contracts, or not use smart contracts at all. Off-chain game infrastructure with NFT assets and interoperability with DeFi may be the right practical setting. Especially if off-chain game elements are controlled by on-chain assets, the coordination around assets with smart contract-based coordination is still strong.

Finally, regardless of whether games ultimately go fully on-chain, the patterns they explore—especially composable mods—can 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. It may coexist, compete, or spiritually succeed with on-chain games.

5. Conclusion

We see many challenges, but still have an intuition that on-chain games can use blockchain to create strange and novel outcomes.

We are excited to explore all frontiers of cryptonative game development with other developers. We are more interested in building games than infrastructure—games we play ourselves.

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。