Author: ck
Crypto-Native Games
The purpose of new technologies is to do entirely new things, explore new possibilities, rather than simply doing old things better or incrementally. When we talk about ‘fully on-chain game’, we are actually emphasizing a pioneering spirit, leveraging the unique attributes of blockchain to create entirely new product experiences, rather than dogmatically putting all game logic and data on the blockchain. In this context, fully on-chain game engines (such as MUD, Dojo, Keystone, Paima Engine, World Engine, etc.) align with this spirit, because they create blockchain game engines (or blockchain application development frameworks), something unprecedented before.
In contrast, in the field of fully on-chain games, although there are many games, there are not many that have real original innovation. Of course, this has a lot to do with the limitations of game mechanics. The gaming field has fully explored all possible game mechanics, and it is very difficult to create new game mechanics.
But above the game mechanics, there is still room for exploration. Projects like PixeLAW start from the “interoperability” of blockchain and explore the new field of interoperability between games . It cannot be concluded that PixeLAW is the most correct direction for the time being, but at least it is one step closer to the right direction. This is the main reason why we build games based on PixeLAW.
PixeLAW’s product form and design philosophy are introduced in detail in “The Easiest Way to Build Fully On-Chain Games” and “PixeLAW’s Engineering Aesthetics”. Next, we will mainly introduce our microscopic experience of PixeLAW and some thoughts arising from it during the development of the fully on-chain version 2048 based on PixeLAW.
Microscopic somatosensory using PixeLAW
For developers who are coming into contact with the Cairo language for the first time, it is not easy to develop games based on PixeLAW. They need to be familiar with the Starknet blockchain, Dojo framework, Cairo language and PixeLAW at the same time. Furthermore, Cairo, in terms of its design philosophy, language maturity, richness of toolchains, etc., differs significantly from Solidity (the programming language for Ethereum smart contracts). It presents considerable challenges for developers, and the following will provide detailed introductions to each aspect.
Starknet
Starknet is an Ethereum Layer 2 blockchain that using ZK Rollup, also known as the ‘most suitable Layer 2 for fully on-chain games’. I believe this statement encompasses multiple dimensions. From a technical perspective, Starknet features a native on-chain zero-knowledge proof mechanism (OP Stack seems capable of incorporating a layer of ZKP in its stack for similar effects); from an ecosystem perspective, there are grants and game jams organized by institutions such as the StarkWare and Bibliotheca DAO; and, of course, there is a marketing component, as the Starknet ecosystem needs to compete with other ZK Rollup and even OP Rollup ecosystems to win more developers.
Dojo
The Dojo framework can be roughly understood as the Cairo language implementation of the MUD framework (the first fully on-chain application development framework), currently targeting the Starknet ecosystem. If you have a certain understanding of the MUD framework, when you see the Dojo framework, except for the difference in programming language, other aspects will feel very familiar. In addition, Dojo is equipped with a tool chain for use with it (including: Katana, Sozo, Torii, Slot, etc.). In this sense, it is more appropriate to call it “Dojo tool set”.
Cairo
The Cairo language was developed by StarkWare in 2020. It is a Turing-complete programming language that generates STARK proofs for general computing, enabling Starknet as Layer 2 to perform provable calculations. Provability means that proofs can be generated on Starknet and verified on the Ethereum network (Layer 1) that the output of the program has been calculated correctly. Since the calculation occurs in Layer 2, Layer 1 can verify the generated proof using less computing resources (the verification process does not require re-execution of calculations), thereby achieving better computing performance and data security .
From the perspective of Solidity developers, due to the trade-off between security and computing performance of Cairo language, and the fact that Cairo language itself is still in its early stages, the learning threshold is higher than Solidity, and the language features are not as rich as Solidity. To complete the same functions, use Cairo language the development workload is likely to be greater.
PixeLAW
PixeLAW was born in July 2023 during the ETHGlobal Hackathon in Paris and won the Starknet Best Use award. In terms of development experience, except for the learning threshold of Cairo language, it is generally very good. PixeLAW Book reads very smoothly, and for developers who want to deploy PixeLAW Core and PixeLAW app_template locally, the whole process is quite smooth. However, if you want to develop games based on PixeLAW, you may need to further read the source code of PixeLAW examples to get more inspiration for engineering implementation.
Development Experience of BRC2048
Communication is very smooth
In the process of developing the fully on-chain version 2048 (BRC2048) based on PixeLAW, although we encountered some features that were not yet supported and encountered some minor bugs in PixeLAW, overall the functions provided by PixeLAW were sufficient to build the game. In addition, it is particularly worth mentioning that the communication with the PixeLAW team is always smooth, and the PixeLAW team’s replies are always timely. You must know that in a cross-time zone collaboration scenario, it is not easy to do this. Special thanks to @JK, shora, @thiscaspar, @mariz-ov from the PixeLAW team, and @ilhte from the MetaCat team.
Less work
We have built 2048 based on the MUD framework before . During the process of building 2048 based on PixeLAW, we obviously felt that the workload was less. Just focus on smart contract development to complete game development. This is a very magical experience and a new development paradigm! This is largely due to PixeLAW’s philosophy: start a world with the smallest components and let it grow with the community . Start with a pixel block and minimal rules, then add new rules, new games, etc. on top of that, and gradually make games interoperable with each other.
Less is more
The picture below is the 2048 game we built based on PixeLAW (also the main interface of PixeLAW). Since the smallest unit that makes up a game is a single pixel block, there will be limitations in the presentation of the game screen. As a result, not all game types are suitable for development with PixeLAW.
But for teams that want to delve deeper into interoperability between games, PixeLAW is a great testing ground. A single pixel block is the smallest programmable unit and the smallest unit of interoperability. It is a wise move to focus on the core goal and ignore secondary matters.
In conclusion
BRC2048 has only completed the preliminary game construction at present. Next, it will further improve the game functions and work with PixeLAW team to explore the specific implementation path of interoperability between games (such as Snake and Painting Games), as well as the use of PixeLAW in Autonomous World. More possibilities in the field .
Let‘s end with a sentence from @Eric, the founder of cellula.live: We are currently in the very early stages of the fully on-chain game/autonomous world. Only by pursuing extreme differentiation can individuals maximize the survival probability of the entire track.
