“全链” 的定义我在早先的文档里已有阐述，就是一个应用的所有逻辑都放在链上，没有设置额外的服务器，就可以被定义为全链应用，套用到游戏板块里，也是同样的定义逻辑：没有连接任何第三方游戏服务器，所有逻辑都在链上进行的游戏，就是全链游戏。
The definition of “fully on-chain” has been explained in earlier documentation: an application can be defined as fully on-chain if all its logic is placed on the blockchain without relying on additional servers. Applied to the gaming sector, the same logic applies: a game that does not connect to any third-party game servers and conducts all its logic on-chain is a fully on-chain game.
每个区块链的账户模型和编程范式都有特定的差别（除了那些 Fork 链），针对 CKB 来说，CKB 采用 UTXO 账户模型及 “链下计算、链上验证” 的编程范式，账户模型和编程范式决定了在这条区块链上构建的游戏应该如何达到全链状态。
Each blockchain has its own distinct account model and programming paradigm (except for those that are direct forks). In the case of CKB, it adopts the UTXO account model and follows a programming paradigm of “off-chain computation, on-chain verification.” The account model and programming paradigm together determine how games built on this blockchain can achieve a fully on-chain state.
从账户模型和编程范式两个角度分析如何在 CKB 上构建全链游戏：
-
账户模型：玩家的所有游戏资产或个人游戏记录都会以 Cell 的形式储存在链上，不会储存到任何第三方服务器上
-
编程范式：将游戏逻辑分解成 “多次小计算” 和 “一次大验证” 两个过程，因为计算的部分始终发生在链下，具备操作空间，所以实现形式更加灵活，而 CKB 的交易手续费并不考虑计算消耗，所以将所有计算汇总成一次链上验证，能最大化减少上链交互所带来的操作延迟
Analyzing how to build a fully on-chain game on CKB from the perspectives of its account model and programming paradigm:
-
Account Model: All of a player’s in-game assets and personal gameplay records will be stored on-chain in the form of Cells, without reliance on any third-party servers.
-
Programming Paradigm: Game logic is split into “multiple small computations” and “a single large verification.” Since computations occur off-chain, they offer greater flexibility in implementation. Meanwhile, CKB transaction fees do not factor in computational costs, so consolidating all computations into one on-chain verification can minimize the operational delays caused by on-chain interactions.
PVE 模式如何全链化 | How to make PVE mode fully on-chain
PVE（Player vs Environment）是指玩家与环境对抗的游戏模式，所谓的环境即表示所有能与玩家发生对抗性互动的游戏实体的集合。在这个模式里，玩家独自与游戏系统进行交互，所以 PVE 模式在设计的时候只需考虑与单个玩家的交互场景，即只设计玩家的所有交互选项和对应的系统反馈。
PVE (Player vs Environment) refers to a game mode where players engage in adversarial interactions with the game’s environment. Here, “environment” represents the collective set of all game entities that can enter into confrontational interactions with the player. In this mode, the player interacts solely with the game system. Therefore, when designing PVE, the focus lies on scenarios involving a single player—specifically, designing all possible player interaction options and the corresponding feedback from the system.
如果把玩家对系统的交互看作输入，系统对玩家的反馈看作输出，在系统参数完全相同的情况下，对于相同的玩家输入系统都会给予完全相同的反馈，那这个系统就是 “可验证” 的。这个特性很重要，因为只有在游戏系统是可验证的情况下，我们才能在 CKB 上验证玩家的系统交互操作的合法性。
If we consider player interactions with the system as input and the system’s responses to the player as output, then a system is considered “verifiable” when, given identical system parameters, the same player input will always produce the same system output. This characteristic is crucial because only when the game system is verifiable can we validate the legitimacy of a player’s interactions with the system on CKB.
WarSpore · Saga 游戏的 PVE 模式虽然是基于 Roguelike 原则设计的，也就是玩家的每局游戏体验会被一个初始随机数种子所影响。游戏采用的是 VRF（可验证随机数函数）技术，即通过伪随机的方式来实现 PVE 模式的可验证性。
Although the PVE mode of WarSpore · Saga is designed around Roguelike principles—meaning each player’s session is influenced by an initial random seed—the game employs VRF (Verifiable Random Function) technology. This means that even with its pseudo-random mechanics, the PVE mode remains fully verifiable.
PVE 全链技术图 | Fully on-chain tech-flow of PVE
关键技术说明：
-
行动力点数会以 “10 Block = 1 AP” 的形式累计，但不会每隔 10 个区块就直接更改链上状态，而是记录最后一次修改行动力的区块号，在创建 PVE 会话时，根据与 Tip 区块的差值自动计算并累计到游戏数据中 -
玩家在客户端的所有操作都会暂存在客户端本地，在发起保存或结算 PVE 会话交易时，这些操作会放入交易的
Witnesses字段中，链上游戏引擎会从会话里恢复游戏的上下文状态，再在其上应用玩家操作，迭代此上下文，如果迭代过程无报错则表示上链成功 -
所有被用于 PVE 游戏的玩家卡牌 DOB 都会被
锁定在会话中，目的是为了避免玩家通过在多个钱包地址间转移卡牌，以通过客户端 “多开” 的方式同时创建多个 PVE 会话，进而通过非法手段大幅提高打金效率 -
初始化 PVE 会话的伪随机系统的初始随机数种子，来源于玩家 “全局游戏数据” 所在区块的
Nonce字段，即在创建 PVE 会话交易时，链上游戏引擎会计算其哈希值以得到初始种子 -
PVE 会话代表玩家游戏状态的链上 “快照”，玩家可以随时将自己的游戏状态进行快照并上链，此操作为
保存游戏，然后重启游戏后，游戏会根据会话中的 “快照” 进行恢复，此过程为读取游戏，所有未上链保存的玩家操作在游戏关闭后均会丢失（未来可暂存在 Cookie 中）
Key Technical Notes:
-
Action Points (AP) accumulate at a rate of “10 blocks = 1 AP.” However, the on-chain state is not updated every 10 blocks. Instead, the block number of the last AP update is recorded. When a PVE Session is created, the AP is automatically calculated and added to the game data based on the difference from the current Tip block.
-
All player actions on the client-side are temporarily stored locally. When a transaction is initiated to save or settle a PVE Session, these actions are placed in the transaction’s
Witnessesfield. The on-chain game engine then restores the game’s contextual state from the Session, applies the player’s actions to iterate that state. If the iteration completes without errors, the on-chain submission is considered successful. -
All player card DOBs used in PVE are locked within the Session. This prevents players from transferring cards between multiple wallet addresses to create multiple PVE Sessions simultaneously via client “multi-instancing,” which could illegitimately boost farming efficiency.
-
The initial random seed for the PVE Session’s pseudo-random system is derived from the
Noncefield of the block containing the player’s “global game data” Cell. When the PVE Session creation transaction is processed, the on-chain game engine calculates its hash to generate the initial seed. -
A PVE Session represents an on-chain “snapshot” of game state. Players can snapshot their current state and save it on-chain at any time—this is the operation of
Save Game. After restarting game, the state is restored from the snapshot in the Session—this is the operation ofLoad Game. Any player actions not saved on-chain will be lost after the game is closed (though they could potentially be stored temporarily in cookies in the future).
PVP 模式如何全链化 | How to make PVP mode fully on-chain
PVP（Player vs Player）是指玩家与玩家间进行对抗的游戏模式，这种模式要求两位玩家同时在线，互相出牌，直至其中一位玩家血量耗尽或者长时间未出牌。对抗类的模式只需专注玩家与玩家间的数据交换即可，但在区块链环境里，双方玩家事先需要交换各自的公钥，对转发前的数据进行签名，然后接收方根据对手方提供的公钥进行签名验证，以确认接收数据的可信度。
PVP (Player vs Player) refers to a game mode where players compete directly against each other. This mode requires both players to be online simultaneously, taking turns playing cards until one player’s health is depleted or a player fails to act within the time limit. While such competitive modes primarily focus on data exchange between players, in a blockchain environment, both parties must first exchange their public keys, sign the data before transmitting it, and then the receiving party verifies the signature using the opponent’s provided public key to confirm the authenticity of the received data.
玩家在进入 PVP 模式前需开通 Fiber 通道，将自己的游戏代币和 CKB 等其他代币注入到通道中，在之后的对战中，每场对战结束后都会根据战况自动分配对战双方通道中的代币额度，如果某一方玩家在战况不利的情况放弃任何游戏操作，那对手方有权在一定区块时间后申请仲裁，将直接判定 “胜出” 并获得更为丰厚的代币配额。
Before entering PVP mode, players must open Fiber channels and deposit their in-game tokens, CKB, and other assets into them. After each match, the tokens in the channel will be automatically redistributed between the two players based on the outcome. If one player abandons the match or fails to act when the situation becomes unfavorable, the opponent has the right to initiate arbitration after a specified block period. In such cases, the opponent will be directly declared the “winner” and receive a more substantial token allocation.
由于 Fiber 仅是支付网络而不是通用消息网络，所以我们仍需启用中继服务器来实现数据交换。中继服务器不会储存任何游戏数据，仅负责数据转发，但按照全链游戏的定义，PVP 模式确实连接了第三方中继服务器，不过任何人都可启用自己的中继服务，所以实际上无需依赖一个固定的第三方中继服务。
Since Fiber functions solely as a payment network and not as a general‑purpose messaging network, we still need to enable relay servers for data exchange. These relay servers do not store any game data and are only responsible for forwarding messages. According to the definition of a fully on‑chain game, the PVP mode does technically connect to a third‑party relay server—however, since anyone can run their own relay service, it does not actually rely on a fixed, centralized third‑party relay.
（PVP 模式尚未开始开发，具体技术细节待开发完毕后再进行补充。） （PVP mode has not yet begun development; specific technical details will be added later.）
UGC 模式如何全链化 | How to make UGC mode fully on-chain
UGC（User Generated Content）是指一个产品中的由玩家所生成的那部分的内容。游戏内容通常来说都是由专业的游戏开发项目方进行制作的，但在这种情况下玩家可体验的内容长度是有限的，且所有的收入也都归项目方所有。如果项目方能让渡一部分游戏内容的制作权利给玩家，同时也按内容制作的受欢迎程度适当让度部分游戏收入，那这种模式就是 UGC 模式。
UGC (User Generated Content) refers to content within a product that is created by players themselves. Typically, game content is developed by professional game studios, which limits the amount of content players can experience and directs all revenue to the studio. However, if the studio shares a portion of the content-creation rights with players and also allocates a fair share of revenue based on the popularity of player-generated content, this model is what we call UGC.
WarSpore · Saga 将 “游戏背景创作” 的游戏内容进行了 UGC 化， 形式上表现为玩家为游戏创作自己所理解的背景故事，故事与故事之间并不是割裂的，而是后一个玩家所撰写的内容需在前一个被大众所认可的背景故事的基础上进行创作，从而形成一个类似 ”区块链“ 一样的链条结构。
WarSpore · Saga adapts the creation of “game background” into a UGC format. In practice, this means players craft their own interpretations of the game’s backstory. These stories are not isolated; rather, each new piece of content must build upon a previously community-approved background narrative, forming a chain-like structure similar to a “blockchain.”
游戏背景故事可以同时被多个玩家撰写，由玩家社区使用游戏代币进行投票，投票占多数的故事将被选为正式的游戏背景故事区块，会产出游戏代币并平均分给为此故事区块投票的玩家地址。
Multiple players can simultaneously contribute game background stories. The player community will then vote on these submissions using game tokens. The story that receives the majority of votes will be selected as the official “game background story block,” generating game tokens that are evenly distributed to the wallet addresses of all players who voted for that winning story.
（UGC 模式尚未开始开发，具体技术细节待开发完毕后再进行补充。）
（UGC mode has not yet begun development; specific technical details will be added later.）
Telegram Portal: