Why develop games based on PixeLAW

Author: ck

Crypto-native games

“Crypto-native games are a way to embrace blockchain development to themaximum Patterns and Blockchain Spirit’s Game”.

New technology is used to do new things and explore new possibilities, not to do old things better and incrementally. When we talk about "full-chain games", we are actually emphasizing an exploratory spirit of "dare to be the first in the world", using the unique attributes of the blockchain to create a new product experience, not just dogma Put all game logic and game data on the blockchain in a traditional way. From this point of view, full-chain game engines (such as: MUD, Dojo, Keystone, Paima Engine, World Engine, etc.) are in line with this spirit, because they create blockchain game engines (or blockchain application development frameworks) ), which has never happened before.

Full-chain game engine. Source: https://www.binance.com/en/research/analysis/a-primer-on-on-chain-gaming

In contrast, in the field of full-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 modes.

A summary of the entire chain of games. Source: https://awmap.xyz/

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 develop games based on PixeLAW.

Image source: https://pixelaw.github.io/book/

PixeLAW's product form and design philosophy are introduced in detail in "PixeLAW: The Simplest Way to Build a Full-Chain Game" 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 full-chain version 2048 based on PixeLAW.

Microscopic body perception using PixeLAW 

Yes For developers who are new to Cairo language, it is not easy to develop games based on PixeLAW. They need to be familiar with Starknet blockchain, Dojo framework, Cairo language and PixeLAW at the same time. >. In addition, the design philosophy, language maturity, tool chain richness, etc. of the Cairo programming language are also very different from Solidity (Ethereum smart contract programming language), which still poses considerable challenges to developers. Next, we will An introduction.

Starknet

Starknet is using ZK Rollup The Ethereum Layer 2 blockchain is also known as "Layer 2 most suitable for full-chain games." I think this statement includes multiple dimensions, the technical dimension, Starknet has the zero-knowledge proof mechanism native to the chain (OP Stack seems to be able to insert a layer of ZKP into its Stack to achieve a similar effect); the ecological dimension, Starknet Foundation, Bibliotheca DAO Activities such as Grant and Game jam organized by organizations; of course there is also a marketing component. After all, the Starknet ecosystem needs to compete with other ZK Rollup blockchain ecosystems and even OP Rollup blockchain ecosystems to win more developers.

Starknet official website: https://www.starknet.io/en

Dojo Framework

Dojo framework can be roughly understood as the Cairo language implementation of the MUD framework (the first full-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".

Source: https://github.com/dojoengine/dojo

Cairo Language

Cairo language was developed by the StarkWare team in 2020. It is a graph that generates STARK proofs for general computing. A complete programming language that enables 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-executing the calculation), thereby achieving better computing performance and data security.

From the perspective of Solidity developers, due to the trade-offs between security and computing performance of the Cairo language, and the fact that the Cairo language itself is still in its early stages, the learning threshold is relatively high. Solidity is not as rich in language features as Solidity. To complete the same function, the development workload using Cairo language may be greater.

Comparison of four smart contract languages. Image source: https://medium.com/scb10x/smart-contract-programming-languages-trade-offs-e2797f0b2968

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.

PixeLAW Github homepage: https://github.com/pixelaw/

Experience in developing BRC2048

Smooth communication

In the process of developing the full chain version 2048 (BRC2048) based on PixeLAW , although we encountered some features that are not yet supported, and also encountered some small bugs in PixeLAW, in general, PixeLAW provides Functional enough to develop our game. In addition, it is particularly worth mentioning that communication with the PixeLAW team is always smooth, and the PixeLAW team's responses are always timely. You must know that in a cross-time zone collaboration scenario, this is not easy to do. Special thanks to @jk, @syora, @thiscaspar, @mariz-ov from the PixeLAW team, and @ilhte  from the MetaCat team.

Communication process with PixeLAW team. Source: https://discord.com/channels/1134242024409792525/1178127430704189550

Less work

We have developed 2048 based on the MUD framework before. In the process of developing 2048 based on PixeLAW, we obviously feel that the workload is 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.

BRC2048 core code part. Source: https://github.com/themetacat/PixeLAW2048/blob/main/brc2048/src/app.cairo#L135

Less is more

The picture below is the 2048 game we developed based on PixeLAW (also the main interface of PixeLAW). Since the smallest unit that makes up a game is a single pixel block, the game screen presentation will be limited, which means that not all game types are suitable for development with PixeLAW. But PixeLAW is a great testing ground for teams that want to delve deeper into interoperability between games. 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.

BRC2048 Game interface

Write at the end

BRC2048 Currently, only the preliminary game construction has been completed. Next, we will further improve the game functions and explore the game room (such as: Greedy snake-eating, drawing games) interoperability, and more possibilities for PixeLAW in the field of autonomous worlds.

Let us end with a sentence from cellula.live founder Eric: We are currently in the very early days of the full-chain game/autonomous world, and individuals can only pursue the ultimate. Only through differentiation can the survival probability of the entire track be maximized.