《三角洲行動》雙端高品質的一體化生產管線與技術支撐【GDC 2024】

導語：在今年的遊戲開發者大會（GDC 2024）上，來自騰訊遊戲的專家持續帶來前沿分享，圍繞AI、渲染、跨端遊戲開發、動畫等遊戲技術應用及遊戲製作，引發同業關注。本文為“《三角洲行動》雙端高品質的一體化生產管線與技術支撐”分享的圖文版乾貨內容。

關聯閱讀：

《三角洲行動》世界建立：跨平臺開發美術管線和工具【GDC 2024】

分享嘉賓：施暘 騰訊互娛天美Y2工作室DF專案客戶端負責人

大家下午好，感謝大家參加本次會議。我叫施暘，是《三角洲行動》遊戲客戶端開發的負責人。本次演講原本應該由我的同事梁尚立和我一起進行。但是由於一些出行問題，他無法加入我們，所以我將獨自進行整個演講。

今天，我將分享《雙端高品質的一體化生產管線與技術支撐》，涵蓋了在開發《三角洲行動》過程中遇到的各種生產挑戰和問題。

首先，讓我們先看一個影片，以瞭解遊戲的基本情況。

《三角洲行動：黑鷹墜落》是在90年代末和2000年代初經典的《三角洲行動》系列的續作，我們決定將其帶回來，打造成一款面向PC、主機和移動裝置的下一代操作員戰術射擊遊戲。

我們的產品規模實際上非常龐大，希望為所有平臺的玩家都能帶來極致的FPS體驗。今天，考慮到PC和移動平臺之間的硬體差異，我們也會主要關注在這兩個平臺的跨端開發上。讓我們先來看看我們所面臨的挑戰。

首先是效能差距很大，幀率是FPS遊戲的基準。我們的目標是覆蓋每個平臺上的低端裝置，為了更好地利用平臺功能，我們決定執行不同的渲染器。另一個問題是支援跨平臺資料互通，我們必須同時開發和釋出內容，這也就意味著移植不是一個可行的選擇。而且，分別為每個平臺負責的兩個獨立團隊在生產和維護效率方面也是不可接受的。因此，我們決定構建一個統一的端手一體開發流程。我們的目標是同一團隊在同一時間交付高質量的跨平臺遊戲。


讓我們來看一下總覽，在我們決定統一跨平臺開發的初期階段，我們實際上經歷了激烈的討論，並設想了許多潛在的問題。基本上，我們將重點分為兩個主要領域，一個是生產流程部分，更多關注資產和內容的製作，另一個是跨平臺執行支援，主要涉及遊戲開發和效能跟蹤工具。

這裡列出的並不是一個完整的列表，這只是其中的一部分問題，實際情況要複雜得多。今天我們無法詳細討論每個細節，但我們選擇了一些我們認為重要且具有挑戰性的典型問題，與大家分享一些想法和方法。


讓我們從資產製作部分開始。

基本上，我們為不同型別的資產設定了不同的共享策略。但是如何構建跨平臺場景是最複雜的問題之一，涉及到單個模型的製作、LOD管理、著色器管理、關卡布局編輯、效能開銷甚至關卡藝術家的工作量。這是我們今天主要關注的生產流程部分。

那麼，首先讓我們看看在跨平臺共享資產時出現了哪些問題？


對於共享資產，我們首先需要解決的問題是如何在同一材質槽中支援兩套著色器。第二，我們充分利用了LOD鏈，但作為一款FPS遊戲，我們不能容忍任何碰撞不匹配。此外，PC和移動裝置之間存在著紋理解析度和畫素比的差異。這導致紋理大小和壓縮設定的變化。當我們在不同平臺之間共享資源時，我們需要在非目標平臺上刪除冗餘資料，以避免記憶體和磁碟儲存的浪費。當然，還有許多其他更細節的問題。


在同一模型中管理不同的著色器非常棘手，特別是我們有多個渲染器，我們在PC和高階移動裝置上執行延遲渲染器，並在其他移動裝置上使用前向渲染。為此，我們實現了一套虛擬材質系統。顧名思義，它用於虛擬化材質。它提供瞭解耦資源和著色器的能力，以及自定義資源組織規則（如紋理通道重對映）的能力。它還維護了多平臺和多質量級別的資源配置，以及我們的模組化材質和功能重用。

在編輯器模式下，虛擬材質模板儲存了不同平臺和不同質量級別的基本材質資訊。然後，它被例項化為虛擬材質例項，並分配給共享模型元件中的材質槽。

在執行時，在打包後的版本中，虛擬材質例項將回退到普通的材質例項，而且其中非目標平臺的資料也會被去除。


下面是一個示意圖，說明了虛擬材質的使用方式。資料提供器主要完成紋理資料的收集，暴露虛擬材質模板使用的紋理槽，管理不同質量級別的資源，並適配資料。效果層由兩個功能組成：材質效果邏輯和與上層的混合方法。混合控制器是一個獨立的邏輯層，處理複雜的混合方法。透過虛擬材質系統，我們基本上將材質與渲染器解耦，使得著色器在不同平臺上甚至在同一模型元件內非常靈活。


除了材質和著色器，第二個典型問題是碰撞。讓我們來看一下這個短影片。當LOD索引偏向移動平臺時，我們開始丟失網格細節，在這種情況下，欄杆從LOD3開始被移除，但我們只能在網格元件中有一個碰撞資料，這將導致碰撞不匹配，對於FPS遊戲來說，這是完全不可接受的。那麼，我們該怎麼解決這個問題呢？


解決方案實際上非常直接。我們擴充套件了碰撞設定，併為其新增了每個平臺的資料。透過這樣做，我們可以在保持一致的遊戲互動的同時，適應其獨特的效能限制和質量要求。

在修正了碰撞資料之後，現在PC和移動平臺都具有了與其渲染模型相匹配的正確碰撞。實際上，每個平臺的屬性方法也被擴充套件到其他資產型別和物件上。例如，天空光立方圖在每個平臺上具有不同的紋理和壓縮設定，另一個例子是相同靜態網格元件的光照貼圖，因為我們在同一關卡中為不同平臺單獨烘焙光照貼圖。

關於更多資產製作的細節，我們工作室的技術美術負責人王理川在之前的演講中從技術美術的角度進行了介紹。如果你感興趣，可以在那裡找到更多資訊。（檢視詳情>>）


好的，一旦我們準備好了所有的資產，問題就變成了如何高效地構建一個在各個平臺上都符合質量和效能標準的沉浸式場景。我們需要關注不同平臺的場景豐富度以及如何管理由於移動硬體限制而產生的不同載入距離。不僅如此，在相對複雜的資源管理和編輯工作流中，我們需要在打包成構建之前識別錯誤。此外，一些特定的最佳化在不同平臺上也有所不同。


總體思路是從兩個方面管理關卡內容。首先，我們有基本的共享層，只包含共享的資產。在此基礎上，我們將適當地拆分平臺特定的內容，並讓它們進入各自的專屬層。另一個方面是資產型別，在右上方的影像中，我們將資產型別分類到不同的層級中，以便更好地管理。

對於需要關卡美術參與的部分，我們儘量減少相關工作量，這意味著大部分內容實際上屬於共享層，並確保基本的關卡布局在各個平臺上與關卡設計師的意圖保持一致。然而，對於特定平臺的內容仍然會進行微調或調整，例如為PC增加豐富性或為移動裝置進行最佳化。影片中展示了關卡截圖的端手對比。

對於由PCG或其他自動化工具生成的內容，因為不需要人工參與，我們完全分離了關卡組，並將其輸出到每個平臺。


在一個大型專案中，隨著跨平臺製作流程的進行，實際上增加了管理的複雜性。我們不可避免地會遇到一些人為錯誤和協作問題，例如放置錯誤的資產、錯誤的平臺引用、紋理浪費等。為了有效消除這些錯誤，我們提供了一套與資產相關的故障排除工具，幫助進行錯誤檢查、提供效能建議和資料統計。影片展示了我們如何透過分析紋理相似性來找出不必要的紋理浪費。


在所有編輯和配置工作完成後，我們不能直接執行關卡。為了滿足我們的規定和效能要求，我們將所有編輯狀態的關卡轉換為執行時關卡。為了實現這一點，我們對執行時關卡進行了更詳細的分層，如圖所示，我們在PC和移動裝置之間有不同的關卡劃分和流式傳輸配置。

射擊遊戲中的另一個典型問題是瞄準，對於PC，我們切換關卡可見性。但對於移動裝置，我們採取了一種平衡的方法，即在瞄準時只流式傳輸視錐內的關卡。

最終，我們的目標是擁有相同的資產、相同的關卡，但透過不同的執行時關卡實現在每個平臺上穩定的效能！


讓我們來看看構建執行時關卡處理的內容。

首先，需要清理未使用的Actor，通常這些都是除錯用的Actor。二，為了提高專用伺服器的效能，物理資料被提取和合並。三，所有的植被都被轉換為每種型別的流式資產。因此，我們可以詳細管理植被的記憶體成本和繪製呼叫。四，地形也被轉換為CDLOD。五，根據位置和邊界大小，網格被自動劃分為不同的級別網格。最後，還需要處理一些其他與遊戲玩法相關的資料。


我們已將整個構建過程整合到自動化工作流中。它分析原始關卡，重新分配資產，生成相應的資產型別，提取關鍵資料，執行特定的最佳化，並自動收集基本的效能統計資料。模型合批是唯一專門為移動平臺定製的部分，而其他過程在各個平臺上保持一致，只有不同的配置。


這是關於移動平臺批處理的核心策略的簡要介紹。首先，我們需要確定批處理一組模型的可行性，包括檢查具有引數的材質、紋理格式、光照貼圖、陰影投射和IBL。批處理還需要驗證其合理性，例如頂點數是否超過限制，紋理解析度是否能滿足預算紋理集的容量，以及距離是否合理。我們最終的批處理結果展示了良好的區域性空間感，並且顯著減少了繪製呼叫。


現在讓我們進入執行時支撐部分，我們將分享一些跨平臺的渲染策略和功能，以及如何統一遊戲開發，還有一些關於效能跟蹤工具的內容。

讓我們先來看看渲染部分。


如前所述，為了更好地利用不同平臺的特性，我們決定執行不同的渲染管線。然而，我們仍然努力在一些主要特性上保持一致。這個圖表展示了渲染方案的具體示例和細分，突出了相似性和差異性。在確保整體一致性的同時，我們還在底層技術上進行差異化開發，以滿足各種質量和效能要求。


在光照方面，我們確保光照元件的一致性，從而在各個平臺上實現類似的光照感知。為了實現這一點，我們採用了一些底層技術，為相同的光照元件實現了不同的方法。例如，天空遮蔽由我們的跨平臺全域性光照解決方案統一提供。但是，對於更詳細的環境光遮蔽（AO），移動裝置更多地依賴於紋理烘焙，而PC則利用GTAO和距離場AO。透過在光照元件上保持一致性，我們的光照藝術家不需要擔心跨平臺差異。


對於全域性光照（GI）部分，我們的演算法是基於體積的，但體積中的體素不儲存任何光照資訊。相反，它們儲存了稀疏分佈的探針和離線擬合的權重。

為了降低整體複雜性，PC和移動裝置之間的共同點包括：

• 相同的離線探針分佈演算法（但密度不同）。
• 相同的資料擬合演算法。
• 相同的基於塊的流式傳輸邏輯。
  

差異主要在於不同的最佳化方向。

移動裝置的資料密度較低，因此離線資料由CPU讀取並組裝成3D紋理，GPU只執行簡單的取樣以最小化GPU負載。因此，移動裝置上的最佳化更加關注CPU讀取，增強快取友好性和資料壓縮，以減少記憶體成本和磁碟儲存。

PC的資料密度較高，因此資料直接載入到圖形記憶體中，GPU實時讀取擬合的權重，並在那裡動態解壓光照資料。PC上的最佳化更依賴於資料儲存格式，我們使用樹狀結構和稀疏儲存來最小化執行時圖形記憶體。此外，還新增了更多的非同步機制，以防止從CPU傳送資料到GPU時出現卡頓。


一旦我們實現了光照的一致性，我們可以在更高層次上封裝一些統一的引數介面來實現時間流逝（TOD）。在這裡，我們使用一個序列管理器來驅動所有的TOD引數。大多數常見的引數都在基礎序列器中實現，而微小的平臺差異則由子序列驅動。


另一個重要的部分是地形。當我們在PC上實現一些先進的技術以獲得更好的質量和效能時，我們始終考慮到移動裝置的適應性，並最終成功將其中的一些技術帶到移動平臺上。


我們為移動平臺進行了許多最佳化，以實現與PC相似的質量。

• 自適應動態紋理陣列為整個世界帶來了32種材質，但執行時只需8種材質的記憶體成本。
• 我們使用隨機三平面混合實現了懸崖渲染，首次使用VT技術，並首次將其引入移動裝置，極大地提高了地形質量。
• 為了在移動裝置上實現每米溼度和色調，我們新增了剪輯貼圖紋理流式傳輸，它可以將大型紋理的記憶體成本從133MB減少到不到2MB，幾乎降低到1%，並幫助我們提高移動裝置上的地形多樣性。
• 對於地形的遠景檢視，我們還實現了具有380K頂點細節的地形，而效能成本僅為80K頂點，而不會丟失任何質量。
  

更詳細的資訊，請檢視由徐雲瀚在Unreal Fest 2023上的演講。


好的，遊戲玩法部分。我們也為遊戲玩法開發構建了許多跨平臺解決方案，但今天我們主要談論戰鬥和使用者介面部分。


在核心戰鬥開發中，我們仍然採用了一種整合的方法，適用於PC和移動平臺。整體戰鬥特性分為三個層次。核心特性層是與平臺無關的基礎，包括遊戲玩法框架、網路模型、移動同步、武器射擊和其他戰鬥細節。靈活特性層提供可擴充套件的跨平臺配置，我們可以根據效能預算和質量水平動態確定啟用哪些特性。平臺特性層處理平臺特定的適應，如輸入控制器或HUD互動。


在我們的專案中，基本骨架在PC和移動裝置之間是共享的。

如圖所示，骨骼物理模擬的複雜性也有所不同，我們在PC上新增了更多的子骨骼和動態細節。動畫的建立基於角色的相同父骨架，確保大多數動畫片段在各個平臺上保持一致並可重用。然而，PC上的動畫具有更高的動畫幀數和更好的壓縮設定。


在動畫特性方面，大部分特性同時針對PC和移動平臺進行開發。考慮到效能限制，我們還在移動平臺上提供了一些替代方案，透過犧牲一些質量來實現相同的效果。例如，換彈動畫，我們在PC上提供完整的動畫片段，但在移動裝置上使用IK來模擬相同的效果，實際上很難區分出差異。


為了根據效能預算動態確定啟用哪些特性，並在每個裝置上實現最佳整體效能，我們使用了一種規劃演算法。實現方法涉及使用規劃演算法，考慮特性的靜態質量和動態執行時條件，定義每個特性的“價值”。然後，在現有的約束條件下選擇最佳的特性集合，包括效能限制和特定特性的約束。整體規劃演算法有點複雜，但基本思想類似於揹包演算法。透過有限次迭代，我們旨在找到滿足約束條件的最佳特性組合。


讓我們來看一下最終的規劃結果：在左側的影片中，我們可以看到在不同預算配置下多個玩家的移動質量。隨著預算的增加，玩家的不真實移動的可能性減少。而遠處的角色在移動行為中不會犧牲諸如地板檢測之類的特性。自然而然地，PC可以啟用更多和更高質量的特性，而移動裝置只能為少數幾個角色啟用有限的特性。

右側的影片展示了遊戲中的最終結果。在遊戲中有64個玩家，存在著相當大的效能壓力。它有效地平衡了效能預算和遊戲呈現，實現了流暢的結果。


對於使用者介面部分，也需要大量的跨平臺工作量。因此，我們的大多數UI頁面是透過自適應UI框架共享的，而一些重要系統是單獨開發的。

為了提高共享UI頁面的效率，我們將平臺特定的引數提取到框架層。首先，DPI曲線被分離出來以更好地適應螢幕尺寸。PC需要處理更廣泛的顯示比例範圍，因此我們新增了比例約束以防止異常顯示問題。在視覺設計階段，我們以一個平臺作為基準，然後在一定的規則下對其他平臺進行調整。不同的平臺具有不同的UI導航方法，因此我們將它們提取並分離到導航層中。我們還提供了各種快速調整選項，例如填充、縮放、調整大小和節點裁剪，以進一步微調最終的UI。


為了更好地共享UI資源，這是我們的原始資源標準，我們選擇2K作為基本解析度。在cook過程中，原始的2K資源被壓縮到1080P用於移動裝置。但是對於PC，資源在執行時透過DPI動態縮小到66.67%，以實現與4K解析度相同的效果。一個小提示是在PC上啟用mipmapping以避免畫素不匹配，以避免閃爍。請參考右側的影片進行比較。


好的，最後一部分，效能。


為了更好地監控和分析與效能相關的問題，我們嘗試了各種工具，但似乎沒有一個符合我們的要求。我們需要的是一個跨平臺工具，不需要任何預先插樁，支援長時間和廣泛的資料收集，而不會影響執行時效能。因此，我們開發了自己的跨平臺效能監控和分析工具，名為metaperf。


效能捕獲的整個迴圈由3個階段組成。在記錄階段，我們為所有平臺實現了高效能取樣器：透過結合每幀的幀時間和自定義資料，我們可以獲得每幀的各種遊戲狀態；然後，透過處理每幀的時間戳併合並樣本中的所有呼叫鏈，我們可以獲得一幀的完整呼叫樹。在最後的分析階段：我們實現了一個基於規則的自動化分析監控服務。這包括各種自動化分析方法，如皮爾遜相關係數。透過比較兩個曲線之間的相關性，我們可以確定效能指標中每個函式的相關性。


metaperf工具已經在我們的專案中廣泛使用，並收集了10000多個遊戲記錄。幫助我們識別和解決了1000多個與效能相關的問題。


好了，總結一下。沒有正確的解決方案，只有合適的解決方案，我們分享的只是實現高質量和高效能跨平臺開發的一種可能方式。您應該根據產品和團隊的情況找到解決方案。工具對於開發效率來說非常重要。希望這次交流能給您一些啟發。


特別感謝整個《三角洲行動》開發團隊，幾乎每個人都提出了建議和反饋，使我們能夠不斷迭代和最佳化流程，使其變得更好。

相關閱讀：

《三角洲行動》世界建立：跨平臺開發美術管線和工具【GDC 2024】


來源：騰訊遊戲學堂