从「黑神话」到「新神话」:Moonveil 如何重塑 Web3 游戏的未来
NingNing
2024-09-04 08:44
订阅此专栏
收藏此文章
Web3 游戏不是「黑神话」,而是一个正在书写的「新神话」。


撰文:NingNing


最近,《黑神话:悟空》的投资人 Daniel 抛出了一个劲爆观点:「大量的游戏行业创业者去做 Web3,那些人不热爱游戏。」作为一个长期关注 Web3 游戏领域的分析师,我不得不说,Daniel 的观点有失偏颇,如同今年年中有些 meme 币的投资者极端 FUD VC 币一样,属于黄眉老怪玩弄的一种倒果为因的诡辩逻辑。


让我们跳出传统的思维框架,用更宏观的视角来看待 Web3 游戏的发展。Web3 游戏并非完全是 VC 生造的加密叙事,传统 3A 游戏产业发展到今天确实面临着巨大挑战:


  • 开发成本天文化:《赛博朋克 2077》开发成本 3 亿多美元,《荒野大镖客:救赎 2》开发成本估计超过 8 亿美元,即将发售的《GTA6》开发成本预计超过 20 亿美元。可怕的是,高昂的开发成本,并不与游戏成功大卖存在正相关关系。当下,5000 万美元开发成本的《黑神话:悟空》杀疯了的同时,8 亿美元开发成本的《星鸣特攻》却惨淡扑街。
  • 创新动力不足:各种 DLC 续作和「换皮」游戏充斥市场,真正的创新越来越少。之所以出现这种与美国好莱坞大片现状类似的现象,底层有着相同的逻辑:产业资本在多轮博弈之后在项目风险与回报率之间达成一种纳什均衡,更偏爱高胜率 + 可接受的低回报率的项目。
  • 玩家价值难以保留:花几百小时刷的装备,离开游戏就一文不值。
  • 独立开发者举步维艰:没有大厂光环,再好的创意也难以出头。在 Steam 平台就算有极个别独立开发者杀出重围获得成功,也免不了 30% 的 Steam 税。


当然,这些问题不是简单地往游戏里塞个区块链就能解决的。但是,Web3 技术堆栈确实为我们提供了一些新的思路和工具。而 Moonveil,正是在用这些新堆栈来解决老问题。


Moonveil 团队是来自 Riot Games、Blizzard 这些顶级游戏公司的资深专家,参与开发过《英雄联盟》、《魔兽世界》这样的现象级游戏。这帮人对游戏的理解,恐怕比很多自诩「纯粹」的传统游戏人还要深刻。


那么,Moonveil 的新堆栈究竟是什么呢?简单来说,他们正在构建一个跨游戏的生态系统,而这个生态系统有以下几个特性:


1. 生态互通:打破游戏孤岛


传统游戏就像一个个孤岛,玩家在 A 游戏里的投入在 B 游戏里毫无价值。Moonveil 要做的是建一座座桥:


  • 跨游戏身份系统:你在《魔兽世界》里的达成的成就,在其他游戏里也能有加成。
  • 资产互通:在 A 游戏里刷的神装,说不定在 B 游戏里也能装 13。
  • 开放的创作平台:玩家和开发者可以自由创造内容,而且这些内容可能在多个游戏里都能用。


在上个周期有很多类似项目受到 VC 和社区的热捧,但最终他们都没有过多热度。一方面是因为 BD 是很辛苦的工作,从生态和技术上的协调成本非常高。另一方面是因为他们只解决流量的事情,并没有整合流动性。而 Moonveil 直接从开发者角度就整合好了流量和流动性。


2. 流动性与价值捕获:Web3 游戏的制胜法宝


在 crypto 世界,成功项目往往有两个特征:抓流量或抓流动性。Moonveil 的目标是实现既要又要:


  • 抓流量:通过优质游戏体验和创新生态,吸引玩家。Moonveil 的自研游戏 Bushwhack 在拉美地区特别是巴西进行测试和推广,有着非常亮眼的数据表现。而 Moonveil 在研游戏还有多款。平台还有一个 Telegram 小程序游戏厂牌:Moonveil Mini,在 Telegram 的海量用户中做转化。
  • 抓流动性:让游戏资产自由流动,创造价值。Moonveil 会通过跨链操作和聚合玩家体现,提供游戏资产的流动性和互操作性的一站式方案。就像是在生态内里建了一个小型金融系统,玩家的每一份投入都可能产生实际价值。


3. 重塑游戏经济:做垂类的流动性分配者


区块链生态系统当前面临的核心挑战是流动性分配。这个问题涉及多个方面:流量的流动性、资产的流动性以及资源的流动性。目前,行业内已经出现了一些针对性的解决方案:Restaking 致力于解决资源流动性问题,Omnichain 和链抽象技术正在处理资产流动性,而各种 Quest 平台则在努力优化流量流动性。


而 Moonveil 在游戏这个垂直领域中提供了一个全面的解决方案。他们不是提供单一的工具,而是构建了一个完整的生态系统,涵盖了从游戏开发到资产管理的全过程。通过这种方式,Moonveil 为游戏行业提供了一个综合的流动性方案,并从中获取价值。


4. 技术整合:降低开发门槛


Moonveil 不只是在做游戏,他们在做的是一个面向开发者的平台,为开发者提供一站式的 Web3 游戏开发解决方案(包括 Rollup、钱包、浏览器、资产发行标准库、NFT 市场、共享流动性池、出入金通道等等),而不仅仅是一个可插拔的 Web3 钱包 SDK。


5. 创新玩法:NFT 的进化


上一轮 bull market 中,PFP(Profile Picture)NFT 曾经风靡一时。然而,这些 NFT 的实用性有限,主要用作社交媒体头像。随着市场热度消退,许多 PFP NFT 项目面临价值大幅下跌的困境。


现在,游戏资产类 NFT 正在兴起。这些 NFT 不仅具有收藏价值,还在游戏中拥有实际功能和效用。这种转变标志着 NFT 正在向更实用、更具可持续性的方向发展。


Moonveil 允许玩家将现有的 PFP NFT 导入到不同的游戏中,作为角色、道具或装备使用。这种做法不仅为现有的 NFT 资产提供了新的实用价值和应用场景,还增强了不同游戏之间的互操作性。


6. 游戏 DID:为游戏公会赋能


在之前的市场周期中,游戏 DID(去中心化身份)的概念被广泛讨论。然而,这些早期的尝试主要针对个人玩家的需求开发,试图聚合和可视化玩家的游戏数据。这种方法忽视了一个关键问题:这些信息对普通玩家的实际价值有限。


Moonveil 认识到,游戏 DID 的首要受众实际上是 B 端的游戏项目方和游戏公会。这些机构需要通过 DID 来更有效地管理和激励玩家。


因此,Moonveil 的游戏 DID 系统专门面向游戏公会设计。这个系统为公会提供了强大的工具,帮助他们更好地管理成员、优化策略、提高运营效率。


这种方法更符合当前 Web3 游戏生态的实际需求。游戏公会在 Web3 游戏中扮演着重要角色,它们往往是最组织化、最活跃的群体。为公会提供有力的工具,可能会对整个生态系统产生积极影响。


7. 生态建设:亲自下场做 Dirty Work


说到生态建设,很多公链项目的做法是广撒网,希望能从 N 个种子项目中自然生长出一个爆款游戏。但现实往往是:要么项目质量不行,要么成功的项目不听话自立门户。Moonveil 在这方面的策略是亲自下场做 Dirty Work。


Moonveil 团队本身就是游戏开发的老手,有着强大的产品能力和自研实力。这意味着什么?他们不需要赌运气等一个优秀的项目出现,因为他们自己就能打造高质量的游戏。


有了这样的背景,Moonveil 在筛选和扶持生态项目时就有了更大的话语权和判断力。他们知道什么样的游戏才能成功,什么样的团队值得投入资源。这不是外行看热闹,而是内行的精准判断。


这种模式简直就是一个完美的正向飞轮:Moonveil 提供平台和经验,优秀的项目得到支持和曝光,玩家享受到高质量的游戏体验,整个生态因此不断壮大。


总而言之,Moonveil 与最近大热的 Story Protocol 有异曲同工之妙,它们都是面向应用场景、解决真实世界问题的商业协议,而非靠发明和编制各种光怪陆离的技术原语驱动的空气项目。


Moonveil 给出的解决方案,本质是标准化 Web3 游戏生命周期中的开发、发行、交易等诸环节,让开发 Web3 游戏就像在 http://pump.fun 开发 meme 币一样简单快捷,从而促进 Web3 游戏的寒武纪大爆发尽快到来。


而海量 Web3 游戏 Dapp Rollup 的产生,会缓解以太坊主网 Blob 空间目前的供求失衡困局。这些 Rollup 之间的互操作需求也会增强链抽象项目的价值支撑。


最后,让我们用 Gartner 的新兴技术成熟度曲线分析一下 Web3 游戏的发展阶段。目前,整个行业可能正处于从「幻想破灭的低谷」向「生产高原期」过渡的阶段。因此,Moonveil 的战略是不追逐短期热点,扎实地为「生产高原期」做准备。


当然,challenges are real。技术壁垒、用户教育、监管不确定性……这些都是整个 Web3 行业需要面对的挑战。但正是这些挑战,恰是 Web3 游戏潜力巨大的反向证明。


回到 Daniel 的批评,我想说的是:真正热爱游戏的人,正是因为看到了传统游戏产业的困境,才选择拥抱 Web3 技术。他们不应该背负「不爱游戏」的原罪,他们是寻求产业范式革新的先行者。


Web3 游戏不是「黑神话」,而是一个正在书写的「新神话」。And I'm here for it。让我们拭目以待,看看这个由真正懂游戏的人打造的 Web3 项目,能把游戏带向怎样的未来。

【免责声明】市场有风险,投资需谨慎。本文不构成投资建议,用户应考虑本文中的任何意见、观点或结论是否符合其特定状况。据此投资,责任自负。

NingNing
数据请求中
查看更多

推荐专栏

数据请求中
在 App 打开