Why Build a Blockchain Game Engine?
Having contacted some game and blockchain developers, we realized that very few of them are proficient in both gaming and blockchain development. Both industries set high threshold for the curious minds who are eager to participate while still honing their skills. So as to dispel the suffering that game designers may endure when developing blockchain games, we decided to build an easy-to-use game development framework.
Over the past three decades of the evolving gaming industry, developers have found that a lot of repetitive work has been involved. So they built a separate framework to minimize the unnecessary repetition, and this framework eventually evolved into the so-called “game engine”.
We believe that the same will take place in the intersection of blockchain and game developing, and we have already seen the amount of inefficiencies and unnecessary repetition in adapting blockchain networks for gaming. For these reasons, we decided to build a blockchain game engine and named it Kabletop.
A Few Concepts to Know Before You Start
Before diving into the details, here are a few concepts you need to know:
Gameplay refers to the in-game pattern, defined through the game rules and connection between players, etc. In card games, the game type covered by this article, gameplay is about how to play the cards according to the rules.
CKB, the abbreviation for Common Knowledge Base, is a decentralized blockchain network that supports the RISC-V instruction set. Due to the special features of its virtual machine, Lua interpreter can be immediately compiled into smart contracts, thus running Lua language on-chain.
- We assume that you have a basic understanding of CKB essentials, such as the transaction data structures and CKB cell model. But no worries if not, our workshop for developers can help.
- NFT, known as Non-Fungible Token, is a unit of non-interchangeable token that represents specific on-chain assets. In the context of blockchain games, NFTs mainly refer to in-game objects such as props or equipment. NFTs can also function as badges that represent certain achievements in the game.
- State channel is an off-chain application state processing technology attached to the blockchain. Generally speaking, the state channel refers to multiple nodes that form a separate network outside the blockchain. These nodes follow certain rules to jointly maintain a certain data state. They submit the final state to the blockchain for confirmation and verification before the network connection is cut off.
- Compared with traditional online games, blockchain games emphasize on user-ownership. More specifically, the assets earned by users in the games are not merely a piece of data recorded in the database; instead, gamers have ownership over these items.
A Brief Introduction to Kabletop
Kabletop is a blockchain game development framework that supports running gameplay directly on the CKB network in the Lua language. It aims to help anyone who wants to design blockchain games on CKB by facilitating the development process with the following two features:
- Rapid deployment of two-player turn-based matches (or in-game two-player turn-based match scenarios) to the CKB network
- Rapid distribution of game items and assets to the CKB as NFTs.
In a two-player turn-based strategy game, two sides take turns to play. A set of rules and in-game items are provided, where the rule sets are further broken down into sub-rules to fit into different items. Players need to collect several items and combine them together as a collection of sub-rules to maximize their chances of winning. Owning items essentially means the player has ownership over a collection of the items' IDs, written in the gameplay together with the associated rules.
Once a two-player turn-based match is broadcasted onto the CKB network via Kabletop, items are presented as the correlated IDs and are displayed in the form of NFTs. The items' NFT IDs are all that the player has, and the operational rules of each item are written into the gameplay in pairs with the corresponding NFT IDs. All actions generated by the gamers and a list of their corresponding NFT IDs will be passed to smart contracts to be verified. When verifications are executed in smart contracts, the code from the gameplay deployed on the CKB will be called.
As a decentralized game engine, Kabletop runs verifications directly on the CKB network to maximumly reduce the reliance on centralized servers. Particularly, for those games that only use servers to verify in-game operations, a separate server is in no way necessary.
Contract Design
When it comes to NFTs, the biggest difference between game NFTs and art NFTs is that games NFTs function as in-game items in virtual scenarios, while art NFTs value scarcity and aesthetics. In terms of their quantity in circulation, art NFTs are strictly limited. The same applies to game NFTs, but only a very few in-game items with certain decorative significance (such as fashion, special effects or skins) have a fixed cap on the quantity. Game NFTs, in general, maintain only a certain degree of dynamic scarcity. The game designers do not directly cap the number of in-game items, but rather setting their output rate and destruction rate to control the quantity.
This is the same method that Kabletop adopts by default to regulate the number of in-game NFTs. Game developers need to set the minting rate of each NFT in their gameplay design. All in-game NFTs must comply with this setting, and even the designers themselves cannot violate it. As part of Kabletop, a feature for destroying NFTs is also included, but the rules need to be specified by the designers.
Compared to traditional software applications, games are more focused on the user experience. It's all about "selling the experience". In a two-player turn-based matches, not only the playability of the game itself having an impact on user experience, smooth operation is crucial as well. Verifying all the in-game operations on-chain will undoubtedly pose an enormous challenge to a smooth user experience. As a decentralized system, blockchain requires each on-chain operation to be verified by peers in the network. This mechanism significantly reduces the operation speed, compared to a system with a centralized server. However, if we rely on a single server to improve the speed, this would contradict the basic concepts of blockchain game design.
As a solution, Kabletop uses “state-channel" to divide the match into on-chain and off-chain processes: all the in-game operations are performed off-chain, while the verification of all these operations takes place on-chain.
In this way, we remove the biggest block to a smooth user experience by placing the in-game data exchange process offline. As a result, players can barely experience any lag. Although the data exchange takes place off-chain, it requires cross-validation from both sides. CKB network will also perform a consistent validation, which can ultimately ensure both the correctness and smoothness of data exchange.
Based on the considerations above, the entire design of Kabletop can be encapsulated in the following four contracts: NFT contract, Wallet contract, payment contract, and Channel contract, where:
- NFT, wallet, and payment contracts work together for the minting and distribution of game NFTs
- NFT and channel contracts work together to verify the in-game actions from both players
NFT Minting, Purchasing and Distributing
An NFT contract identifies the NFTs owned by the users. Each NFT ID is represented by a 20-byte hexadecimal string. NFT IDs can be sequentially combined together.
Minting and distributing NFTs require a wallet contract and a payment contract, each of which maintains a parameter, Owner, regarding its ownership. When the two Owner parameters are identical, it suggests NFT minting; when different, it suggests NFT distributing or purchasing.
This process is detailed as follows:
Mint NFT
Create an NFT Issue Config Cell. Its data field contains the following sections set by the creator:
- The price of the package from which the NFTs are extracted
- The number of NFTs extractable from each package
- The list containing all NFTs minted by the creator and their probabilities of being drawn
Mint NFT
Buy NFT
Before purchasing, the buyer needs to spend a certain amount of CKBs to create a Personal NFT Purchase Cell (skip this if the buyer already has one). Then the buyer pays CKBs to this cell to purchase NFT card packages (the payment process needs to refer to the creator's NFT Issue Config Cell).
After the payment is completed, the number of purchased card packages will be recorded in the data field of the Personal NFT Purchase Cell, which can be withdrawn by the NFT creator only.
Buy NFT
Distribute NFT
If the number of purchased packages exists in the Personal NFT Purchase Cell, the buyer can consume these NFT packages and receive NFTs based on a random seed generated by the CKB block that contains the “NFT purchase" transaction. The probability settings are stored in the NFT Issue Config Cell.
Once the packages are consumed, the number of purchased packages in the Personal NFT Purchase Cell will be cleared to zero.
Distribute NFT
We'd like to note that due to certain conflicts between Kabletop's requirements for NFT data structures and the popular NFT standard—mNFT protocol, for convenience, Kabletop uses a custom NFT standard in the demo. This is only an interim design to implement our concept. One of the future tasks of Kabletop is to integrate with the new mNFT/CoTA standard.
State Channel Based Two-Player Turn-Based Matches
A two-player turn-based match is a relatively simple gaming model. Both players take turns to finish their rounds. The overall state of the match evolves through the consecutive rotations of the turns until reaching a stage considered as “over".
With these features, such a game model can be seen as a finite state machine that uses the actions of the players as input parameters. The only concern is to ensure that the player's input is rule-compliant, more precisely, is considered rule-compliant by the opposing player.
To enable the state machine recognizes the fact that the current player's action has been confirmed as legitimate by the other player, we introduced the signature and signature verification mechanisms. All the operations of a player in the current turn must be verified by the other player. A signature is required once the verification is complete. All in-game operations can be considered legitimate by the state machine only if they are paired with the corresponding signatures. Since the player's actions are unpredictable, the signatures inevitably contain randomness. Given that, signatures can be used as random number seeds in each turn.
Both players need to remain online throughout the match, but what if one side suddenly drops offline? Intentionally or unintentionally, the match cannot proceed. The online battle will switch offline, meaning all the operations taking place offline will be submitted to the CKB network. This is known as the “challenge mode”, each successful submission is considered a successful challenge.
A timeout is granted after a player completes a successful challenge. If the opponent does not initiate the next round within that period, the player who successfully initiated the last challenge wins the game. Since each challenge iterates the state forward, the player can also end the game normally in challenge mode.
We illustrate the above process in the following stages:
| Stage | Description |
| 1 | Establish the state channel |
| 2 | Close the state channel |
| 3 | Challenge the state channel |
Establish the State Channel
The config information of the match is stored in lock_script_args, and the CKBs staked by both sides is stored in the Channel Cell. As both sides need to reach a consensus, they must jointly establish the Channel Cell and complete their signatures after the verification.
Establish the State Channel
Close the State Channel
The data from either side is stored in witnesses for further verification. It also requires a cell with compiled Lua code that contains the entire gameplay to be referenced for verification.
When the verification is complete, Channel Cell will be consumed. The CKBs staked in the Channel Cell will be reallocated to each side based on the result.
Close the State Channel
Challenge the State Channel
If the data stored in witnesses is insufficient to obtain the result, it will be considered a channel challenge. The challenger must input additional information into the data.
If the amount of CKBs previously staked in the Channel Cell is insufficient for the storage that the challenge requires, the challenger needs to cover it at his/her own expense. This amount of CKBs will be returned after the channel is closed.
Open the picture in a new tab to view in full size.
Challenge the State Channel
State Channel Interaction Flow
Connection is established on both sides.
Client-side player and server-side player in turn provide match information, including the setting and players' NFTs. Then the client submits the channel to initiate a transaction. As soon as the transaction is confirmed, the state channel is created.
The lock_hash of the Channel Cell functions as the initial random number seed to determine who goes first and the starting hand.
One side plays a combination of the cards in hand, where each action is synchronized with the opponent. By the end of the turn, the player informs the opponent to verify all operations and return the signature after confirming everything is correct. This data will be used as the random number seed for the next turn, starting with the opponent.
The battle repeats until the game ends or the network breaks.
- If the game ends, the winner collects data from all the operations and signatures, then submits them to the smart contracts for verification. The state channel will close after verification.
- If the network is disrupted, either player can continue the game until no more turns available. After that, one collects data from all the operations and signatures, together with all the unsigned operations (which are set as challenge data), then submits them to the smart contracts for validation. The state channel will be in Challenge mode after verification.
State Channel Interaction Flow. (Open the picture in a new tab to view in full size.)
SDK: Bridging Game Engine and Blockchain
We have covered the core of Kabletop design above. For game development on the Kabletop framework, developers also need to know how to develop Dapps on CKB. To facilitate the development process further, we provide SDKs of two levels:
- The
kabletop-ckb-sdk(https://github.com/cryptape/kabletop-ckb-sdk) encapsulates all the processes for interacting with Kabletop contracts. As a low-level SDK, it directly deals with CKB nodes. It also provides other practical components for networking and wallet-related tasks.
- The
kabletop-godot (https://github.com/cryptape/kabletop-godot) encapsulates kabletop-ckb-sdk with the Rust library of the Godot game engine. It provides the Godot game engine developers with the immediate interface to integrate with the Kabletop framework.
Kabletop's SDKs are in Rust. So, to faster verify the feasibility of Kabletop, we chose GodotEngine, a game engine that supports development in Rust. GodotEngine is a lightweight, easy-to-use, multilingual, and designer-oriented 2D/3D open-source game engine with a large audience.
We also created a simple and interesting card game with Kabletop. (The demo is only available in Chinese for the moment.) Built on the Kabletop framework, this game has implemented all its features, making the cards into NFTs and giving them combat attributes. Players can buy cards, build collections, choose their characters, and battle with their combination of in-game items. They either connect through LAN or a relay server. With everything ready to go, both players compete against each other on the CKB network by turning on or off their state channels.
Despite all the challenges in the development process, we bring Kabletop to help those interested in blockchain game design. If you want to learn more about Kabletop, feel free to contact us. The creator of the next top blockchain game might be you!
Exploration Never Stops
Kabletop framework is still a baby of the CKB family. Our exploration never stops. Here are some possible directions we are moving towards:
- Integrate Kabletop with more mainstream game engines, such as Unity, CocosCreator, and Unreal.
- Integrate the creation and publishing tools for all the visualizations of in-game NFTs.
- Provide a more generalized wallet management solution such as WalletConnect and Unipass.
- Support more game genres such as turn-based matches for 2+ players and real-time strategy (RTS).
- Extend the existing relay server into a decentralized relay network, and provide a decentralized environment for global users acting as in one single server.
- Decentralize the storage of data generated in-game.
✍🏻 Written by Yukun Li
Other articles that you might like:
