致歉
大家好，我是 Kabletop 的作者，我忘记了之前的 Nervos Talk 账号，所以新建了一个。
前言
回想起那是 21 年 3 月的时候，我刚接触 CKB 和 Rust 语言，于是边学边写，踉踉跄跄地花了 9 个月的时间做出了 Kabletop 这款基于状态通道的卡牌 PVP 游戏框架，还附带做了游戏 Demo，转眼间 4 年过去了，即便以现在的眼光来看，Kabletop 的技术架构仍是超前的。
在这 4 年时间里，我坚持为 CKB 生态做出贡献，同时也积累了大量开发经验，但当年制作 Kabletop 时的心血澎湃，早已变得陌生，就在去年 3 月的时候，我突然回想起当时制作 Demo 时是拔取一款有名的 Roguelike 卡牌游戏的美术资源，名为杀戮尖塔 (Slay the Spire)，但我却从来没玩过，我突发奇想地想要去玩一下，就在玩了一段时间后我深刻地感受到，这款游戏是能在 CKB 上被制作成全链游戏的绝佳样板，于是我做了一个决定，对杀戮尖塔进行最大限度的改造，将其制作成一款能运行在 CKB 上的重量级全链游戏。
在达成这个目标的路上会充满艰难，但就是因为难，唤醒了早已被我淡忘的澎湃激情。
制作前的思考
什么是 “全链游戏”？我对它的定义很直接，如果一款运行在链上的游戏没有连接任何传统的中心化游戏服务器，那就可以被定义为全链游戏，放到 CKB 的场景里，就是只有 Client 和 CKB 合约的游戏，但真正回到全链游戏的制作上，仍然有很多细节问题需要解决，囊括了技术问题、用户体验问题和产品设计问题，我将它们罗列如下：
- Roguelike 强调随机性，在游戏开始前需要设定一个随机数，在 CKB 上如何设定这个随机数并保证可验证性？
- 全链游戏的任何操作都会发起 CKB 交易，如何平衡 “全链” 主题的完整性和玩家的游玩体验？
- 如何保证游戏的跨平台运行特性？
- 客户端负责计算，合约负责验证，但两者之间仍有大量可复用的游戏逻辑，如何从技术上解决客户端与合约端的代码复用问题？
- 杀戮尖塔是典型的 PVE 游戏，而 Kabletop 是针对 PVP 场景设计的，两个模式能否同时存在？
- 是否需要引入代币经济学和 FOMO 效应？
- 是否能将 Spore/DOB 协议引入进来？
- 对于游戏背景的设定，能否参考 Loot Adventure 的文本 NFT 方式，通过引入 UGC 模式来实现玩家共创？
- PVP 模式的消息传递是基于 Kabletop 的 Relayer 网络还是采用目前还未成熟的 Fiber 网络？
在正式开始游戏制作之前，我深入思考了上述 9 个关键问题，接下来我将向大家分享我的思考过程和最终采用的方案，也欢迎大家提出自己的想法，我非常愿意和大家一起分享知识，互相学习。
Roguelike 随机数种子
对于随机数种子的寻找与注入，真正需要关注的位置是在 CKB 合约端，只要合约端确定了解法，客户端只需配合就行。
在 Kabletop 中，开启一局对局前，同样需要设定当前对局的起始随机数，这个随机数用于随机化双方玩家的手牌抽取，而这个随机数的生成方式，是从特定区块中通过某些字段的组合来生成的。
所以我仍然采用 Kabletop 的方式来实现 Roguelike 随机数种子的注入，玩家开始战斗前会需要创建一个战斗会话 Cell，打包此 Cell 的区块将用来提供初始随机数种子。
平衡 “全链” 主题与玩家体验
在以太坊主网运行很慢的时候，发生在主网上的交易拥有最高的安全等级，但却同时伴随着最慢的交易速度和最昂贵的交易成本，因此为了提高效率和降低成本，诞生了 Layer2，本质上是通过牺牲安全等级来换取速度的提升和成本的优化，注重安全的应用仍然部署在主网，不那么注重安全的应用，就可以迁移到 Layer2 上，以换取更好的用户体验。
回到游戏设计上，我们同样可以采用 Layer2 的思路，将安全等级较低的操作缓存到链下，当需要结算的时候，再一并打包提交到链上，这样既保证了游戏的 “全链” 特性，同时也能顾及到玩家的游玩体验。
在 Kabletop 中，双方玩家各自互相验证对方的操作并将操作数据与签名数据同步保存在链下，形成可验证的操作序列，当游戏结束需要进行结算时，再由胜利的一方发起上链交易，链上合约会对操作序列进行一次性验证。
所以，在游戏的战斗流程中，我仍然采用类似 Kabletop 的方式，玩家的所有操作我会缓存在链下，当玩家想要退出结算时，再进行一次性链上验证，这样对于战斗流程，玩家的体验与传统 Web2 游戏别无二致，仅在结算时需要等待一定的链上确认时间，但我觉得这是完全可以接受的。
不过仍然有每次操作都需要一次上链确认的场景，那就是 “抽卡”，因为卡牌是玩家的重要资产，由于其重要性，我必须牺牲它的操作体验来保证资产的安全性，不过好在抽卡操作是低频的，所以对游玩体验的影响相对有限。
游戏的跨平台特性
游戏如果能同时在 PC 端和手机端运行，那会非常有利于游戏的传播，所以我会选择将游戏按照 Web 游戏的标准进行制作，因此我选用的游戏引擎是 CocosCreator，它能非常方便的导出 Web 游戏包，而且运行在 Web 端的应用能非常方便的连接 JoyID 和 Metamask 等钱包，更重要的是，它能制作成 Telegram Mini App，我们在 Telegram 上已经有了钱包，名为 UTXO Global。
因此，选用 Web 作为游戏的运行环境就是一个非常自然的决定。
双端代码复用问题
游戏前端由 TypeScript 编写并运行在浏览器中，后端由 Rust 编写并运行在 CKB-VM 中，两者之间如何复用代码，答案呼之欲出，就是 Wasm 技术。
我将游戏后端逻辑分为两块，合约逻辑和核心运行逻辑，后者在前后端都需要用到，简单地说，前端使用它来响应玩家的游戏操作并生成操作序列，后端使用它来在链上验证操作序列的合法性。
我将游戏的核心运行逻辑以 [no_std] 的 Rust 代码独立编写，这样既能编译到 Risc-V 被合约引用，又能被编译到 Wasm 被前端引用。
PVE 和 PVP 双模式共存
在传统网络游戏中，PVE 和 PVP 两种模式通常都是共存的，尤其是在 MMORPG 中，前者提供合作体验，后者提供对抗体验，让玩家的游戏体验更加多元化。
在区块链游戏中，除了丰富游戏体验外，往往游戏模式还会和代币经济学深度绑定，举个例子，PVE 模式如果用于资源产出，那 PVP 模式就可用于资源消耗，以达到供需平衡。
考虑到游戏体验的完整性，我决定让游戏同时支持 PVE 和 PVP 两种游戏模式，前者参考杀戮尖塔的设计，后者参考 Kabletop 的设计。
代币经济学与 FOMO
如果区块链游戏仅仅将重点放在 “可玩性” 上，那在传统游戏面前将毫无竞争力可言，所以真正的卖点一定是 “代币化”，也就是区块链游戏只有基于 “代币经济” 来构建 “可玩性” 才真正具备竞争力。
代币经济是 FOMO 的前提，FOMO 效应如能控制得当，可在游戏的冷启动阶段发挥积极作用，还能替代一部分 Referral 系统的功能，所以采用保守的 FOMO 策略能实现利大于弊的效果。
因此我决定为游戏引入代币经济和轻度 FOMO 特性，大概的设定如下：
- 代币无限增发，增发逻辑全部放在 PVE 模式中，不设置其他增发途径
- 引入 “体力值” 概念，用于限制 PVE 模式的游玩次数
- PVP 模式采用代币作为筹码，赢家能拿走输家一半筹码
- 卡牌盲盒的价格根据盲盒的开启数量线形增加，价格只增不减
Spore/DOB 协议的引入
Spore 协议是 CKB 上一个有趣的 NFT 协议，而 DOB 协议是基于 Spore 协议构建的子协议，专注于传播 “万物均有 DNA” 的哲学概念，同时 Spore/DOB 协议也是生态中主推的 NFT 协议，被多个交易平台所接受，所以帮助其传播也是所有在 CKB 上拥有 NFT 元素的项目的共有职责。
因此，将游戏中的卡牌和盲盒这两个资产元素以 Spore/DOB 的协议实现，是一个自然而然的决定，所有从游戏中产出的卡牌和盲盒均能在任何支持 Spore/DOB 协议的第三方交易平台上进行交易。
游戏背景共创
当我看到 Loot Adventure 仅提供了一段简短的背景描述信息的时候，我感觉我看到了一个宇宙，因为内容虽然简短，但它框定了一个故事框架，允许所有人在这个故事框架内进行任意形式的创作，这样的开放式 UGC 模式存在诞生伟大作品的可能性。
我不太擅长为游戏编写背景故事，我也不希望游戏的背景故事仅仅由我一个人来撰写，我将为游戏设定一个背景故事框架，允许任何在游戏中拿到 “背景碎片” 的玩家在这个框架内进行任意形式的创作，包括但不限于小说、视频、图片和游戏。
没有人能知道这款游戏的背景故事最终会是什么样的，但不管怎样，它都值得被期待。
Relayer 还是 Fiber
PVP 对战中，双方玩家之间需要互相传递各自的操作信息，在 Kabletop 中是通过一个叫 Relayer 的服务来完成的，不过这是一个折中的方案，因为在理想情况下，每个玩家都能在本地的客户端程序中运行一个小型节点，对战双方各自连接对方的节点以达到不依赖外部服务来实现消息传递的目的。
CKB 生态里有 Fiber 闪电网络，虽然目前仍是以 Relayer 的模式在运行，但未来我听说会提供 Wasm 支持和内网穿透的功能，届时，Fiber 闪电网络将更加的去中心化，任何运行在浏览器中的 Web 应用都能轻松接入 Fiber 网络。
Fiber 是 CKB 当前的主要战略项目，未来会有很大的成长空间，所以在遇到完全无法解决的技术问题之前，我都会优先考虑通过接入 Fiber 网络来实现 PVP 对战功能。
制作的规划与进度
游戏的开发规划大致分为三个重要节点，即三个里程碑事件，分别是 PVE 模式的完结、PVP 模式的完结和 UGC 模式的完结。只有当三个里程碑同时完成时，游戏才能达到最完整的状态，游戏的代币经济也才能最大化的体现出来。
里程碑一：PVE 模式 (预计耗时：1 年 9 个月)
每个里程碑事件里都包含着大量需要完成的细小工作，尤其是第一个里程碑，需要从游戏策划开始，从零搭建起一个完整的链游系统，所以这个里程碑事件耗时最长，不过开发也已接近尾声。
以下为开发工作列表：
- 卡牌和盲盒合约
- 底层事件循环引擎
- 卡牌功能和 Buff 效果
- PVE 中的怪物逻辑
- PVE 合约
- 合约测试用例
- 合约 Wasm 导出封装器
- 客户端 UI 资源外包
- 客户端美术资源 AI 生成
- 客户端音乐音效资源
- 客户端功能开发和测试
- 游戏整体调优
- 卡牌和盲盒 Decoder 合约
- 卡牌和盲盒 DOB 渲染器
- Telegram 群组机器人开发
- 接入 UTXO Global 钱包和 Telegram Mini App 开发
- 游戏 PVE 相关文档资料
以下为部分游戏截图：
里程碑二：PVP 模式 (暂定耗时 3 ～ 4 个月)
在启动这个里程碑之前，我会先对 Fiber 进行全方位的研究，目前据我所知，Fiber 仅支持使用 UDT 资产，暂不支持任意可编程的功能需求，这对于目前想要在 Fiber 上开发应用的开发者来说是一个致命伤，不过当前也许存在一些妥协性的手段。
如果能采用 Fiber 来制作游戏的 PVP 模式，那将会是 Fiber 网络里的第一个全链游戏，从而达到双赢的效果，所以我会优先考虑 Fiber 的方案。
里程碑三：UGC 模式 (暂定耗时 2 ～ 3 个月)
在开始 UGC 模式之前，我首先会在 PVE 模式中额外引入一个新的 NFT 资产，名为 “记忆碎片”，它会是类似于 Unicorn 和 Loot Adventure 那样的文本 NFT，承载着一段关于游戏背景故事的内容片段，UGC 创作者可以基于此展开创做。
只有记忆碎片的拥有者才能修改创作内容，创作的内容与记忆碎片绑定，如果记忆碎片被交易，那对应内容的修改权限也跟着被交易。
后续的计划
目前我已经为游戏创建了一个官方的 Telegram 群组，欢迎大家一起加入进来讨论：
如果你想要深入了解游戏背后的技术架构和设计细节，请持续关注后续的游戏文档更新，这也将是我接下来的工作重点，期待这些文档资料能为正在或将要在 CKB 生态内进行项目开发的开发者们提供帮助。
目前游戏运行在 Testnet 网络，玩家可以随意购买卡牌来深度体验游戏，感受游戏的代币经济模型，提出自己的见解，大家一起来完善游戏的游玩体验，待一切都稳定下来后，我会启动游戏的主网部署。
游戏的主网部署和第二与第三里程碑的开发，我会在成功申请下 Community Fund 后开始，届时我会开源我在第一里程碑中的所有开发内容，后续所有的开发工作，也将在完全开源的状态下进行。
感谢所有给我提供过支持的朋友，期待 CKB 越来越好。