做個幾萬人一起玩的《荒野大鏢客》有可能嗎？

多人遊戲的規模，一直是個讓人捉摸不透的問題。從 MUD 發展而來的 MMORPG，同時線上人數超過五位數的並不少見，但到了《方舟：生存進化》《ATLAS》和“吃雞類”的作品中，伺服器、或者說一個房間容納的人數一般在 70 到 200 之間徘徊。

估計有不少玩家曾經幻想過，將《荒野大鏢客：救贖2》這樣細緻入微的單人體驗塑造成大型 MMO，上萬名牛仔在西部世界裡快意恩仇、何其壯觀。但即使是技術力如此之強的 Rockstar，也只敢採取“32 人戰局”的設計方式，並在刪減了一些內容的情況下推出《荒野大鏢客 Online》。


有時候，擴充多人遊戲規模的瓶頸，還不單單只是願不願意花錢買伺服器的問題。拋開設計、玩法上的考慮，許多開發團隊面臨著“想做大卻沒法做大”的技術窘境。《絕地求生》跟《堡壘之夜》將人數設定在 100，也未必全是討個好彩頭。你要說藍洞和 Epic 想要致敬高見廣春的小說《大逃殺》，那應該也是構思 42 人相互廝殺的世界。

巧的是，今年我在 CJ 逛展時結識了田桑。他過去曾在 EA 負責線上遊戲的功能設計，後來又任職英礴（Improbable）的遊戲解決方案工程師，跟進過 5 個 MMO 專案，十分了解多人線上遊戲的構造。我們從“吃雞”的人數聊到《荒野大鏢客：救贖2》的多人模式，於是就有了這篇科普。

為什麼 MMORPG 能支援上萬人

線上多人遊戲的規模能到今天這個程度，肯定不是一蹴而就的。1996 年的 MUD《俠客行》最早是在大學裡設定的伺服器，當玩家規模增長到 1000 人同時線上時，其負載瞬間就被推到了極限。

同時期圖形化的網遊顯得更加“寒磣”，由於網路遊戲的使用者存在多個狀態，如果說文字 MUD 僅僅是用一句話來描述，那圖形化的狀態可能要涉及到位置、動作、頻率等諸多因素，每秒鐘得同步非常多次，導致資料的容量特別大。因此號稱領先於時代的《子午線59》，一個伺服器能夠容納的人數也只不過 250 人。


《網路創世紀》的製作團隊當時沒少為使用者規模這事操心，在 Alpha 測試的時候他們就覺得 250 人離“大型多人互動”的概念還有些距離，於是 Beta 測試前是又是買硬體又是研究新技術。到了 1997 年，這群人在 BUG 一堆的情況下硬是把能夠同時容納的併發人數懟到 3000，導致後來不少漏洞被玩家利用。

在田桑看來，因為 90 年代是個快速發展的時代，他理解的早期使用者規模擴容偏向堆頻寬和硬體。只不過現在成本的越來越高，採取這種方法的代價太大，一個側面現象就是 CPU 的主頻很多年來沒有太大提升。而從技術的角度來說，傳統 MMORPG 使用的架構是 C/S（伺服器-客戶機），作為一個被應用了 10 多年的架構，廣泛存在於《Runescape》《魔獸世界》等作品的設計中，它可以說是網路遊戲支援上萬人同時線上的基礎。

從名字就能看出來，C/S 最早是兩層結構，客戶機也就是玩家電腦（主機）負責渲染，伺服器處理遊戲邏輯。後來又加了一層“資料庫”，搭載了用於儲存遊戲結果的儲存器，估計也不用做太多科普。


為了保證使用者的規模足夠大，傳統 MMORPG 在“保真度”上做了很多犧牲。所謂的保真度可以簡單理解成遊戲的細緻程度，包括物理模擬，比如撞牆之後產生反作用力，或是像《半條命2》那樣實打實的把罐子握在手裡撿起來；也包括延遲和同步，比如動作遊戲和 FPS 遊戲對伺服器幀率都有非常高的要求。

根據田桑的解釋，傳統 C/S 的客戶端不做模擬，或者是比較輕量的模擬，它們把這些狀態以比較低的頻率發到伺服器，對伺服器的負載要求較低，因此就可以允許更多的玩家同時線上。


保真度的差異，我們甚至能從單機遊戲和 MMO 的渲染邏輯中看出來。單機遊戲的影像會盡可能從 GPU 中載入，理想狀態下最好能做到不訪問硬碟和主存。《超級馬力歐兄弟》每個關卡中的方塊、每個怪物出現的位置都是固定的，角色、敵人和場景在遊戲啟動時就渲染讀取完畢，進而放到 GPU 記憶體中。

而 MMO 中更多引入了“其它玩家”的變數，加上其技能、特效、位置的無數種組合，基本無法提前確定要渲染的東西，因此只能動態的從主存和硬碟讀取紋理等資料。客戶端與伺服器的互動最先只確定玩家位置，本地先進行輪廓渲染，再在保持幀率的前提下一點點把畫面讀出來，體驗肯定要差一些。


事實上，在犧牲了保真度的前提下，要保證使用者的規模夠大，儘可能降低伺服器負載，C/S 架構仍然需要寫一個極其複雜的後端。從《魔獸世界》的處理方式不難看出，那個年代暴雪工程師的天賦何其之高。

最常見的就是“空間分割法”，即把遊戲中的地理（地圖）進行分割，逐一分配給不同的伺服器程式或者裝置。


一個變種是“空間複製法”，即把世界複製很多份，每份單獨塞到一個伺服器；而為了解決玩家因刷寶、挑戰高難度怪物而大量聚集起來的問題，他們又研究出“例項法”，單以副本的方式為每波玩家提供極其有限的地區。


因此在田桑的眼中，基於 C/S 的 MMORPG 有著相當高的技術門檻：


而這裡提到的 DS（Dedicated Server，專用伺服器），不僅是當下很多主流線上多人遊戲都會使用的技術，也恰好能夠解答“為什麼「吃雞」的玩家得是 100 人”的問題。

為什麼一局吃雞的玩家得是 100 人

首先得宣告 100 人只是個數量級，並非錙銖必究的數字。

簡單來說，DS 可以比喻成“房間制”。好比《絕地求生》《堡壘之夜》《戰地5》和《我的世界》，一個伺服器（獨立主機）對應一個房間，然後這個房間大致能夠容納兩位數到三位數的玩家。

目前市面上主流的遊戲引擎，如虛幻和 Unity 為線上多人遊戲提供的解決方案都是 DS。這是一種能最大限度提高網遊保真度的架構，它最早的目的就是為了解決 FPS 的同步問題，追求高精度、低延遲，涵蓋客戶端預測、伺服器校驗，延遲補償等多種技術。


田桑拿虛幻引擎舉了個例子：“DS 結構下，引擎是帶到伺服器上執行的，客戶端渲染相關的部分被剝離出來了，執行的是物理、AI 等純邏輯。由於伺服器能執行物理計算，所以聯網遊戲可以做到物理的同步，就可以實現很真實的遊戲體驗。”

在虛幻引擎的 DS 下，伺服器便承擔了計算碰撞同步的任務，例如判定武器有沒有命中，環境爆炸產生的碎片軌跡這些東西。而且角色的 AI 行為樹同步也依賴 DS，所以伺服器會高頻率地處理狀態，負載非常大。這導致 DS 架構雖然有著支援高保真度遊戲的優點，同樣也具備高消耗、低承載的缺點。

一個典型例子是《光環5》的戰區模式。這個用到 DS 架構的模式，支援的最大玩家數是 24 人，而且對於 AI、載體和目標的數量都有相應限制，原因正是要確保不會超過伺服器的承載量。為此開發團隊簡化了 AI 邏輯，因此在戰區模式下 NPC 會顯得比戰役中的要“蠢”。


如果延續 C/S 架構下的擴容思路，玩家們可能會感到困惑 —— 一臺伺服器負載太高，你加幾臺伺服器不就完事了麼？

然而，DS 架構在這一點上還受限於遊戲引擎：

Epic 有一段時間為了《堡壘之夜》能支援 100 人共鬥絞盡腦汁，對虛幻引擎做了不少優化。比如在跳傘降落的過程中，主動降低遠端呼叫所需要的頻寬；又比如限制客戶端向伺服器傳送移動更新的頻率，避免因為客戶端幀率過高，最終導致伺服器過度負載。


Epic 曾提到過一個觀點，既然一家公司都要做大型 MMO 了，那肯定有自己獨特的要求和後端解決方案，依樣畫葫蘆地照搬他們的 DS 不太適合，虛幻本身去研究擴容的事情可能會比較雞肋，鼓勵開發者基於這項技術自己想辦法。

而主要邏輯是單執行緒執行的 Unity，其實或多或少也和虛幻引擎一樣需要面臨同樣的問題。

做個幾萬人的《荒野大鏢客》有沒有可能

從上面兩個部分的論述來看，不難發現如今線上多人遊戲面臨一個兩難的局面。要麼就沿用傳統 C/S，自己寫後端，以降低保真度為代價追求規模；要麼就拿 DS 架構辦事，縮小規模，提高保真度。

但有沒有辦法將它們融合起來呢？其實很多開發團隊都在思考這個問題。

市面上有著這樣特性的產品不多，“褒貶不一”的海盜冒險多人遊戲《ATLAS》勉強算一個。拋開產品品質的問題，《ATLAS》用的就是 DS 架構，而且“理論上”支援 40000 名玩家同時遊玩。


他們的做法，是在 DS 外自己寫了世界伺服器和資料伺服器的後端。先把多個 DS 例項給拼起來，再由世界伺服器統一負責管理 —— 比如只要玩家過地圖，就把玩家的資料搬到另一臺伺服器。其實可以類比成《魔獸世界》的“空間分割法”，當然明顯能夠看出技術不怎麼成熟，Steam 上負面評價最多的地方就是“卡”和“連不上”。

英礴本來也打算打造一個龐大的、高保真度的遊戲世界，結果發現技術方面都是坑。於是乾脆先把 DS 的問題捋清，降低日後遊戲製作的門檻和風險，因此催生出了一個解決方案（工具）：SpatialOS。

SpatialOS 是一個基於底層公有云資源的遊戲開發環境。它一方面會給你提供雲端的伺服器託管，一方面給予技術支援，類似於一個多功能外掛。這個工具可以很簡單的接入虛幻和 Unity 引擎，甚至任何其他的第三方引擎，它主要提供在 DS 架構下擴充多人遊戲規模的手段。


其中一個擴容思路和《ATLAS》有點像，如果一個 DS 不夠用，就把多個 DS 拼接起來統一管控。因為 SpatialOS 虛幻開發套件的方向就是走多程式，這樣更容易利用多核甚至多機器的計算資源，可以突破傳統 DS 的限制 —— 簡而言之就是給遊戲加伺服器有用了。

上面這段話有點繞，直接看“把 DS 拼起來”的示例圖更加直觀。下圖中 9 個方塊代表 9 個 DS，每個遊戲伺服器的管轄區域分別由不同顏色代表，玩家不僅可以無縫跨越伺服器邊界，也能和不同區域的其它玩家互動。



據田桑解釋，這背後的祕密是 9 個 DS 之上有一個“網路層”，它才真正負責所有遊戲狀態的管理。一個 DS 是一個區，通過這個管理層將所有區彌合起來。客戶端連到這個管理層，而不是所有的 DS 之上。


說到分層這個概念，SpatialOS 中還有項名為“AI 負載拆分”的功能，正好能解決前文《光環5》戰區模式的問題。理論是，如果把 AI 的負載扔到另一個伺服器，那不就為玩家擴容騰出空間了嗎，而且還不必讓 NPC 變“蠢”，可謂一舉兩得。

這種方法可以採取的應用很廣，對延遲要求不高，和核心繫統（如物理）耦合度不高的東西都可以拆分出來，比如天氣系統。分出來的層，則基於雲放到另一臺虛擬機器上。

英礴本身做了一些實驗，使用原生虛幻引擎的情況下，在已有 100 名玩家的基礎上最多可以執行 229 個 AI；而將 AI 負載扔到另一個伺服器後，維持相同伺服器幀率的前提下 AI 數量可以達到 479 個，相當於擴容了一倍。

目前正在測試的冒險生存遊戲《拾荒者》（Scavengers），剛好就採用了 AI 負載拆分的技術。開發商 Midwinter Entertainment 表示玩家會在遊戲中遭遇極端天氣、怪物肆虐，外來入侵者以及敵對玩家團隊等各方面的威脅。而 AI 負載拆分使得他們在 3x3 公里的地圖內，一方面保證了這些高保真度的體驗，一方面又實現了“60 名玩家+300 個 AI”的規模。


當然，儘管分層看起來很牛逼，但銀彈卻是不存在的，田桑舉了個例子：


所以，要想在 DS 架構下把玩家的規模擴大，得綜合多種方法。SpatialOS 實際上還有一套名為 QBI 的系統，可以自定義降低同步頻率，解決一些網路負載的問題。比如其中一個表現就是令距離玩家較近的活動物體看起來更順暢，越遠“越卡”，主要是看開發者如何發揮想象。


正如之前提到的技術限制，MMORPG 人數規模很大，可以達到幾千上萬人，但基本集中在社交、打怪，或者是副本的互動方式，很少見到有真實的物理模擬。另外一個方向是像《堡壘之夜》《方舟：生存進化》這樣的遊戲，它們有些地方做得很細緻，但人數又容易碰到瓶頸，通常就是房間制的。

由此引申到能不能做“容納幾萬人的《荒野大鏢客：救贖2》”的問題，田桑認為理論上是可行的，只是還沒有開發者觸及到這根線。而且即使解決了技術問題後，話題就又回到了無法迴避的開發風險和成本。

不過，未來這兩種需求應該會交匯到一起，使得線上多人遊戲在現今的標準上再進一步：一方面能支援更多玩家，一方面又能保證更真實的模擬。至少有人目前正在朝著這個方向努力，或許再過不久，有著高保真度的大型多人線上遊戲就不再僅僅停留在幻想中。

作者：箱子
來源：VGtime
地址：https://www.vgtime.com/topic/1095188.jhtml