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

　　剝離設計和玩法，讓我們從技術的角度解析這個問題。

　　多人遊戲的規模，一直是個讓人捉摸不透的問題。從 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 人。

　　當然，那個年代《子午線59》的同屏人數已經足夠震撼了

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

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

　　從名字就能看出來，C/S 最早是兩層結構，客戶機也就是玩家電腦(主機)負責渲染，服務器處理遊戲邏輯。後來又加了一層"數據庫"，搭載了用于保存遊戲結果的存儲器，估計也不用做太多科普。

　　一個典型的 C/S 架構交互

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

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

　　《黑色沙漠》在 MMORPG 裡的保真度算是不錯，但相比單人遊戲還是差了一截

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

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

　　突然冒出來這麼多人，在線多人遊戲的圖像具有不可預測性

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

　　最常見的就是"空間分割法"，即把遊戲中的地理(地圖)進行分割，逐一分配給不同的服務器進程或者設備。

　　空間分割法

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

　　空間複制法

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

　　"市場喜好抛開不說。MMORPG 的技術門檻就要比 DS 高。UE 的 DS 我個人覺得就是一個非常棒的産品，像做《方舟：生存進化》的，還有其它很多工作室，他們沒有多少後端積累，就可以把遊戲做到那個量級。"

　　而這裡提到的 DS(Dedicated Server，專用服務器)，不僅是當下很多主流在線多人遊戲都會使用的技術，也恰好能夠解答"為什麼「吃雞」的玩家得是 100 人"的問題(當然DS和C/S不是同一類概念)。

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

　　首先得聲明 100 人隻是個數量級，并非锱铢必究的數字。

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

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

　　《GTA5》的戰局也是一個 DS

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

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

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

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

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

　　"虛幻引擎的主要邏輯是單線程運行，如果把服務器的主頻性能，比如從 16 核變成 32 核，能夠負載的人數其實是不能增加的。而且就算從一台機器增加到兩台機器，可容納的玩家數量也不會變化，因為有一個技術架構的限制……至于增加核心數有沒有用，這個還要看引擎本身是否支持多線程擴展。"

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

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

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

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

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

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

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

　　《ATLAS》

　　他們的做法，是在 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"的規模。

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

　　"假設 A1 區域有 10000 人，負載不下了。那要麼把 A1 切成 A1 和 A2，分别放 5000 人，也可能是在 A1 上面再加一層，這都是開發者自己去控制的。但是這個事情會帶來成本，因為兩個區間之間有大量通信，要靠服務器硬件來堆。

　　比如一個服務器要從 1000 人擴容到 3000 人，那就分三層……如果每層額外帶來的性能損耗是 50%，每一層實際隻能跑 500 人，三層隻有 1500 人。那你又得多分幾層，這時候的損耗可能又不止 50% 了。"

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

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

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

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