在今年的 Unite 大會上，騰訊天美技術專家田亞濤和 Unity 中國的軟件工程師司天語為大家?guī)砹恕逗辖饛楊^：覺醒》項目的客戶端與服務端一體化方案，其中包括 DS 專用服務器進程彈性啟動、多房間管理及高性能連接能力等。

田亞濤：大家好，我是來自天美 J1 工作室的田亞濤。首先感謝團結引擎團隊對我們技術方案的認可，也非常高興能在此與大家交流我們的實踐經驗。

我自 2014 年加入騰訊以來，先后完整參與了《魂斗羅：歸來》與《合金彈頭：覺醒》的研發(fā)工作，長期專注于 GamePlay 體系、實時聯(lián)機同步以及 DS（Dedicated Server）架構相關的研發(fā)與優(yōu)化。《合金彈頭：覺醒》作為一款 2023 年上線的橫版射擊手游，目前已在國內與多個海外地區(qū)穩(wěn)定運營。

本次分享將重點介紹兩個方向：網絡同步框架以及基于 Unity 的 DS 引擎架構優(yōu)化。在《魂斗羅：歸來》時期，我們探索并沉淀了一套基于 Unity 引擎的前后端一體化技術體系，而在《合金彈頭：覺醒》中，我們在此基礎上進一步迭代，對多項關鍵技術進行了系統(tǒng)化打磨與演進。

公平精準的網絡同步框架

對于《合金彈頭：覺醒》，我之所以在前面特別強調橫版射擊，是因為與第一人稱或第三人稱射擊不同，橫版射擊的子彈飛行路徑和命中過程對玩家是完全可見的，命中是否準確非常直觀。因此，只要畫面表現(xiàn)與最終傷害結果出現(xiàn)任何不一致，玩家都會立即察覺。在第一人稱或第三人稱射擊中，受擊反饋多以閃紅等效果呈現(xiàn)，彈道細節(jié)并不會完全暴露，所以玩家對命中精度的敏感度沒有這么高；但在橫版射擊中，這種差異被無限放大。

也正因為如此，早期常用的“攻擊者優(yōu)先、服務器權威”機制在《合金彈頭：覺醒》中難以直接落地，會出現(xiàn)“看似沒有被擊中卻掉血”或“明明命中卻沒有傷害”的情況，讓玩家誤以為是外掛或者同步異常。在研發(fā)的整個過程中，我們在聯(lián)機相關（包括 DS）的部分投入了大量時間，希望在網絡環(huán)境不可控的前提下，盡可能在“實時性”和“一致性”之間找到平衡，讓玩家看到的畫面與游戲真實的判定盡可能一致，也就是實現(xiàn)我們一直追求的“所見即所得”。

要解決“同步”問題，首先必須具備一套可靠且高性能的網絡基礎設施，這是整個聯(lián)機技術的第一層能力。我們需要一個高效的網絡中間件，它的核心職責是承載數(shù)據(jù)傳輸，既要支持可靠的 UDP 通道，也要支持非可靠的 UDP 通道，以滿足不同類型同步數(shù)據(jù)對實時性和可靠性的要求。在此基礎上，我們在聯(lián)機框架層提供了 RPC 與狀態(tài)同步兩套能力，使上層邏輯能夠在統(tǒng)一的通信抽象下完成指令發(fā)送、狀態(tài)更新和關鍵事件傳遞，為后續(xù)所有同步機制提供一致而可靠的通信支持。

對于《合金彈頭：覺醒》這類高實時性的同步游戲而言，每秒 30 次的同步頻率對帶寬要求非常高。在帶寬優(yōu)化上，除了常規(guī)處理，我們也針對同步內容本身做了細致打磨，包括數(shù)據(jù)類型定制、浮點精度控制以及差異化更新等。同時，在策略層面，我們結合對象池與緩沖機制，并在 MTU 自適應、合包和批量發(fā)送等方面進行了優(yōu)化，以盡量降低同步成本并提高傳輸效率。

在帶寬優(yōu)化之后，我們進一步處理流量優(yōu)化。在壓縮和增量同步之外，我們希望將整體流量控制在可接受的量級上。為此，除了歷史記錄緩存，我們也結合序列號機制，并基于客戶端與網絡實際情況做了一些定制化策略，使整體流量的增長趨勢更可控，也更符合我們的預期。

游戲中也大量使用了輸入緩存和命令隊列，這類邏輯由于觸發(fā)頻率極高，對 GC 的敏感度非常強。如果在這些高頻路徑上出現(xiàn)額外分配，就會加速觸發(fā) GC，從而導致主線程暫停，直接影響實時聯(lián)機體驗。為此，我們針對這些模塊進行了優(yōu)化，將無謂分配盡量壓縮甚至消除，以在同步過程中盡可能減少 GC 對客戶端流暢度的影響。

有了前面的優(yōu)化，所有數(shù)據(jù)與策略本身也需要被有效監(jiān)控。因此，我們在研發(fā)階段和外網環(huán)境中都建立了一套完整的監(jiān)控體系，用來確保網絡質量與實際體驗始終符合預期。同時，這些監(jiān)控結果也為后續(xù)的動態(tài)調整提供了可靠的數(shù)據(jù)依據(jù)，使我們能夠更及時地評估網絡表現(xiàn)并進行針對性優(yōu)化。

在此之外，我們還設計了自適應網絡能力，會根據(jù)前面提到的策略與實時監(jiān)控數(shù)據(jù)，動態(tài)選擇更適合當前網絡狀況的同步方案。無論是在影子跟隨還是航位推測等模式下，系統(tǒng)都會優(yōu)先保證玩家在不同網絡質量下都能獲得盡可能平滑的體驗。

講完網絡層，我們再看同步框架層面。項目在立項階段首先完成了邏輯和表現(xiàn)的分離，這不是傳統(tǒng)的 UI MVC，而是將一個 Game Object 拆分為邏輯體和表現(xiàn)體：邏輯體用于處理追幀、各種同步拉扯等核心邏輯，而表現(xiàn)體在動畫、特效等層面保留更高的平滑性和表現(xiàn)靈活度?；谶@樣統(tǒng)一的邏輯層，我們在同步模式上采用了幀同步與狀態(tài)同步的融合方案，并結合早期《魂斗羅：歸來》的經驗以及單機、聯(lián)機都在 Unity 上統(tǒng)一研發(fā)的優(yōu)勢，使整體同步結構更清晰、更一致。在此基礎上，我們從對時模式轉向多端對幀，讓所有端共享一致的幀號，使后續(xù)的同步行為與策略調整都能以統(tǒng)一幀號為依據(jù)。

接下來，看一下角色同步。對于這樣一款高實時性的同步游戲而言，手感始終是第一優(yōu)先級，《合金彈頭：覺醒》也采用了客戶端先行的方式。這里的 1P 指本地玩家自身；2P 指服務器或 DS；3P 則是我所看到的其他玩家?；玖鞒淌潜镜叵葓?zhí)行移動，同時同步地向服務器發(fā)送移動指令；服務器在收到后會進行校驗，如果校驗不通過，會下發(fā)糾正并觸發(fā)相應的拉扯。對于 3P 來說，表現(xiàn)更多是基于服務器下發(fā)的緩存數(shù)據(jù)，再通過平滑插值來重建對方的移動軌跡。但由于是橫版射擊，3P 的畫面本質上看到的仍然是一定程度的歷史位置，因此我們也會做一定程度的預測補償，讓對方角色的表現(xiàn)盡量接近實時。

前面提到有預測就一定會有預測失敗的情況，那失敗該怎么處理呢？如果只是簡單地把本地移動包發(fā)給 DS，由 DS 檢測到不一致后直接把角色位置拉回到服務器認為的正確位置，那在玩家這邊就會出現(xiàn)很強的“瞬間被拽回去”的感覺：前一刻一系列操作都很流暢，下一刻因為收到的是一幀稍晚的服務器確認（相對本地來說是歷史狀態(tài)），整個人突然被拉回原位置，體驗會非常割裂。我們的做法是先回滾到出錯時刻對應的狀態(tài)，再基于那一刻之后的輸入記錄做一次前滾重放，讓角色按正確的軌跡重新跑一遍，使得在玩家視角下動作依然連貫。比如說，角色原本在地面奔跑，隨后觸發(fā)一次跳躍，如果 DS 發(fā)現(xiàn)其中存在偏差并做了輕微糾正，本地會先回到糾正后的狀態(tài)，再重新模擬奔跑到起跳的過程，最終在畫面上仍然看到的是出現(xiàn)在正確位置上的那次跳躍，而不會出現(xiàn)突兀的拉扯感。

接下來是命中校驗。在開始之前，先對《合金彈頭：覺醒》中的子彈做一個簡單介紹，共分為三類：第一類是 Hit-Scan（快速子彈）；第二類是 Projectile（帶彈道、帶軌跡）；第三類則是前兩類特性的結合。針對不同類型，我們會采用不同的命中與同步策略。以第一類快速子彈為例，在實際玩法中，無論子彈速度多快，只要玩家在畫面上成功躲開，就會自然認為自己不應該被擊中，因此命中并不是在“開槍瞬間”就能直接判定的，這其中涉及的處理邏輯非常多。為了優(yōu)先保證本地體驗，快速子彈在本地命中時會立即給出反饋，同時將命中事件上報服務器，由服務器校驗后再下發(fā)最終傷害結果。而對于另外兩類子彈，通常由服務器直接進行命中判斷并下發(fā)傷害。因此，在很長一段時間里，我們命中相關的技術優(yōu)化主要圍繞快速子彈展開，目標是讓其在高實時性的前提下做到準確、可信，并具備足夠的反外掛能力。

為什么我們會強調第一類快速子彈是“彈道”，而不是“彈幕”？原因在于它雖然速度很快，但仍然是以逐幀的方式在飛行。同時，在飛行過程中，它還會根據(jù)實時狀態(tài)進行邏輯判斷，例如命中的目標是否已死亡，從而決定是否繼續(xù)穿透、穿透次數(shù)，以及是否需要分裂、分裂成什么類型的子彈。因此，看似簡單的快速子彈，實際在邏輯上是非常重的。針對這種情況，我們采用的是客戶端命中上報，再由 DS 校驗的方式。那如何防外掛呢？在這里我們引入了一套“影子快照（Shadow Snapshot）”技術。它的含義是：DS 不僅在命中瞬間做歷史校驗，而是會在整個子彈飛行過程中持續(xù)采集行為數(shù)據(jù)。有了這些影子快照，DS 就可以在自己的視角下確保這些行為鏈路是可控且可信的，并在客戶端上報命中時進行二次校驗。

在反外掛層面，基于前面已經構建的一系列能力，我們會從三層來處理反外掛問題。首先是在框架層，服務器本身具備絕對權威，可以確保關鍵邏輯不會被客戶端篡改；其次是在校驗層，我們通過“影子快照”以及多種狀態(tài)檢查與記錄機制，對行為鏈路進行持續(xù)驗證；最后是在監(jiān)控層，我們會對異常行為進行監(jiān)測，包括異常加速、異常頻率發(fā)包等模式。通過這三層的協(xié)同，基本能夠覆蓋大部分外掛風險點并確保整體的安全性。

前面的內容講完之后，不可避免地會提到“同步”層面的效率問題。在實際研發(fā)中，我們經常會處理聯(lián)機調試、內外網異常定位等情況，因此我們認為聯(lián)機調試工具本身同樣至關重要。為此，我們在多個維度上構建了相應的模擬與調試能力，用來復現(xiàn)和分析各種網絡狀態(tài)，從而更有效地優(yōu)化整體的網絡體驗。

最后做一個簡單總結：從底層通信能力，到預測、回滾、補償，再到帶寬優(yōu)化和反外掛，構建了一套公平且精準的網絡同步框架。

基于 Unity 引擎的 DS 架構

下圖展示了構建 Unity DS 的一個簡單參考。為什么選擇 Unity 來做 DS?優(yōu)勢非常明顯：一方面前后端邏輯可以直接復用，減少了重復開發(fā)；另一方面，后臺邏輯中有大量場景需要依賴物理系統(tǒng)，Unity 自帶的物理能力讓前后端能夠以更一致的方式處理相關邏輯，從而形成一套更連貫、成本更低的方案。

在實際開發(fā)過程中，除了前面提到的“邏輯與表現(xiàn)分離”之外，我們在資源和功能層面也盡可能做到前后端統(tǒng)一，一套開發(fā)同時滿足兩端需求，使整體流程更加簡潔高效。

在研發(fā)效率層面，下方圖中的左上部分展示了我們在實際開發(fā)過程中所使用的 DS 視圖，在其中可以直接看到前端與后臺的運行狀態(tài)，這對于暫停、回溯以及日常調試都非常有幫助。右下部分則展示了我們在版本體驗階段的另一種用法：在手機上游玩時一旦發(fā)現(xiàn)聯(lián)機問題，可以很輕松地將這一局接入本地 DS，并直接在編輯器中以 DS 視角進行調試。這套研發(fā)效率體系在項目過程中發(fā)揮了重要作用，特別是對于《合金彈頭：覺醒》這樣一款內容量較大的游戲，使我們能夠更高效地構建和驗證大量關卡內容。

既然《合金彈頭：覺醒》是一款內容型游戲，那么對應的后臺 DS 負擔也會隨之變重，特別是在內存占用和整體資源壓力方面。項目早期我們做過一輪引擎瘦身和常規(guī)優(yōu)化，但當這些手段都用到位之后，可繼續(xù)優(yōu)化的空間已經非常有限，而內容量卻還在持續(xù)增長。從后臺的視角來看，為避免運行時加載帶來的卡頓，很多情況下 DS 在啟動時就需要一次性加載全部內容，這也進一步加大了資源層面的壓力。

于是我們繼續(xù)深入分析。當時原始的 Unity 引擎模型是：一個進程對應一個實例、一個實例對應一場戰(zhàn)斗，這意味著許多基礎開銷，包括我們自有的對象池，都是獨占的。對于一些只需要“一名玩家 +AI”的輕量玩法來說，這種模式在資源利用上實際上相當奢侈，因為它會為這樣的小場景跑起一個完整的進程。那么接下來該怎么辦？我們當時有兩條思路：第一是做共享內存，第二是做多房間。共享內存的方案在調研后發(fā)現(xiàn)實現(xiàn)成本較高，因此最終我們選擇了多房間的方向。

改造的目標是什么呢？在之前的項目中，我們的做法是左圖那種模式：一個進程跑完一場戰(zhàn)斗后做一次 Reset，然后再串行復用這個進程。在《合金彈頭：覺醒》中，我們希望能進一步提升這一模式，向右圖那樣的架構發(fā)展——也就是讓底層的基礎消耗（包括各類對象池和資源）保持共用，然后在其之上創(chuàng)建多個房間并行運行。這里需要解決的關鍵問題在于：多個房間、多個 Level 如何同時存在，并且彼此之間保持完全隔離。換句話說，從 DS 的視角看，即便它們位于同一個坐標系下，各房間之間也必須做到互不干擾。

早期我們評估過三種方案：空間分割、場景疊加以及邏輯 Room?？紤]到《合金彈頭：覺醒》在早期本身就是大世界結構，坐標體系依賴偏移來實現(xiàn)，如果繼續(xù)采用前兩種方案，隨著時間推移不僅會引發(fā)坐標精度的問題，整體復雜度也會大幅提升。因此最終我們選擇了第三種方案，即基于邏輯 Room 的方式來實現(xiàn)多房間并存。

要實現(xiàn)多房間完全并存，我們需要做到“三大隔離”。第一是引擎內置對象的隔離；第二是物理層的改造與隔離；第三是邏輯狀態(tài)的隔離。由于開始進行這些改造時項目內容量已經相當龐大，這三類隔離在落地過程中大部分都屬于工程層面的實際挑戰(zhàn)，因此整體投入了相當多的時間來完成。

在完成改造之后，從DS的視角來看，我們希望整個系統(tǒng)能夠以統(tǒng)一的方式驅動更新。有了 Room 的概念之后，我們內部把整體結構稱為“大樓”，便于理解：一棟大樓里包含多個房間，由 RoomManager 來統(tǒng)一Tick各個房間。那么，一個進程應當承載多少房間才合適？我們主要從幾個角度來評估：第一，希望在 30 幀的更新頻率下能夠穩(wěn)定地完成所有房間的 Tick；第二，從穩(wěn)定性出發(fā)，盡量避免單個房間出現(xiàn)異常時影響到整棟大樓；第三，需要結合 CPU 與內存的占用比例，尋找一個進程可承載房間數(shù)量的合理平衡點。

下方的視頻展示了改造后的一個簡單效果。從后臺視角可以看到，房間是可以直接動態(tài)新增的，同一個 DS 進程中也能夠不斷創(chuàng)建新的房間。左側則展示了兩個獨立運行的客戶端，它們之間完全隔離、互不影響，由此也能初步驗證我們的多房間方案達到了預期目標。

以 10 個房間為規(guī)模進行 DS 架構改造后，我們總結的收獲大致如視頻所示。實際上線外網后，我們又根據(jù)不同玩法在資源占用上的差異進行了多輪調整。最終外網的大多數(shù)玩法穩(wěn)定在約 15 個房間的配置下運行，而部分資源較重或流程特殊的玩法則會動態(tài)調整為 10 個房間甚至 5 個房間，以確保資源使用保持在合理范圍內。目前這套多房間方案已經穩(wěn)定運行于國內與海外的正式環(huán)境中。

完成了 DS 的多房間優(yōu)化后，隨著游戲持續(xù)運營、內容規(guī)模不斷擴大，我們又遇到了新的問題：即便在“大樓”架構下實現(xiàn)了資源復用，同一進程的整體內存占用依然偏高。從后臺數(shù)據(jù)以及海外機型分布來看，部分場景已經出現(xiàn)了明顯的內存瓶頸，因此我們需要進一步進行內存層面的優(yōu)化。另一個問題是啟動時間過長。前面提到，服務器的進程通常會提前拉起，但由于內容量不斷積累，線上環(huán)境中一個進程的拉起時間已經達到 45 秒到 1 分鐘，這對于后臺的資源調度效率而言是明顯偏慢的。

基于這兩個問題，我們也調研了 Fork 方案。Fork 本身并不復雜，但與 Unity 結合在當時確實存在一定挑戰(zhàn)，原理這里就不展開了。預期收益主要有兩點：一是希望在“大樓”之間進一步復用內存；二是在進程拉起階段能夠更快啟動，并減少 CPU 的毛刺開銷。那么在改造過程中，我們具體做了哪些事情呢？

下圖左側列出了我們認為較為關鍵的改造點，包括引擎 I/O 的重定向、I/O 管理與業(yè)務側的配套調整，以及線程層面的裁減和網絡層的多路復用。右側則展示了我們在評估方案時重點考慮的問題——也就是選擇在何時進行 Fork 才是最合適、最穩(wěn)定的時機。

下圖展示了我們在引入 Fork 后獲得的收益。可以看到，F(xiàn)ork 之后的內存占用下降得非常明顯；在進程拉起方面，原本需要 45 秒到 1 分鐘的啟動時間，使用 Fork 生成子進程后基本能夠縮短到毫秒級。隨著這一優(yōu)化落地，服務器的整體資源成本也隨之顯著下降。

完成上述改造后，我們在后臺 DS 的開發(fā)過程中也經常需要進行大量性能測試。有些測試場景動輒要幾十個房間，僅依靠人工很難構建和復現(xiàn)。因此，我們在這一層面也做了相應的自動化能力，包括在 DS 性能出現(xiàn)問題時，能夠快速觸發(fā)并復現(xiàn)相關場景。通過這套方案，只需執(zhí)行一條指令，就能在 10 分鐘內完成一輪完整的數(shù)據(jù)采集，并在右側所示的分析工具中基于各模塊輸出清晰的耗時分布。

下方的視頻展示了我們在測試過程，能夠在本地編輯中直接看到在整個測試階段發(fā)生的具體情況，幫助我們更直觀地了解各項表現(xiàn)并定位可能的問題。

以上就是對這兩個方案的介紹。我們在項目中的探索最終沉淀為一套完整且經過線上驗證的解決方案，不僅支撐了我們的自身項目，也即將通過團結引擎服務于更多開發(fā)者。關于這項技術如何進一步融入團結引擎并開啟新的可能，下面有請團結引擎的技術同學司天語為大家揭曉。謝謝大家！

團結引擎 DS 聯(lián)機方案

司天語：感謝亞濤精彩的分享！接下來，由我跟大家講一講這套方案如何融入團結引擎，如何讓各位開發(fā)者今天不僅僅是來聽一場技術方案的分享，也是可以真實的把這一套方案運用到自己的游戲上去。我是來自于 Unity 中國底層架構組的軟件工程師司天語。我們之所以會選擇使用這套聯(lián)機方案融入到引擎，最重要的是看中這一套框架成熟。如果一套框架沒有經過大量線上游戲的驗證，也沒有經歷過大規(guī)模的實踐檢驗，我們是沒有足夠的信心向開發(fā)者去推薦這套框架和技術的。

如今不管是穩(wěn)定性、功能性還是性能，各個方面都已經非常成熟。因此在騰訊天美 J1 工作室的框架方案基礎上，團結引擎進行了代碼編寫，一起將它從“專用”打造成“通用”網絡 DS 連接框架帶給開發(fā)者們。既然這套框架已經非常成熟了，那么我接下來講一下團結引擎會做些什么？我們在引擎中會使用更高性能的 C++ 來實現(xiàn)這套框架的內核，相比于純 C# 的實現(xiàn)，我們可以預見會有進一步的性能提升。同時，我們也會繼續(xù)優(yōu)化這一套框架，對一些復雜模塊進行解耦和重新封裝，并且會設計一套簡潔明了、易拓展的接口供開發(fā)者調用。我們會努力將這套框架變成更強大、更通用、更易用的產品。

說完了高性能的設計理念，在這個 feature 上面，我們還有另外一個思路，就是 All In One。一直我們都會思考：“哪些功能應該引擎去做，哪些功能應該讓開發(fā)者自己去寫業(yè)務代碼？”一直以來我們在引擎的研發(fā)過程中都會去思考，哪些功能應該去引擎去做，哪些功能又應該讓開發(fā)者自己去寫業(yè)務代碼。

一直以來團結引擎都保持著盡量只做引擎該做的事情，這就使得團結引擎是非常精簡、高性能且高拓展的一個引擎。在這個 feature 上面，我們希望引擎可以盡可能做更多的事情。不僅是 DS 框架會下沉到引擎當中，同時我們也會將更多的業(yè)務核心的邏輯也封裝成組件，下沉為引擎的能力。我們希望可以給開發(fā)者帶來真正“開箱即用”的體驗。除此之外，剛才亞濤剛才提到了關于分析 ping 值、ds 幀率、模擬斷線、弱網模擬、軌跡校對、預測、插值等一系列的 Debugger 和 Profiler 工具。我們都會集成進引擎，而且會在部分分析工具中提供引擎源碼級別的更加深入到引擎層面的分析能力。這些工具我們也都會內置的引擎當中，同時在部分工具（如果可以的話），我們還會提供引擎原碼級別更加深入到引擎底層的一些分析和調試的能力。

我們框架會做到或者說我們希望幫助開發(fā)者做到的就是降低成本，這是所有項目在開發(fā)過程中都非常關心的問題。為了盡可能地榨干服務器的性能、避免造成浪費，這套方案在服務器高承載方面也做了很多的創(chuàng)新。一臺 Linux 服務器先是通過 DSA 拉起“種子進程”，然后再 Fork 出多個 DS 進程，然后每個 DS 進程又可以并行地運行多個房間支撐起很多個對局，這就可以讓我們盡可能榨干一臺服務器的性能，以達到降低服務器的成本。其次，這套框架還會幫助項目降低開發(fā)成本。首先，該框架前后端會使用同一套邏輯，既保證一致性，也大大減輕邏輯開發(fā)的負擔。接著就是剛才提到的，我們會將多數(shù)項目都有可能用到的核心功能、核心業(yè)務邏輯都組件化封裝，然后常用的功能都會有官方提供的組件，大家不用再去造輪子、重復地去進行開發(fā)。同時，我們也會給出完整的功能、詳細的文檔，并且會積極地建設社區(qū)的專題，讓大家可以快速地和研發(fā)人員面對面的交流問答，并且我們也會長期維護這套聯(lián)機方案。

最后，我們希望和天美 J1 工作室，一起共同將這套方案盡可能地打造為迄今為止團結引擎上最全面、最豐富、最完整的通用 DS 聯(lián)機框架。我們會在 2026 年的上半年帶著這套框架與各位開發(fā)者見面，敬請期待。謝謝大家！

Unity 官方微信

第一時間了解Unity引擎動向，學習進階開發(fā)技能

每一個“點贊”、“在看”，都是我們前進的動力