導語：在今年的遊戲開發者大會（GDC 2024）上，來自騰訊遊戲的專家持續帶來前沿分享，圍繞AI、渲染、跨端遊戲開發、動畫等遊戲技術應用及遊戲制作，引發同業關注。本文為“《三角洲行動》雙端高品質的一體化生産管線與技術支撐”分享的圖文版幹貨内容。
分享嘉賓：施旸 騰訊互娛天美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多個與性能相關的問題。
好了，總結一下。沒有正确的解決方案，隻有合适的解決方案，我們分享的隻是實作高品質和高性能跨平台開發的一種可能方式。您應該根據産品和團隊的情況找到解決方案。工具對于開發效率來說非常重要。希望這次交流能給您一些啟發。
特别感謝整個《三角洲行動》開發團隊，幾乎每個人都提出了建議和回報，使我們能夠不斷疊代和優化流程，使其變得更好。