下一批建立在链上的游戏将利用可验证的证明、所有权和资产可编程性,同时专注于围绕真正的用户获取和留存而不是代币投机建立的游戏循环。
原文标题:Gaming Infrastructure Part 1: Defining On-chain Gaming
原文作者:Shanav K Mehta & Dev Bharel
原文来源:jumpcrypto
编译:Kate, Marsbit
长期以来,游戏一直被吹捧为加密货币的潜在核心用例。基于原生数字资产并服务于全球用户,游戏在许多方面都是利用链上可验证证明、所有权和全球支付轨道的最佳选择。然而,与任何新的创新一样,第一个版本往往有很多不足之处。第一批游戏自然是笨拙的,花哨的,并且因为过度金融化的体验而让许多真正的玩家失去了兴趣。
然而,下一批建立在链上的游戏将利用可验证的证明、所有权和资产可编程性,同时专注于围绕真正的用户获取和留存而不是代币投机建立的游戏循环。更重要的是,这个群体是由经验丰富的游戏开发者构建的。除了由共享状态无服务器计算支持的新型游戏之外,我们开始看到来自世界上一些最大的游戏工作室的 IP 开始上链。
尽管加密原住民和游戏玩家对链上游戏仍持一定程度的怀疑态度,但令人兴奋和吸引人的链游的要素已经非常到位。最后一个要素是强大的基础设施,它能够让用户体验到与传统游戏一样流畅的链上游戏体验。
在本系列文章中,我们将涵盖从链上游戏类型到实现每个版本的链上游戏所需的基础设施类型的所有内容。
我们首先定义可能存在的链上游戏类型。
从广义上讲,“链上游戏”一词被用来描述一系列游戏类型,其中游戏的链上程度可以从每一步的状态更新到一次性可选的资产组件铸造。以下是对这一范围内每种游戏类型的粗略概述。
全链游戏一直是最近关于链上游戏讨论的焦点。在这种方法下,区块链被用作集中式游戏服务器的替代方案,所有玩家都可以在链上索引和写入共享状态。
共享状态捕获的数据不仅与资产有关,还与游戏状态的所有方面有关。例如,在国际象棋游戏中,链上的共享状态将在玩家每走一步棋之后,捕获有关黑棋和白棋的每个棋子位置的细节。这种方法可以实现持久性(即,即使没有原始创造者的持续贡献,游戏也可以继续生存)、审查阻力和社区拥有的开发等功能。
虽然这可以创建新的游戏类型,但这种方法目前只适合于回合制游戏的某些子集,因为每个移动都必须作为交易提交给区块链,必须经过共识并在进行下一个移动之前达到最终结果。具体来说,这非常适合于每回合状态更新相对较少的游戏,因为每回合玩家数量较少或每个玩家的移动次数较少。成功采用这种方法的游戏包括Dark Forest和0xMonaco。AllianceDAO博客中详细记录的18xx等类型也非常适合这种方法。
随着游戏复杂性的增加,无论是以同步游戏的形式还是以更频繁的状态更新的形式,所需的状态转换可能会扩展到不仅包括玩家输入,如象棋游戏中的移动,还包括琐碎的机制(如角色扮演游戏中的被动再生生命值)。因此,要求这些游戏机制持续的“曲轴”(以及随之而来的gas费用)限制了实际的游戏设计空间。考虑到区块链架构的当前状态,这些游戏类型可能更适合链上/链下混合方法。
在这种模式下,用户资产存在于链上,而游戏循环存在于链下。链上资产状态在会话开始时由游戏服务器索引,状态转换记录在链下的游戏服务器上。状态只有在会话结束或游戏循环结果对资产状态产生重大影响时才会从游戏服务器传回链上。也许用户可以选择“保存状态”并支付相关的gas费用。这种方法在速度和性能之间进行了权衡。
让我们以《街头霸王》之类的PvP格斗游戏为例。用户可以在链上拥有他们的Ryu角色,并证明他们的所有权以启动链下的游戏会话。然而,与第一种方法不同的是,每次移动后的状态(例如角色在每次移动后损失了多少能量)将保留在游戏服务器上。只有当宣布赢家时,如果对链上的资产有任何影响,状态才会在链上更新。例如,如果角色完成了升级,那么NFT元数据就会发生变化,或者如果两名玩家参加了现金奖励锦标赛,那么智能合约就需要解决。这种方法更适合功能丰富且每个玩家移动频率更高的游戏,如MMORPG和FPS游戏。
这种方法需要高性能的基础设施。一些需求包括快速索引、链上元数据可更新资产标准、用于在链上通信链下状态的数据中继基础设施,以及基于中继数据的链上自动执行。如果没有这些,用户摩擦将会很高,开发者采用率将会很低。
在这种方法下,游戏看起来就像今天一样,资产所有权和状态更新记录在链下游戏数据库中。与现有游戏的唯一不同之处在于,用户可以选择将当前版本的角色资产铸造成链上的NFT,如果他们愿意,可以在那里进行交易。此外,游戏可能有某种忠诚度/季票,作为链上的NFT,便于基于所有权在游戏中进行访问控制。虽然正在为方法1和方法2构建适当的基础设施,但这条路径对用户来说可能是摩擦最小的。
以上每种方法都解决了不同的问题。
例如,方法1解决了游戏服务器信任问题。通过索引和写入链上的共享状态,这种方法规避了对游戏服务器的需求。这为全链游戏开辟了一个全新的设计空间,可能非常适合回合制游戏的某些子集。
方法2解决了可验证的资产所有权和资产可编程性。这种方法将去可信需求限制在资产层,而不是游戏状态的所有方面。这也可以通过在二次销售中引入去信任机制而创造出围绕游戏资产的可验证经济。
方法3解决用户体验问题。这种方法认为,在当前的基础设施状态下,上述两种方法都给玩家带来了太多的摩擦,因此链上组件应该是可选的和有限的。
我们认为,通过适当的基础设施,方法1和方法2可以提供与方法3类似的用户体验,并将游戏状态的不同部分添加到链上。这将需要使通信、库存管理和状态转换自动化、无缝化的标准。
在接下来的文章中,我们将重点介绍其中的一些基础设施,以及可能影响该基础设施性能的潜在设计约束和决策。例如,在下一篇文章中,我们将探讨一个名为ARC (Action Registry Core)的可更新链上资产框架,该框架是围绕传统游戏中称为ECS(实体组件系统)的架构模式构建的。
敬请关注!