作者: 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 的微觀體感和由此引發的一些思考。
使用 PixeLAW 的微觀體感
對第一次接觸 Cairo 語言的開發者來說，基於 PixeLAW 開發遊戲並不容易，需要同時熟悉 Starknet 區塊鏈、Dojo 框架、Cairo 語言和 PixeLAW。此外，Cairo 程式語言的設計哲學、語言成熟度、工具鏈豐富度等方面，較Solidity（以太坊智能合約程式語言） 也有很大不同，對開發者還是有相當大的挑戰的，接下來將一一介紹。
Starknet
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 框架
Dojo 框架可以粗略地理解為MUD 框架（首個全鏈應用開發框架）的Cairo 語言實現，目前針對Starknet 生態。如果你對MUD 框架有一定了解，當看到Dojo 框架時，除程式語言的差異，其他方面會感到很熟悉。此外，Dojo 配備了與之搭配使用的工具鏈（包含：Katana、Sozo、Torii、Slot 等），從這個意義上說，叫做「Dojo 工具集」比較合適。
來源：https://github.com/dojoengine/dojo
Cairo 語言
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
PixeLAW 於2023 年7月在巴黎ETHGlobal 黑客松期間誕生，並獲得Starknet Best Use 獎項。開發體驗方面，除Cairo 語言的學習門檻外，整體還是很不錯的。 PixeLAW Book 讀起來很流暢，對於想在本地部署PixeLAW Core、PixeLAW app_template 的開發者來說，整個過程相當絲滑。不過想要基於PixeLAW 開發遊戲的話，可能需要進一步閱讀PixeLAW examples 的原始碼以獲得更多工程實作上的靈感。
PixeLAW Github 首頁：https://github.com/pixelaw/
開發 BRC2048 的體驗
溝通流暢
我們基於 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 的一句話來結尾：當前處於全鏈遊戲/自主世界的極早期，個體只有追求極致的差異化，才能獲得整個賽道的生存機率最大化.