Paradigm: The Unique Value and Open Issues of the Whole Chain Game
Original author: Charlie Noyes, Doug
Original compilation: CaptainZ
The possibilities are endless at the intersection of gaming and cryptocurrency. Vitalik was inspired to create Ethereum when Blizzard nerfed his class skills in World of Warcraft. World of Warcraft is not critical infrastructure, but we expect virtual worlds to be critical infrastructure: trillions of assets and millions of jobs. It’s hard to imagine them existing under the control of a centralized platform.
Of course, in theory, decentralized applications sound attractive. And the most attractive in practice are those applications that can only be realized through Crypto: applications that can only appear on the chain. Despite the strong narrative momentum, identifying exactly which unique features a full-chain game has has proven to be difficult.
Why put games on the blockchain?
This post reflects the state of our thinking on this issue.
How to design for emergence
Some games achieve long-term engagement by giving creative users the tools to generate their own new content (“UGC”). The two major sources of UGC - modules and open economies - are the breakthrough directions we believe full-chain games may achieve.
module
Mods allow third-party developers to achieve more than what the games original developers envisioned. Many genre-breaking games (such as DoTA, LoL, PUBG) originated as mod versions of other games. Others, like Roblox, have transitioned from games to modding platforms. While game studios typically focus on production value, an engaged modding community brings variety and novelty: akin to Netflix versus YouTube.
Minecraft is a good concrete example. Simple game mechanics facilitate adjustment. Mods that extend these mechanics can be remixed into functionally new experiences. Many popular Minecraft servers are completely different from the original (such as jailbreak, battle royale, etc.).
However, even Minecraft has a limitation: players cannot contribute new mods to existing servers. They had to start a new server to introduce the changes. As a result, the universe of Minecraft is fragmented among many parallel, mostly non-interactive, private servers.
There are good reasons why modern games, like Minecraft, implement modding primarily through instancing (new servers) rather than scripting (existing servers). Ensuring that player-contributed code is compatible with the native ruleset is difficult (and exploiting this is especially challenging). Updates to the ruleset may break mods built on top of it. Limited computing resources require intelligent provisioning.
However, instantiation leads to fragmentation. Every mod that spawns a new server competes with other servers for player attention. Modders have to consider not only what would be interesting to add to a world, but also whether its worth starting a new server for.
Consider that many potential mods may only make sense contextually - i.e. adding to an already existing world. For example, lets say you run a restaurant in a Minecraft server and want to add a new item to the menu. It doesnt make sense to start a new server to achieve this, because you need to convince all clients to move to the new server as well, which they probably wont because they have their own clients and commits in the existing server .
Those fragmented game worlds lose the ability to gradually expand.
open economy
The in-game economy is another dimension of almost unlimited creativity. We will use EVE (the first game to employ full-time economists) as a teaching example.
In an informal mix of game systems and external infrastructure, EVEs players produce and trade goods; claim, lease, and contest territories; and organize everything from industrial collectives to warlike pirate gangs. Tasks as simple as transporting resources have fully player-run companies dedicated to completing them - complete with customer service, service level agreements and employee benefits.
Players have been coming to EVE for over 2 decades, not because of new content from the developers, but because of a rich social and economic world driven by other players.
However, even EVEs economy has some significant limitations:
1. Limited in-game primitives. Any transaction that goes beyond the set of primitives determined by the developer (e.g., a loan agreement) must rely on an informal, unenforceable trust network. This trust limits the complexity and size 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 fiat currency for in-game goods or services. Those that allow this are only large compliance departments and do so under strict terms.
Full chain game
There are many different potential forms of blockchain gaming. Our focus is on the most crypto-native: a fully on-chain game whose state and logic exist entirely on an open smart contract platform.
Equally important, modules for full-chain games can be deployed as their own contracts without permission, alongside the base game logic. And users only need to select their client to choose which mods to participate in (rather than the admin making the decision for them).
So, why put all games on the blockchain? We think the strongest reasons are based on the following two points:
Combinable modifications. Players can add mods to full-chain games without asking for permission or splitting their state. On-chain infrastructure and smart contract developers are ready for the challenges of allowing players to upload code without permission: security audits, access control, resource metering, etc. Traditional games are ill-suited to this environment and are unlikely to be reorganized around support for composable mods.
A permissionless open economy. Instead of being restricted to a set of game primitives defined by the games developers or having to rely on informal and non-enforceable agreements, players can use smart contracts to create a games economy. Additionally, players’ sovereign custody of game assets eliminates compliance costs.
Composable modules are not “uniquely enabled” by the full-chain game, but are a path-dependent innovation. While legacy games could theoretically support composable mods, they currently dont, and theres no incentive to change this. This model will only be explored out of necessity (i.e. in crypto).
The combination of composable mods and a permissionless economy could lead to large on-chain game worlds. Mod developers will build on a simple ruleset base and expand it with new mod content. They will be able to use real money, have access to DeFi markets, and have the freedom to experiment. The resulting economy can 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, much like in the same guess-and-experiment cycle that birthed other crypto app ecosystems.
Most discussions of full-chain gaming delve into this optimistic future in more detail. Were more interested in understanding specifically whats holding this future back: the open problems that need to be solved so that large-scale game worlds are possible.
open question
Technical limitations constrained game design.
It is generally believed that the main reason why no full-chain game stands out at present is that the technical infrastructure is not yet ready, so most games are stuck in the proof-of-concept stage: simple gameplay, buggy client, and limited resources for players and mod developers. participate.
Existing infrastructure and developer tools are limited. In particular, the EVM is slow and clumsy, the existing Solidity data model is not conducive to complex game development, and no mainnet chain is suitable as a deployment target for games (given high cost and low scale).
Fortunately, we already see ways to address these issues. Rollups scalability and cost reduction advances have been embraced by much of the crypto community. There are also many teams developing infrastructure specifically for gaming. For example, Lattice is developing a system combined with the Solidity framework and compatible tools (indexing, state synchronization, etc.), which can simplify EVM game development. There are also teams like Dojo, Argus, and Curio developing infrastructure platforms.
Other questions relate more to the nature of full-chain gaming. In particular, certain properties of permissioned chains prevent support for mainstream game design mechanics:
1. Imperfect information: a key mechanism in many games. Existing solutions have unacceptable flaws (e.g. DarkForest’s cryptographic fog of war turned into a hardware mining competition).
2. Automation colludes with witches: there’s just no way to stop it. There is no way to distinguish between bots and real players, and no way to ensure that players are unique. Developers must build games that are not undermined by bot strategies or witch collusion.
3. Timing: Blockchain is driven by asynchronous transactions. Most traditional games are built around timed game loops that have nothing to do with player interaction.
It is possible that these constraints will inspire creativity and game types we have never seen before, just like MakerDAO and Uniswap emerged from DeFi without borrowing the model of traditional finance. However, traditional games are less technically and legally constrained than traditional finance—they have been able to explore more territory—so it seems less likely that novel full-chain games will emerge from uncharted territory. We believe that in order to provide full-chain games with a chance to achieve breakthrough success, it is necessary to improve these limitations.
research direction
1. TEE. Although very unwieldy for the task, Trusted Execution Environments (TEEs) are the only practical option for permissioned private computing 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, and MACI may be adjusted for on-chain games and further improved through tight integration with related game systems.
3. Customize Rollups. By modifying rollups to include global timing as part of their state transition function (at no gas cost), it seems possible to get some form of traditionally timed game loop on-chain. Other game-specific modifications could also be interesting.
Using ZKP to enable private state is another existing research direction. However, we are skeptical that the non-programmable privacy they provide can unlock meaningful game mechanics. The current difficulty of writing circuits also limits their usefulness.
Composability is inherently financial
In a system open to the world, an incentive is more than just a suggestion. Incentives are more like physical laws like gravity or entropy. If an aspect of the system is not incentive compatible, it is only a matter of time before it is exploited.
—— Nikolai Mushegian
Smart contract blockchains are highly adversarial, financialized environments. This is not a path-dependent product of decentralized culture: it is a mechanistic result of permissionless compositionality. As applications primarily based on composability, full-chain games are exposed to these incentives at a primitive level.
In a vacuum, full-chain game developers need to grapple with the inevitability of real money markets, MEV (pre-run incentives), and economic exploitation before considering the impact of modularity. The threshold for designing an incentive-compatible full-chain game may be quite high; it may be equivalent to designing a secure DeFi product.
The second-level problem is more difficult. Full-chain games are designed to be modifiable, and modularity will bring its own burst of incentives. Even if a developer manages the core game incentives proficiently, it has no idea what will be built on top of it - or what incentives will be introduced. (Actually, allowing this unpredictability to emerge is their goal.)
To give another analogy to DeFi, consider an oracle. In a vacuum, an oracle may be economically secure (not conducive to manipulation). However, oracles cannot predict which applications will be integrated or combined with them. If a lending protocol uses oracles to trigger liquidations, the oracles inherit incentives to manipulate — often fatally. Likewise, when a Minecraft mod introduces the MEV incentive to mine a block first, it affects gameplay for all players, even those clients that dont interpret the mod.
This is a difficult problem to solve. Trying to license or otherwise limit who can develop modules for full-chain games is directly at odds with maximizing emergence (the reason for building on-chain in the first place).
We suspect that incentive compatibility will be a decisive challenge in full-chain game design. Some traditional games avoid real-world money markets because they are a compliance headache; many more simply dont think theyre fun. Full-chain gaming needs to figure out how to take advantage of financialization pressures without being consumed by them.
research direction
1. Anti-fragile design. Core game mechanics can influence, but not dictate, what modules appear on top of them. The extent to which full-chain games can encourage social modules is an open question, and which game design is least likely to be corrupted by N-order incentives.
2. Permission setting. A direct attack on financialization is controlling who can play the full chain game and who can deploy new code to it. This has obvious trade-offs with appearing but at least it might be worth experimenting with games in closed gardens before exposing them to strict permissionlessness. And we can set permissions smartly (not just a simple whitelist).
3. Order Flow Auction. Rather than trying to prevent emergent incentives, we can try to exploit them. For example, by forcing all game transactions to go through an order flow auction, returning their proceeds to the games economic faucet. Any value created by the modules is injected back into the games economy (for example, by buying back scarce goods). The downside is that underlying actions can still harm gameplay (e.g. players mining coal to fund solar power).
Metagame tends to stagnate
Full-chain games will inevitably have a longer release cycle than traditional games. They want to maximize novel experiences, and frequent disruptive updates can discourage creators from investing in these worlds. Updates also require new review. Many full-chain game developers view permissionless “autonomy”—no administrator keys, no updates, infinite persistence—as a goal in itself.
Therefore, based on technical and philosophical reasons, full-chain games will exist within the autonomy range between never updated to infrequently updated.
The best case scenario for a fully autonomous full-chain game is that the right ruleset can inspire an active modding community and endless novel experiences. Perhaps even an experience that is only possible with decades of undisturbed experience.
However, most games are managed to prevent metagame stagnation. Players are already very good at figuring out the best strategies for traditional games; now MEV will provide an additional clear incentive. These strategies tend to be static and uninteresting. A truly autonomous world loses the ability to control the metagame at any level - Vitalik may be wrong to worry about his Warlock issues.
Rather than an inherent design goal, we suspect the key question will be: How much autonomy can a successful full-chain game have?
research direction
1. Seasonality. Many traditional games deploy upgrades on a cycle of months to years (such as WoW expansions). The main trade-off is that it takes away the incentive for players to build complex mods, since they may not work in future seasons. We think this is one of the most promising approaches for iterative experiments.
2. Automatic feedback. Just as Bitcoin automatically adjusts its difficulty in response to computing power, full-chain games can build anti-stall redirection into core game mechanics. This is not specific to full chain games - centralized games are definitely more capable of doing this - but they may innovate as needed.
3. New governance mechanism. Although we are generally governance minimalists, there can be an interesting space for exploring non-token based systems. The ability to create new rules can even be part of the core game loop (for example, the game Mao). Some early attempts already exist; for example, Topology tightly integrated a bespoke governance system into their full-chain game Isaac.
Should the game be fully on-chain?
There may be some accessible on-chain game designs that cleverly take advantage of permissionless composability. These worlds could thrive as open economic incentives continually drive new content, lasting indefinitely on censorship-resistant and unbiased blockchains.
But at the same time, there may not be enough uniqueness to justify passing these open questions (which are not trivial). Again compared to traditional finance, gaming has always been highly experimental. Therefore, standard full-chain games should prove that the value of their existence is higher than DeFi-the latter solves a previously closed market.
If fully on-chain games arent a viable approach, the reason to be excited about them may be expressed in less on-chain ways. Viable games might use smart contracts minimally, or not at all. The GameFI game (Web2.5 game) infrastructure with NFT assets and interoperability with DeFi may be the right practical fix. Especially if some elements of non-full-chain games (Web2.5 games) are controlled by on-chain assets, smart contract-based coordination only around assets can still be powerful.
In the end, whether games are fully on-chain or not, the patterns they explore—particularly combo mods—may drive innovation in traditional game design. Traditional studios may see the potential and be willing to invest significant resources in redesigning the off-chain engine to support combinatorial mods. It may coexist, surpass or spiritually succeed with the whole chain game.
in conclusion
We see many difficult problems, but still intuitively believe that full-chain games can use blockchain to create strange and novel results.
We’re excited to explore all frontiers of crypto-native gaming with other builders. Were more interested in the construction game than infrastructure - a game we know how to play ourselves.
