《天涯明月刀手遊》開發歷程：讓技術成為創新的驅動力

以下文章來源於騰訊遊戲學堂 ，作者騰訊遊戲學堂

講師丨Luke
騰訊互動娛樂 專家工程師

本文系騰訊遊戲“Rocket Plan”引擎技術沙龍-北京大學專場分享內容摘錄，分享主題為《〈天涯明月刀〉手遊技術研發分享》。敬請期待後續更多精彩內容上線。

《天涯明月刀手遊》2017年開始，歷經4年研發，2020年10月份正式上線。這裡我們將回顧一下整個專案的開發歷程，使大家對《天涯明月刀手遊》在技術層面有更深入的瞭解。


首先我們來看看《天涯明月刀手遊》一些比較有特色的遊戲內容。

高品質的捏臉系統：

捏臉系統向來是MMO遊戲必備的系統。《天涯明月刀手遊》在這個系統上表現了極高的品質，不僅完美還原了端遊的品質，甚至很多細節超過了端遊。

導致後續很多玩家反過來向端遊的開發組要求手遊的一些效果。

高開放性的戰鬥系統：

《天涯明月刀手遊》的戰鬥系統戰鬥表現上有著不輸動作遊戲的戰鬥效果，以及炫麗的技能表現。這套戰鬥系統從端遊開始有8、9年的沉澱，但是在表現出色的同時整個系統也非常的複雜。

這麼複雜的戰鬥系統，在多人戰鬥時對效能的壓力是非常大的。底層的效能優化可能是玩家看不見的，但卻能給很多玩家看得見的內容提供了基礎。

主機級別的場景渲染：






《天涯明月刀手遊》在場景的表現上也是非常出色的。大氣、植被、水面都有非常好的效果，在我們的PBR2.0架構下的夜景光照更真實，更能讓玩家感受到真實的武俠世界。場景的大視距和遠處細節的高精度非常讓玩家有沉浸感。以及我們的美術生產管線提供給美術極大的發揮空間，可以創作一些高度風格化的場景效果。

《天涯明月刀手遊》是一款以主機遊戲的畫面為目標的產品，因此我們在任何細節上都沒有放鬆。

無論是畫面效果、戰鬥系統、精緻的捏臉都是構建在天手引擎的基礎之上的，技術在整個產品的研發裡扮演了很重要的角色。

我們在技術方面有很多突破，這對行業產生了推動級的影響。我們研發週期大約是三、四年，但背後是有完整的十年的技術積累。

天涯明月刀引擎組是非常注重團隊技術積累的，在引擎技術的各方面都有詳細的knowledge graph，積累了各種技術實現和經驗總結。無論任何一項技術，無論團隊裡的任何同學，都很快能上手去開發，這是非常重要的。

時至今日，遊戲開發已經是一個非常複雜的系統性工程了。

遊戲開發，誰都想創新。而真正製作的時候才發現捉襟見肘，無法實現的想法太多。

接下來是靠技術發力解決問題還是限制創新做一個能做得出來的產品，是很多團隊需要解答的問題。

《天涯明月刀手遊》的整個開發歷程也是經歷了這樣的起伏。

《天涯明月刀手遊》開發歷程回顧


這是2017年剛開始研發時的畫面，美術在嘗試資源規格和效果，程式在新增各種基礎功能。


2018年遊戲已經展現了比較高的美術品質。但大量的細節也使效能問題突顯了出來。在這個鏡頭下，Drawcall達到800-1000，在當時驍龍835的CPU只能跑10fps左右。

對整個團隊來說，這是一個是否要妥協的關鍵點。對於《天涯明月刀》這樣一個IP來說技術上的妥協是不可接受的。

我們對Unity引擎做了大量的研究和分析，最終決定重寫整個底層的渲染管線架構以及使用Vulkan作為Android平臺預設的圖形介面。這是一個正確的決定，我們也因此在同期的產品中取得了很大的技術優勢，併為未來打下了基礎。


2019年我們又在多執行緒架構和Vulkan的基礎上引進了大量新技術。不斷的效能優化，給美術效果和遊戲內容留出了空間。

上面的畫面正是2017年的位置，可以說效果已經是天翻地覆了。


2020年是我們最後衝刺的一年。在這一年裡，《天涯明月刀手遊》又完成了大量的內容開發，以及不斷的適配調優，使我們能適配的機型不斷下探。我們也希望將遊戲能提供給更多的使用者。


要知道MMORPG在手遊開發裡面，可以說是最高難度的挑戰。

首先我們要面對海量的資源，而且這些高品質高規格的資源還要大量堆砌在遊戲中。尤其是團戰的時候，大量的玩家和特效進一步推升了效能壓力，而這個時候往往最需要保證效能的時候。

《天涯明月刀手遊》為了應對這樣的挑戰可以說引入了非常複雜的技術棧。


在引入這些技術的時候我們是有著明確的技術思路的。

資料處理的並行能力可以說是整個業界未來的方向，同時也是天手引擎技術的大方向。我們通過架構調整以及引入大量新技術，將引擎的並行處理能力推到最大。

在真正的專案開發中控制好如此複雜的技術棧是非常大的挑戰，對於關鍵性技術我們秉持了逐漸推出，不斷測試，不斷迭代的原則，以此來保證《天涯明月刀手遊》開發順利進行。

正是在這樣的思路的指導下我們完成《天涯明月刀手遊》一次比一次驚豔的四次對外測試。


這四次測試不僅是遊戲內容和品質的測試，也是我們比較大的技術里程碑，在每個測試階段我們均安排了一些關鍵的技術點對外驗證。

這裡面很多工作其實也並不是一開始就考慮到的，在四年的開發和測試周期裡，我們也不斷迭代，不斷提出更高的要求。

小樓一夜聽春雨

第一次測試我們主要對外驗證的是多執行緒渲染框架。


在與原生Unity的對比上我們可以看出在drawcall達到1000左右時原生Unity的渲染大約需要80ms一幀。

在《天涯明月刀手遊》最後上線時，我們通過各方面技術加持的優化將一幀的時間優化到16ms以內，有一個整體5倍的提升。


引擎設計的核心是對資料的處理，在重寫底層框架之初我們對整個引擎的資料處理做了詳細的設計。

我們將資料分為三部分：

• Renderer——供主執行緒遊戲邏輯使用，遊戲邏輯對這部分資料做直接修改。
• TranscriptRenderNode——供渲染執行緒使用，與主執行緒的Renderer對應，只儲存Renderer的渲染相關的屬性。
• 渲染命令和GPU Resource——提交執行緒是負責呼叫圖形API的執行緒，在這裡關心的只有要執行什麼渲染命令和對應的資料與GPU資源。
  

同時需要對這些資料的使用解耦，保證不同執行緒只使用自己的資料，對多執行緒架構的穩定來說最重要的就是資料的執行緒安全。這裡我們提供了兩種方式的資料轉換：

• Context形式，拷貝提交的方式
• Change-Update形式，資料改變以命令形式在不同執行緒的物件之間傳遞和更新的方式
  

同時針對一些需要在不同執行緒之間使用的資料我們提供了保證其生命週期正確的資料流控制方式。

比如一個RenderPipelineContext，由主執行緒生產，生產之後會以加引用計數的方式保證其不被銷燬。RenderPipelineContext後續會被渲染執行緒使用，做為一幀畫面渲染的上下文，並在渲染流程結束後減引用計數將其轉移至銷燬佇列。最後由提交執行緒真正銷燬，保證Context內的所有資源在當幀渲染命令全部結束後銷燬。

另外我們還引入Data-Oriented Design（DOD）的程式碼設計思想。

DOD與OOP不同的地方是在於，OOP是一個建立模型，讓複雜的問題更有邏輯更易於理解的程式設計思路，而DOD則是完全面向效能，以對資料的處理效能最優的方式去設計程式。

在這些設計的指導下，我們對引擎底層進行了大量的重寫，最終實現了一套更好的架構。


除了對引擎架構的重構，效能優化也非常依賴於對硬體的理解。

手機的硬體環境是非常複雜的，最新的CPU驍龍865、855都是4小核-3大核-1超大核的架構，再往前的CPU大部分是4大核-4小核的架構，再早的還有4小核-2大核等等不同的CPU架構。

由於對移動硬體來說溫度是非常重要的指標，因此手機廠商的控溫策略也是不一樣的，手段包括降頻甚至關核。

在如此複雜的硬體條件下我們要如何做好效能和發熱的均衡，這就需要對硬體做深入的瞭解和大量的實測。


通常來說手機廠商是不建議調整Thread Affinity的，CPU會有自己的排程策略以保證效能和溫度的平衡，但這也並不是一個絕對正確的選擇，真正什麼樣的方式是對專案有益的還是要理論結合實際的進行測試。

我們經過大量的測試之後，最終的方案是將除了主執行緒和提交執行緒以外，效能負載不算很高的其他執行緒都繫結在小核上。這樣做在多人戰鬥的時候幀數會有輕微的下降，但換來的是溫度上2-3度的收益。這在產品體驗方面可以說是更優的選擇。


另外測試比較多的是執行緒時序的調整。

提高硬體並行程度，在短時間內更充分的利用CPU，被證明是更適合手機硬體的方式。我們在沒有任何程式碼優化的情況下僅靠執行緒時序的調整就在不同手機上得到了3-9度的溫度降幅。

這種情況在我們團隊內部通常被稱為“低垂的果實”，即在大量底層工作都已經鋪墊好的基礎上能用很低的代價得到很好的收益。如此大的溫度降幅正是建立在天手引擎大量並行化的架構基礎上的。



整個天手引擎的開發過程也不是一蹴而就的，從一個專案開發的角度來說，一邊開發專案一邊做引擎的徹底重寫是非常困難的。因此我們在天手引擎的開發過程中也是非常小心地從專案收益最大化的角度去考量這個問題的。

在第一階段“內部測試版本”完成之後，我們有了一定的效能收益，但仍然有很多可見的優化空間。但我們並沒有繼續鑽在優化這一個點上，而是交付了一個版本給QA進行測試，保證這個版本的穩定。最終QA給出的測試資料無論是效能還是穩定性都得到了團隊的認可。

天手引擎正式加入版本構建之後很長一段時間我們都是雙線維護，即同時維護原生Unity和天手引擎兩個版本，美術和策劃仍在使用原始版本。

在這個階段我們不斷完善編輯器相關功能以及各種版本製作相關的功能，到2019年下半年，天手引擎才全面替代了原始版本。

這樣的開發節奏勢必對引擎組的效率有一定影響，但卻能最大程度的保證整個專案的順利進行。

江湖何處不飛花

Vulkan是我們第二次測試的技術里程碑


目前業界主流的仍然還是OpenGLES，Vulkan 2016年投入使用，但在《天涯明月刀手遊》開發的時期，Vulkan API還並不成熟。

Vulkan在理念上是有著巨大的進步的，在對GPU的使用上也給開發者更大的空間，但同時也提高了使用難度。我們從17年其實就開始關注vulkan了，但直到2018年才正式決定擁抱Vulkan。

通過引入Vulkan API，我們在大量渲染drawcall的情況下，效能進一步提升了20%-30%，並且使我們得以受益於後續其他新技術帶來的效能提升。

Vulkan真正使用起來難度是非常高的，相當於技術團隊來實現部分原來由驅動層實現的功能。在解決相容性問題和各種GPU hung問題的過程中，我們付出了大量的時間和精力。不過我們從這個過程中得到的經驗也是其他團隊無法比擬的。

更令人興奮的是在我們和硬體廠商緊密的合作當中反過來也使Vulkan更加成熟。高通、華為這些廠商都對天手引擎都給予了很高的評價。

與誰把酒邀明月

GPU Driven和Virtual Texture是第三次測試的技術里程碑。

在vulkan的基礎上，以及我們對引擎架構並行化的方向下，GPU Driven順理成章的成為了天手引擎後續開發的一個主要技術點。CPU和GPU之間的並行進一步優化了效能。


在圖形方面有了Vulkan之後，天手引擎就開始可以去挑戰主機平臺最前沿的一些技術了。

比如說AdaptiveVirtualTexture，它是主機平臺上面的地形渲染比較好的一種技術。應用這項技術可以在提升地貌豐富性的同時不增加渲染開銷。

但在手機上落地是非常的困難，裡面有大量的細節，天手引擎組的一位專家級工程師做了大約一年到一年半的時間，反反覆覆迭代優化細節。最後才在手機平臺上去跑通，使得地形渲染上能獲得平均約兩倍的收益。


另一個技術GPUDriven也是最新一代主機上比較重要的技術，將原來在CPU上的流程完全搬到GPU上，以資料驅動的方式實現，比如說地形剔除和渲染。

這部分做好後天手引擎就獲得了另一個非常強的技術優勢，原來可能都是十幾個渲染指令完成的事情現在只要一個，少了90%的開銷。同時由於可以在GPU上做更精細的剔除，渲染的頂點資料量數少了75%。

將我行兮向天涯

在所有這些效能的提升之後，天手引擎擁有了更大的發揮空間。於是引擎組跟美術一起在進一步提升《天涯明月刀手遊》的效果上開始發力。


當效能上有了足夠的空間後，負責渲染feature開發的同學和美術同學開始可以發揮實力了，將整體的光照水準大大的拔高一個層次。

《天涯明月刀手遊》的整個PBR2.0系統大致可以分為以下幾部分：

• BRDF，這部分除了一些優化演算法，不做大的簡化，保證物理正確。
• LookDev製作管線，保證美術在各個環境下都能得到最終遊戲內的視覺效果，製作正確的材質。
• 完整的光照分量，充分考慮各種光照分量的物理正確性，通過對光照分量的拆分在遊戲中體現Time of Day，體現動態的光照變化，體現遮擋資訊。
• 物理正確的渲染流水線，在材質資訊、光的方向和遮擋等資訊被正確計算的基礎上，如何在相機里正確的表現亮度、顏色等最終被玩家接收到的訊號也是非常重要的。符合物理的光源照度以及參考相機曝光原理為美術提供曝光設定可以保證美術能正確的設定亮度。再加上後期對Tonemapping演算法的調整，使得玩家能看到非常自然真實的光照效果。
  

以下是一些效果的對比圖：




PBR2.0系統下的夜景對比

原始場景：


PBR2.0的場景：




來源：騰訊遊戲學堂
原文：https://mp.weixin.qq.com/s/2LbPnmPJ62fAFJqyKV4lrA