Is it that Web3 games are not working, or have we not found the right path?
Author: Lola, Delphinus Lab
With the phenomenal success of "Black Myth: Wukong," there has been a wave of criticism within the industry about Web3 games. In the current market environment, which is already very depressed and self-doubting, an additional layer of debuff has been added.
Is it that Web3 does not love games? Indeed, in the early bubble stage of the market, a strong speculative atmosphere is inevitable. However, many builders still enter this industry with the intention of creating a good game, a game that truly belongs to the players. For Web3 to achieve true mass adoption, games are an unavoidable and effective path to deeply penetrate the market.
But reality is harsh. When people try to list the top Web3 games, they find that the number of quality games is extremely limited. Most games are mediocre, failing to provide players with a good user experience and falling far short of the expectations for mass adoption. Many game teams with successful practical experience in Web2 have stumbled in Web3. From my current understanding, the main reasons for this are:
Compared to traditional games, Web3 games find it difficult to provide continuous game content updates.
Due to different audiences, Web3 games need to consider more game economic issues beyond gameplay than traditional games.
Challenges in Game Content Updates
For a game to maintain long-term vitality, patch updates are essential; otherwise, bugs cannot be fixed, and the freshness for players will not last. In traditional game development, if the data structure remains unchanged but the game logic changes, a simple program logic patch can complete the related upgrade.
However, the immutability of the blockchain adds difficulty to this seemingly simple implementation. Taking Solidity game development as an example, a game contract that has gone online often determines the overall data structure of the game. Because the game logic itself is the migration of data states, modifying the game logic often requires an upgrade of the contract.
After the contract is upgraded, it is impossible to continue reusing the data from the pre-upgraded contract. To complete the upgrade of the game logic, there are only two choices:
Migration
Separating the data layer and the logic layer in the initial contract design
The second choice will increase the gas consumption of contract calls, so frequent game content upgrades are often difficult to achieve in Web3, which harms the sustained customer acquisition capability of a game with potential.
Logic upgrade without data interface
Logic upgrade with data interface
To solve this problem, the first step is to address the issues of data reuse and data upgrade. When the game logic is modified, we still hope that the original data can be preserved as is. The best zero-cost solution here is an independent App As A rollup. In the App rollup, the original data's Merkle root can be directly reused, and the modification of the logic only needs to be reflected in the code logic.
Logic upgrade running directly in the virtual machine
Even after solving the issues of data reuse and logic upgrade, the problem of data structure upgrade still poses a certain challenge to game upgrades. Ordinary on-chain data migration often requires using an oracle to modify the data according to a predetermined script before re-entering it into the chain, which consumes a lot of time.
In the App As A rollup architecture, after the data migration is audited, it can run in zkVM, thereby achieving completely verifiable migration logic. Since data migration is often data reorganization in many scenarios, with relatively little computational logic involved, if the code involved in reorganizing each leaf node is around 1000 lines, then the execution trace required for over a million leaf nodes can be around 1000*1 million. Currently, the proof time for every million lines of trace in a typical zkVM is 9-15 seconds, so the overall zk data migration time is still a controllable number.
It is precisely because of the data independence of Application Rookup that a new methodology has been brought to Web3 game content iteration.
And due to the complexity of other on-chain apps and the far less urgent need for updates compared to games, zkVM will bring new opportunities to full-chain games, or verifiable games.
Challenges in Economics and Profit Distribution
Game project development is a complex and very tedious task. If a high-quality game cannot bring tangible economic benefits, then compared to the traditional game industry, Web3's attractiveness to developers will gradually decline.
Currently, the relationship between game projects and public chains often revolves around traffic relationships, with revenue relationships as a secondary consideration. In the mid-game project, it often relies on the platform traffic and initial traffic provided by the public chain. The public chain then enjoys the incremental users brought by the game after it goes online.
The revenue relationship is more complex and hides deeper issues of profit distribution: on the one hand, user behavior generates revenue, including gas revenue for the chain and game content consumption fees; on the other hand, game traffic and consumption bring about the appreciation of the coin price, and games with trading volume generate asset revenue through the issuance of game tokens, while also bringing about a prosperous ecological effect for the chain, further increasing the token valuation expectations of the public chain.
In this complex relationship of interests, there is actually no clear definition of how user actual expenditures should be reasonably allocated. The cold start of a game requires a large amount of capital, and the first income for users often mainly goes to paying gas fees to the chain, which makes the feedback cycle for game creators very long, sometimes even leading to situations where game development teams artificially inflate the DAU base value of the chain and rely on meager grants to recover. This forces games to attract players to pay gas for interaction with the game through token expectations in the early stages. This gas burden is no longer negligible for a game player, to the extent that guiding users to consume their own tokens in chain games, i.e., purchasing game tokens, becomes more difficult compared to traditional games.
Because game top-ups are the most crucial step for game positive feedback, the gas burden greatly hinders the customer acquisition capability of games. However, because chain games need to bear the traditional obligation of on-chain transactions, even on layer2, gas still mercilessly takes precedence over the first top-up of the game's native token. Therefore, Web3 does not truly provide a "play before pay" game experience.
Game item trading is considered the most attractive aspect of mid-to-late-stage blockchain games. High-value game items obtained through spending or long-term interaction, after circulation and collection, continue to appreciate. However, most of the premium brought about by the circulation and trading of game items is divided among other on-chain products: the trading fees of game NFTs may be divided by NFT exchanges, and the trading of game tokens is divided by DeFi. The value created by good games does not effectively flow back into the game to support the game team.
The fluctuation of token value will lead to dynamically amplified in-game output. When the value of game tokens is underestimated, the game fee is low, and the game output and the actual investment in game tokens are often positively correlated, leading to a low token price and lower cost for the same game token, resulting in higher output. When the game token value is high, the excessively high value of the game token hinders in-game consumption impulses. This amplification effect subjects the fluctuation of the game token value to the dual influence of off-chain and on-chain output, increasing the challenges related to token economic design.
App As A rollup + zkVM: A Possible Way Out
In enumerating this series of challenges, we unexpectedly found that the architecture of Application As Rollup can effectively alleviate the related problems to some extent.
First, the real gas of the self-owned rollup will significantly reduce to 1/20 or even less compared to full-chain games. This can allow the project to completely eliminate gas fee interference in the early stages of the game, providing a truly free-to-play gaming experience and creating a better environment for initial user acquisition and cold start of the game.
Secondly, Application As Rollup can provide a one-click lending platform, allowing users to borrow in-game tokens using USDC in the early stages of the game, encouraging users to try out paid features in the game. Since the expected output of the game often exceeds consumption, users can completely redeem the originally borrowed USDC collateral after the output exceeds consumption.
In the circulation process, Application As a Rollup can effectively act as a cross-chain bridge for game assets. When we need to transfer assets on different chains, we only need to Deposit into the game, and then Withdraw on another chain. This native cross-chain functionality allows the game itself to capture a portion of the value of game item transactions.
More radically, games can provide stablecoin deposit and lending functions, allowing the TVL value that was previously only captured by the chain to now be captured by the game itself. Finally, Application Rollup can introduce a mechanism similar to gas fees for paying players, ultimately capturing traditional chain gas fees. A possible design of this mechanism is that gas fees are lower when the token value is higher, and gas fees are higher when the token value is lower: essentially benefiting from the independence of layer3 to link gas value and token value, mitigating token value fluctuations.
Of course, none of this will happen overnight. Delphinus Lab's zkWASM, as an early player in pushing zkVM into gaming applications, recently released zkWASM Mini Rollup. This is a toolkit for rapid development and deployment of ZK Rollup applications. It allows developers to write Rust code, compile it into WebAssembly, and then run it in a Node.js environment. This SDK handles transactions, generates zero-knowledge proofs, and interacts with the blockchain.
The core process is: receiving transactions, processing transactions in the WASM virtual machine, generating proofs using zkWASM cloud services, and finally submitting the proofs to the blockchain for verification and settlement. The entire process ensures the privacy and security of transactions, while greatly improving the scalability of the blockchain. Developers only need to focus on application logic without delving into the complex details of zero-knowledge proof technology. It also includes a Rollup monitoring system, which can trigger on-chain settlement using proofs and transaction data, verify proofs using stored Merkle roots and the verify API, and ensure settlement in the order of the on-chain Merkle roots. Additionally, the SDK simplifies the setup of the local development environment, requiring only the launch of MongoDB and Redis, running dbservice, and then executing npm run server in the ts directory to start the complete local service.
The emergence of the zkWASM Mini Rollup SDK provides a highly potential solution for the dual challenges faced by Web3 games. Through the architecture of Application As A Rollup, it not only simplifies the process of updating game content but also provides new possibilities for optimizing the game's economic model.
This innovative approach first utilizes the compatibility of WASM, allowing a large number of traditional developers to use their familiar programming languages such as Rust to write game code. Secondly, it allows game developers to more easily achieve data reuse and logic upgrades, greatly reducing gas fees, and possibly achieving a truly "0 gas play" and "play before pay" experience. At the same time, it provides more opportunities for game projects to capture value, including cross-chain asset transfers, lending functions, etc., helping to establish a more sustainable game economy.
Using zkWASM to launch rollups in one click means that we can take solid steps towards mass adoption on both the developer and user sides. Although this technology is still in its early stages, Web3 games are facing both internal and external distrust in this cycle, and are struggling to move forward in questioning. However, it points out a path to solve the core problems faced by current Web3 games.
As more game developers adopt this technology, and more game operators and lending protocols are willing to participate in the economic model proposed earlier, we have reason to believe that Web3 games will gradually overcome the existing challenges. We do not expect to have our own "Black Myth: Wukong" or "Call of Duty," but by doing the difficult and right things, relentlessly striving towards the ultimate goal rather than seeking shortcuts, Web3 games will eventually usher in their "facing destiny" moment and lead the entire industry through the long night before widespread application.
免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。
