《光环无限》开发者分享：有史以来最大的光环游戏是如何打造的？

【GameLook专稿，未经授权不得转载！】

GameLook报道/在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工作室的同事们做出的贡献。