Table of Contents
1 Design for Emergence
1.1 Modules
1.2 Open Economic System
- In-depth Analysis of POW Tokens Computing Power and Value in the Cryptocurrency World
- Microsoft and GPT-4 join forces to disrupt the workplace with a new Office.
- In-depth analysis of ARB on-chain chips Users are continuously increasing their holdings; most large holders are at a loss.
2 Full Chain Game
3 Open Questions
Technical constraints limit game design.
Composability is essentially financialized.
Metagames tend to stagnate.
4 Should games be fully on-chain?
5 Conclusion
6 Acknowledgements
The intersection of games and cryptocurrencies is full of infinite possibilities. Vitalik’s inspiration for creating Ethereum came from Blizzard weakening his professional skills in World of Warcraft. World of Warcraft is not “critical infrastructure”, but we expect that virtual worlds will 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, decentralized applications sound attractive in theory. But in practice, the most attractive ones are those that can only be realized through Crypto: applications that can only appear on the chain. Although there is a strong narrative drive, it is not easy to precisely identify the unique features of full chain games.
Why put games on the blockchain?
This article reflects our thinking on this question.
Designing for “Emergence”
Some games achieve long-term engagement by giving users creative tools to generate new content (“UGC”). The two main sources of UGC – modules and open economic systems – are the breakthrough directions we believe full chain games can achieve.
Modules
Modules allow third-party developers to create content beyond what the original game developers envisioned. Many groundbreaking games (such as DoTA, LoL, PUBG) originated from mod versions of other games. Others, like Roblox, have transitioned from games to mod development platforms. While game studios typically focus on production value, mod communities with high engagement bring diversity and novelty: similar to the comparison between Netflix and YouTube.
Minecraft is a good concrete example. The simple game mechanics lend themselves to adjustments. Modules that extend these mechanics can create new experiences on the functional level. Many popular Minecraft servers are completely different from the original version (such as prison and survival games).
However, even Minecraft has a limitation: players cannot contribute new modules to existing servers. They have to start a new server to introduce changes. As a result, Minecraft’s “universe” is fragmented among many parallel, mostly non-interactive private servers.
The reason modern games achieve modding, like Minecraft, mainly through instantiation (new servers) rather than scripting (existing servers), has its reasons. Ensuring the compatibility of player-contributed code with the native rule set is difficult (particularly utilizing this point is particularly challenging). Updates to the rule set can break mods built on top of them. Limited computing resources require intelligent allocation.
However, instantiation leads to fragmentation. Each module that creates a new server competes for players’ attention with other servers. Module developers not only need to consider what is interesting to add to a world, but also whether it is worth opening a new server for this purpose.
Considering that many potential modules may only make sense in context – that is, adding them to an existing world. For example, suppose you operate a restaurant in a Minecraft server and want to add a new item to the menu. It doesn’t make sense to open a new server to do this because you would need to convince all the customers to also 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 lose 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 full-time economists) as a teaching example.
In the informal combination of game systems and external infrastructure, EVE’s players produce and trade goods; declare, lease, and vie for territories; and organize everything from industrial collectives to warlike pirate gangs. Even simple tasks like transporting resources have fully player-run companies dedicated to 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 the developers, but because of the rich social and economic world driven by other players.
However, even EVE’s economy has some significant limitations:
- Limited in-game primitives. Any transaction beyond the set of primitives determined by the developers (e.g., loan agreements) must rely on informal, unenforceable trust networks. This trust limits the complexity and scale of the economic structure.
- Regulatory constraints. Due to compliance issues, the vast majority of games (including EVE) simply prohibit players from transferring any assets or exchanging in-game goods or services for fiat currency. Those that allow it have large compliance departments and maintain strict terms.
Full Chain Games
There are many different potential forms of blockchain games. Our focus is on the one that has the most native encryption: fully on-chain games, where the 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 alongside the base game logic, without permission. And users only need to choose their client to select the modules they want to participate in (instead of an administrator making decisions for them).
So, why put the game entirely on the blockchain? We believe the most compelling reasons are based on the following two points:
- Composable modifications. Players can add modules to full chain games without requesting permission or splitting their state. On-chain infrastructure and smart contract developers have already prepared for the challenge of allowing players to upload code without permission: security audits, access control, resource metering, etc. Traditional games are not suited for this environment and are unlikely to be restructured around supporting composable modules.
- Permissionless open economy. Players can use smart contracts to create a game economy instead of 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’ custody of game assets eliminates compliance costs.
The composable module is not unique to the whole chain game, but an innovative approach based on dependency paths. Although traditional games theoretically support composable modules, they do not currently support them and have no incentive to change this. This model will only be explored out of necessity (i.e., in cryptography).
The combination of composable modules and permissionless economies could create large-scale on-chain game worlds. Module developers will build on a simple set of rules and expand with new module content. They will be able to use real currency, be closer to the DeFi market, and have the freedom to experiment. The resulting economy could be highly complex and reflexively incentivize the creation of cumulative content. Once it is clear that money can be made, activity could explode, as with other crypto application ecosystems in the speculative-experimental cycle.
Most discussions about whole-chain games delve into this more detailed optimistic future. What interests us more is understanding the specific factors that hinder this future: the open issues that need to be addressed for a large-scale game world to emerge.
Open Issues
Technical limitations constrain game design
It is widely believed that the main reason why there is no standout whole-chain game at the moment is that the technical infrastructure is not ready, so most games remain in the concept validation stage: simple gameplay, buggy clients, and limited participation from players and module 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 suitable as a deployment target for games (considering high costs and low scale).
Fortunately, we have seen approaches to address these issues. The scalability and cost reduction progress of Rollup has been accepted by most of the crypto community. Many teams are also developing game-specific infrastructure. 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. There are also teams like Dojo, Argus, and Curio developing infrastructure platforms.
Other issues are more related to the essence of whole-chain games. In particular, certain attributes of permissioned chains hinder support for mainstream game design mechanisms:
- Incomplete information: a key mechanism in many games. Existing solutions have unacceptable flaws (e.g., the cryptographic war fog in DarkForest turned into a hardware mining competition).
- Automation and collusion with witches: cannot be stopped fundamentally. It is impossible to distinguish between robots and real players, and it is impossible to ensure that players are unique. Developers must build games that are not vulnerable to robot strategies or collusion with witches.
- Timing: blockchain is driven by asynchronous transactions. Most traditional games are built around timing game loops unrelated to player interactions.
These limitations may inspire creativity and game types 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 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, it is necessary to improve these limitations.
Research Directions
- TEE. Although cumbersome for tasks, trusted execution environments (TEEs) are the only practical option for performing permissioned private computation on public blockchains.
- MACI. This is a mechanism originally designed by Vitalik Buterin to enhance the anti-collusion capabilities of on-chain voting systems. MACI may be adjusted for on-chain games and further improved through close integration with relevant game systems.
- Custom Rollups. It seems possible to obtain some form of traditional timing game loop on-chain by modifying rollups to include global timing as part of their state transition function (without gas costs). Other modifications specifically for games may also be interesting.
Using ZKP to enable private states is another existing research direction. However, we are skeptical of whether the non-programmable privacy they provide can unlock meaningful game mechanisms. The current difficulty of writing circuits also limits their practicality.
Composability Inherently Has Financial Characteristics
In an open system to the world, incentives are not merely a suggestion. Incentives are more like physical laws such as gravity or entropy. If some aspect of a system is not compatible with incentives, it is only a matter of time until it is 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 decentralized culture: it is the mechanical result of permissionless composability. As a primarily combinatorial application, blockchain games are exposed to these incentives at the primal level.
In a vacuum, before considering the impact of modularity, developers of blockchain games need to deal with the inevitability of real money markets, MEV (front-running incentives), and economic exploitation. The threshold for designing a incentive-compatible blockchain game may be quite high; it may be equivalent to designing a secure DeFi product.
The second-level problems are even more tricky. Blockchain games are designed to be modifiable, and modularity brings its own burst of incentives. Even if developers skillfully manage the core game incentives, they do not know what the upper layers will construct – or what incentives they will introduce. (In fact, allowing for this unpredictable emergence is their goal.)
Let’s consider another analogy with DeFi. Take an oracle, for example. In a vacuum, an oracle may be economically secure (not prone 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 the manipulation incentive, which is often fatal. Similarly, when a Minecraft module introduces MEV incentives to mine a block first, it affects the gameplay of all players, even those clients who don’t understand this module.
This is a difficult problem to solve. Trying to license or otherwise restrict who can develop modules for a full-chain game directly contradicts the maximization of emergence (the reason for building on-chain first).
We suspect that incentive compatibility will be a decisive challenge in the design of full-chain games. Some traditional games avoid real-world currency markets because they are compliance headaches, and others simply think they are not fun. Full-chain games need to figure out how to harness financialization pressures without being consumed by them.
Research Directions
- Antifragile Design. Core game mechanics can be influenced but not determined, and it remains an open question to what extent full-chain games can encourage social modules and which game designs are least susceptible to N-order incentive corruption.
- Permission Settings. Attacking financialization is directly controlling who can play full-chain games and who can deploy new code for them. This comes with obvious trade-offs, but it may be necessary to experiment with games in closed gardens before exposing them to strict permissionlessness. And we can be clever with permission settings (not just simple whitelisting).
- Order Flow Auctions. Instead of trying to prevent sudden incentives, we can try to leverage them. For example, by forcing all in-game transactions through an order flow auction that returns the proceeds to the game’s economic faucet. Any value created by modules would be reinjected into the game’s economy (e.g., by repurchasing scarce goods). The downside is that underlying behavior may still harm gameplay (e.g., players mining coal to fund solar power).
Metagames Tend to Stagnate
Full-chain games are bound to have longer release cycles than traditional games. They aim to maximize novelty experiences, and frequent disruptive updates discourage creators from investing in these worlds. Updates also require new audits. Many full-chain game developers see “autonomy” – no admin keys, no updates, indefinite persistence – as a goal in and of itself.
Therefore, for technical and philosophical reasons, full-chain games will exist within the range of autonomy from “never updating” to “infrequent updates”.
The ideal situation for a fully autonomous blockchain game is that the correct set of rules can inspire an active modding community and endless novel experiences. These experiences may only be possible after decades of uninterrupted development.
However, most games are subject to management to prevent metagame stagnation. Players have become very adept at finding optimal 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 metagames at any level – Vitalik may have been mistaken in his concerns about the Warlock.
Instead of being an inherent design goal, we suspect the key question will be: to what extent can a successful blockchain game be autonomous?
Research Directions
- Seasonality. Many traditional games deploy upgrades on a cycle of several months to several years (such as WoW expansions). The primary trade-off is to motivate players to build complex mods, as they may become obsolete in future seasons. We believe this is one of the most promising approaches for iterative experimentation.
- Automatic feedback. Just as Bitcoin automatically adjusts its difficulty to respond to hash power, blockchain games can build redirections against stagnation into their core game mechanics. This is not specific to blockchain games – centralized games have much stronger capabilities in this regard – but they may innovate out of necessity.
- New governance mechanisms. While we are generally governance minimalists, exploring non-token-based systems may provide an interesting space. The ability to create new rules could even be part of the core game loop (e.g., the card game Mao). There have been some early attempts; for example, Topology has tightly integrated a custom governance system into their blockchain game Isaac.
Should games be fully on-chain?
There may be accessible on-chain game designs that can cleverly leverage permissionless composability. These worlds could thrive on open economic incentives, constantly driving new content, and existing indefinitely on a blockchain that is resistant to censorship and neutral.
However, at the same time, there may not be enough uniqueness to justify solving these open questions (which are not trivial). Again, compared to traditional finance, games have always been highly experimental. So, standard blockchain games should prove their value proposition is higher than DeFi – the latter solves an previously closed market.
If fully on-chain games are not a viable approach, the reasons for excitement about them may be expressed in a less “on-chain” way. Viable games may simply use smart contracts minimally or not at all. GameFI games with NFT assets (Web2.5 games) infrastructure and interoperability with DeFi may be the right practical focal point. Especially if certain elements of non-blockchain games (Web2.5 games) are controlled by on-chain assets, coordination based on smart contracts around the assets can still be powerful.
Finally, whether the games are fully on-chain or not, the patterns they explore, especially the combination modules, may drive innovation in traditional game design. Traditional studios may see the potential and be willing to invest a lot of resources to redesign off-chain engines to support combination modules. They may coexist with, surpass, or spiritually succeed fully on-chain games.
Conclusion
We see many difficult problems, but still intuitively believe that fully on-chain games can use blockchain to create unique and novel results.
We are excited to explore all the frontiers of crypto-native games with other builders. We are more interested in building games than infrastructure – games we would play ourselves.
If this sounds exciting to you, please contact us: {charlie, doug}@LianGuairadigm.xyz
Acknowledgements
Thanks to our colleague t11s for spending a lot of time providing feedback on this article, and thanks to Matt Huang, Dan Robinson, Dave White, and Frankie for their 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 article by: @_charlienoyes @dougfeagin translated to the Chinese community by @hicaptainz
Like what you're reading? Subscribe to our top stories.
We will continue to update Gambling Chain; if you have any questions or suggestions, please contact us!
