Original author: Charlie Noyes, Doug

Translated by: CaptainZ

The intersection of gaming and cryptocurrency is full of infinite possibilities. Vitalik was inspired to create Ethereum because Blizzard weakened his professional skills in World of Warcraft. World of Warcraft is not "critical infrastructure", but we expect virtual worlds to become critical infrastructure: containing trillions of assets and millions of job opportunities. It is hard to imagine them existing under the control of centralized platforms.

Of course, in theory, decentralized applications sound very attractive. However, in practice, the most attractive ones are those that can only be realized through Crypto: applications that can only appear on the chain. Despite strong narrative power, it has been proven difficult to accurately identify the unique features of fully chained games.

Why put games on the blockchain?

This article reflects our thinking on this issue.

How to design for "Emergence"

Some games achieve long-term engagement by providing creative user tools that allow them to generate new content ("UGC"). The two main sources of UGC - mods and open economies - are the breakthrough directions we believe the full-chain game can achieve.

Module

Modding allows third-party developers to implement content beyond what the original game developers envisioned. Many groundbreaking games in various genres (such as DoTA, LoL, PUBG) originated from modded versions of other games. Others, such as Roblox, have transitioned from games to modding platforms. While game studios typically focus on production value, highly engaged modding communities bring diversity and novelty, akin to the contrast between Netflix and YouTube.

Minecraft is a great concrete example. Simple game mechanics make it easy to adjust. Modifying these mechanics can create new experiences in terms of functionality. Many popular Minecraft servers are completely different from the original version (such as prison, 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. Therefore, the "universe" of Minecraft is fragmented among many parallel, mostly non-interactive private servers.

The reason why modern games implement mods like Minecraft is mainly through instantiation (new server) rather than scripting (existing server) for good reason. It is difficult to ensure that the code contributed by players is compatible with the native rule set (especially using this feature is particularly challenging). Updating the rule set may break mods built on top of it. Limited computing resources need to be intelligently allocated.

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

Considering that many potential mods may only make sense in context - that is, added to an already existing world. For example, let's say you run a restaurant on a Minecraft server and want to add a new item to the menu. Starting a new server to do this doesn't make sense because you would need to convince all of your customers to switch to the new server, and they may not do so because they have their own customers and commitments on the existing server.

Those fragmented game worlds have lost the ability to expand gradually.

Open Economy

The in-game economy is another dimension of almost unlimited creativity. We will use EVE (the first game to employ a full-time economist) as a teaching example.

In the informal combination of game systems and external infrastructure, EVE players produce and trade goods; declare, lease, and compete for territory; and organize everything from industrial collectives to aggressive pirate gangs. Even simple tasks like transporting resources are handled by companies fully operated by players - complete with customer service, service level agreements, and employee benefits.

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

However, even the economy of EVE has some significant limitations:

1. Limited in-game primitives. Any transaction beyond the primitive set determined by the developer (e.g. borrowing agreement) must rely on an informal, non-executable trust network. 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 with fiat currency. Only large compliance departments that operate under strict terms allow such actions.

Full-chain game

There are many different potential forms of blockchain games. Our focus is on the one with the most native encryption: fully on-chain games, where the state and logic exist entirely on an open smart contract platform.

Equally important, the modules of the entire chain game can be deployed as their own contracts without permission next to the basic game logic. And users only need to choose their client to select the modules they want to participate in (rather than the administrator making decisions for them).

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

Technical limitations constrain game design.

People generally believe that the main reason why there is no standout full-chain game at present is that the technological infrastructure is not yet ready, so most games are still in the concept verification stage: simple gameplay, buggy clients, and limited participation from players and module developers.

Existing infrastructure and developer tools are limited. In particular, the EVM runs slowly and clumsily, the existing Solidity data model is not conducive to complex game development, and there is no mainnet chain suitable for deployment as a game target (considering high costs and low scale).

Luckily, we have already seen ways to solve these problems. The scalability and cost reduction progress of Rollup has been accepted by most of the crypto community. There are also many teams developing infrastructure specifically for gaming. For example, Lattice is developing a system that combines with the Solidity framework and 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 involve the essence of the full-chain game more. In particular, certain properties of permissioned chains hinder support for mainstream game design mechanisms:

1. Incomplete Information: A critical mechanism in many games. Existing solutions have unacceptable flaws (for example, DarkForest's cryptographic warfare turned into a hardware mining competition).

2. Automation and witchcraft collusion: cannot be prevented. It is impossible to distinguish between robots and real players, nor can it be ensured that players are unique. Developers must build games that are not vulnerable to robot strategies or witchcraft collusion.

3. Timing: Blockchain is driven by asynchronous transactions. Most traditional games are built around timed game loops that are unrelated to player interaction.

It is possible that these restrictions will stimulate creativity and new types of games that we have never seen before, just like MakerDAO and Uniswap emerged from DeFi without borrowing from traditional financial models. However, traditional games have fewer technological and legal restrictions than traditional finance - they have already been able to explore more areas - so the possibility of novel blockchain games emerging from unknown areas seems smaller. We believe that in order to provide a breakthrough opportunity for blockchain games to succeed, it is necessary to improve these restrictions.

Research direction.

1. TEE. Despite being 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 ability of on-chain voting systems. MACI may be adjusted for use in on-chain games and further improved through close integration with relevant game systems.

3. Custom Rollups. It seems possible to include global timing as part of its state transition function (without gas costs) by modifying rollups, which may result in some form of traditional timing game loop on the chain. Other modifications for gaming may also be interesting.

Using ZKP to enable private states is another existing research direction. However, we are skeptical about the meaningful game mechanisms they provide for unlocking non-programmable privacy. The current difficulty in writing circuits also limits their practicality.

可组合性天生具有金融化特性

Composability has inherent financial characteristics

In a system that is open to the world, incentives are not just a suggestion. Incentives are more like physical laws, such as gravity or entropy. If some aspect of the system is not compatible with incentives, it is only a matter of time before it is exploited.

——Nikolai Mushegian

Smart contract blockchain is a highly adversarial and financialized environment. This is not a product of the path dependence of decentralized culture: it is a mechanical result of permissionless composition. As a primary application based on composition, the entire chain game will be exposed to these incentives at the primitive level.

Before considering the impact of modularity, full-chain game developers in the cryptocurrency industry need to address the inevitability of real-world currency markets, MEV (pre-execution incentives), and economic utilization in a vacuum. Designing a full-chain game that is compatible with incentives may be as challenging as designing a secure DeFi product.

The second-level problem is even more tricky. The full-chain game is designed to be modifiable, and modularity will bring its own sudden incentives. Even if the developer manages the core game incentives proficiently, they do not know what the upper layer will build or introduce incentives. (In fact, allowing such unpredictable occurrences is their goal.)

Here's another analogy to DeFi: consider an oracle. In a vacuum, the oracle may be economically secure (not susceptible to manipulation). However, the oracle cannot predict which applications will integrate or combine with it. If a lending protocol uses an oracle to trigger liquidation, the oracle inherits manipulation incentives - often fatal. Similarly, when a Minecraft module introduces MEV incentives to mine a block first, it affects gameplay for all players, even those clients that don't interpret the module.

This is a difficult problem to solve. Attempting to license or otherwise restrict who can develop modules for the entire chain game is directly contradictory to maximizing emergence (which is the reason for building on-chain in the first place).

We suspect that compatibility of incentives will be a decisive challenge for the design of full-chain games. Some traditional games avoid real-world currency markets because they are compliant headaches; and more people just think they are not fun. Full-chain games need to figure out how to leverage financial pressures without being consumed by them.

Research Direction

1. Anti-fragile design. The core game mechanics can influence, but not determine, what kind of modules will appear on top of them. To what extent a full-chain game can encourage social modules is an open question, as well as which game design is least susceptible to N-order incentive corruption.

2. Permission Setting. Directly attacking financialization is to control who can play the full-chain game and who can deploy new code for it. This involves clear trade-offs, but at least it may be necessary to experiment with the game in a closed garden before exposing them to strict non-permissibility. And we can cleverly set permissions (not just simple whitelists).

3. Order Flow Auction. We can try to utilize them instead of trying to prevent sudden incentives. For example, by forcing all game transactions through an order flow auction, its revenue is returned to the game's economic faucet. Any value created by the module will be reinjected into the game's economy (e.g. repurchasing scarce goods). The downside is that underlying behavior may still harm gameplay (e.g. players mining coal to fund solar power).

Meta-games tend to stagnate

Full-chain games will inevitably have longer release cycles than traditional games. They hope to maximize the novelty experience, and frequent disruptive updates will make creators unwilling to invest in these worlds. Updates also require new approvals. Many full-chain game developers see the "autonomy" without the need for permission - no administrator key, no updates, and unlimited duration - as a goal in itself.

Therefore, for technical and philosophical reasons, the autonomy of the whole-chain game will exist within the range of "never updated" to "infrequently updated".

For the best scenario of maximum autonomous full-chain games, the correct set of rules can inspire an active mod community and endless new experiences. It may even lead to experiences that can only be produced after decades of undisturbed development.

However, most games are managed to prevent metagaming from stagnating. Players have become very good at finding the best strategies for traditional games; now MEV will provide additional explicit incentives. These strategies are often static and uninteresting. A truly autonomous world loses the ability to control metagaming at any level - Vitalik may have been worried about his Warlock's problem.

Instead of saying it is an inherent design goal, we suspect the key question will be: to what extent can a successful full-chain game have autonomy?

Research Direction

1. Seasonal. Many traditional games deploy upgrades on a cycle of several months to several years (such as WoW expansions). The main trade-off is that it discourages players from building complex modules, as they may become obsolete in future seasons. We believe this is one of the most promising methods for iterative experimentation.

2. Automatic Feedback. Just as Bitcoin automatically adjusts its difficulty to respond to computing power, blockchain games can build redirection against stagnation into their core game mechanics. This is not specific to blockchain games - centralized games have a much stronger ability to do this - but they may innovate out of necessity.

3. New Governance Mechanisms. Although we are usually minimalists when it comes to governance, exploring non-token-based systems may have an interesting space. The ability to create new rules can even become part of the core game loop (for example, the game Mao). There have been some early attempts; for example, Topology tightly integrates a custom governance system into their full-chain game Isaac.

Should games be fully on-chain?

There may be some accessible on-chain game designs that can cleverly utilize combinatory elements without requiring permission. These worlds may thrive due to open economic incentives that continuously drive new content, and they can persist indefinitely on a censorship-resistant and impartial blockchain.

However, at the same time, there may not be enough uniqueness to justify the openness of these issues (which are not trivial). Compared to traditional finance, gaming has always been highly experimental. Therefore, a standard full-chain game should prove its value is higher than DeFi - the latter solves a previously closed market.

If fully on-chain games are not a feasible approach, the reasons for their excitement may be expressed in less "on-chain" ways. Feasible games may only minimally use smart contracts or not use them at all. The GameFI games (Web2.5 games) with NFT assets, infrastructure, and interoperability with DeFi may be the right practical focus. Especially if certain elements of non-full-chain games (Web2.5 games) are controlled by on-chain assets, coordination based on smart contracts around assets may still be powerful.

Finally, regardless of whether the games are fully on-chain, their exploration patterns - especially the combination of modules - may drive innovation in traditional game design. Traditional studios may see the potential and be willing to invest significant resources in redesigning off-chain engines to support combination modules. They may coexist, surpass, or spiritually succeed fully on-chain games.

Conclusion

We have encountered many challenging issues, but we still intuitively believe that the whole-chain game can leverage blockchain to create unique and innovative outcomes.

We are excited to explore all the frontiers of native crypto games with other builders. We are more interested in building games than infrastructure - games that we ourselves will play.

Source Link

Welcome to join the official BlockBeats community:

Telegram Subscription Group: https://t.me/theblockbeats

Telegram Discussion Group: https://t.me/BlockBeats_App

Official Twitter Account: https://twitter.com/BlockBeatsAsia