《王者榮耀》能夠成為如今國(guó)內(nèi)最成功的手游，其后方成熟的技術(shù)團(tuán)隊(duì)可以說是功不可沒。這個(gè)曾經(jīng)在端游時(shí)代主導(dǎo)搭建RTS游戲《霸三國(guó)》框架的技術(shù)團(tuán)隊(duì)，在轉(zhuǎn)型做MOBA手游《王者榮耀》后為游戲提供了巨大的支持。但這個(gè)過程也并非一帆風(fēng)順。

在今年剛結(jié)束的騰訊TGDC上，《王者榮耀》技術(shù)總監(jiān)孫勛在技術(shù)專場(chǎng)中，對(duì)這款游戲進(jìn)行了一次技術(shù)復(fù)盤，為聽眾嘉賓就從技術(shù)層面上講解了游戲在引擎、整體網(wǎng)絡(luò)架構(gòu)與網(wǎng)絡(luò)同步方案上的嘗試與轉(zhuǎn)變。

孫勛稱，目前游戲的服務(wù)器架構(gòu)主要由“游戲大廳”和“PvP”2個(gè)部分組成，而在不斷探索中，其后來又在架構(gòu)中加入了Proxy中轉(zhuǎn)服務(wù)器，也正是這個(gè)服務(wù)器的加入為《王者榮耀》解決了后來“安卓、iOS”同服等一系列出現(xiàn)的問題。

此外，他還介紹了《王者榮耀》在網(wǎng)絡(luò)協(xié)議以及同步方案上的一些嘗試，并一一復(fù)盤了這些嘗試的優(yōu)劣勢(shì)，并解答了為什么，最終游戲會(huì)放棄TCP協(xié)議（傳輸控制協(xié)議）與曾經(jīng)在《霸三國(guó)》中所使用的CLIENT-SERVER結(jié)構(gòu)（C/S結(jié)構(gòu)），并且轉(zhuǎn)而使用了UDP協(xié)議（用戶數(shù)據(jù)報(bào)協(xié)議）與幀同步同步方案。

以下為會(huì)議速記整理：

大家好，今天由我?guī)怼锻跽邩s耀》后臺(tái)技術(shù)上面的分享。

我叫孫勛，是一名后臺(tái)開發(fā)程序員。2005年加入騰訊，最開始不是做游戲，2007年前一直做拍拍網(wǎng)，2007年加入成都臥龍工作室，也就是現(xiàn)在的天美L1工作室。之前參與過《QQ三國(guó)》、《封神記》、《霸三國(guó)OL》，到后來的《王者榮耀》，現(xiàn)在是這款游戲的技術(shù)總監(jiān)。

今天分幾部分和大家介紹王者后臺(tái)開發(fā)過程中的一些內(nèi)容和思考：包括《王者榮耀》整個(gè)背景介紹、后端架構(gòu)、上線后的調(diào)整，以及網(wǎng)絡(luò)同步方案和反作弊方案等。

現(xiàn)在《王者榮耀》后端機(jī)器大概有4600多臺(tái)，我們的容量也有一定的擴(kuò)展，進(jìn)程數(shù)目是4萬(wàn)多個(gè)。

《王者榮耀》游戲背景
?

2012年，我們當(dāng)時(shí)做的端游《霸三國(guó)OL》，就是王者的前身。這款產(chǎn)品最開始是偏向RTS的游戲，后來我們把它改成了端游MOBA，再后來做成了手游MOBA，即現(xiàn)在的《王者榮耀》。從2012年開始做RTS游戲到2013年，從多控制單位的RTS游戲，變成MOBA游戲，到2014年啟動(dòng)手游MOBA的預(yù)研，再到2015年2月份我們把大量人力（大概100多號(hào)人）投入做《英雄戰(zhàn)跡》（《王者榮耀》前身）開發(fā)，時(shí)間并不長(zhǎng)。

《霸三國(guó)》的玩法是玩家可以在戰(zhàn)前通過排兵布陣構(gòu)成自己局內(nèi)的策略，通過控制多個(gè)單位，技能釋放、兵種特性的釋放形成對(duì)抗。我們最開始做《霸三國(guó)》的時(shí)候客戶端引擎是unreal，但在做《王者榮耀》的時(shí)候改用了unity引擎，3到4個(gè)月的研發(fā)時(shí)間內(nèi)，產(chǎn)品本身從代碼層面沒有任何東西是從《霸三國(guó)》那里搬過來用的，全部代碼都需要重寫。

《霸三國(guó)OL》的一些啟示
?

做端游《霸三國(guó)OL》的這段經(jīng)歷，給我們做王者帶來很多相應(yīng)的啟示，比如策劃、程序及整個(gè)團(tuán)隊(duì)對(duì)MOBA的理解。另外當(dāng)時(shí)在做端游《霸三國(guó)》的時(shí)候，我們采用了CLIENT-SERVER的模式，但其實(shí)在過程中有借鑒類似幀同步的概念：例如在斷線重回對(duì)視野的處理這塊。

傳統(tǒng)的做法是，重回時(shí)會(huì)發(fā)當(dāng)前的鏡像和后續(xù)的其他下行通知信息。這種做法會(huì)有一個(gè)問題，如果新增其他的場(chǎng)景內(nèi)模塊的時(shí)候，根據(jù)場(chǎng)景內(nèi)包含的當(dāng)前的各種物件、所在狀態(tài)的各種各樣信息，都需要把這些東西打包發(fā)下去，在后續(xù)開發(fā)、維護(hù)的時(shí)候會(huì)顯得很麻煩。

我們的做法是，把服務(wù)器下發(fā)的所有序列包做緩存，并按順序重發(fā)，QQ買賣平臺(tái)讓客戶端做出快進(jìn)的表現(xiàn)，它的概念和幀同步比較類似。還有一點(diǎn)，就是預(yù)留設(shè)計(jì)彈性，在最開始的RTS中，每個(gè)玩家最多可以操作5-8個(gè)單位進(jìn)行對(duì)抗，到后來改成MOBA游戲，只能操作一個(gè)英雄，并且加入各種各樣的場(chǎng)景，我們本身的技術(shù)框架并不需要做出顛覆性的改動(dòng)。

整體架構(gòu)
?

《王者榮耀》目前后臺(tái)的整體架構(gòu)設(shè)計(jì)是源自產(chǎn)品的需求。如果大家玩過《王者榮耀》就會(huì)知道，PvP對(duì)抗是不分區(qū)服的。微信1區(qū)的玩家可以和微信2區(qū)玩家一起對(duì)抗，甚至iOS平臺(tái)也可以和Android平臺(tái)的人一起玩，但同時(shí)一些共地方也保留了分區(qū)概念，比如戰(zhàn)隊(duì)、排行榜是基于“區(qū)”概念的。“區(qū)”在游戲里面就是編號(hào)，可以理解為打在玩家新建角色上的Logo。

我們最開始做架構(gòu)實(shí)現(xiàn)的時(shí)候，服務(wù)器當(dāng)時(shí)做得比較簡(jiǎn)單，從原型開始只是保留了大廳和PvP服務(wù)器這兩塊，兩者是分開的。PvP服務(wù)器使用類似CGI調(diào)用，可以分配資源的使用，用完之后再回收，不負(fù)責(zé)其他的東西。需要的東西從大廳拿，用了之后回給大廳，讓大廳回寫DB。

我們?cè)诖髲d和PvP之間做直聯(lián)，后來把直聯(lián)改成了中間轉(zhuǎn)發(fā)，在《王者榮耀》里面我們叫Proxy，相當(dāng)于代理服務(wù)器，以屏蔽本身后端很多進(jìn)程分布的細(xì)節(jié)。因?yàn)橛螒虮旧淼臋C(jī)器、進(jìn)程很多，還有不同的路由規(guī)則。

某些排行榜或者戰(zhàn)隊(duì)是根據(jù)邏輯區(qū)的編號(hào)來確定哪臺(tái)機(jī)器，或者多臺(tái)機(jī)器進(jìn)行處理的。有些消息采用隨機(jī)轉(zhuǎn)發(fā)或者多發(fā)廣播的方式，這些都是由Proxy負(fù)責(zé)路由。之后又加入了房間服務(wù)器，它負(fù)責(zé)的是《王者榮耀》內(nèi)匹配、排位等相關(guān)功能，怎么樣把實(shí)力比較接近的人糅合到一塊兒玩，是由房間匹配服務(wù)器來做相應(yīng)的負(fù)責(zé)的，因此會(huì)有戰(zhàn)隊(duì)和其他服務(wù)器戰(zhàn)隊(duì)匹配到一起。

最后我們?cè)谏厦婕尤肓艘粋€(gè)Adapter，作用是用本身已經(jīng)部署的大區(qū)資源實(shí)現(xiàn)跨服匹配的功能。游戲的后端架構(gòu)，除了戰(zhàn)隊(duì)這樣的服務(wù)器之外，所有其他的模塊都可以在線擴(kuò)容，或者在發(fā)現(xiàn)引起在線下降的故障時(shí)，從整個(gè)架構(gòu)里自動(dòng)屏蔽掉。因?yàn)槁酚煞绞綍?huì)限定比如一區(qū)、二區(qū)、三區(qū)到這臺(tái)機(jī)器處理，如果故障，影響的只是某幾個(gè)邏輯區(qū)玩家請(qǐng)求的處理，降低故障影響范圍。

《王者榮耀》目前的機(jī)器數(shù)量，可能每周都會(huì)發(fā)現(xiàn)有機(jī)器壞掉，至少有一臺(tái)機(jī)器宕掉，在架構(gòu)里面保證模塊自動(dòng)屏蔽，和在線擴(kuò)容，是非常重要的事情。整體結(jié)構(gòu)比較像MMO的三層結(jié)構(gòu)，MMO在騰訊有比較典型的三層級(jí)別結(jié)構(gòu)。大廳服務(wù)器會(huì)根據(jù)玩家所在區(qū)，登錄具體區(qū)的大廳服務(wù)器。單個(gè)大廳進(jìn)程可以承載2萬(wàn)人，單個(gè)PvP可以承載1.2萬(wàn)，小區(qū)登錄微信一區(qū)還是二區(qū)就是角色Logo，打在玩家身上。

《王者榮耀》現(xiàn)在外網(wǎng)有四個(gè)大區(qū)，比如Android手Q、Android微信、iOS手Q、iOS微信，此外還有搶先服。我們會(huì)用程序開關(guān)的方式，在大版本發(fā)布之前，優(yōu)先更新?lián)屜确?#xff0c;這時(shí)候它不能和正式服玩家匹配在一起，因?yàn)樗麄兊陌姹静灰恢隆．?dāng)全服發(fā)布之后，它的版本更新一致之后，我們會(huì)打開開關(guān)，搶先服的玩家可以和正式服的玩家一起進(jìn)行PvP的匹配。

除此之外，我們還有專門的體驗(yàn)服，是給策劃驗(yàn)證相關(guān)設(shè)計(jì)的，體驗(yàn)服保留可能刪檔的操作，但在正式環(huán)境這是絕對(duì)不允許的。另外，以前的傳統(tǒng)手游偏單機(jī)，就會(huì)做很多協(xié)議兼容，客戶端版本沒有更新可以玩。但是《王者榮耀》里的主要玩法是PvP，同時(shí)結(jié)合實(shí)現(xiàn)方式，不同版本的玩家不能匹配一起，所以我們沒有做多版本協(xié)議兼容。

上線后的調(diào)整
?

上線后，《王者榮耀》本身的后臺(tái)架構(gòu)，整體上沒有做太大的改動(dòng)，因?yàn)槲覀冏龆擞蔚臅r(shí)候，對(duì)這套結(jié)構(gòu)比較清楚，我們知道哪個(gè)地方可能有什么樣的問題，所以整個(gè)結(jié)構(gòu)一直比較穩(wěn)定。

但是我們做了相應(yīng)的微調(diào)，做得最多的是網(wǎng)絡(luò)本身的優(yōu)化。《王者榮耀》上線的時(shí)候，市面上要求網(wǎng)絡(luò)及時(shí)性強(qiáng)的即時(shí)PvP游戲是比較少的。我們做了各種各樣的嘗試，比如在網(wǎng)絡(luò)做CPU方面的性能優(yōu)化、延遲、丟包等等，網(wǎng)絡(luò)本身花的時(shí)間是最多的。

架構(gòu)上的微調(diào)，像剛才提到的中轉(zhuǎn)模塊，我們架構(gòu)中大廳機(jī)器很多，PvP機(jī)器很多，架構(gòu)中不需要每個(gè)進(jìn)程知道詳細(xì)信息，比如大廳服務(wù)器不需要知道后面有多少房間服務(wù)器，只需要知道后面有房間服務(wù)器，可以訪問就OK。

怎么劃分、平衡負(fù)載、怎么屏蔽后端故障節(jié)點(diǎn)，都是由Proxy路由功能在負(fù)責(zé)。因?yàn)榇髲d、PvP機(jī)器太多，我們通過Proxy將整個(gè)架構(gòu)劃分成彼此之間沒有交集的“樹枝”概念，每組Proxy只負(fù)責(zé)一部分的大廳和PvP服務(wù)器。這兩種服務(wù)器在《王者榮耀》服務(wù)器里面最多，但是后端通聯(lián)之外，Proxy之間再建立連接，減少單個(gè)Proxy通道數(shù)的同時(shí)，保持整個(gè)結(jié)構(gòu)的通聯(lián)。

ProxyAdapter是上線后加入的，最開始上線只有四個(gè)大區(qū)，手Q、微信、Android、iOS四個(gè)環(huán)境，最早Android的玩家也不能和iOS開黑。開始Android和iOS分開也有一定原因，我們之前設(shè)想Android會(huì)先更新，iOS后跟新，以保持版本更新的穩(wěn)定性。但后來我們希望Android和iOS的玩家可以因?yàn)殛P(guān)系鏈一起開黑。

所以當(dāng)Android、iOS版本更新頻率一致時(shí)，我們希望不需要部署太多額外的機(jī)器資源和開發(fā)，直接利用Android和iOS已有的PvP服務(wù)器和大區(qū)資源，打通Android和iOS的PvP。當(dāng)Android玩家登錄Android大區(qū)會(huì)連接到Android大廳，iOS登錄之后連接iOS大區(qū)的大廳，當(dāng)他們需要開黑的時(shí)候，我們通過Adapter把中轉(zhuǎn)模塊所有的大區(qū)橋接起來，通過一定的算法投遞到某個(gè)大區(qū)。投遞的選擇和大區(qū)資源占比有直接關(guān)系。

網(wǎng)絡(luò)同步方案
?

之前做《霸三國(guó)》的時(shí)候采用CLIENT-SERVER的模式，服務(wù)器判定客戶端表現(xiàn)，那為什么我們?cè)谧觥锻跽邩s耀》的時(shí)候選用幀同步的方式呢？

CLIENT-SERVER模式的好處在于：

首先，安全。因?yàn)槎际欠?wù)器計(jì)算，客戶端只是負(fù)責(zé)表現(xiàn)層面的功能，不會(huì)影響各種判定的結(jié)果。

另外，CLIENT-SERVER模式因?yàn)槭腔诮Y(jié)果的表現(xiàn)，所以中間可以出現(xiàn)丟包，丟包是可以被接受和處理的，只要最終結(jié)果補(bǔ)發(fā)一致即可。

幀同步在端游用得比較多，大家比較熟悉的DotA，還有《星際爭(zhēng)霸》，都是用的幀同步技術(shù)。幀同步本身對(duì)網(wǎng)絡(luò)要求更加嚴(yán)苛，下發(fā)的執(zhí)行序列是不允許丟包的，需要嚴(yán)格保證順序性，包是12345，就必須是12345，如果丟包，必須要等到丟的包到達(dá)之后才能順序后續(xù)執(zhí)行。

MOBA本身的單位比較多，同屏?xí)r客戶端最多有將近100個(gè)單位，假如一個(gè)AOE技能打到20個(gè)單位，然后種了一個(gè)debuff，CLIENT-SERVER狀態(tài)模式需要發(fā)這些信息下去，可能潛在的同步狀態(tài)信息是比較多的。

另外一個(gè)CLIENT-SERVER模式本身開發(fā)的方式，客戶端表現(xiàn)與服務(wù)器的判定，要完美的匹配是比較困難的。

我們之前做端游MOBA的時(shí)候，一個(gè)英雄技能我們開發(fā)要兩三周的時(shí)間。《王者榮耀》當(dāng)時(shí)開發(fā)周期是三、四個(gè)月，這樣的時(shí)間壓力下，我們用CLIENT-SERVER的方式搞不定，時(shí)間不夠。當(dāng)時(shí)團(tuán)隊(duì)心里會(huì)比較緊張，因?yàn)槟菚r(shí)候市面上并沒有看到用這種方式做強(qiáng)PvP、高及時(shí)性手游的。

幀同步網(wǎng)絡(luò)抗抖動(dòng)能力比較弱，因?yàn)椴荒軄G包。幀同步的基本原理，大家有興趣可以下來自己了解一下。一般會(huì)有區(qū)分，是網(wǎng)絡(luò)還是主機(jī)模式。該技術(shù)的要點(diǎn)在于局內(nèi)的運(yùn)算都是基于客戶端運(yùn)算，10個(gè)人中，每個(gè)人都會(huì)各自算一份，有相同的起始、相同的輸入、完全相同的中間運(yùn)算邏輯，不存在隨機(jī)過程，這時(shí)候運(yùn)算的結(jié)果，理論上應(yīng)該是一致的。

甚至包括浮點(diǎn)數(shù)運(yùn)算都不應(yīng)該存在，它有精度的問題。包括很多碰撞，動(dòng)畫，還有基本的數(shù)學(xué)運(yùn)算庫(kù)都是后臺(tái)自己實(shí)現(xiàn)的，要去浮點(diǎn)整形化，避免客戶端的本地邏輯，這是最容易犯的錯(cuò)誤，這是出現(xiàn)不同步最常見的原因。如果某個(gè)經(jīng)驗(yàn)不是很足的客戶端程序，寫程序時(shí)候用本地的代碼做相應(yīng)的邏輯，可能跑得越來越遠(yuǎn)，10個(gè)人都是平行的世界。

整體的網(wǎng)絡(luò)結(jié)構(gòu)，大體看來分三層：服務(wù)器、客戶端邏輯層，客戶端表現(xiàn)層。

服務(wù)器主要負(fù)責(zé)的功能有兩部分：一是收集所有玩家上行的輸入，把它按定時(shí)的間隔打包成輸入的序列，投放給所有客戶端；二是當(dāng)客戶端出現(xiàn)丟包的時(shí)候，服務(wù)器進(jìn)行補(bǔ)發(fā)；還有把客戶端上行冗余的信息替換掉，比如有新的輸入到了，就把老的輸入Drop或者替換掉。在《王者榮耀》里，我們的邏輯是66毫秒一次，1秒同步15個(gè)包，這是不能少的，因?yàn)閹讲荒軄G包，數(shù)據(jù)包必須有嚴(yán)格的執(zhí)行序列。

客戶端邏輯層理解為客戶端本地的服務(wù)，就是所有客戶端運(yùn)行的結(jié)果必須強(qiáng)一致，不能有真的隨機(jī)、不能有本地邏輯、不能有浮點(diǎn)數(shù)運(yùn)算。拿到相同的輸入，產(chǎn)生結(jié)果必須一致。

客戶端表現(xiàn)層會(huì)根據(jù)邏輯層的數(shù)據(jù)去做Copy或者鏡像，然后在表現(xiàn)層進(jìn)行平滑，幀數(shù)不一樣，但是不會(huì)影響最終的運(yùn)算結(jié)果，只影響動(dòng)畫和動(dòng)作的表現(xiàn)。

PvP最開始上線時(shí)，我們用的是TCP技術(shù)。TCP在局域網(wǎng)的情況下表現(xiàn)還是不錯(cuò)的，沒有什么問題，但是當(dāng)外網(wǎng)出現(xiàn)丟包或者抖動(dòng)的時(shí)候，受限于實(shí)現(xiàn)方式，比如窗口、慢啟動(dòng)各方面的原因，會(huì)發(fā)現(xiàn)當(dāng)出現(xiàn)重連的時(shí)候游戲非常卡，所以后來我們沒有用TCP，改為了采用UDP。如果出現(xiàn)丟包，服務(wù)器會(huì)在應(yīng)用層做補(bǔ)發(fā)。UDP受限于MTU（最大傳輸單元）的大小，大于MTU，會(huì)出現(xiàn)分包，可能也會(huì)出現(xiàn)整包的丟失。

所以我們也會(huì)有些比較大的包會(huì)在App層由服務(wù)器做分包，中間出現(xiàn)丟包再由服務(wù)器補(bǔ)發(fā)，把零碎的包拼成整包再做解包。比較有價(jià)值的是UDP包，如果手機(jī)因?yàn)樾盘?hào)抖動(dòng)等出現(xiàn)丟包，下發(fā)的時(shí)候通過冗余方式，是比較有效的解決方法。

幀同步的消息比較小，按照理論1秒15個(gè)驅(qū)動(dòng)幀來算，20分鐘的錄像是10M左右。但是我們外網(wǎng)統(tǒng)計(jì)，正常的5V5對(duì)局20分鐘，錄像的大小大概是3M左右。服務(wù)器會(huì)把玩家的操作做純內(nèi)存的存儲(chǔ)，當(dāng)出現(xiàn)丟包的時(shí)候，服務(wù)器會(huì)通過編號(hào)快速找到緩存信息進(jìn)行下發(fā)。同時(shí)根據(jù)丟包的情況，我們會(huì)計(jì)算給這個(gè)人發(fā)送冗余量的變化量。

最開始發(fā)送每個(gè)包會(huì)冗余前面3幀的信息，如果丟包嚴(yán)重，我們會(huì)嘗試冗余更多信息再下發(fā)。客戶端拿到之后會(huì)盡量壓縮邏輯執(zhí)行的過程。幀同步有比較麻煩的模式在于，它不像CLIENT-SERVER的模式隨進(jìn)隨出，崩潰之后重回必須從一開始運(yùn)行，中間運(yùn)算過程不能少掉。

當(dāng)然，我們也嘗試過其他的一些方法。比如客戶端上行之后，不需要服務(wù)器定時(shí)的間隔去做收集然后下發(fā)，而是通過染色幀編號(hào)直接下發(fā)，這樣響應(yīng)更及時(shí)，操作反饋更強(qiáng)、更快。當(dāng)時(shí)我們做出來的結(jié)果是，這對(duì)手感的提升微乎其微，但是帶來的負(fù)面問題卻很大，因?yàn)椴辉偈且幻?5個(gè)包固定的下發(fā)，下發(fā)包的數(shù)量非常多，完全和這個(gè)人的操作習(xí)慣有關(guān)系，有可能一個(gè)人一秒之內(nèi)產(chǎn)生了十幾二十個(gè)輸入，就需要把這些輸入打包之后對(duì)客戶端下發(fā)。客戶端因?yàn)槭瞻芏?設(shè)備也會(huì)明顯發(fā)燙。

我們也有和其他部門合作，做類似于TCP的技術(shù)，大家直觀想到如果丟包就在io層做重發(fā)。但是實(shí)際的結(jié)果會(huì)發(fā)現(xiàn)，做的這個(gè)技術(shù)偏底層，所以對(duì)丟包的控制性不那么靈活，而且可能出來的結(jié)果還沒有tcp本身好。

傳統(tǒng)的幀同步的方式會(huì)做延遲投遞，這個(gè)我們也有嘗試過。如果間隔時(shí)間內(nèi)出現(xiàn)丟包，或者出現(xiàn)包下行的時(shí)網(wǎng)絡(luò)波動(dòng)，可以通過延遲投遞這種方式抹平抖動(dòng)和丟包的情況。我們嘗試過這個(gè)方案但最終沒有這樣做的原因在于：《王者榮耀》里面一些英雄體驗(yàn)起來感覺偏動(dòng)作，對(duì)反應(yīng)要求比較快，延遲投遞雖然抗抖動(dòng)和抗丟包的能力確實(shí)不錯(cuò)，但是手感上達(dá)不到我們的要求。

另外，做CLIENT-SERVER方式的實(shí)現(xiàn)，一般都會(huì)有一個(gè)套路，客戶端提前表現(xiàn)，根據(jù)服務(wù)器的表現(xiàn)做平滑或者拉扯。這個(gè)方案我們也嘗試過，但最終還是放棄了，因?yàn)檫@個(gè)技術(shù)會(huì)讓角色本身的表現(xiàn)有點(diǎn)發(fā)飄。客戶端本地動(dòng)，馬上客戶端表現(xiàn)就跟著動(dòng)，但根據(jù)服務(wù)器的下行，其實(shí)會(huì)做一些偏移或者修正。當(dāng)網(wǎng)絡(luò)抖動(dòng)出現(xiàn)的時(shí)候，角色會(huì)有一點(diǎn)發(fā)飄，所以這個(gè)方案我們放棄掉了。

幀同步方案，所有客戶端進(jìn)行運(yùn)算，期望產(chǎn)生一致的結(jié)果，但如果因?yàn)閎ug或者某個(gè)人使用修改器，跑出來的結(jié)果會(huì)和其他人不一樣，當(dāng)不一樣出現(xiàn)，我們的說法是不同步了。我們會(huì)定時(shí)把一些關(guān)鍵信息提取出來做hash，不同步的人的hash和其他人會(huì)不一樣。《王者榮耀》不同步率上線時(shí)大概是2%，也就是100局可能有2局出現(xiàn)一個(gè)人或者多個(gè)人結(jié)果和其他人不一樣。我們現(xiàn)在把不同步率做到了萬(wàn)分之三，一萬(wàn)局里面只有三局出現(xiàn)這個(gè)情況。

這是怎么提升的呢？如果你用幀同步一定會(huì)遇到不同步的問題，客戶端寫錯(cuò)了，用了本地邏輯，可能浮點(diǎn)數(shù)的運(yùn)算誤差達(dá)到那樣的臨界點(diǎn)，它就會(huì)產(chǎn)生運(yùn)算結(jié)果不一致。

我們的方法有很多：自動(dòng)化測(cè)試，用機(jī)器人不斷跑，比如上新英雄之前，有腳本測(cè)試不斷跑，看會(huì)不會(huì)產(chǎn)生不同步的結(jié)果；有專門的體驗(yàn)服、搶先服大區(qū)，發(fā)布到正式網(wǎng)絡(luò)之前先測(cè)試，先暴露問題，再解決問題；另外，當(dāng)不同步的時(shí)候，我們會(huì)把這局整個(gè)錄像和客戶端間的log上傳和保存下來，這樣可以根據(jù)錄像和中間執(zhí)行的日志序列快速的定位是哪個(gè)地方出現(xiàn)問題。

我們對(duì)延遲和單局質(zhì)量也有相應(yīng)的監(jiān)控，這一局有沒有卡或者卡多少次，有沒有出現(xiàn)丟包，丟包多少，最大的延遲、最大的抖動(dòng)是多少，我們都是有相應(yīng)的記錄和統(tǒng)計(jì)。運(yùn)營(yíng)部的同學(xué)給我們提供了很多幫助，我們會(huì)有相關(guān)的網(wǎng)絡(luò)測(cè)速、問題分析的SDK的合入。

按照我們自己的統(tǒng)計(jì)，游戲卡頓主要的原因有幾個(gè)：一是小區(qū)的帶寬比較繁忙，很多小區(qū)其實(shí)都是公用帶寬出口，比如有人在下電影、看直播，占用了很高帶寬，你玩游戲就可能會(huì)卡。

二是Wi-Fi路由器延遲比較高，家里的Wi-Fi路由器長(zhǎng)期沒有重啟，就會(huì)存在終端過多、信道干擾、其他大流量的應(yīng)用下載情況，這也會(huì)影響你玩《王者榮耀》。還有手機(jī)信號(hào)差、信號(hào)抖動(dòng)，Wi-Fi、4G空口丟包等。

我們其實(shí)在網(wǎng)絡(luò)優(yōu)化上做了很多的嘗試，例如根據(jù)丟包情況加大冗余，然后優(yōu)化我們各方面執(zhí)行的效率，去減少CPU的占用。《王者榮耀》后臺(tái)方面，有兩個(gè)點(diǎn)是我們一直努力在做的，網(wǎng)絡(luò)優(yōu)化和匹配機(jī)制，我們嘗試用各種各樣的方法，甚至后面也會(huì)嘗試用AI深度學(xué)習(xí)的方法，來更加精準(zhǔn)的定位玩家本身的真實(shí)水平，讓他能夠匹配到更加真實(shí)的同等水平的對(duì)手和隊(duì)友。

總結(jié)

以上是生活随笔為你收集整理的《王者荣耀》游戏技术总监：技术架构与同步方案上做出改变？的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。