作者: ck
“加密原生游戲是一種最大限度地擁抱區塊鏈開發模式和區塊鏈精神的游戲”。
新技術是用來做全新的事情、探索全新的可能性，而非更好地、漸進地做舊的事情。當我們談“全鏈游戲”的時候，實際上是在強調一種“敢為天下先”的探索精神，利用區塊鏈的特有屬性，創造全新的產品體驗，而不僅僅是教條式的將游戲邏輯、游戲數據全部放在區塊鏈上。以此來看，全鏈游戲引擎（如：MUD、Dojo、Keystone、Paima Engine、World Engine 等）是符合這種精神的，因為它們創造了區塊鏈游戲引擎（或者叫區塊鏈應用開發框架），這是之前從未有過的。
全鏈游戲引擎。來源：https://www.binance.com/en/research/analysis/a-primer-on-on-chain-gaming
反觀全鏈游戲領域，雖然游戲數量眾多，但真正有原生創新的不算太多。當然這跟游戲機制（game mechanics）的有限性有很大關系，游戲領域已經充分探索了所有可能的游戲機制，要再創造新的游戲模式非常困難。
全鏈游戲匯總。來源：https://awmap.xyz/
但在游戲機制之上，依然有可探索的空間。像?PixeLAW?這樣的項目，從區塊鏈的“可互操作性”出發，探索游戲間互操作性這一全新領域。暫時不能斷定?PixeLAW 是最正確的方向，但至少離正確的方向更近了一步，這是我們基于 PixeLAW 開發游戲的主要原因。
圖片來源：https://pixelaw.github.io/book/
關于?PixeLAW 的產品形態、設計哲學在《PixeLAW：構建全鏈游戲的最簡單?法》和《PixeLAW 的工程美學》中有詳細介紹。接下來將主要介紹我們基于 PixeLAW 開發全鏈版 2048 過程中，對 PixeLAW 的微觀體感和由此引發的一些思考。
對第一次接觸?Cairo 語言的開發者來說，基于?PixeLAW 開發游戲并不容易，需要同時熟悉?Starknet 區塊鏈、Dojo?框架、Cairo 語言和?PixeLAW。此外，Cairo 編程語言的設計哲學、語言成熟度、工具鏈豐富度等方面，較 Solidity（以太坊智能合約編程語言） 也有很大不同，對開發者還是有相當大的挑戰的，接下來將一一介紹。
Starknet?是采用?ZK Rollup 的以太坊 Layer 2 區塊鏈，也被稱為“最適合全鏈游戲的?Layer 2”。我認為這個說法包含多個維度，技術維度，Starknet 有鏈原生的零知識證明機制（OP Stack 似乎也可以在其 Stack 中插入一層 ZKP 來達到類似效果）；生態維度，Starknet 基金會、Bibliotheca DAO 等機構組織的 Grant 和 Game jam 等活動；當然也有營銷的成分，畢竟?Starknet?生態需要與其他?ZK Rollup?區塊鏈甚至 OP?Rollup 區塊鏈生態競爭來贏得更多開發者。
Starknet 官網：https://www.starknet.io/en
Dojo 框架可以粗略理解為 MUD 框架（首個全鏈應用開發框架）的 Cairo 語言實現，目前針對 Starknet 生態。如果你對 MUD 框架有一定了解，當看到 Dojo 框架時，除編程語言的差異，其他方面會感到很熟悉。此外，Dojo 配備了與之搭配使用的工具鏈（包含：Katana、Sozo、Torii、Slot 等），從這個意義上說，叫“Dojo 工具集”更合適。
來源：https://github.com/dojoengine/dojo
Cairo 語言由?StarkWare?團隊于 2020 年開始開發，是為通用計算生成 STARK 證明的圖靈完備編程語言，使?Starknet 作為 Layer 2 能夠進行可證明性計算。可證明性意味著可以在 Starknet 上生成證明，并在以太坊網絡（Layer 1）上驗證程序的輸出已經被正確計算。由于計算發生在 Layer 2，而 Layer 1 使用較少的計算資源即可驗證生成的證明（驗證過程不需要重新執行計算），從而實現更好的計算性能和數據安全性。
從 Solidity 開發者的角度來說，由于 Cairo 語言在安全性和計算性能方面的取舍，加之 Cairo 語言本身尚處早期，學習門檻較 Solidity 高、語言特性不如 Solidity 豐富，完成同樣的功能，使用 Cairo 語言開發工作量有可能會更大。
四種智能合約語言對比。圖片來源：https://medium.com/scb10x/smart-contract-programming-languages-trade-offs-e2797f0b2968
PixeLAW 于 2023 年7月在巴黎 ETHGlobal 黑客松期間誕生，并獲得 Starknet Best Use 獎項。開發體驗方面，除 Cairo 語言的學習門檻外，總體還是很不錯的。PixeLAW Book 讀起來很流暢，對于想在本地部署 PixeLAW Core、PixeLAW app_template 的開發者來說，整個過程相當絲滑。不過想要基于 PixeLAW 開發游戲的話，可能需要進一步閱讀 PixeLAW examples 的源代碼以獲得更多工程實現上的靈感。
PixeLAW Github 主頁：https://github.com/pixelaw/
溝通流暢
我們基于?PixeLAW?開發全鏈版 2048 （BRC2048）的過程中，雖然遇到有些特性尚未被支持，也遇到過 PixeLAW 的一些小 bug，但總體上 PixeLAW 提供的功能足以開發我們的游戲。此外，特別值得一提的是，與?PixeLAW 團隊溝通總是很順暢，PixeLAW 團隊的回復總是很及時，要知道在跨時區協作的場景下，做到這一點并不容易。這里要特別感謝 PixeLAW 團隊的@jk、@syora、@thiscaspar 、@mariz-ov，以及 MetaCat 團隊的 @ilhte?。
與?PixeLAW 團隊溝通過程。來源：https://discord.com/channels/1134242024409792525/1178127430704189550
工作量更少
之前我們基于 MUD 框架開發過 2048，在基于?PixeLAW 開發 2048 的過程中，明顯感覺工作量少了。只需專注智能合約開發，即可完成游戲開發。這是非常神奇的體驗，也是全新的開發范式！這很大程度上歸功于?PixeLAW 的理念：用最小的組件開始一個世界，并讓它與社區一起成長。從一個像素塊和最少的規則開始，然后在此基礎上添加新規則、新游戲等，并逐步讓游戲之間有互操作性。
BRC2048 核心代碼局部。來源：https://github.com/themetacat/PixeLAW2048/blob/main/brc2048/src/app.cairo#L135
少即是多
下圖是我們基于 PixeLAW?開發的?2048?游戲（也是 PixeLAW 的主界面）。由于組成游戲的最小單元是單個像素塊，因此游戲畫面呈現上會有所局限，進而導致并非所有游戲類型都適合用?PixeLAW 開發。但對于想要深入探索游戲間互操作性的團隊來說，PixeLAW 是很好的試驗場。單個像素塊是最小的可編程單元、也是最小的互操作性單元，關注核心目標，忽略次要事務，不失為一種明智之舉。
BRC2048?游戲界面
BRC2048?目前只完成了初步的游戲構建，接下來會進一步完善游戲功能，并與 PixeLAW 團隊一起，探索游戲間（比如：貪吃蛇、畫圖游戲）互操作性的具體實現路徑，以及 PixeLAW 在自主世界領域的更多可能性。
讓我們以?cellula.live 創始人 Eric 的一句話來結尾：當前處于全鏈游戲/自主世界的極早期，個體只有追求極致的差異化，才能獲得整個賽道的生存機率最大化.
喜來順財經
