鵝廠遊戲開發的引擎中臺都涵蓋了哪些內容？

2020年12月8日，由騰訊遊戲學院舉辦的第四屆騰訊遊戲開發者大會（Tencent Game Developers Conference，簡稱TGDC）進入了第二天的議程。來自騰訊互動娛樂研發效能部的引擎核心技術組負責人魏楠先生，分享了建設引擎中臺過程中，核心渲染、內容工具和開發效率等方面的實踐經驗。以下是分享視訊和文字實錄：


今天主要分享，在過去一段時間，我們作為技術中臺，和騰訊遊戲內部很多專案合作、協助3A手遊開發時積累的一些技術經驗。

隨著手遊市場不斷變化，玩家對手遊的品質要求也越來越高。什麼是一個3A高品質手遊呢？其實可以借鑑傳統的主機遊戲作為參考。如下圖，都是獲得玩家高度認可的3A主機遊戲。


通過我們的觀察和分析，以下幾點非常重要：

• 渲染效果。如果大家比較關注遊戲技術發展的話，渲染一直是其中非常重要的一環。畫面的質量對於遊戲的體驗是至關重要的一個環節。
• 海量內容。隨著給玩家提供的內容越來越多，玩家所能探索的東西也會越來越多，可以極大豐富玩家體驗。
• 豐富玩法。如果可以提供豐富的玩法，玩家就可以獲得不同的樂趣。
  

綜合上述，如果能夠實現這些，就可以給玩家頂級體驗。而作為技術中臺，我們因為資源、人力等各方面的限制，不可能所有東西都做，所以我們只能聚焦於幾個最核心的能力：

• 核心渲染。我們希望能通過核心渲染技術上的一些突破，幫助專案組在移動平臺上真正實現質的提升、飛躍；
• 內容工具。因為要生產更多、更高質量、不同樣式的內容，我們肯定需要在工具側也做一些突破。通過這些工具幫助整個專案組，或者製作人員實現這些內容的生產；
• 開發效率。隨著內容增多、玩法豐富，團隊的開發效率也會遇到瓶頸。提高開發效率就成了至關重要的一環，這會對最終的遊戲品質有非常關鍵的影響。
  

基於這些考慮，我們做了以下具體措施來發揮中臺優勢：

核心渲染


首先是移動端渲染管線開發。我們跟很多專案組合作，他們對動態、光照和陰影的訴求越來越強烈。目前來看，光照是整體渲染效果最核心的一個環節。

基於這方面考慮，首先我們會把所有資源投入在移動端延遲管線的開發上，在移動端實現一套延遲管線，來提升整體遊戲畫面。

在開發過程中，我們劃定了三個非常重要的目標：

第一，效能提升。我們希望能在移動平臺硬體效能有限的情況下，真正支援到百盞動態光源。效率、效能能夠同時滿足具體遊戲專案的要求；

第二，頻寬、功耗優化。在手機上，不管是發熱還是電池消耗，都會影響玩家體驗；

第三，相容性。鑑於手機硬體非常豐富，各廠商之間不管是特性還是Driver層面，都有很大的差異，所以做好相容性也非常重要。我們希望在低端、中端、高階，不同硬體廠商上，都能有非常好的覆蓋。


基於這三點，我們在整體開發過程中總結出了以下經驗：

第一部分，通過對光源比較徹底的優化，預期可以提升20%-25%的效率；

第二部分，在頻寬層面針對不同的GPU，比如ARM的Mali、高通的Adreno，充分利用這些硬體的特性，我們可以達到25%-30%的頻寬節省。有了這樣的節省，我們在一些手機上的測試結果，有2℃-4℃的降溫，極大提升了玩家體驗；

另外在內部測試和實際落地專案中，從一些專案測試的資料反饋來看，不管是在低端、中端、高階上，使用這一套移動端延遲管線，在效能上都可以和當前主流的前向管線保持一致，甚至超越前向管線。

當然最後還是有些問題，因為本身前面提到諸多複雜性。所以如果要解決，需要有一套非常複雜的方案，這會進而極大提升整體實現的複雜度。所以就會帶來整體引擎側的維護成本、複雜度提升，這是大家需要非常注意的；


第三部分，需要在整體實現過程中考慮硬體、API，甚至一些Driver方面的問題和限制。這樣才能有針對性地解決問題。針對於硬體和API限制，這裡列舉了一些我們的經驗。

比如在Vulkan方面，因為Vulkan本身會提供一些非常有價值的新特性和擴充套件，在實現上會簡單一點，而且對效能和功耗優化都非常明顯。

但是有一個最大的問題，當前市場上能夠支援的硬體非常有限，同時Driver層面的支援也非常薄弱。因為廠商多年精力都放在OpenGLES上，Vulkan只是在近一兩年，才逐漸轉換成一個重點，所以這部分應該非常留意。

另一方面是OpenGLES的優勢。第一，廠商硬體支援非常廣泛，大部分都有對應特性支援，Driver上面也比較成熟。最大的問題是各個廠商往往提供了一些擴充套件，它們各方面有非常多差異。比如我們核心的，針對功耗方面的優化，在ARM、Mali和高通的Adreno GPU上就需要使用到不同的擴充套件。這樣就會明顯提升整體實現的複雜度和維護成本。

最後在Metal這邊也有OpenGLES的優勢。目前支援各方面還是比較好的，主要是因為有廠商來做這個，所以相對來說是最容易支援的一套API。

內容工具

第二部分給大家介紹一下，針對海量內容生產開發的一套工具——基於Houdini的PCG工具。


目前看來，特別是針對開放大世界、MMO這種品類的遊戲，因為本身場景非常巨大，內容資源量也非常大，就需要藉助一些程式化生成的方式來提升團隊製作效率。往往大家都會圍繞Houdini來開發一套PCG生產流程。而對於我們團隊來說，開發這套工具最關鍵、最核心的是關注整體流程。

從經驗來看，不同的專案對不同的效果、資源一般都有不同的需求，所以在效果側最好還是由專案組自己解決。而對我們來說，能做的就是提供一套工具，讓專案組靈活、快速，並且複用性地開發自己的流程，這是最關鍵的一點。同時也能幫助他們，把這套流程合理而有機地和整體引擎整合在一起，這是我們工作最關鍵的部分。

基於這些思考，我們開發了一套基於Houdini的PCG流程工具。這裡第一個最核心的概念就是基於一個叫Node Graph PCG Flow的流程工具。這套工具最核心的想法，其實就是可以通過節點圖的形式靈活定義自己的整體PCG流程。


在這個Flow圖裡，我們有不同型別的節點，包括輸入、輸出、處理節點。靠整體資料流把這些所有的節點串聯起來，通過輸入和輸出節點和引擎進行資料交換，並來完成定義整體程式化生成的流程。

在這些處理節點裡，我們可以把不同的Houdini處理節點封裝在裡面，甚至一些我們自己完全獨立開發的程式化生成演算法也可以放到這個節點圖裡，然後把這些處理流程串聯起來。

接著給大家展示一下，我們針對這套Flow流程工具開發的一些資料輸入工具：


第一個工具是曲線工具，因為曲線作為河流、道路生產最重要的輸入資料，是非常重要的。我們想給大家開發一套工具，能夠非常靈活地定義、修改曲線。右邊是我們開發的Mask工具，它對於在整體引擎裡標註整體區域、在區域裡面進行程式化生成，是非常重要的一個源資料。所以我們也開發了一套Mask工具，幫大家靈活地定義這個型別的資料。


同時我們也提供了一套完整的Houdini HDA Library給專案組使用，可以讓專案組基於我們已經開發的一些Houdini HDA，根據專案本身的一些需求，在整體這些HDA基礎上進行一些擴充套件、定製或者修改，快速搭建自己的流程。

包括地形、植被、道路、河流、岩石、建築等等，這些HDA會提供一些最基礎的功能。目前我們這套工具在騰訊遊戲內部已經有幾個專案在使用，我們看到，專案組可以非常快速地利用我們這些工具來靈活搭建流程、快速實現一些Prototype工作，也能驗證自己整體流程上的一些想法。


接著給大家介紹一個叫做Superman的面部表情動畫工具。這套工具主要針對表情動畫和捏臉的需求，它支援任意3D角色的面部定製，支援自動繫結、快速捏臉、表情系統，以及口音等數字資產製作，同時可以結合專業的面部資料對接。甚至簡單一點，iPhone上的AR Kit也可以與它對接。


這套工具最主要的優勢有三點：

第一是功能全面，支援谷歌框架和Blendshape資料的自動雙向轉換；

第二是通用性較強，從具體專案組來看，這套工具可以支援不同風格，包括寫實、Q版角色等。它的操作非常簡單，不管是安裝還是功能，整體都對美術側非常友好，只需要簡單兩步就可以讓美術使用起來；

第三是開發效率明顯提升，這也是最關鍵的一點。關於效率，這邊有一些具體資料。


比如自動繫結，傳統做法一般需要一週時間做好一個繫結。但如果使用這套工具，就可以在一小時的級別完成；

捏臉系統方面，有些專案可能需要一週左右才能初步搭建。但如果使用這套工具，大概兩天就可以完成；

在表情製作方面，通常專案大概需要1.5周左右。如果使用這套工具，大概兩天左右就可以完成；

最後，情緒、口型資產生成，藉助自動化生成，可以從以前的1.5周時間變成馬上生成，基本可以忽略不計。

開發效率

返回到前面提到的光照本身，它是渲染最核心的效果，即使有像延遲管線這樣的技術，對於動態光源、光照，我們能有非常好的支援，但是像間接光照這種，我們依然需要藉助一些預計算的方式才能比較好的支援到。

目前來看，主流引擎裡的光照烘焙會是一個計算量非常大、非常耗時的過程。有些具體專案裡，比如前面提到的開放大世界專案一個像5K*5K的地圖，烘焙一整套圖往往需要一整天時間。這樣就極大限制了開發效率。

所以基於這些問題，我們利用GPU開發了一套GPU加速的光照烘焙系統。這裡開發其實有幾點需要注意：


第一，雖然開發了一套新的系統，但肯定還是要保證它和以前的舊系統在整體烘焙的效果、質量上完全對齊，甚至在個別點上做到超越；

第二，我們的初衷是要大幅提升整體烘焙效率。從實際情況來看，我們確實可以將效率提升一個數量級的；

第三，這套系統應該是一個比較好、完備的、可以進行功能擴充套件的系統。我們在後期開發一些功能時已經驗證了這一點，比如我們在光照烘焙系統上又增加了一些新的烘焙特性，來支援一些新的需求。


這裡是一個簡單的效果對比圖，基於CPU光照烘焙系統和GPU烘焙系統的截圖。

從圖裡標註出來的地方可以非常明顯地看到，CPU光照烘焙系統的漏光還是比較嚴重的，而GPU烘焙就完全避免了這些問題。要實現這些效果，最主要還是在演算法、實現方式上對CPU這邊的一些改進和差異所提升的效果。

另外，這裡也有關於烘焙效率的一個對比。這是我們在半年前的測試資料，裡面基本上是有三組資料，第一組，像藍色標出來的是這套CPU光照烘焙系統大概需要多長時間。中間這部分資料，我們測試的時候是一塊2080 Ti的顯示卡。右側資料是我們自己搭建的GPU伺服器，一臺有八塊Quadro RTX 6000的顯示卡。


通過這個資料對比我們看到，在單塊GPU上我們一般效能提升會有3-7倍。如果是針對一臺伺服器做對比，我們一臺伺服器大概會有15-30倍的提升。

這裡的資料差異，主要是因為在不同場景裡，因為烘焙時任務有一定差別，所以有些任務效率提升會高一些，有些會低一些。但是整體上如果和伺服器對比，我們認為基本上會是一個比較大的數量級差別。所以就像前面我提到的，像5K*5K的地圖，一般CPU需要一天，我們這邊可能一個小時，甚至一個小時之內就可以完成烘焙。


最後介紹一下我們開發的一套分散式構建系統，主要目的是利用分散式系統提升整體遊戲構建效率。目前來看，引擎本身編譯、資源場景、構建、打包等等流程，都是非常耗時的。因為有一些實際專案可能會出不同的版本，整體上有些是幾個小時，甚至確實以天數計。這樣的時間會嚴重製約專案開發進度、迭代效率。

其實不管用多麼強勁、單一的一臺構建伺服器，也沒有辦法完全解決這個問題。最好的方式，是把一個耗時的處理流程放到分散式環境裡，利用分散式環境大量的計算能力、可擴充套件能力，來更好地解決問題。

另外目前來看，像我們這樣一箇中臺部門其實有很多的計算資源，這些資源平時也會空閒下來，如果能夠在平時集中式地利用，對資源利用率也會有一個非常好的提升。

基於這些想法，我們開發了這樣一套分散式構建系統。開發同時，我們最開始可能只會盯著一兩個任務來做，但是在做的過程中我們感覺到，構建流程當中任務種類非常多、非常複雜。這就要求我們最好是開發一套開放式的作業框架，在這套框架中隨著開發程式不斷改進，讓不同形式的任務都能完全納入到這套框架裡，讓這套框架能不斷提升本身能力。

同時，系統還提供了一些相應的Cache機制。因為本身在一個團隊裡，有可能一個使用者的構建結果對另一個使用者也一樣，如果我們有一套比較好的Cache機制，就能夠保證這些處理完結果的複用。這樣會更進一步地提升整體系統效率和利用率。基於這些，這套系統能非常顯著地提升整體程式、美術的工作效率。


這裡面其實還有一個比較重要的一個部分，就是這套構建系統需要對於不同平臺的支援。因為目前來看，我們不單單需要讓這套系統跑在Windows上，同時還要能跑在MacOS、Linux上。不僅僅能構建出來PC版本、安卓版本，同時也要能構建出iOS版本。

所以在開發這套系統時，我們就需要充分考慮跨平臺問題，選擇比較好的實現方式。這邊有一些目前這套系統的實際執行資料，我們測試時大概是使用像32核64執行緒這樣CPU的一臺伺服器進行構建引擎，大概需要半個小時左右。如果使用我們的分散式構建系統，我們使用四臺伺服器構建，整體時間可以縮減到大概8-10分鐘。


而另外一部分是Shader構建，以往做法需要550秒左右完成測試地圖的構建。而利用分散式系統，我們可以把整體時間縮減在150-200秒之間。


好的，最後總結一下今天的分享。作為技術中臺，通過打造一些核心的基礎能力，包括渲染、內容製作工具、整體管線開發效率，其實可以顯著地協助到遊戲團隊來開發3A手遊。