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

田亞濤：大家好，我是來自天美 J1 工作室的田亞濤。首先感謝團(tuán)結(jié)引擎團(tuán)隊對我們技術(shù)方案的認(rèn)可，也非常高興能在此與大家交流我們的實踐經(jīng)驗。

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

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

公平精準(zhǔn)的網(wǎng)絡(luò)同步框架

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

基于 Unity 引擎的 DS 架構(gòu)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

團(tuán)結(jié)引擎 DS 聯(lián)機(jī)方案

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

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

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

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

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

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

Unity 官方微信

第一時間了解Unity引擎動向，學(xué)習(xí)進(jìn)階開發(fā)技能

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