[[205807]]

《王者榮耀》能夠成為如今國內(nèi)最成功的手游，其背后成熟的技術(shù)團(tuán)隊支持可以說是功不可沒。

這個曾經(jīng)在端游時代主導(dǎo)搭建 RTS 游戲《霸三國》框架的技術(shù)團(tuán)隊，在轉(zhuǎn)型做 MOBA 手游《王者榮耀》后為游戲提供了巨大的支持，但這個過程也并非一帆風(fēng)順。

[[205808]]

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

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

此外，他還介紹了《王者榮耀》在網(wǎng)絡(luò)協(xié)議以及同步方案上的一些嘗試，并一一復(fù)盤了這些嘗試的優(yōu)劣勢。

為大家解答了為什么，最終游戲會放棄 TCP 協(xié)議(傳輸控制協(xié)議)與曾經(jīng)在《霸三國》中所使用的 Client-Server 結(jié)構(gòu)(C/S結(jié)構(gòu))，并且轉(zhuǎn)而使用了 UDP 協(xié)議(用戶數(shù)據(jù)報協(xié)議)與幀同步方案。

本文是騰訊王者榮耀項目技術(shù)總監(jiān)孫勛帶來的《王者榮耀技術(shù)架構(gòu)》主題演講內(nèi)容整理。將分幾部分為大家介紹王者后臺開發(fā)過程中的一些內(nèi)容和思考：包括《王者榮耀》整個背景介紹、后端架構(gòu)、上線后的調(diào)整，以及網(wǎng)絡(luò)同步方案和反作弊方案等。

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

《王者榮耀》游戲背景

[[205809]]

2012 年，我們當(dāng)時做的端游《霸三國OL》，就是王者的前身。這款產(chǎn)品最開始是偏向 RTS 的游戲，后來我們把它改成了端游 MOBA，再后來做成了手游 MOBA，即現(xiàn)在的《王者榮耀》。

從 2012 年開始做 RTS 游戲到 2013 年，從多控制單位的 RTS 游戲，變成 MOBA 游戲，到 2014 年啟動手游 MOBA 的預(yù)研，再到 2015 年 2 月份我們把大量人力(大概100多號人)投入做《英雄戰(zhàn)跡》(《王者榮耀》前身)開發(fā)，時間并不長。

《霸三國》的玩法是玩家可以在戰(zhàn)前通過排兵布陣構(gòu)成自己局內(nèi)的策略，通過控制多個單位，技能釋放、兵種特性的釋放形成對抗。

我們最開始做《霸三國》的時候客戶端引擎是 unreal，但在做《王者榮耀》的時候改用了unity 引擎，3 到 4 個月的研發(fā)時間內(nèi)，產(chǎn)品本身從代碼層面沒有任何東西是從《霸三國》那里搬過來用的，全部代碼都需要重寫。

《霸三國OL》的一些啟示

做端游《霸三國OL》的這段經(jīng)歷，給我們做王者帶來很多相應(yīng)的啟示，比如策劃、程序及整個團(tuán)隊對 MOBA 的理解。

另外當(dāng)時在做端游《霸三國》的時候，我們采用了 Client-Server 的模式，但其實在過程中有借鑒類似幀同步的概念：例如在斷線重回對視野的處理這塊。

傳統(tǒng)的做法是，重回時會發(fā)當(dāng)前的鏡像和后續(xù)的其他下行通知信息。

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

我們的做法是，把服務(wù)器下發(fā)的所有序列包做緩存，并按順序重發(fā)，讓客戶端做出快進(jìn)的表現(xiàn)，它的概念和幀同步比較類似。

還有一點，就是預(yù)留設(shè)計彈性，在最開始的 RTS 中，每個玩家最多可以操作 5-8 個單位進(jìn)行對抗，到后來改成 MOBA 游戲，只能操作一個英雄，并且加入各種各樣的場景，我們本身的技術(shù)框架并不需要做出顛覆性的改動。

《王者榮耀》整體架構(gòu)

目前《王者榮耀》后臺的整體架構(gòu)設(shè)計是源自產(chǎn)品的需求。如果大家玩過《王者榮耀》就會知道，PvP 對抗是不分區(qū)服的。

微信 1 區(qū)的玩家可以和微信 2 區(qū)玩家一起對抗，甚至 iOS 平臺也可以和 Android 平臺的人一起玩，但同時一些共有地方也保留了分區(qū)概念，比如戰(zhàn)隊、排行榜是基于“區(qū)”概念的。“區(qū)”在游戲里面就是編號，可以理解為打在玩家新建角色上的 Logo。

我們最開始做架構(gòu)實現(xiàn)的時候，服務(wù)器當(dāng)時做得比較簡單，從原型開始只是保留了大廳和 PvP 服務(wù)器這兩塊，兩者是分開的。

PvP 服務(wù)器使用類似 CGI 調(diào)用，可以分配資源的使用，用完之后再回收，不負(fù)責(zé)其他的東西。需要的東西從大廳拿，用了之后回給大廳，讓大廳回寫 DB。

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

某些排行榜或者戰(zhàn)隊是根據(jù)邏輯區(qū)的編號來確定哪臺機(jī)器，或者多臺機(jī)器進(jìn)行處理的。有些消息采用隨機(jī)轉(zhuǎn)發(fā)或者多發(fā)廣播的方式，這些都是由 Proxy 負(fù)責(zé)路由。之后又加入了房間服務(wù)器，它負(fù)責(zé)的是《王者榮耀》內(nèi)匹配、排位等相關(guān)功能。

怎么樣把實力比較接近的人糅合到一塊兒玩，是由房間匹配服務(wù)器來做相應(yīng)的負(fù)責(zé)的，因此會有戰(zhàn)隊和其他服務(wù)器戰(zhàn)隊匹配到一起。

最后我們在上面加入了一個 Adapter，作用是用本身已經(jīng)部署的大區(qū)資源實現(xiàn)跨服匹配的功能。

游戲的后端架構(gòu)，除了戰(zhàn)隊這樣的服務(wù)器之外，所有其他的模塊都可以在線擴(kuò)容，或者在發(fā)現(xiàn)有引起在線下降的故障時，從整個架構(gòu)里自動屏蔽掉。

因為路由方式會限定比如一區(qū)、二區(qū)、三區(qū)到這臺機(jī)器處理，如果故障，影響的只是某幾個邏輯區(qū)玩家請求的處理，降低故障影響范圍。

《王者榮耀》目前的機(jī)器數(shù)量，可能每周都會發(fā)現(xiàn)有機(jī)器壞掉，至少有一臺機(jī)器宕掉，在架構(gòu)里面保證模塊自動屏蔽，和在線擴(kuò)容，是非常重要的事情。

整體結(jié)構(gòu)比較像 MMO 的三層結(jié)構(gòu)，MMO 在騰訊有比較典型的三層級別結(jié)構(gòu)。大廳服務(wù)器會根據(jù)玩家所在區(qū)，登錄具體區(qū)的大廳服務(wù)器。

單個大廳進(jìn)程可以承載 2 萬人，單個 PvP 可以承載 1.2 萬，小區(qū)登錄微信一區(qū)還是二區(qū)就是角色 Logo，打在玩家身上。

《王者榮耀》現(xiàn)在外網(wǎng)有四個大區(qū)，比如 Android 手 Q、Android 微信、iOS 手 Q、iOS 微信，此外還有搶先服。

我們會用程序開關(guān)的方式，在大版本發(fā)布之前，優(yōu)先更新?lián)屜确@時候它不能和正式服玩家匹配在一起，因為他們的版本不一致。當(dāng)全服發(fā)布之后，它的版本更新一致之后，我們會打開開關(guān)，搶先服的玩家可以和正式服的玩家一起進(jìn)行 PvP 的匹配。

除此之外，我們還有專門的體驗服，是給策劃驗證相關(guān)設(shè)計的，體驗服保留可能刪檔的操作，但在正式環(huán)境這是絕對不允許的。

另外，以前的傳統(tǒng)手游偏單機(jī)，就會做很多協(xié)議兼容，客戶端版本沒有更新可以玩。但是《王者榮耀》里的主要玩法是 PvP，同時結(jié)合實現(xiàn)方式，不同版本的玩家不能匹配一起，所以我們沒有做多版本協(xié)議兼容。

上線后的調(diào)整

上線后，《王者榮耀》本身的后臺架構(gòu)，整體上沒有做太大的改動，因為我們做端游的時候，對這套結(jié)構(gòu)比較清楚，我們知道哪個地方可能有什么樣的問題，所以整個結(jié)構(gòu)一直比較穩(wěn)定。

但是我們做了相應(yīng)的微調(diào)，做得最多的是網(wǎng)絡(luò)本身的優(yōu)化?！锻跽邩s耀》上線的時候，市面上要求網(wǎng)絡(luò)及時性強(qiáng)的即時 PvP 游戲是比較少的。

我們做了各種各樣的嘗試，比如在網(wǎng)絡(luò)做 CPU 方面的性能優(yōu)化、延遲、丟包等等，網(wǎng)絡(luò)本身花的時間是最多的。

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

怎么劃分、平衡負(fù)載、怎么屏蔽后端故障節(jié)點，都是由 Proxy 路由功能在負(fù)責(zé)。因為大廳、PvP 機(jī)器太多，我們通過 Proxy 將整個架構(gòu)劃分成彼此之間沒有交集的“樹枝”概念，每組 Proxy 只負(fù)責(zé)一部分的大廳和PvP服務(wù)器。

這兩種服務(wù)器在《王者榮耀》服務(wù)器里面最多，但是后端通聯(lián)之外，Proxy 之間再建立連接，減少單個 Proxy 通道數(shù)的同時，保持整個結(jié)構(gòu)的通聯(lián)。

Proxy Adapter 是上線后加入的，最開始上線只有四個大區(qū)，手 Q、微信、Android、iOS 四個環(huán)境，最早 Android 的玩家也不能和 iOS 開黑。

開始 Android 和 iOS 分開也有一定原因，我們之前設(shè)想 Android 會先更新，iOS 后更新，以保持版本更新的穩(wěn)定性。但后來我們希望 Android 和 iOS 的玩家可以因為關(guān)系鏈一起開黑。

所以當(dāng) Android、iOS 版本更新頻率一致時，我們希望不需要部署太多額外的機(jī)器資源和開發(fā)，直接利用 Android 和 iOS 已有的 PvP 服務(wù)器和大區(qū)資源，打通 Android 和 iOS 的 PvP。

當(dāng) Android 玩家登錄 Android 大區(qū)會連接到 Android 大廳，iOS 登錄之后連接 iOS 大區(qū)的大廳，當(dāng)他們需要開黑的時候，我們通過 Adapter 把中轉(zhuǎn)模塊所有的大區(qū)橋接起來，通過一定的算法投遞到某個大區(qū)。投遞的選擇和大區(qū)資源占比有直接關(guān)系。

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

之前做《霸三國》的時候采用 Client-Server 的模式，服務(wù)器判定客戶端表現(xiàn)，那為什么我們在做《王者榮耀》的時候選用幀同步的方式呢?

Client-Server 模式的好處在于：

首先，安全。因為都是服務(wù)器計算，客戶端只是負(fù)責(zé)表現(xiàn)層面的功能，不會影響各種判定的結(jié)果。

另外，Client-Server 模式因為是基于結(jié)果的表現(xiàn)，所以中間可以出現(xiàn)丟包，丟包是可以被接受和處理的，只要最終結(jié)果補發(fā)一致即可。

幀同步在端游用得比較多，大家比較熟悉的 DotA，還有《星際爭霸》，都是用的幀同步技術(shù)。

幀同步本身對網(wǎng)絡(luò)要求更加嚴(yán)苛，下發(fā)的執(zhí)行序列是不允許丟包的，需要嚴(yán)格保證順序性，包是 12345，就必須是 12345，如果丟包，必須要等到丟的包到達(dá)之后才能順序后續(xù)執(zhí)行。

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

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

我們之前做端游 MOBA 的時候，一個英雄技能我們開發(fā)要兩三周的時間?！锻跽邩s耀》當(dāng)時開發(fā)周期是三、四個月，這樣的時間壓力下，我們用 Client-Server 的方式搞不定，時間不夠。

當(dāng)時團(tuán)隊心里會比較緊張，因為那時候市面上并沒有看到用這種方式做強(qiáng) PvP、高及時性手游的。

幀同步網(wǎng)絡(luò)抗抖動能力比較弱，因為不能丟包。幀同步的基本原理，大家有興趣可以下來自己了解一下。

一般會有區(qū)分，是網(wǎng)絡(luò)還是主機(jī)模式。該技術(shù)的要點在于局內(nèi)的運算都是基于客戶端運算，10 個人中，每個人都會各自算一份，有相同的起始、相同的輸入、完全相同的中間運算邏輯，不存在隨機(jī)過程，這時候運算的結(jié)果，理論上應(yīng)該是一致的。

甚至包括浮點數(shù)運算都不應(yīng)該存在，它有精度的問題。包括很多碰撞，動畫，還有基本的數(shù)學(xué)運算庫都是后臺自己實現(xiàn)的，要去浮點整形化，避免客戶端的本地邏輯，這是最容易犯的錯誤，這是出現(xiàn)不同步最常見的原因。

如果某個經(jīng)驗不是很足的客戶端程序，寫程序時候用本地的代碼做相應(yīng)的邏輯，可能跑得越來越遠(yuǎn)，10 個人都是平行的世界。

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

服務(wù)器主要負(fù)責(zé)的功能有兩部分：

收集所有玩家上行的輸入，把它按定時的間隔打包成輸入的序列，投放給所有客戶端。

當(dāng)客戶端出現(xiàn)丟包的時候，服務(wù)器進(jìn)行補發(fā);還有把客戶端上行冗余的信息替換掉，比如有新的輸入到了，就把老的輸入 Drop 或者替換掉。

在《王者榮耀》里，我們的邏輯是 66 毫秒一次，1 秒同步 15 個包，這是不能少的，因為幀同步不能丟包，數(shù)據(jù)包必須有嚴(yán)格的執(zhí)行序列。

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

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

PvP 最開始上線時，我們用的是 TCP 技術(shù)。TCP 在局域網(wǎng)的情況下表現(xiàn)還是不錯的，沒有什么問題，但是當(dāng)外網(wǎng)出現(xiàn)丟包或者抖動的時候，受限于實現(xiàn)方式。

比如窗口、慢啟動各方面的原因，會發(fā)現(xiàn)當(dāng)出現(xiàn)重連的時候游戲非?？?，所以后來我們沒有用 TCP，改為了采用 UDP。如果出現(xiàn)丟包，服務(wù)器會在應(yīng)用層做補發(fā)。

UDP 受限于 MTU(最大傳輸單元)的大小，大于 MTU，會出現(xiàn)分包，可能也會出現(xiàn)整包的丟失。

所以我們也會有些比較大的包會在 App 層由服務(wù)器做分包，中間出現(xiàn)丟包再由服務(wù)器補發(fā)，把零碎的包拼成整包再做解包。

比較有價值的是 UDP 包，如果手機(jī)因為信號抖動等出現(xiàn)丟包，下發(fā)的時候通過冗余方式，是比較有效的解決方法。

幀同步的消息比較小，按照理論 1 秒 15 個驅(qū)動幀來算，20 分鐘的錄像是 10M 左右。但是我們外網(wǎng)統(tǒng)計，正常的 5V5 對局 20 分鐘，錄像的大小大概是 3M 左右。

服務(wù)器會把玩家的操作做純內(nèi)存的存儲，當(dāng)出現(xiàn)丟包的時候，服務(wù)器會通過編號快速找到緩存信息進(jìn)行下發(fā)。同時根據(jù)丟包的情況，我們會計算給這個人發(fā)送冗余量的變化量。

最開始發(fā)送每個包會冗余前面3幀的信息，如果丟包嚴(yán)重，我們會嘗試冗余更多信息再下發(fā)?？蛻舳四玫街髸M量壓縮邏輯執(zhí)行的過程。

幀同步有比較麻煩的模式在于，它不像 Client-Server 的模式隨進(jìn)隨出，崩潰之后重回必須從一開始運行，中間運算過程不能少掉。

當(dāng)然，我們也嘗試過其他的一些方法。比如客戶端上行之后，不需要服務(wù)器定時的間隔去做收集然后下發(fā)，而是通過染色幀編號直接下發(fā)，這樣響應(yīng)更及時，操作反饋更強(qiáng)、更快。

當(dāng)時我們做出來的結(jié)果是，這對手感的提升微乎其微，但是帶來的負(fù)面問題卻很大，因為不再是一秒 15 個包固定的下發(fā)，下發(fā)包的數(shù)量非常多，完全和這個人的操作習(xí)慣有關(guān)系。

有可能一個人一秒之內(nèi)產(chǎn)生了十幾二十個輸入，就需要把這些輸入打包之后對客戶端下發(fā)?？蛻舳艘驗槭瞻芏啵O(shè)備也會明顯發(fā)燙。

我們也有和其他部門合作，做類似于 TCP 的技術(shù)，大家直觀想到如果丟包就在 IO 層做重發(fā)。

但是實際的結(jié)果會發(fā)現(xiàn)，做的這個技術(shù)偏底層，所以對丟包的控制性不那么靈活，而且可能出來的結(jié)果還沒有 TCP 本身好。

傳統(tǒng)的幀同步的方式會做延遲投遞，這個我們也有嘗試過。如果間隔時間內(nèi)出現(xiàn)丟包，或者出現(xiàn)包下行時的網(wǎng)絡(luò)波動，可以通過延遲投遞這種方式抹平抖動和丟包的情況。

我們嘗試過這個方案但最終沒有這樣做的原因在于：《王者榮耀》里面一些英雄體驗起來感覺偏動作，對反應(yīng)要求比較快，延遲投遞雖然抗抖動和抗丟包的能力確實不錯，但是手感上達(dá)不到我們的要求。

另外，做 Client-Server 方式的實現(xiàn)，一般都會有一個套路，客戶端提前表現(xiàn)，根據(jù)服務(wù)器的表現(xiàn)做平滑或者拉扯。

這個方案我們也嘗試過，但最終還是放棄了，因為這個技術(shù)會讓角色本身的表現(xiàn)有點發(fā)飄。

客戶端本地動，馬上客戶端表現(xiàn)就跟著動，但根據(jù)服務(wù)器的下行，其實會做一些偏移或者修正。當(dāng)網(wǎng)絡(luò)抖動出現(xiàn)的時候，角色會有一點發(fā)飄，所以這個方案我們放棄掉了。

幀同步方案，所有客戶端進(jìn)行運算，期望產(chǎn)生一致的結(jié)果，但如果因為 Bug 或者某個人使用修改器，跑出來的結(jié)果會和其他人不一樣，當(dāng)不一樣出現(xiàn)，我們的說法是不同步了。

我們會定時把一些關(guān)鍵信息提取出來做 Hash，不同步的人的 Hash 和其他人會不一樣。

《王者榮耀》不同步率上線時大概是 2%，也就是 100 局可能有 2 局出現(xiàn)一個人或者多個人結(jié)果和其他人不一樣。我們現(xiàn)在把不同步率做到了萬分之三，一萬局里面只有三局出現(xiàn)這個情況。

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

我們的方法有很多：自動化測試，用機(jī)器人不斷跑，比如上新英雄之前，有腳本測試不斷跑，看會不會產(chǎn)生不同步的結(jié)果;有專門的體驗服、搶先服大區(qū)，發(fā)布到正式網(wǎng)絡(luò)之前先測試，先暴露問題，再解決問題。

另外，當(dāng)不同步的時候，我們會把這局整個錄像和客戶端間的 Log 上傳和保存下來，這樣可以根據(jù)錄像和中間執(zhí)行的日志序列快速的定位是哪個地方出現(xiàn)問題。

我們對延遲和單局質(zhì)量也有相應(yīng)的監(jiān)控，這一局有沒有卡或者卡多少次，有沒有出現(xiàn)丟包，丟包多少，最大的延遲、最大的抖動是多少，我們都是有相應(yīng)的記錄和統(tǒng)計。

運營部的同學(xué)給我們提供了很多幫助，我們會有相關(guān)的網(wǎng)絡(luò)測速、問題分析的 SDK 的合入。

按照我們自己的統(tǒng)計，游戲卡頓主要的原因有幾個：

• 小區(qū)的帶寬比較繁忙，很多小區(qū)其實都是公用帶寬出口，比如有人在下電影、看直播，占用了很高帶寬，你玩游戲就可能會卡。
• Wi-Fi 路由器延遲比較高，家里的 Wi-Fi 路由器長期沒有重啟，就會存在終端過多、信道干擾、其他大流量的應(yīng)用下載情況，這也會影響你玩《王者榮耀》。
• 手機(jī)信號差、信號抖動，Wi-Fi、4G 空口丟包等。

我們在網(wǎng)絡(luò)優(yōu)化上做了很多的嘗試，例如根據(jù)丟包情況加大冗余，然后優(yōu)化我們各方面執(zhí)行的效率，去減少 CPU 的占用。

《王者榮耀》后臺方面，有兩個點是我們一直努力在做的，網(wǎng)絡(luò)優(yōu)化和匹配機(jī)制，我們嘗試用各種各樣的方法，甚至后面也會嘗試用 AI 深度學(xué)習(xí)的方法，來更加精準(zhǔn)的定位玩家本身的真實水平，讓他能夠匹配到更加真實的同等水平的對手和隊友。

[[205813]]

孫勛

騰訊王者榮耀項目技術(shù)總監(jiān)

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