騰訊《天涯明月刀》5年研發歷程覆盤，效能、畫質優化方法解讀

作為騰訊遊戲首款自主研發的3D武俠題材MMORPG遊戲，《天涯明月刀》憑藉其自研的Quicksliver引擎，高度還原了很多真實景觀，塑造出杭州、開封等經典場景，並通過真實的光影效果和流暢的戰鬥畫面，向玩家展現了逼真寫實的武俠世界。本期《論道》，騰訊北極光工作室群的專家工程師劉冰嘯將深入覆盤《天涯明月刀》5年開發歷程中，針對遊戲主城、多人場景等進行的諸多優化，分享製作大型MMORPG遊戲效率提升的方法以及常見疑難問題。


以下為分享實錄：



縱觀整個《天涯明月刀》的發展歷史，從優化的角度來看，大概經歷了以下過程：

在2011年，專案的內部測試已經實現了在定製的遊戲引擎基礎上的多執行緒渲染框架，極大地提升了渲染效率，也為後續開發渲染功能打下了深厚的基礎。

在2012年的第一次技術內測前，我們完成了任務系統、邏輯執行緒和主執行緒同步方式的改進，這部分對後面多人及主城優化會有非常大的幫助。

在2013年的一測和2014年的二測，我們分別針對主城和多人展開了專項優化，最終在玩家群體中確立了《天涯明月刀》效能優化比較好的口碑。


在一個大型遊戲專案裡是如何完成這些優化的呢？

從《天涯明月刀》的經驗來看，首先要求整個團隊能在一起完成協作，如上圖所示，程式優化只是一小部分。對一個專案來說，優化是整個團隊的事情，包括策劃、美術、客戶端程式和伺服器程式等同事都需要參與進來。

其次，要保證有一個固定的人力來專職處理優化的問題，可以是TA（技術美術），也可以是比較有經驗的程式設計師。

另外，遊戲引擎本身也需要有非常豐富的資料收集能力，最好能從各個角度來獲取一些非常重要的效能指標。

最後，我們要保持技術預研投入一些高階的技術，往往能最後獲得非常好的收益。



在一測時，我們針對杭州主城和開封主城做了很多優化，給玩家看到的是一個非常精美細緻的場面。但最開始的時候，通過Debug（除錯）檢視是發現了非常多的問題，如：物件缺少合適的LOD（細節級別）；物件的貼圖分配不合理，屏佔比比較小的物件卻給了很大的貼圖。


當時《天涯明月刀》專案是怎麼攻克這些問題的呢？

在展開優化之前，我們會首先和地圖美術組打好招呼，預留好時間安排。在優化的過程中，資料是必須要優先考慮的。在程式展開優化工作時，資料收集和Profile程式碼的實現和改進 花費了大概一到兩週的時間。其餘時間，由於之前的文件準備和其他的Profile工具比較齊全，美術就可以完全自主展開工作。這時候，程式設計師就可以解放出來來完成自己的工作，可以達成比較好的並行開發。

到了真正開始著手調整地圖的時候，效率很高，經過兩週，在地圖上面的優化已經非常地明顯。


前期準備階段我們都做了哪些準備？

第一，我們開發了一整套可以自動記錄和恢復相近位置的工具，並且和地圖美術的同學一起針對主城的典型區域配置了大概有30套的相機位。

第二，我們製作並且完善了非常多收集效能資料的工具，其中比較重要的有PerfZone，可以在地圖中劃定部分割槽域，收集詳細的效能資料。


第三，同時開始對一些先進技術展開預研，這裡介紹一下DumpStats（統計輸出）工具，它首先是按照時間，對於當前PerfZone裡面的資料進行Dump（輸出），方便美術、QA同事回溯歷史並且事無鉅細地把所有用到的資源按照大小、型別、出現的問題輸出。這樣，美術同學很快就可以針對性地修復一些資料，很容易就能把一些前期的重點問題給解決。


其次，我們也開發了一種場景熱度圖的技術，地圖中每4米一個單位，我們儲存這裡的效能關鍵資料，例如FPS（幀率）、ShadowMap（陰影繪製時間）、Geometry Buffer時間和Lighting（光照渲染）時間，並且可以做到隨著版本實時走。這樣，我們可以很容易看到地圖中的熱點區域，並且也能隨著歷史回溯查到它的資訊。


除此之外，從美術角度出發，我們也製作了能顯示各種Debug Views（除錯檢視）的工具，美術通過這些工具就可以找到和解決具體問題。例如，這個檢視就把場景中的高光貼圖尺寸不符合和Diffuse（漫反射）貼圖比例關係的物件以粉紅色的方式體現出來，通過美術的調整，我們就可以把場景裡面出現問題的物件全部地給替換掉。


這是另外一個Debug Views檢視，它顯示了物件在螢幕空間的投影尺寸和它的三角面的對應關係，越紅的物體，表示它需要製作面數更低的LOD。


這張檢視反映了物體的貼圖尺寸是否過大，如果我們制定一個10米左右的物件，在5米攝像距離下應該採用的是512畫素的貼圖，那麼超過這個比例的物體就會以不同的顏色來顯示。

以上的這些Debug Views，能幫助美術第一時間找到出現問題的物件，然後採用相應的方法去修正。


在主城優化裡，另外一個非常重要的工具就是遮擋剔除，好的遮擋剔除能極大地減少不必要的Drawcall（CPU對圖形繪製介面的呼叫）數目，針對這個功能，我們採用的是軟體光柵化的方法來在CPU上獲得深度資訊。


我們通過在建築內製作保守的內包圍盒來製作遮擋體，同時提供Debug檢視來幫助美術判斷這裡的遮擋是否有效，除了顯示遮擋體的深度圖方式，我們也給了一個更直觀的檢視，這張檢視顯示了當前攝像機位置下的Drawcall數目以及物件型別，物件型別越多會導致佔用記憶體的視訊記憶體越多。有多少物件被遮擋剔除掉是用來衡量遮擋是否有效的，越多的遮擋體會導致越多的光柵化時間，應該控制在一定的範圍內。

我們看到影像上的這個Bug模式，X軸是物件型別，Y軸是對應的物件數目，可以很直觀地觀察當前視角下物件種類和利用率的情況。


通過以上的這些工具，美術就可以有針對性地在不同的位置上調整模型位置或者重新制作遮擋體，以優化Drawcall數目、視訊記憶體佔用和繪出的三角形數目。優化之後，大部分觀察點上的效能都能得到50%以上的提升。

在程式提供各式各樣的工具讓美術同學可以著手進行調整之後，程式這邊也並行進行了一些新技術的研究，其中一個產出就是：將遠景物件離線或者線上烘培成一個2D面片的Impostor（圖片）。烘焙出的Impostor仍然保留Normal（法線）和高光，所以在渲染的時候仍然可以計算光照。


像上圖所示，在技術內測的時候因為太遠，Streaming（流式載入）物件無法載入，使得這個區域看起來十分地空。


當我們採用Impostor技術之後，這些物件就可以使用Impostor方式顯示出來，由於這種技術是可以以一個Drawcall的方式完成大量的繪製，所以在效率上是非常地節省。我們可以看到這些綠色或者紅色區域分別是離線和線上烘焙出來的Impostor，其中很多細節部分都可以顯示出來。


回到主城的視角來看，在《天涯明月刀》裡絕大多數的物件的第四級LOD都會以Impostor的方式替代，這個時候物件其實已經被解除安裝掉了，節省了大量的記憶體視訊記憶體，也極大地提高了效率。這個是我們在主城優化中，使用的非常重要的一門優化技術。


總結一下，在主城優化的過程中，是離不開程式和美術的分工協同，各個團隊在各自領域裡面做出重要的工作；並且在整個時間線上，程式與美術可以做到協同並進。這樣的話，使得《天涯明月刀》的引擎在大規模上場景設計上以最小的資源保證了最好的表現。



接下來，將分享二測時我們是如何完成針對多人場景的優化的。二測開始前，我們瞭解到策劃有大規模團戰的設計需求，要能做到500人級別的團戰。

在開始之前，我們就通過論壇、微博、QQ、直播等方式收集了玩家的反饋資訊，瞭解到玩家在主城裡經常聚集的區域，另外瞭解到相對一測，玩家的基礎配置已經提升了不少。這也對我們採用更高階的技術提供了資料支援。


多人戰鬥是非常動態的環境，所以我們設計了一套測試機制，協同伺服器、客戶端和QA Team一起選擇穩定的伺服器和客戶端版本，部署在幾乎接近於真實的外網測試環境，測試伺服器長期地在同一位置進行大量角色的耗費效能模擬。有了這樣的測試環境，我們就可以採用之前提到的各種資料上的Profile工具進行調優。


首先，我們從全域性角度上來考慮這個優化問題，策劃同學根據收集到的效能資料和玩法設計，估算出我們遊戲裡面的重點密集區域，主要是主城裡面的擺攤區和外貿行。它的開銷主要是主城本身的複雜物件開銷和多人開銷。

我們把拍賣行和擺攤區的區域分別進行設計，拍賣行設計為室內，擺攤區設計為室外，這樣的話通過遮擋剔除，我們會剔除掉部分進入室內的角色。

而對於野外的盟會戰開銷，盟會戰我們優先是選擇在野外地圖中，而且是效能比較好的區域 進行投放，包括復活點、傳送點，我們都採用類似的方法來設計。甚至在主城門口的接收區也設計了城門、城牆這樣大型遮擋，來剔除進入城內的角色的渲染開銷。


從程式的角度來看，關鍵策略是根據重要度，在全域性的角度來分配計算的配額。例如針對動畫更新，我們設計了一個演算法，優先更新離你最近的以及最靠近視野中心的一個角色，其它的角色可以不更新或者是隔一定的幀數來更新。

另外，我們對特效的開銷也做了分級，每個特效型別都被分配了一定的權重，當整個特效型別的預算耗費達到了一定的指標之後，新的特效將不再產生。我們也特別開發了一套系統，來判斷主角和主角關係鏈上面的角色，例如同小隊、遊戲目標、攻擊主角的人，優先把配額分配給這些角色。

其次，我們也測試了角色LOD，在多人且相當近的範圍內，角色可以採用更加低的LOD級別，像這樣的兩個角色的多邊形數目，左邊的是 100%，右邊的只有左邊的15%，但是從遠處看起來基本上沒有任何區別。

所有的策略都建立在相機的位置和玩家的當前效能之上，而且各個模組可以根據當前的效能指標進行動態的Scale（擴充套件）。在多人團戰中，使用了動態預算系統，經過調校的多人戰鬥有了非常流暢的表現。


由於多人場景是一個非常動態的情況，所以會存在非常頻繁地載入和釋放的呼叫，為了防止卡頓，我們針對載入建立做了非常多的平滑處理。

例如，我們給定執行時候的角色載入數目上限，我們給Streaming（流式載入）和Loading（底層載入）層控制任何Geometry（物件）和材質的建立數目，甚至包括根據移動來載入的植被，也有平滑載入的機制來防止系統在過度震盪的情況下引起卡頓和多餘的計算開銷。

其實，平滑開銷的方法也會用在其它的系統裡面，例如，我們在處理最遠一級的陰影系統，計算物件之間的遮擋關係時，也是平滑到多個幀裡面來完成，避免單幀計算出現的卡頓。


那麼，回到底層的技術實現上，我們針對多人系統做了哪些？

首先是多個角色的GPU Instancing機制，可以在角色模型一致的情況下，極大限度地減少角色的渲染開銷。

其次，因為角色身上套裝量的開銷，美術手動製作LOD太過於麻煩，我們也整合了自動製作LOD的工具，在角色LOD的自動生成上有非常好的效能收益。通過角色LOD的方式，可以在Geometry Buffer時間上獲得一倍的資料提升。


另外，我們會把每幀更新之後的動畫資料寫入動態貼圖中，在Skining（GPU蒙皮）時，貼圖裡面讀取骨骼的Transform（矩陣變換），為了節省寫入動畫資料中的開銷，我們優化了這部分機制。從CPU更新到GPU的骨骼texture（貼圖）的過程中，可以看到傳輸過程中要做兩次拷貝，

第一次拷貝是從遊戲拷貝給顯示卡驅動提供的PCIE介面上的記憶體，第二次拷貝是驅動從PCIE拷貝至顯示卡上的視訊記憶體。在最早的實現下，這些寫入都是在主執行緒完成的，這妨礙了主執行緒的時間。當我們採用任務系統來更新動畫的時候，我們可以選擇直接在動畫更新完之後寫入，這樣的話，把寫入的開銷分散到不同的執行緒裡面完成，減少了主執行緒的整體開銷時間，資料傳輸上可以減少6到7毫秒的時間，相當於FPS從30幀提到43幀。


優化過程中，我們也發現了不少的問題。從程式的質量來看，分為如下的幾級。

第一級，我們認為是錯誤的級別。例如，錯誤地使用資料結構，主要是缺乏對演算法和硬體架構的認識，想當然地呼叫函式。如在vector裡面做遍歷來查詢，其實只要換成MAP 或者HashMap就可以獲得更好的效率。另外一個是在執行時建立字串的雜湊，會導致字串雜湊計算，並且在更新字串池的時候會有加鎖更新操作

再往上一級，我們認為是Normal級別。例如，某模組裡面需要每幀獲得玩家的高度位置進行計算，這個操作需要獲取當前玩家碰撞資料所在的三角形，根據這個三角面的Barycentric（座標）來獲取其精確的高度資料。這個級別上如果做得比較好，可以到達Good級別。

Good級別上，我們可以看看其它模組是否也需要每幀去獲得玩家的位置高度，然後我們每幀可以只計算一次，當每個模組獲取的時候，直接從cache裡面去拿到這個結果。

再往上，我們認為是一個更高階別的Great的做法，可以真正思考下，這個玩家高度是否真的需要一個準確的高度值，我們是不是可以實現一個粗略的版本。

最後一個級別，我們認為是從產品的角度出發，能和策劃、美術一起討論問題。例如，前面提到的規劃多人區域的方式，我們避免從不合理的角度來處理問題；又如，必須要求在場景最複雜的情況下達到多人場景的效能。


總結一下，多人場景優化的過程其實也是一個全面協同的結果，需要策劃、美術和程式一起從產品的角度上去考慮優化的問題，自上而下地對每個環節進行優化，使得《天涯明月刀》即便是在大規模團戰中，也能表現出優越的效能。