Apology
Hi everyone, I am the author of Kabletop. I forgot my previous Nervos Talk account, so I created a new one.
Preface
Looking back to March 2021, I had just started learning CKB and Rust. I learned while coding and spent 9 months stumbling through the development of Kabletop, a card PVP game framework based on state channels, along with a game Demo. Four years have passed, and even from today’s perspective, Kabletop’s technical architecture remains ahead of its time.
Over these 4 years, I have continued to contribute to the CKB ecosystem while accumulating extensive development experience. However, the passion I felt when creating Kabletop has long become unfamiliar. Last March, I suddenly recalled that when making the Demo, I had borrowed art assets from a famous Roguelike card game called Slay the Spire, but I had never actually played it. On a whim, I decided to try it. After playing for a while, I deeply felt that this game would be an excellent template for creating a fully on-chain game on CKB. So I made a decision: to transform Slay the Spire to the greatest extent possible and create a heavyweight fully on-chain game that can run on CKB.
The path to achieving this goal will be full of difficulties, but it is precisely because of these challenges so that they have reawakened the passion I had long forgotten.
Pre-Development Considerations
What is a “fully on-chain game”? My definition is straightforward: if a game running on-chain does not connect to any traditional centralized game servers, it can be defined as a fully on-chain game. In the context of CKB, this means a game with only a Client and CKB contracts. However, when it comes to actually creating a fully on-chain game, there are still many detailed issues to solve, encompassing technical problems, user experience issues, and product design challenges. I have listed them below:
- Roguelike emphasizes randomness. A random number needs to be set before the game starts. How do we set this random number on CKB and ensure verifiability?
- Every operation in a fully on-chain game will initiate a CKB transaction. How do we balance the completeness of the “fully on-chain” theme with player experience?
- How do we ensure the game’s cross-platform running characteristics?
- The client is responsible for computation, and contracts are responsible for verification, but there is still a large amount of reusable game logic between them. How do we technically solve the code reuse problem between client and contract sides?
- Slay the Spire is a typical PVE game, while Kabletop was designed for PVP scenarios. Can both modes coexist?
- Do we need to introduce token economics and FOMO effects?
- Can we introduce the Spore/DOB protocol?
- For the game’s background setting, can we reference Loot Adventure’s text NFT approach and implement player co-creation through UGC mode?
- For PVP mode message passing, should we use Kabletop’s Relayer network or the currently immature Fiber network?
Before officially starting game development, I deeply considered the above 9 key questions. Next, I will share my thought process and the final solutions I adopted. I also welcome everyone to share their ideas. I am very willing to share knowledge and learn together.
Roguelike Random Number Seed
For finding and injecting random number seeds, the key focus is on the CKB contract side. Once the contract side determines the solution, the client only needs to cooperate.
In Kabletop, before starting a match, we also need to set the starting random number for the current match. This random number is used to randomize both players’ card draws. The generation method for this random number is created by combining certain fields from a specific block.
So I will still use Kabletop’s approach to implement Roguelike random number seed injection. Before players start a battle, they will need to create a battle session Cell, and the block that packages this Cell will be used to provide the initial random number seed.
Balancing “Fully On-chain” Theme with Player Experience
When Ethereum mainnet ran very slowly, transactions on the mainnet had the highest security level but were accompanied by the slowest transaction speeds and most expensive transaction costs. Therefore, to improve efficiency and reduce costs, Layer2 was born. Essentially, this trades security level for speed improvement and cost optimization. Applications that prioritize security still deploy on the mainnet, while applications that are less security-focused can migrate to Layer2 to gain better user experience.
Returning to game design, we can adopt a similar Layer2 approach, caching lower-security operations off-chain, and then batch submitting them on-chain when settlement is needed. This ensures the game’s “fully on-chain” characteristics while also considering player experience.
In Kabletop, both players verify each other’s operations and synchronously save operation data and signature data off-chain, forming a verifiable operation sequence. When the game ends and settlement is needed, the winning party initiates an on-chain transaction, and the on-chain contract performs a one-time verification of the operation sequence.
Therefore, in the game’s battle flow, I will still adopt a similar approach to Kabletop. All player operations will be cached off-chain. When players want to exit and settle, a one-time on-chain verification will be performed. For the battle flow, the player experience will be no different from traditional Web2 games, with only a certain on-chain confirmation delay time needed during the settlement, which I think is completely acceptable.
However, there are still scenarios where each operation requires an on-chain confirmation, and that is “card roulette.” Since cards are important assets, due to their importance, I must sacrifice operational experience to ensure asset security. Fortunately, these operations are low-frequency, so the impact on gameplay experience is relatively limited.
Game Cross-platform Characteristics
If a game can run on both PC and mobile, it will be very beneficial for game distribution. Therefore, I will choose to develop the game according to Web game standards. The game engine I will use is CocosCreator, which can easily export Web game packages. Applications running on the Web can easily connect to wallets like JoyID and Metamask. More importantly, it can be made into a Telegram Mini App. We already have a wallet on Telegram called UTXO Global.
Therefore, choosing Web as the game’s runtime environment is a very natural decision.
Dual-end Code Reuse Problem
The game frontend is written in TypeScript and runs in the browser, while the backend is written in Rust and runs in CKB-VM. How do we reuse code between them? The answer is obvious: Wasm technology.
I divide the game backend logic into two parts: contract logic and core runtime logic. The latter is needed on both frontend and backend. Simply put, the frontend uses it to respond to player game operations and generate operation sequences, while the backend uses it to verify the legality of operation sequences on-chain.
I write the game’s core runtime logic independently in [no_std] Rust code, which can be compiled to Risc-V for contract reference and to Wasm for frontend reference.
PVE and PVP Dual Mode Coexistence
In traditional online games, PVE and PVP modes usually coexist, especially in MMORPGs. The former provides cooperative experiences, while the latter provides competitive experiences, making player game experiences more diverse.
In blockchain games, in addition to enriching game experiences, game modes are often deeply bound to token economics. For example, if PVE mode is used for minting resources, PVP mode can be used for resources consumption to achieve supply-demand balance.
Considering the completeness of the game experience, I have decided to make the game support both PVE and PVP game modes simultaneously. The former references Slay the Spire’s design, while the latter references Kabletop’s design.
Tokenomics and FOMO
If blockchain games only focus on playability, they will have no competitiveness compared to traditional games. So the real selling point must be tokenization. That is, blockchain games only truly have competitiveness when building playability based on tokenomics.
Tokenomics is the prerequisite for FOMO. If FOMO effects are properly controlled, they can play a positive role in the game’s cold start phase and can replace some functions of Referral system. Therefore, adopting a conservative FOMO strategy can achieve benefits outweighing drawbacks.
Therefore, I have decided to introduce Tokenomics and light FOMO features to the game. The general settings are as follows:
- Tokens have unlimited issuance, with all issuance logic placed in PVE mode, without any other issuance approaches
- Introduce an “Action Point” concept to limit PVE mode play frequency
- PVP mode treats tokens as Chips, with winners taking half of the loser’s
- Card blind box prices increase linearly based on the number of boxes opened, with prices only increasing, never decreasing
Introduction of Spore/DOB Protocol
The Spore protocol is an interesting NFT protocol on CKB, and the DOB protocol is a sub-protocol built on the Spore protocol, focusing on spreading the philosophical concept that “everything has DNA.” At the same time, the Spore/DOB protocol is also the main NFT protocol promoted in the ecosystem and is accepted by multiple trading platforms. Therefore, helping to spread it is a shared responsibility of all projects with NFT elements on CKB.
Therefore, building the game cards and blind boxes on the Spore/DOB protocol is a natural decision. All cards and blind boxes produced from the game can be traded on any third-party trading platform that supports the protocol.
Game Background Co-creation
When I saw that Loot Adventure only provided a background framework, I felt like I saw a cosmos. Although the content was brief, it framed a story framework that allows everyone to create in any form within this story framework. Such an open UGC mode has the possibility of giving birth to great works.
I am not very good at writing game background stories, and I don’t want the game’s background story to be written by me alone. I will set a background story framework for the game, allowing any player who obtains “chronicle fragments” in the game to create in any form within this framework, including but not limited to novels, videos, images, and games.
No one can know what the game’s background story will ultimately be like, but regardless, it is worth looking forward to.
Relayer or Fiber
In PVP battles, both players need to exchange their own operation information. In Kabletop, this is done through a service called Relayer, but this is a compromise solution. In an ideal situation, each player would be able to run a small node inside their local client, with both sides connecting to each other’s node to achieve message relay without relying on external services.
The CKB ecosystem has Fiber Lightning Network. Although it currently still runs in a relayer-like mode, I have heard that Wasm support and intranet penetration features will be provided in the future. At that time, the Fiber Lightning Network will be more decentralized, and any Web applications running in a browser will be able to easily access the Fiber network.
Fiber is CKB’s current main strategic project and will have great growth potential in the future. Therefore, before encountering completely unsolvable technical problems, I will prioritize implementing PVP battle functionality by accessing the Fiber network.
Development Planning and Progress
The game’s development plan is roughly divided into three important milestones, which consist of three events: completion of PVE mode, completion of PVP mode, and completion of UGC mode. Only when all three milestones are completed simultaneously can the game reach its most complete state, then the game tokenomics will be maximally realized.
Milestone One: PVE Mode (Estimated Duration: 1 year 9 months)
Each milestone event contains a large number of small tasks that need to be completed, especially the first milestone, which needs to start from game planning and build an entire on-chain game system from scratch. Therefore, this milestone event takes the longest time, but development is also nearing completion.
The following is the development work list:
- Card and blind box contracts
- Low-level game event loop engine
- Card functions and Buff effects
- Monster logic in PVE
- PVE contract
- Contract test cases
- Contract Wasm exporter
- Client UI resources outsourcing
- Client art resources AI generation
- Client music and sound effect resources
- Client feature development and testing
- Game continuos optimization
- Card and blind box Decoder contracts
- Card and blind box DOB renderer
- Telegram group bot development
- Access UTXO Global wallet and Telegram Mini App development
- Game PVE-related documentation
The following are some game screenshots:
Milestone Two: PVP Mode (Duration TBD: 3-4 months)
Before starting this milestone, I will first conduct comprehensive research on Fiber. Currently, as far as I know, Fiber only supports UDT assets and does not yet support arbitrary programmable functionalities. This is a fatal flaw for developers who want to develop on Fiber, though there may exist some trade-off solutions.
If we can use Fiber to create the game’s PVP mode, it will be the first fully on-chain game in Fiber, achieving a win-win situation. Therefore, I will prioritize the Fiber solution.
Milestone Three: UGC Mode (Duration TBD: 2-3 months)
Before starting UGC mode, I will first introduce a new NFT asset in PVE mode called “Chronicle Fragments.” It will be a text NFT similar to Unicorn and Loot Adventure, carrying a content fragment from the game’s background story, on which UGC creators can base their creations.
Only the owner of fragments can modify their linking contents, as contents are tied with them. If fragments are traded, right of modification to the corresponding content are also traded.
Future Plans
I have currently created an official Telegram group for the game. Everyone is welcome to join and discuss:
If you want to deeply understand the technical architecture and design details behind the game, please continue to follow subsequent game documentation updates. This will also be my next work focus. I look forward to these documents providing help to developers who are or will be developing projects within the CKB ecosystem.
Currently, the game runs on the Testnet network. Players can freely purchase assets to deeply experience the game, feel the tokenomics model, and take its insights. Let’s work together to improve the play experience. After everything is stabilized, I’ll launch its mainnet deployment.
The mainnet deployment and the development of the second and third milestones will begin after I successfully applied for the Community Fund. At that time, I will open source all my development contents from the first milestone, and all subsequent development work will also be conducted in a completely open source state.
Thank you to all friends who have provided support. I look forward to CKB getting better and better.