Spatial OS的MMO遊戲架構是不是革命性的？

是的。

我們從設計（玩法）、技術（架構）和效率（工業化）三個方面來聊聊為什麽SpatialOS對於MMO 是革命性的。

一、設計（玩法）

如果大家開啟Steam，可以看到它的線上玩家統計數據：

我截取了前20多位的遊戲，它們大都有這兩點共性： 多人線上，動作射擊 。

也許有人會問，這些打槍遊戲跟MMO有什麽關系呢？事實上，這些遊戲的大量線上人數被分散在了不同的房間裏，廣義上來講，也是MMO。接下來我們會用房間型MMO來代指它們。
近年來在房間型MMO的發展過程中，有這樣一種趨勢：一個房間內能夠容納的玩家人數，是在逐漸增加的：

PUBG的出現攪動了市場：支持100人同局的PvP遊戲出現了！更多玩家同局不代表遊戲更好玩，但是， 在玩家人數這個維度上的解放，的確會給遊戲設計者提供更大的發揮空間 ，是可能創造出全新的遊戲方向的。

當然，和傳統型MMORPG相比，目前房間型MMO的同服人數簡直不值一提。但反過來，這些房間型遊戲所提供的互動程度，也是傳統型MMORPG無法做到的。 多年以來，兩者走向截然不同的方向 。但是，當傳統型MMORPG不再滿足於往一組伺服器裏放更多玩家，而希望加入更豐富的互動；當房間型MMO的人數因為引擎的限制難以繼續突破；當玩家不再滿足於市面上的同質化遊戲時，新的遊戲型別，以及與之相配套的技術就是水到渠成了。

二、技術（架構）

接下來我們從技術角度分析一下，為什麽傳統型MMORPG做復雜的模擬和互動比較難，以及房間型MMO的最大人數是如何受引擎限制的。

傳統型MMORPG的後端，一般是自研引擎，歷史久遠，坊間戲稱「祖傳程式碼」。而前端，這些年逐漸走上工業化的路線，開始使用Unity、虛幻等主流引擎。所以前後端開發的技術棧，甚至開發語言，都逐漸走向了分裂。主流引擎中內建的成熟的物理、AI等技術，不能直接運用到後端，需要單獨實作。像物理這種前後端都可能模擬的系統，還需要考慮如何與引擎的版本做相容。所以從成本角度出發，後端就幹脆不做。

前後端分別開發的方式，還帶來了通訊協定、業務實作邏輯前後端版本不一致的問題。筆者曾
經就深受其害，這裏就不一一贅述。

另外在傳統型MMORPG使用的三層架構中，興趣管理（廣播）是在連線層實作的，但是連線層沒有狀態數據，客戶端只能基於頻道（Channel）去訂閱訊息，但是無法做更細粒度的訂閱或興趣變更。比如，玩家在開啟瞄準鏡的時候，變為訂閱長錐形視野範圍內的物件資訊，這個在三層架構裏怎麽做呢？必然要在場景服增加大量的業務程式碼。場景服中狀態和模擬（業務邏輯）的耦合又帶來了新的問題：跨服邏輯的實作。

還是剛才瞄準鏡的例子，如果瞄準的區域不在玩家所屬的場景伺服器，這個區域的物件資訊怎麽發送給瞄準的玩家呢？這時候就需要場景伺服器之間發送訊息。這種解決方法除了增加了實作復雜度，還增加了延遲（訊息返回到客戶端的總時間），在瞄準鏡這種對延遲要求高的套用場景，玩家體驗會比較差（物件不能及時出現或更新）。

綜上， 傳統三層架構在一些實作主流動作射擊遊戲中的復雜模擬，成本高，實作難，或者效果不好 。

那麽SpatialOS是怎麽解決這個問題的？首先，它把狀態數據和興趣管理都放在同一層，然後配合QBI，開發者可以自由地定義興趣範圍、狀態型別，以及頻率。興趣範圍包括立方體，球形，圓柱體等基本形狀，並且可以組合查詢。興趣定義好之後，客戶端就會持續從網路層直接收到變化的狀態。更妙的是， 伺服端也可以使用QBI來訂閱興趣 ，來管理形狀不規則，甚至是動態改變的地圖區域。

SpatialOS的網路層本質上是個分布式的記憶體資料庫，所以它也可以實作持久化。可能有人會問，連線、興趣管理、持久化你們全做了，我們開發者還需要做什麽啊？答：遊戲模擬。角色的行走跳躍、物理系統、NPC的AI，這些跟遊戲玩法密切相關的邏輯。 我們努力把開發者從分布式網路的復雜性中解放出來 ，甚至我們認為，開發者不應該在剛開始設計遊戲時，就受限於網路系統能容納多少玩家或NPC等計算。這些指標應該 像那些基於雲的互聯網系統能做到的一樣，是可以方便擴容縮容的 。

而房間型MMO的計算量受限，是因為它們的後端跟前端一樣， 是單行程的，無法受益於分布式的架構 。那麽開發者在設計之初，就要經常面臨的困境是，好，我們就做100人的玩法，然後做著做著想加點AI進去，然後發現伺服器幀率掉下去了，這時候要麽砍玩法，要麽砍最大線上人數，還有第三條不歸路：魔改引擎。

三、效率（工業化）

我們相信遊戲開發者是有能力實作SpatialOS做到的一切——比如把狀態管理放到連線層，比如引擎的客製，甚至說，自己從頭開發一個包括前後端的遊戲引擎。但是，能做到就一定值得做嗎？縱觀遊戲行業近年的發展，Unity和虛幻遊戲引擎的普及代表了一個訊號： 遊戲的開發，至少是遊戲前端的開發，正在工業化 。開發者不必再需要從頭搭建遊戲的基礎框架，甚至不需要掌握多少渲染管線、網路通訊等底層知識，就可以建立出遊戲了。換句話說，讓遊戲開發者用更快的速度做他們更擅長的、想要快速叠代實作的玩法和內容，把其它交給第三方來開發和維護。

引擎的維護是工業化過程中， 產品向服務過渡 的一個繞不過的問題。功能交付給使用者（引擎使用者）後， 版本的相容怎麽實作？功能的交叉整合誰來做？ 一個典型的例子就是虛幻引擎的專用伺服器（Dedicated Server）。它早已不是一個單純的網路後端功能了。如果僅僅是提供網路通訊層和基本的內容復制（Replication）加上遠端程序呼叫（RPC），是難以幫助開發者跨過網路遊戲開發的重重門檻的，所以虛幻引擎還對角色移動等元件進行了深度整合，使開發者 開箱可用平滑的移動同步、延遲補償、剛體插值同步等功能 。更厲害的是，每當虛幻引擎推出大的特性，比如Gameplay技能系統和Chaos，它都會考慮為其進行網路功能的整合。

所以我們可以想想 為什麽像PUBG和ARK這樣的遊戲，最早是誕生於虛幻引擎 ，執行在專用伺服器上，恐怕不光是虛幻引擎的前端表現力更好吧？它簡直就像一個房間型MMO的孵化器，越來越多的創意會越來越快地誕生出來。當然，很快創意就會碰到玩家人數和模擬效能的壁
壘，之前已經提過，這裏就不再贅述了。

當我們和開發者談SpaitalOS的時候，我們會在創意賦能之前，談到一個更重要，更實際的點： 風險管理 。我們認為這也是提高整體效率的關鍵。我們希望開發者在火力全開時沒有後顧之憂，所以我們從一些比較成熟的行業借鑒了工業化的思路，用工具和流程來幫助開發者降低風險。

比如網頁開發中早已成熟的叠代方式——你申請一台雲伺服器，把你的PHP指令碼放上去，就可以直接把連結發給朋友進行測試了。之後你每做一些修改，都可以很快地重新走一遍這個流程， 去驗證你的修改是否能達到預期。當你的測試達到一定規模，一台伺服器支撐不住的時候， 雲平台的橫向擴容和負載均衡 功能讓你彈指之間就能讓你的負載上升一個數量級。

我們再對比一下遊戲行業傳統開發方式——首先你會在開發的很長一段時間裏使用內網伺服器做測試，所以你工作室外的朋友，或者潛在成為最核心粉絲的玩家，都接觸不到你的遊戲，更不要說反饋和叠代了（當然我們也可以用「保密」來解釋）。然後遊戲要進行小規模的對外測試了，你需要找一個機房，租一台機器和頻寬。這個時候 後端執行的硬體和網路環境都發生了變化 ，如果你沒有進行充分的適配和測試，這次對外測試就面臨著從網路延遲高體驗差，到玩家連不上，甚至後台程式崩潰的風險。接下來對外測試的規模越來越大，每次你都會面臨同樣的風險，流程好的就提前適配和測試，讓技術來填坑；流程差點，就給玩家道歉補償，讓營運來填坑。那我們能不能讓這個坑一開始只用趟一遍呢？

對比網頁開發的叠代模式，我們需要補上的技術棧有：基於雲的一鍵式上傳部署；可配置的擴容方案；基於雲的分發下載和A/B測試方案，以及基於雲的日誌和效能監控工具。這些我們都會在第一天就免費交付給開發者去使用，並持續維護。

四、總結

綜上，從設計上來講，我覺得未來MMO的趨勢是目前房間型MMO和傳統型MMORPG的結合；從 技術上看，SpatialOS透過分布式引擎後端的方式，實作了高線上人數和高保真度的結合，使設計成為可能；而放眼遊戲工業化的浪潮，革命性的MMO也需要革命性的工具賦能，降低成本和風 險。

在這個下一代MMO呼之欲出的時代，作為一個玩家，也希望開發者們能破除禁錮，早日開發出更多好玩的MMO。

如果想要詳細了解SpatialOS的技術和功能，歡迎檢視SpatialOS官網。