ashkeling报道/2020年12月7日- 10日，由腾讯游戏学院举办的第四届腾讯游戏开发者大会（Tencent Game Developers Conference，简称TGDC）在线上举行。

TGDC自 2017年创办以来，一直坚持以开发者视角与需求为出发点，结合行业发展趋势，对大会内容进行不断升级和扩充，旨在为国内外游戏专业人士打造开放的交流分享平台，推动游戏行业良性发展、探索游戏更多可能。

在第二日（12月8日）的活动中，腾讯互动娱乐研发效能部引擎核心技术组负责人魏楠进行了精彩的演讲分享，通过在过去与多个项目组的合作经验，总结出了引擎中台对于研发效率的提升。他表示“技术中台通过打造核心的一些基础能力，渲染方面、内容制作工具，关注整个管线的开发效率，其实是可以显著的协助到游戏团队来开发3A手游”

以下是演讲实录

魏楠：大家好，我是来自腾讯互娱研发效能部引擎技术中心的魏楠。

今天这个机会主要想给大家分享一下，在过去一段时间我们作为技术中台和腾讯游戏内部很多项目合作过程中，协助大家来进行3A手游开发整个过程中积累的一些技术经验。

随着手游市场的不断地变化，OB欧宝体育电竞官网对手游的品质要求也越来越高，那么什么是3A高品质手游呢？其实这里面可以借鉴传统的主机游戏作为参考。

如这些所列的，其实都是非常获得OB欧宝体育电竞官网认可的一些3A主机游戏，在这里面通过我们的观察和分析，不难发现有以下几点是非常重要的。首先第一点是渲染效果，如果大家比较关注整个游戏技术发展的话，渲染一直是在游戏开发技术当中非常非常重要的一环，画面的质量对于OB欧宝体育电竞官网、对游戏本身的体验是至关重要的一个环节。

另外一部分就是海量的内容，随着给OB欧宝体育电竞官网提供内容越来越多，OB欧宝体育电竞官网所能探索的东西也会越来越多，这样就可以极大丰富OB欧宝体育电竞官网的体验。接着是玩法本身，如果可以提供丰富的玩法，OB欧宝体育电竞官网就可以获得不同的乐趣。

综合上述几点我们可以看到，如果能够实现这些的话就可以给OB欧宝体育电竞官网一个顶级的体验，而作为技术中台，在这其中我们可能因为资源、人力各方面的限制不可能所有东西都来做，所以我们只能聚焦于几点、几个最核心的能力。

我们这边大概有三部分，第一部分就是核心渲染，我们希望能够通过核心渲染技术上面的一些突破能够帮助项目组在手机、移动平台上真正实现一个质的提升、飞跃。

另外一部分是内容工具，因为要生产更多的内容；要生产更高质量的内容；要生产更多不同样式的内容，所以我们肯定需要在工具侧也做一些突破，通过这些工具帮助整个项目组或者制作人员真正能够实现内容的生产。

最后因为整个内容越来越多玩法越来越丰富，其实整个团队开发效率也会是成为一个瓶颈，那么如何能够提高整个开发效率也是至关重要的一环，这样会对整个团队最终开发出来游戏的品质有非常关键的影响。基于这方面的考虑，我们会聚焦核心能力来发挥整个中台的一些优势。

首先第一部分大概谈一下移动端的渲染管线开发，因为我们跟很多项目组合作，项目组对动态、光照和阴影的诉求会越来越强烈。目前来看的话光照会是整个渲染效果最核心的一个环节，所以基于这方面考虑，首先第一我们所有的资源会投入在移动端的延迟管线上的开发，希望能够通过在移动端实现一套延迟管线，能够很好地来提升整个游戏画面品质。

在整个开发过程中我们其实划定了三个非常重要的目标，第一个目标其实就是在性能方面的提升。我们希望能够在移动、平台、硬件有限的情况下，真正能够支持到百盏动态光源，这样效率、性能均能够满足具体游戏项目的要求。

第二部分，因为在手机上不管是发热、电池消耗，其实对OB欧宝体育电竞官网的体验是至关重要的，所以针对带宽、功耗的优化也会是非常重要的一个环节。

最后就是鉴于手机、硬件非常的丰富，各个厂商之间不管是特性或者是Driver层面都有很大的差异，所以做好兼容性也非常重要，我们希望在低端、中端、高端不同硬件厂商上能有一个非常好的覆盖。

鉴于这三点考虑，我们在整个开发过程中大概总结出来了以下一些经验，第一部分，其实就是通过比较彻底的优化，通过对光源clean的优化预期可以提升20%到25%的效率。第二部分在带宽层面针对不同的GPU，比如说像ARM的Mali、高通的Adreno，充分利用这些硬件的一些特性，我们可以达到25%到30%带宽上的节省。有了这样的节省，我们在有一些手机上测试下来的结果，可以有2度到4度温度的降低，这样可以极大地提升OB欧宝体育电竞官网的体验。

另外在我们自己内部测试，还有在实际落地项目里面项目测试的一些数据反馈来看，不管是在低端、中端、高端上，使用这一套移动端延迟管线在性能上其实是可以和当前主流的前向管线保持一致，并且超越前向管线。当然最后还是有些问题，因为本身前面提到诸多的复杂性，所以这里面如果要解决这些复杂性是需要有一套非常复杂的方案，有一套非常复杂方案就进而会极大地提升整个实现的复杂度，所以就带来在整个引擎侧维护成本、维护复杂度极大地提升，这是大家需要非常注意的。

最后一点其实就是整个实现过程中，是需要考虑硬件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工具作为在整个引擎里面来标注整个区域，在区域里面进行程序化生成是非常重要的一个源数据，所以我们在这边也开发了一套Mask工具，能够帮大家非常灵活来定义这个类型的数据。

同时我们也提供了一整套完整的Houdini HDA Library给项目组来使用，可以让项目组来基于我们已经开发的一些Houdini HDA，根据自己项目本身的需求在这些HDA基础上进行一些扩展、进行一些定制或者修改，能够快速来搭建自己的流程。这里面包括像地形、植被、道路、河流还有岩石、建筑等等这些HDA，提供一些最基础的功能给大家来使用。

目前我们这套工具在整个腾讯游戏内部已经有几个项目在使用，我们看到项目组其实是可以非常快速地利用我们这些工具灵活来搭建自己的流程，来快速实现自己一些游戏Prototype的一些工作来验证自己整个流程上面的一些想法。

接着给大家介绍一个叫做Superman的面部表情和动画的工具，这套工具其实主要还是针对表情动画和捏脸这样的需求来开发的，这套工具会支持任意3D角色的面部定制，能够支持自动绑定、快速捏脸、表情系统以及口音等数字资产的制作，同时能够可以结合专业的面部，甚至是比较简单一点iPhone上的AR Kit来进行面部数据的对接。

这里面这套工具最主要的优势，首先第一点功能还是非常全面的，支持像谷歌框架和Blendshape数据自动双向的转换，另外通用性是比较强的，因为我们在具体项目组来看，这套工具可以支持不同风格包括写实、Q版角色的制作，操作会非常简单，不管是在安装上还是在功能上，我们看来对美术侧非常友好，只需要简单两步就可以让项目组的美术来使用起来。

最后一点，最关键的一点也是整个工具在开发制作效率上会带来一个非常明显的提升。关于效率，这边其实有一些具体的数据，比如像自动绑定这边我们和具体项目沟通，基本统计出来一般传统可能需要大概一周时间可以做好一个绑定，但如果使用这套工具的话可以在一小时就可以来完成。

第二部分是一个捏脸系统的搭建，我们看到有些项目可能需要一周左右时间才能初步搭建一个捏脸系统，如果是使用这套工具的话，结合这套Superman的工具大概两天就可以搭建这么一套捏脸系统。关于表情制作通常的项目大概是需要1.5周左右的时间，如果使用这套工具，大概两天左右时间就可以完成。

最后就是情绪、口型资产生成，因为这套是会自动化生成，所以就可以完全从以前的1.5周时间变成自动马上可以生成，基本可以忽略这个时间的情况。

另外在本次TGDC，我们团队专门做这套工具的刘凯同学会有一个专门针对Superman这套工具的详细分享，如果大家比较感兴趣的话可以关注他的分享。

再返回到关于前面提到的光照本身，因为光照本身是渲染最核心的效果，但是即使有像延迟管线这样的技术，对于动态光源、动态光照我们有个非常好的支持，但是像间接光照我们依然还是需要借助一些预计算的方式才能会比较好的支持到。

另外目前来看，主流引擎里面的光照烘焙会是一个计算量非常大、非常耗时的过程，有些具体项目里比如前面提到开放大世界的项目里，像5K乘5K这样的一个地图如果说对一整套图烘焙，往往需要一整天的时间才能烘焙完，所以这样就极大限制了整个团队开发制作的效率。

基于这些问题我们这边利用GPU开发了一套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这边的构建。Shader的话我们基本看到，可能是需要550秒左右完成我们自己测试地图的一个构建，而如果利用我们这套分布式系统，我们可以把整个时间缩减在150秒到200秒之间这么一个时间。还是非常显著，可以提升整个构建的效率。

最后总结一下今天我分享的一些内容，其实就是说作为技术中台的话，通过打造核心的一些基础能力，包括渲染方面、内容制作工具，关注整个管线的开发效率，其实是可以显著的协助到游戏团队来开发3A手游，

以上是我今天分享的内容。