整理/以撒
在之前的文章里，葡萄君提到了工业化对于游戏公司转型的重要性。而在正在举办的第四届腾讯游戏开发者大会（Tencent Game Developers Conference ，以下简称 TGDC）上，工业化同样是一个被集中讨论的命题。像腾讯游戏副总裁、腾讯游戏学院院长夏琳就在开幕演讲上提到，游戏产业要有进一步发展，需要更加成熟的工业化体系。
这并不是巧合，因为工业化带来的巨大成本差距，捏住了高成本研发的命脉。而在推进工业化的进程中，引擎自然成为了厂商们共同的目标。像心动网络CEO黄一孟就说过，这几年他们才发现，公司过去一直在用Excel做游戏，现在才开始学会用引擎。
如何用最低的成本把引擎用到极致，甚至让之后的研发都能复用？近几年为了解决这样的问题，技术中台又走进了人们的视野。但在游戏行业，中台的发展还相对不那么成熟。在这个过程中，目标、工具、技术等方面都需要摸索。例如我们的一位技术中台负责人读者就曾表示：游戏技术中台要想起作用，没有3年都很难。
面对这种情况，腾讯互娱研发效能部引擎核心技术组负责人魏楠在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的GPU上，和在高通的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周时间变成马上生成，基本可以忽略不计。
在本次TGDC，我们团队专门做这套工具的刘凯同学会有一个专门针对Superman的详细分享，如果大家感兴趣可以关注他的分享。
开发效率
返回到前面提到的光照本身，它是渲染最核心的效果，即使有像延迟管线这样的技术，对于动态光源、光照，我们能有非常好的支持，但是像间接光照这种，我们依然需要借助一些预计算的方式才能比较好的支持到。
目前来看，主流引擎里的光照烘焙会是一个计算量非常大、非常耗时的过程。有些具体项目里，比如前面提到的开放大世界项目一个像5K*5K的地图，烘焙一整套图往往需要一整天时间。这样就极大限制了开发效率。
所以基于这些问题，我们利用GPU开发了一套GPU加速的光照烘焙系统。这里开发其实有几点需要注意：
第一，虽然开发了一套新的系统，但肯定还是要保证它和以前的旧系统在整体烘焙的效果、质量上完全对齐，甚至在个别点上做到超越；
第二，我们的初衷是要大幅提升整体烘焙效率。从实际情况来看，我们确实可以将效率提升一个数量级的；
第三，这套系统应该是一个比较好、完备的、可以进行功能扩展的系统。我们在后期开发一些功能时已经验证了这一点，比如我们在光照烘焙系统上又增加了一些新的烘焙特性，来支持一些新的需求。
这里是一个简单的效果对比图，基于CPU光照烘焙系统和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手游。
Q&A
我看到大家有一些问题，我今天在这边尽量尝试回答一下。
Q1：在整体分享中提到的一些技术点已经存在很久了，为什么我们还要持续关注、开发？
A：举个例子，就像我们延迟管线一样，本身它是一个非常成熟的技术，甚至在十几年前的PC、主机游戏上就已经成为一个主流了。但是因为当前我们的整体范畴是手机游戏，而这一部分在移动平台上一直没有得到非常充分的应用。
在这方面，最主要的还是硬件限制。正好目前根据玩家对手机游戏新的品质提升要求，这些技术相当于又浮出了水面。在新的软硬件环境下，我们可能就需要重新来看这些技术，但是因为本身软硬件存在差异，我个人认为，在实践过程中还是有很多新的挑战，或者说新的技术点是可以突破的。
这就是为什么我们会长期持续关注、开发。其实这也是整体市场、产品发展到一个阶段的需要。
Q2：谈谈对内容工具和制作管线未来技术发展的思考？
A：第一点应该非常清晰，不管什么工具还有管线技术的发展，其实都跟开发团队本身的需求密不可分。就像很早以前大家不知道PCG这些相关的开发技术，但是为什么现在还要关注？因为本身随着场景、内容越来越多，大家没有办法完全覆盖到成本，所以就需要这种程序化生成的方式来开发，这本身是开发侧的需求；
另一方面，我们也需要主动去寻找一些技术，比如说现在最关键的云计算、AI技术。比如云计算在游戏后端运行，或者后台这部分应用比较多。但是在前端、在游戏本身制作过程当中，应用还非常有限。这就是为什么我们会开发分布式构建系统。从本质上来说，我们就想做一个Cloud Bill，充分利用一些Centralize的资源提升整体制作效率。
所以从正向来看，我个人认为利用云计算、AI结合整体游戏内容工具、制作管线会是越来越重要的点。
Q3：怎样看中台这个岗位？未来它会不会成为刚需？
A：关于中台，其实它不光是当前、未来，在过去都一直存在。如果大家有关注，比如育碧，可能在十几年前就有，EA也在十几年前其实就已经有类似于中台的技术团队、引擎团队，来帮助项目组做一些事情。
中台本身也是一个分工合作、各展所长，来解决整体游戏开发过程中问题的一个比较有效的方式。制作团队可能擅长于他们本身的一些事情，中台则有自己的优势，比如技术资源上、时间维度、人力上的一些优势。所以中台未来肯定还会继续存在的。
Q4：关于UE5（虚幻5）有什么看法？它会怎么影响行业？
A：我感觉这个问题可能并不是UE5怎么影响行业，而是为什么、行业到底发展到什么阶段，最后才会产生UE5，反过来问可能是更好的一个问题。
首先在目前，至少从UE5放出的DEMO来看，其实最核心反馈的一个信息是，目前新一代主机硬件已经上市了，在新一代主机软硬件上面提供了一些特性、能力，才促成了UE5当前主要宣传的这些功能。
所以从我们来看，其实更应该关注游戏本身平台硬件这些，现在到底属于一个什么样的状态，才会催生整体引擎技术的发展。比如说我们看到新的主机在I/O方面非常非常强大，未来的话可能大家也都会在某种形态，用云游戏作为一种平台也会越来越普遍。
在这些技术背景下，引擎会怎么样发展？引擎受这些行业的趋势会受到怎样的影响？我感觉这样来思考这个问题才会更贴切一些。
以上就是我今天的分享，谢谢大家。
（点击此处可以观看这场演讲的视频回放，以及其他嘉宾的分享。未报名用户可以预约回看。）
