尋夢新聞LINE@每日推播熱門推薦文章，趣聞不漏接❤️
以下為本次分享實錄
《天涯明月刀》引擎的主要優化經歷
縱觀整個《天涯明月刀》的發展歷史，從優化的角度來看，大概經歷了以下過程：
-
在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拷貝至顯卡上的顯存。
第一次拷貝是從遊戲拷貝給顯卡驅動提供的PCIE接口上的內存，第二次拷貝是驅動從PCIE拷貝至顯卡上的顯存。在最早的做到下，這些寫入都是在主線程完成的，這妨礙了主線程的時間。當我們採用任務系統來更新動畫的時候，我們可以選擇直接在動畫更新完之後寫入，這樣的話，把寫入的開銷分散到不同的線程里面完成，減少了主線程的整體開銷時間，數據傳輸上可以減少6到7毫秒的時間，相當於FPS從30幀提到43幀。
優化過程中，我們也發現了不少的問題。從程序的質量來看，分為如下的幾級。
第一級，我們認為是錯誤的級別。例如，錯誤地使用數據結構，主要是缺乏對算法和硬件架構的認識，想當然地調用函數。如在vector里面做遍歷來查詢，其實只要換成MAP 或者HashMap就可以獲得更好的效率。另外一個是在運行時創建字符串的哈希，會導致字符串哈希計算，並且在更新字符串池的時候會有加鎖更新操作。
再往上一級，我們認為是Normal級別。例如，某模塊里面需要每幀獲得玩家的高度位置進行計算，這個操作需要獲取當前玩家碰撞數據所在的三角形，根據這個三角面的Barycentric（坐標）來獲取其精確的高度數據。這個級別上如果做得比較好，可以到達Good級別。
Good級別上，我們可以看看其它模塊是否也需要每幀去獲得玩家的位置高度，然後我們每幀可以只計算一次，當每個模塊獲取的時候，直接從cache里面去拿到這個結果。
再往上，我們認為是一個更高級別的Great的做法，可以真正思考下，這個玩家高度是否真的需要一個準確的高度值，我們是不是可以做到一個粗略的版本。
最後一個級別，我們認為是從產品的角度出發，能和策劃、美術一起討論問題。例如，前面提到的規劃多人區域的方式，我們避免從不合理的角度來處理問題；又如，必須要求在場景最複雜的情況下達到多人場景的性能。
總結一下，多人場景優化的過程其實也是一個全面協同的結果，需要策劃、美術和程序一起從產品的角度上去考慮優化的問題，自上而下地對每個環節進行優化，使得《天涯明月刀》即便是在大規模團戰中，也能表現出優越的性能。
·END·
如今我們看到的天刀是整個項目組上下一心不斷努力的結果，更少不了追求遊戲品質的玩家們的好建議٩( ‘ω’ )و 來和刀娘聊一聊玩天刀以來性能和畫質的體驗吧~
↓↓快給刀娘設置星標吧↓↓