作者:Fiona, IOSG Ventures
本文爲IOSG原創內容,僅做行業學習交流之用,不構成任何投資參考。如需引用,請注明來源,轉載請聯系IOSG團隊獲取授權及轉載須知。
感謝@BriefKandle Creator of @netherscape_xyz, @stokasz CEO@rhascau @mintersworld,@0xcurio team, @SebastienGllmt cofounder@PaimaStudios, @hiCaptainZ, and @SerenaTaN5 提供的幫助和寶貴意見!
-
全鏈遊戲/自治世界("FOG/AW")是圍繞Web 3的少數重要敘事之一。相比於只通過NFT連接到Web3的Web2.5應用不同,FOG/AW將遊戲邏輯也放在了鏈上。它利用區塊鏈作爲遊戲服務器,成爲遊戲狀態的去中心化信任源。這帶來了持久性、抗審查、可組合性等優點,但也限制了構建在其之上的遊戲多樣性和復雜性。
-
隨着遊戲復雜性和可玩性要求的提高,對引擎架構提出了更多的挑战要求:比如幀數延遲、隨機數、生命值恢復、連續的被動效果、計時器等等。其中時間的概念以及Ticks單位在區塊鏈上是不一樣的。Mud提供了不少思路來模擬時間流逝以及被動恢復技能。比如,當玩家在房間中移動時,交易中附帶根據一些預定義的設計移動房間中的所有物品。以此感知時間和狀態的變化。
-
FOG/AW技術棧可被抽象爲:开發者爲ui/ux和遊戲核心邏輯編寫前端和後端代碼,然後通過遊戲狀態的循環來同步所有的變化,最後由索引器將新的狀態反映到前端的本地設備上。
-
由於許多遊戲類型,如RTS,需要高的tickrates,而由共識產生的區塊鏈只能處理區塊時間的變化,tickrate是這裏要解決的一個大問題。Curio和Argus是這方面的領先者,他們正在摸索鏈的層面上增加遊戲tickrate。Mud在試圖最大程度實現全鏈上,整個應用程序狀態都保存在 EVM 中。並沒有爲實現遊戲更高tickrate上引入鏈下結合的方案。
-
對於不同鏈的選擇上,Dojo在引領Starknet的全鏈生態。根據@tarrenceva的描述,Starknet有State diffs狀態差異,不同於optimistic rollups,重點放在了執行輸出而不是輸入。對遊戲的影響主要可能在於優化成本,例如國際象棋遊戲:在三分鐘的遊戲中,可能會發生 50 步。通過狀態差異,單個證明和最終狀態可以證明“輸出”。而optimistic rollups需要所有中間狀態的“輸入”。
定義 FOG/AW:遊戲狀態是如何同步的
我認爲要判斷是否是FOG,基准是遊戲狀態是如何同步的(source of truth)。
對於Web 2.5遊戲或傳統的多人遊戲,有一個中心化的服務器來定義當前的遊戲狀態,當玩家發送行動時,服務器會編譯這些輸入並將更新的結果返回給每個連接的玩家的設備。服務器處理所有的輸入(tick),解決不一致的問題,並定期向玩家發送更新,提供遊戲中所有元素的快照,每一個tick都更新遊戲狀態。遊戲狀態("game state or tick")是遊戲世界中每個對象的屬性的時間快照。Tickrate 是指遊戲服務器每秒鐘計算並向玩家廣播更新的遊戲狀態的次數。Tickrate 越高,遊戲體驗就越精確、越高保真。一般來說,實時战略或動作遊戲需要高。tickrate,而卡牌遊戲等回合制遊戲則不需要。
Source:https://www.gabrielgambetta.com/client-server-game-architecture.html
對於完全運行在鏈上的遊戲,區塊鏈是遊戲服務器並作爲遊戲狀態的去中心化的信任源。在這種情況下,不僅NFTs或代幣有真正的所有權,就連遊戲者的ticks以及遊戲邏輯也是在鏈上的。這就是爲什么可以實現真正的所有權、持久性、抗審查性、可組合性等。理想情況下,遊戲者的每個動作都應該提交給區塊鏈,在達成共識後,遊戲狀態被更新並返回到本地設備。因此,自然而然地,需要較少tickrate的遊戲類型更適合完全在鏈上進行。
解決遊戲的延遲、時間等的挑战
隨着遊戲復雜性和可玩性要求的提高,對引擎架構提出了更多的挑战要求:比如幀數延遲、隨機數、生命值恢復、連續的被動效果、計時器等等。
幀數延遲其實在Web2世界也非常普遍,來自包括客戶端渲染和用戶操作上的延遲。特別是FPS這種高tickrate 遊戲,一旦出現延遲,玩家體驗會非常差,Web2中的其中一個解決辦法是 lockstep state update,讓所有玩家的同步按玩家中最高延遲的標准來同步,以此解決玩家公平性的體驗。當引入區塊鏈並需要等待交易確認後,這個延遲可能會更嚴重。爲此,Mud也增加了遊戲中常用的optimistic rendering樂觀渲染這一機制,假設用戶操作成功,並在服務器同意之前(或者在本例中是在事務確認之前)將其渲染在客戶端中。
鏈上生成隨機數是一個經常被討論的課題,Mud認爲可以將用戶行爲作爲隨機結果的輸入,在交互發生後生成。
時間的概念以及Ticks單位在區塊鏈上是不一樣的。@SebastienGllmt認爲在用fraud proof概念的鏈上(比如Op)很難使用計時器,因爲一旦出錯,將需要回滾,如果遊戲中用到計時器,體驗將很差。Mud提供了不少思路來模擬時間流逝以及被動恢復技能。比如隨時間流逝增加金幣,每次玩家執行需要金幣的操作時,根據玩家之前的金幣數量、最近一次刷新的數量和刷新率來計算玩家的金幣數量。再比如,當玩家在房間中移動時,交易中附帶根據一些預定義的設計移動房間中的所有物品。以此感知時間和狀態的變化。
寫腳本“作弊”也許不是問題。@BriefKandle 不認爲對遊戲系統的MEV算作弊,防止腳本能簡單的MEV是遊戲團隊需要考慮的事情,Web2的遊戲开發需要轉變思路,好的MEV bot是遊戲內的NPC。
部分功能已在最近推出的一些鏈上遊戲中實現,比如Rhascau中,他們使用了計時器和連續被動效果。基本上使用區塊時間作爲刻度。(在當前的 L2 中,區塊時間 = tickrate)。
FOG/AW 技術棧
FOG/AW引擎框架是一個开發者工具棧,可以讓开發者利用區塊鏈作爲服務器和信任源構建遊戲。此外,它可以解決目前的一些問題:
-
由於沒有標准/現成的框架,構建鏈上FOG/AW的效率低下;
-
缺乏模塊化和代碼重用性;
-
缺乏可組合性。隨着FOG/AW引擎的發展,鏈上遊戲可以更加有趣和富有想象力。
爲了便於理解,這類引擎一般簡化的技術流程是:开發者爲ui/ux和遊戲核心邏輯編寫前端和後端代碼,然後通過遊戲狀態的循環來同步所有的變化,最後由索引器將新的狀態反映到前端的本地設備上。
爲了使運行在區塊鏈上的遊戲也能順暢地運行這一回路,Mud,Dojo,Curio,Argus,Paima engine及Lootchain等正在爲此开發各自的技術棧。技術棧由3個關鍵部分組成:鏈、核心开發棧和遊戲前端。他們都有自己的創新,在去中心化和遊戲復雜性之間做出權衡。
-
遊戲前端:包含傳統引擎如Unity、Unreal等以及react/Threejs等語言和強大的工具提供渲染等功能,增強遊戲可玩性和體驗感必不可少的一環。以上項目基本都能提供相關SDK供开發者使用。
-
核心开發棧:設計一套方案能讓遊戲邏輯運行在區塊鏈上,並能按時同步到前端。關鍵組件包括合適的數據庫結構(定義遊戲行爲和邏輯),以及遊戲狀態的同步和返回。
-
鏈:大部分選擇了Ethereum、Optimism和Starknet上構建。
下圖描繪了不同的協議是如何設計各自的技術棧。以Mud V2爲例來看其運作流:
-
一個开發者會在Mud調用一些Web2的前端工具來編寫代碼,利用這些強大的功能如渲染使得遊戲更可視化看起來更好玩;
-
同時,开發者會依Mud的智能合約框架(Mud World)來寫遊戲的人物、物品以及具體的運行邏輯等,比如當英雄A從X處移動至Y處,並發起對Y地塊的討伐,多大概率或什么情況下能成功佔領該地塊;
-
以上的動作及遊戲狀態會被記錄在Mud Store,它是一個鏈上數據庫,負責全局遊戲狀態,是遊戲狀態同步的信任來源;
-
當英雄A對Y進行討伐,其實是玩家在前端本機上點擊了鼠標並提交了該命令上鏈,該命令依據开發者的遊戲設計邏輯,以及當前Store裏的遊戲狀態,造成了一個結果,該結果被更新至新的遊戲全局狀態,並被同步上鏈;
-
Mud上的遊戲支持Web、Mobile等各種前端,不過可能會面臨復雜的索引需求,Mode正是爲此而开發的一個鏈下索引器。
現在,讓我們談談這些核心框架的共同和不同的設計。
-
他們中的大多數遵循Mud v1設計,並利用ECS作爲遊戲开發的數據結構。這是遊戲邏輯的編寫和呈現方式。Mud V2對其進行了改進,數據被定義在Tables和Systems,這允許其他的數據標准(不必如V1遵守ECS 數據建模標准),這給了开發者更多的選擇,使其更具包容性。
-
大多數都使用去中心化的數據庫,因爲區塊鏈自然地是遊戲狀態和數據庫的信任來源。Mud在試圖最大程度實現全鏈上,整個應用程序狀態都保存在 EVM 中。並沒有爲實現遊戲更高tickrate上犧牲去中心化或者引入鏈下結合的方案。
-
由於許多遊戲類型,如FPS,需要高的tickrates,而由共識產生的區塊鏈只能處理區塊時間的變化,tickrate是這裏要解決的一個大問題。Curio和Argus在自己的創新設計中,率先希望在鏈的層面上增加tickrates。
-
對於不同鏈的選擇上,Curio和Loot都利用Caldera構建Op stack chain,除此之外,Dojo在引領Starknet的全鏈生態。根據@tarrenceva的描述,Starknet有State diffs狀態差異,不同於optimistic rollups,重點放在了執行輸出而不是輸入。對遊戲的影響主要可能在於優化成本,例如國際象棋遊戲:在三分鐘的遊戲中,可能會發生 50 步。通過狀態差異,單個證明和最終狀態可以證明“輸出”。而optimistic rollups需要所有中間狀態的“輸入”。
目前已經有一些遊戲構建在這些引擎之上,Mud和Dojo都在爲此舉辦黑客松吸引开發者構建應用,Curio也剛在ETHCC發布魔獸爭霸的minigame demo。
很明顯,FOG/AW正在成爲公鏈爭奪的關鍵生態,由Lattice提出的AW(自治世界)是一個很大的概念,不僅限於遊戲、還包含社交、金融等衆多屬性。因此,構建在此之上的是一個充滿想象力的虛擬世界,即Metaverse。我們可以期待一些新形態的遊戲、社交、金融等融合應用。
Reference:
1.https://mirror.xyz/matchboxdao.eth/d3lVAOa9Bi0kY-caoUT3lDC6E61mWJqtP1q6tME4xGY
2.https://jumpcrypto.com/writing/defining-on-chain-gaming/
3.https://www.oneqode.com/what-is-a-game-server/
4.https://medium.com/@qingweilim/how-do-multiplayer-game-sync-their-state-part-2-d746fa303950
5.https://latticexyz.notion.site/Building-Autonomous-Worlds-with-MUD-39d5eb5d31034589bc54a2053efb4c56
6.https://twitter.com/tarrenceva/status/1660686571270705152
7.https://book.dojoengine.org/framework/sozo/overview.html
鄭重聲明:本文版權歸原作者所有,轉載文章僅為傳播信息之目的,不構成任何投資建議,如有侵權行為,請第一時間聯絡我們修改或刪除,多謝。