《光環無限》開發者分享：有史以來最大的光環游戲是如何打造的？_世界訊息
在3A游戲領域，《光環（Halo）》一直是非常受歡迎的FPS之一。不過，隨著玩家對內容的需求提高，現代3A游戲的制作往往需要比以往任何時候都更多的內容，即便是數百人團隊，往往也很難做到內容創作效率和品質之間的平衡。
此前的GDC演講中，微軟旗下343 Industries工作室的主環境技術美術Kurt Diegert和TA總監Mikael Nellfors以《光環：無限（Halo：Infinite）》為例，講述了工作室如何打造首個跨平臺和有史以來最大的《光環》游戲，以及這個過程中的許多新挑戰和機會。
以下是Gamelook聽譯的全部內容：
(相關資料圖)
Kurt Diegert：
今天的主題是打造“Zeta Halo”，主要是講我們如何對內容創作工具、工作流以及最佳方法進行規模化，打造了有史以來最大的《光環》游戲。我是Kurt Diegert，在343工作室擔任主環境技術美術師。
我們來了解今天都會談到哪些內容，首先會講講343工作室的一些文化和歷史，然后談談《光環：無限》的目標是什么，隨后會談到我們為實現這些目標而打造的一些東西，比如Mask Painter系統、地形系統，HLODs系統以及一些程序化內容創作工具。最后，我們會聊聊內容可拓展性系統。
343工作室歷史和《光環：無限》研發目標
Mikael Nellfors：
了解我們的人可能知道，343 Industries是由微軟在2007年成立的，主要目的是為了從Bungie工作室手中接過《光環》系列的研發任務。《光環：無限》是我們工作室的第四款FPS游戲，如果看之前我們的《光環》游戲內活動，它們都是非常線性化、獨特和手工打造的，使用了非常耗時且容易被破壞的特殊工作流，比如沒有地形系統或者程序化技術充滿整個游戲世界，另外，它們的定位往往是單個平臺。
所以，當我們談到《光環：無限》的時候，很快意識到以前的方法是無法規模化的，
當我們為《光環：無限》做規劃的時候，一些目標包括：我們知道必須支持大型開放可玩空間，意味著我們需要提升迭代速度和穩定性，使用能夠用足夠多樣性充滿游戲世界的模塊化工作流，還需要有程序化工作流制作更多的內容，而且是不能被破壞的，以便我們能夠更快速迭代。
而且，這一次我們希望定位多平臺，我們必須支持9年前的Xbox One那么老的機器，還要能支持高端PC。所以，后續我們提到低配的時候，指的就是Xbox One，高配則指的是高端PC。
那么，為了完成這些目標，我們要做多少內容呢？圖中左側是《光環5》的所有活動關卡，右側則是《光環：無限》的主要活動島嶼。如果把這些《光環5》的關卡放到新游戲島嶼上，它只占了10%的內容量，所以，我們必須做足夠的內容填滿這個更大的世界。
Mask Painter系統
Kurt Diegert：
如Mikael所說的那樣，我們為《光環：無限》打造了模塊化工作流，比如圖中是同樣的模塊打造的不同配置的墻體，Mask Painter系統的目標，就是減少模塊化工作流當中的重復。
不過，我們還希望Mask Painter能夠通過繪制非模塊化內容的方式，創造更多樣化的感覺。我們知道自己希望Mask Painter做到所見即所得的效果，讓它可以在實際關卡、資源之上繪圖，實時看到素材更新，提升我們的迭代時間。
我們還希望Mask Painter系統可以做到不被打斷，而且能夠反映藝術方向。另一個有趣的目標是，我們不希望這個系統有任何的Popping。最后，我們希望這個系統能夠在內存和運行性能方面能夠負擔得起。
在設計Mask Painter的時候，我們第一個決策就是采用紋理遮罩，而不是用頂點顏色推動素材混合，因為頂點顏色混合會讓幾何體LOD出現大量Pop。決定了紋理遮罩之后，我們知道內存使用是需要一直關注的點，所以我們在系統中打造了很多工具讓它處于可控范圍之內。
美術師們具體說明他們繪制的每個遮罩，我們還不希望對每個地方的每個資源都進行獨特的繪制，所以我們用工具打造了一些變體，可以在需要的時候使用。
最后，紋理遮罩的內存使用沒有我們擔心的那么高，平均每個活動加載最高的時候消耗60MB，最低的時候只有37MB，即便是用頂點顏色，我們可能也要多消耗10MB內存。
所以，我們打造的Mask Painter系統是非常快的，我們可以同時繪制多個網格，右下角的部分向美術師們展示我們繪圖的圖層是什么，它們可以同時在任何數量的網格上繪制，并得到更快速的工作流。
這是我們的變形版物體，首先，我們在不同的兩扇們上繪制同行的遮罩，我們設置一些變體，以便讓這扇門變得獨特。
Mask Painter系統的一部分是著色器界面，我們是在此前《光環》研發的多層著色器基礎上研發而來，但最后可以支持所有的著色器、Painter。
這為我們帶來了一些比較酷的案例，比如這條河與瀑布的交叉，在之前是不可能實現的。
簡單介紹一下Mask Painter的部署，它運行在GPU上，每個繪畫操作都是一個draw，頂點使用Mask Painter UV，我們還支持重做和撤銷操作，因此加快了工作流程。
地形系統
Mikael Nellfors：
如我之前所說，以前的《光環》游戲是沒有地形系統的，所以它們的地形都是獨特的資源，在Maya當中制作并運行在World Machine里。它們的素材層次很有限，所以，如果你想在地形上部署一個物種，然后在另一邊部署另一個，就需要做大量工作。
遮罩也必須通過DCC繪制或者生成，我們無法直接看到效果，而且必須手動進行優化。
舉些例子，比如這是《光環5》的地形場景，看起來是非常不錯的。
不過，這才是地形真正的樣子，它被分成了很多獨立的部分，所有的三角形都是由美術師們手動刪除的，因為它們被巖石和環境所覆蓋，為了讓視覺效果看起來完美，他們不得不手動刪除這些三角形。我們覺得這樣的時間投入不值得，所以不能再那么繼續下去。
對于地形目標，我們的目標依然是所見即所得，需要支持從小到大型的場景。它需要同時在游戲里支持多個玩家，需要有素材繪制、支持物理效果并且附加音效，帶有程序化地表生成，而且需要不被打斷、能夠擴展至多個平臺。
我們最終的結果是，從《孤島驚魂》和《地平線：零之曙光》演講中獲得了啟發，很多地形是在玩家探索的時候，根據他們的視線范圍程序化生成，我們使用了基于塊的渲染，可以通過分辨率和幀率來控制規模，并隨著實時進程增加虛擬紋理。
我們希望增加更多的細節，所以還增加了一個Micro Displacement功能，我們也可以根據不同的平臺對其進行控制。
接下來我們后退一步，看看整個地形系統是如何運作的：
這些基本上就是我們系統的高層次部件，主要分為離線部分和runtime部分。在離線部分，所有東西都是通過遮罩運行的，所以我們所有的heightmap、遮罩或者用戶生成貼圖放到兩個graph當中，我們有控制地形幾何體的SculptingGraph，還有用來控制素材和地表覆蓋物的SurfacingGraph。
這些隨后為runtime進行優化，然后進入虛擬紋理和地表覆蓋物遮罩部分，虛擬紋理還會渲染素材，做一些傳統虛擬紋理不能實現的事情。
不過，我們最后還是做了兩個地形系統模型，一個是之前說過的Runtime版本，通過HLSL編譯。對于編輯版本，我們所有東西都是實時運行，之所以使用兩個模型，主要是為了達到所見即所得的效果，所以我們希望做到即時編輯和快速運行。這種方式的不利之處在于，我們最終不得不用兩種代碼路徑，這導致了一些問題和bug，而且在編輯的時候還需要額外的編譯，我們覺得這是未來可以提高的地方。
Sculpting Graph
Kurt Diegert：
Sculpting Graph是用來控制地形幾何體的，所以一開始它能做的事情并不多。不過，我們很快為地形增加了視覺效果，大部分時候它都是離線運行的，不過我們也支持編輯的時候實時運行。Sculpting Graph部署的時候是作為渲染graph，可以讓內容團隊實現node-based圖形編程。
我們用它做的一些東西，比如道路系統，美術師可以通過編輯器直接修改道路的位置、地形素材和很多細節。
我們用它做的另一件事情就是地形體積系統，原本我們每個地形都要投入一個美術師負責具體的調整，SculptingGraph的出現可以讓一個人搞定同一個區域的地形變化。
我們還希望通過Sculpting Graph讓我們能在Houdini做一些東西，做到比原生地形功能更好的效果。所以我們用它來運行Erosion模擬，還在Houdini里做了Macro Texture，可以做到地形上的顏色變化。
最后一個是濕度，這實際上是另一個HeightMap，主要描述地下水位線在哪里，以便描述巖石的濕度變化，比如它在不同的水位和環境，會因為濕度問題發生外觀的變化。
SurfacingGraph
Mikael Nellfors：
如之前所說，Surfacing Graph控制的是地形素材和地表覆蓋物，它由三個部分組成：輸入部分的遮罩、輸出部分的素材層（包含高度、位置和顏色信息）以及Node-based道路系統，美術師們對這部分有完全的控制權。
舉個例子，這是編輯模式的界面，我們可以決定地表的植被類型、大小、高度和顏色等諸多細節，這可以讓美術師們快速嘗試不同素材，知道他們想要的是什么效果。
通過案例你們可以看到，這個Surfacing Graph包含的內容很多，有22個輸入遮罩，53個地表覆蓋物擺放，65個不同的素材輸出，24個音頻放置和19個特效放置。
Graph部分基本上就說完了，最后來展示團隊用這個技術做的一些東西：
HLODs
Kurt Diegert：
我們過去也為《光環》游戲打造過HLODs，但之前都是手動完成的，但是在《光環：無限》項目上做到規模化是不可能的。我們還希望使用高保真資源，可能有大量的著色器，幾何體，用普通的LOD方法是行不通的，所以我們希望通過remesh來解決這些問題，烘焙很多細節。
所以我們比較清楚的是，低配機器需要節約GPU占用和內存消耗，實際上，我們甚至不知道HLODs可以使用多少內存，我們試圖讓每個HLODs占用內存控制在100MB內。
與此同時，我們知道平衡這些需求可能會比較棘手，我們的解決方案是為這些HLODs系統打造了很多的控制工具，比如對每個HLOD進行縮減或者remeshing，確定使用哪些網格，手動控制體積等等。
這是一個通過試錯不斷迭代的過程，我覺得我們一路走來學到了很多有趣的經驗，最初我們以為需要對網格做很多的控制、決定哪些網格出現或者不出現在某個HLOD中，以減少內存占用。但是，我們發現Remesh做到了很好的效果，我們本來以為需要具體控制每個HLOD的紋理分辨率和幾何體品質，但實際發現并不要。
我們說過模塊化工作流，比如巖石，我們有75個巖石網格，最后我們將每個基地用一個母HLOD作為興趣點，之下還有多個子HLODs，以便加入高品質資源，在它們離攝像機較近的時候仍然有高品質視覺效果。之前說，我們原來每個HLOD的預算是100MB內存占用，但最后發現，可用的內存實際上有300MB。
程序化內容創作
前面說過，我們希望用Houdini做地形，我們使用了Python API直接讀寫游戲數據文件，就像是在Houdini當中直接加載地圖。隨后，我們可以做很多事，比如運行Erosion模擬，或者生成地形宏觀紋理，我們還用類似方式生成Flowmap、Hex Placement和分塊。
內容規模化
Mikael Nellfors：
以往的《光環》游戲都是面向一個平臺制作的，所以它們的地形引擎有一定的規模化能力，通過progressive resolution和Throttling系統根據性能控制分辨率，但這種系統非常少。有些參數是暴露的，有些是通過寫代碼實現，但這個系統很難讓我們知道游戲內發生了什么，而且功能十分有限。
所以我們知道需要一個非常靈活的系統，支持多種硬件配置，比如一開始我們就確定要支持9年前的Xbox One，所以它的可拓展性必須很強。我們希望它是一個數據驅動的系統，并且能夠手動調整，我們還希望藝術總監能夠決定哪里可以犧牲視覺品質來提高不同平臺的CPU、GPU和內存的運行效果。
雖然手動調整意味著仍然需要投入很多時間，但同樣我們可以對內容創作有比較高的控制力。
我們最終做了一個Scalability Presets，可以看到很多的細節設置都直接做到了引擎當中，它們每一個設定通常都有多個選擇，比如低中高以及終極效果。右側則是根據不同機器配置對不同參數進行預置。
比如對于幾何體，我們可以根據平臺選擇跳過LOD，或者擴大LOD距離、渲染距離。
對于這個設置，我們最主要的判定標準是幀率，如果它無法達到目標幀率，我們還有Progressive Resolution進行補救，如果仍然達不到GPU幀率要求，這時候就會使用Throttling。比如設置幾何體的時候，我們有高低值。
做到這一步沒有捷徑，我們的內容團隊和工程師使用了常規的性能審核工具，我們還通過一些工具收集數據，通過PowerBI觀察能耗趨勢。
最后，我希望展示一些《光環：無限》的實際案例，這些都是在PC上運行的動態效果，但你可以把它運用到主機上。比如天空效果，在Xbox One可能展示的云就比較少，在新主機上就可以開最高畫質，不過整體游戲在不同配置的運行效果依然是連貫的。
在幾何體方面，可以看到素材并沒有太大的差別，但高低配主要的區別在于光照和體積。
以上基本上就是我們今天分享的全部內容，這里感謝所有343工作室的同事們做出的貢獻。
