在手游3A化元年，如何搭建引擎中台？
分享/郭智 整理/迪亚菠萝包
最近两年内，“引擎”和“中台”这两个词在圈内得到很多公司和从业者的关注，部分公司尝试搭建了自己的中台体系，但此前很少能看到关于中台相关的公开分享内容。
在今天举行的TGDC2019腾讯游戏开发者大会上，腾讯互娱天美工作室群技术副总监郭智分享了他对于引擎中台的理解，复盘了天美J3工作室自去年以来搭建引擎中台的历程，并结合《使命召唤手游》项目，阐述了J3工作室引擎中台在建立画面呈现标准和确立制作管线方面的作用，同时还分享了在参与《使命召唤手游》制作过程中，引擎中台的部分技术沉淀。
以下为郭智的详细分享内容：
各位好！我来自于天美工作室，欢迎大家今天来到TGDC2019的现场。今天我分享的主题是用中台思维去解读引擎团队如何帮助高品质游戏——《使命召唤手游》的技术升级。
“引擎”和“中台”这两个词是近两年来比较热门的词汇，今天我会以中台视角介绍我们在《使命召唤手游》里做的一些工作。
引擎公共能力的建设
这部分是对天美J3工作室引擎技术组整个搭建过程的简单复盘，我们这个组成立了一年，才刚刚开始，今天抛砖引玉和大家一起探讨，一起进步。
2018年可以说是手游3A化元年，我们一起看看业界游戏技术有什么变化。
首先是引擎技术移动化，我们在手游上大肆的使用端游时代的技术。大家都在使用线性空间光照及HDR管线；大世界成为热潮，很多开发者不断地讨论多地貌的地形制作，地形渲染；TOD日夜变化大肆流行，雾和大气也是标配；图形上都使用基于物理的渲染，以及在移动端实现一些拟合的动画光照GI效果。
同时，引擎与工具也在不断升级：UE4普及，Unity也升级到了2019，以Houdini与Substance为代表的美术工具被大家广泛使用。
硬件也在进步：高通GPU已经到了855 ，苹果进入了a13，性能与几年前的PC无限拉近。PC显卡已经进化成光线追踪的RTX，各大引擎厂商都在更新自己的光追烘焙器。
此外，各种3A大作前沿技术被手游使用，比如Destiny的VisualEffect技术，《Far Cry 5》和《幽灵行动》的大世界技术，各个游戏公司也在各大技术峰会和大作中吸取技术经验。
综合起来，其实是端游技术在手游延伸，引擎工具的发展，硬件的发展，再加上整个业界技术的分享和传承，其实现在整个手游技术已经不断往AAA化发展。
技术深厚的公司出现了一大堆高质量的手游，比如像《天堂2》、《PUBG Mobile》在国内外都取得了不俗的成绩。在未来其实会有更多高质量的手游出现，技术竞争也会越来越激烈。我们制作的《使命召唤手游》会在今年上线海外，大家也可以看一下这款产品，我们做了很多深度技术的改造。
再来看看传统游戏开发团队的架构。它的组成很简单，按照岗位划分成美术团队、策划团队、服务器开发和客户端开发。
同时，技术团队中有那么一小波同学会做一些引擎开发工作。他们负责一些面向于项目需求的特性开发，性能优化，解决一些技术难题，参与攻坚一些项目，这样的架构能够很好的服务团队，这一波人也能为项目解决各种各样的疑难问题。
两年前，这样的运作模式出现了很多很多的爆款，腾讯内部很多成功产品也是由这种架构延伸出来的，但长远来看这样的架构还是会出现瓶颈。
在手游AAA化、对于品质和创意要求越来越高的今天，技术已经成为胜败的关键。以前游戏开发团队往往会存在三类问题：技术积累比较缓慢，技术管件需要升级，人才需要升级。
1、技术积累缓慢。
因为游戏产品一般都是需求驱动，用人力解决问题。限于技术眼界，往往团队里面所使用的技术是为了满足当前需求，所以技术积累会比较慢。同时，会因为团队只关注单一产品，对一些前沿方向相关技术储备不足。
2、人才。
国内做引擎或者做底层的开发者数量其实非常有限。当我们要做一些和引擎技术相关的深度开发时，很难找到这方面的人才。
因此，我们要建立一些培养和管理机制去做配套，配套好以后，还要在工作室的每个项目做引擎技术的全覆盖。这样，项目组的研发人员能够和技术中台、引擎组的人实现很好的协同。
3、开放和传承。
以前整个业界技术都是封闭的，现在开源协同已经变成了共识，大家不断分享自己的技术，中台组织也要对外不断进行合作，合理的共建。
在《使命召唤手游》研发过程中，我们联合了引擎厂商、芯片厂商、手机厂商，以及腾讯内部的技术中台的力量。
最后，对这些已经沉淀出来的技术需要在各个项目里面不断做传承。不仅仅是技术上的中间平台或中间件，而是一整套集创新组织架构，敏捷研发流程以及前沿游戏技术的综合生态。
为什么建立引擎中台？
我们的目标有两个：
一，在组织维度上营造环境，支持项目快速创新、规模化创新，提供完整的持续交付工具链。
二，在技术维度上赋能业务，根据技术前瞻提前组织资源，利用技术先发和可复用的优势，赋能业务真正做到多（同一时间支持多个项目），快（持续快速交付），好（品质保障），省（技术与人才充分复用）逐个落地。
这是我们中台的架构，现在只是刚刚开始。人才上也会是多维度的人才，覆盖游戏开发的各方面，比如技术美术，做引擎技术的开发，维护workflow的工具链开发，做自动化测试的开发。
提供引擎技术能力，开发制作管线，工作流工具建设，技术美术能力等全方位能力去支撑业务，同时也会从业务发展过程中发辅中台。
和业务非常紧密结合是这个团队最大的特别之处，我们不会一味做很多不落地的技术。我会根据工作室未来方向定义自己的Roadmap，比如未来会做大世界，会推PBR的管线，会做过程化的布局，我们70%的需求来源于业务，然后剩余30%来源于对业界趋势的一些思考。
同时中台支撑需要有很好的流程支撑，比如说需求管理、目标管理、代码管理、开发流程管理等方方面面。
这是引擎中台的技术全貌，囊括了整个引擎的方方面面，从底层是一些引擎的技术，基于引擎技术是一些工具链，一些workflow制作管线。然后再上层是一些开发框架和支撑我们现在的一些各种各样的手游的研发，所以说整个东西其实不是一门技术，还是支持整个项目研发的方方面面。
建立画面呈现标准
说完中台建设，我们来看，以中台思维去思考我们在《使命召唤手游》所做的一些引擎工作。
第一个方面，画面品质升级。要做画面升级，首先要建立画面呈现标准，我以中台视角说说普PBR时代画面呈现的最佳实践与升级。
第一步，对一个IP产品来说，我们要定义它制作的主基调。一开始，我们在做《使命召唤手游》的时候，要考虑性能，因为当时的机器比较差，做性能永远能服务于大盘用户，就经历过一段时间使用传统的phong光照模型做简单还原，一张diffuse,normal specular，静态烘焙。
我在2018年组建了工作室引擎组，对游戏画面做了重大翻新，使用PBR复刻主机画面，要挑战主机画面丰富度，去还原和满足IP高端玩家的主机情怀。
这张图左边是两年前的情况，右边是去年我们做了画面升级后的效果，整个品质提升了非常多。
我们有了主基调之后，既然要做PBR，就要统一制作管线和技术管线，对于制作管线来说，美术资源需要在线性空间计算。
对于技术管线来说，我们要为引擎定义并且统一渲染管线，渲染管线是根据硬件scaleable的HDR渲染管线。
有渲染管线之后，对于画面呈现来说，我们要建立一致的画面标准。比如这个角色，每个像素，我们定义Material Model，Lighting Model和Shading Model。
对于真实感来说：标准建立了，我们要用同样的语言在说话。他们都是具有物理意义的参数和真实物理定律(PBR)。全场景是统一光照环境的。使用动态光影 PBR IBL
先看看Shading Model。我们构建了一整套完整的手机平台pbr光照方案高中低配都采用了完整的PBR信息。动态物体使用全实时计算 动态阴影，直接光使用的是GGX Specular Lambert Diffuse，间接光使用 IBL的Cubemap和SH球谐光照。
Occlusion使用了Baked AO表示 Diffuse AO，再根据 bake AO，normal，Eye direction smoothness信息计算Specular AO。如果是低配我们直接使用AO替代SO。
对于静态物体，出于性能考虑，我们低配简化了很多光照成分。有5级LOD，有4级是对PBR做数学拟合的近似，1级是为最低端机器的兼容性考虑。光影使用全实时计算加上lightmap,shadowmask方案。
直接光使用的是预先烘焙的直接光阴影shadowmask，间接光使用 IBL的 cubemap 和 烘焙的lightmap。Occlusion数据来说，使用法线梯队产生小范围AO加上Lightmap AO，Specular AO的方式和动态物体类似。
再聊下我们的Material Model，固有色贴图存一张，法线贴图加粗糙度存一张，金属度和AO存一张。Lighting Model，直接光为Directional Light,间接光使用Lightprobe和Refectionprobe。
前面就是我们为《使命召唤手游》定义的PBR工作流，做个小结：
项目中所有物体统一使用 PBR 材质渲染，BRDF 均为 Lambert GGX Cook-Torrance
实时光阴影：Shadowmap 衍生技术 （实时 / 预烘焙）
间接光：Convoluted Cubemap SH ( Lightprobe ) Lightmap
通用性：80% 的可见实体均使用这套Shading Model的变种，其他20%（头发、皮肤、水体、植被）使用其他特殊方法
确定了Shading Model, Materiel Model和Lighting Model，画面标准就基本建立。
3A级手游制作管线
下面要聊聊《使命召唤手游》这样一个AAA级手游的制作管线。
整个制作管线的核心因素有哪些？我认为有三个方面，一个是量产，一个是引擎，一个是性能。
制作管线，需要使用流程与工具保证美术素材的正确和合理性。原则有两个：一，美术素材输入PBR标准；二，生产规格与生产环境。
如何达到PBR资源的量产化？首先要可以验证，其次要有详尽、可追溯的文档和记载，同时还要有科学性。PBR的诞生本来就是工业化的产物，当你一味强调各种hack，每个美术用不同做法制作之后，就不可能科学，不可能量产，最后整个团队就会乱掉，会把这个开发周期给拉长。
量产要求我们要有标准的场景验证：我们需要在Substance Painter里面提供了一系列标准光照环境给美术验证。这些场景需要满足三个要点：
图形技术保证：在同一个 IBL 光照环境下，Substance Painter 与 引擎内显示效果有95%以上的一致性。
制作环境约束：美术制作者Substance Painter 渲染环境必须是标准光照与标准着色器。
验收制度约束：任何人讨论素材本身的效果品质问题时，只能参考标准光照下的效果。
这是我们所有的标准场景环境，其实覆盖了整个游戏里面所出现的方方面面，有一个主场景和六个辅助场景（其实现在已经不止六个）。
主场景主要验证三个方面：固有色明暗和色相；不同粗糙度表面的镜面反射情况，以及金属材质的镜面反射情况。
辅助场景主要验证五个方面：室内环境（弱点光源）；暖色调环境下效果；强对比阴阳光照；典型室外光照下效果；固有色是否太黑。同时，我们提供定义详细规则的文档白皮书。
最后一个要点是正确性。我们借助了很多“黑科技”去考查光照，我们借助的素材有屏幕校色，照度仪（重要）和RiteChart 标准色卡。我们在各种环境下测量球谐参数SH以及Lightmap，在Substance与Unity里面都提供参考固有色比色卡。经过这样严格、科学的验证，才能得到目前3A级的《使命召唤手游》的画面。
对于中台组织来说，我们要推行的是管线和整个制作生产本身，而不是提供一门技术。
《使命召唤手游》引擎技术沉淀
说完整个画面承呈现和PBR的制作管线，我们回顾一下我们之前做的技术沉淀。
首先。我们日常的引擎迭代里面需要有一个完善的自动化兼容性测试框架。能尽可能保证所交付的引擎是稳定的。
我们和腾讯Wetest质量平台合作，定义了一套devops自动测试框架，每日拉起TOP200的手机做测试。测试结果和基础机器的backbuffer做对比，可以发现各种渲染异常。也可以验证游戏Graphic API的兼容情况。同时，可以针对Top200机器做兼容性，性能测试，以及支撑新渲染特性以及渲染管线的评估。通过这个框架我们解决了不少的问题。
这套框架有如下几个作用。
在技术预研期的作用包括：
移动设备发展趋势
技术方案选择
新技术成长过慢
在研发期的作用包括：
引擎修改稳定性问题
自动化性能监控
要解决引擎测试缺少特定的性能信息，干扰多
要解决渲染管线耦合性较高，大量问题反复发作
同时测试案例集成及推广
在运营期的作用包括：
自动化测试替代手工测试
Bug报不清，难以定位修复
项目组经验传承
自动化兼容性测试已经在天美工作群分享共建，各个项目一起用，迭代各种各样有益的测试用例的框架。有了这个自动化监用性测试框架之后，我们就能很安心的做一些引擎开发和特性，然后跟上业界的一些技术趋势，把握一些技术趋势。
这是我们现在的第二个管线——大世界制作管线。我们对地形系统做了很深度的改造。我们会使用一些VTF，比如说支持64种材质的变化，同地貌的折扣也会进行合并，支持十种生态环境，支持地形的Continuus Distance Dependent做LOD变化。
我们通过过程化技术，大世界制作管线，生产出来比较高质量、符合自然界规则的一些大场景，这个迭代也非常快。以前我们生产一棵树，需要LD或者一些美术在场景里面手工摆，现在我们只需要通过程序化的方式生成地形，植被等信息。生产效率会更快，地图的质量也更高。
我们还对烘焙器做了很深度的定制，烘培器使用了GPU的烘焙，原来我们在PVP地图里面单次烘培需要4-6个小时时间，使用这个烘培机。只需要3-5分钟就搞定了，整个效果也有所提升。
我们还对管线做了更深度的拓展，使用自己拓展的烘焙器，我们还实现程序化生成lightprobe，让整体光影更加真实，迭代更加快速。
同样是PCG程序化生成，我们还融合到植被制作中。借力于Houdini，我们程序化生成法线和AO，让整个植被的生产周期由2周缩短为2天。
最后我们提供了一系列workflow 保证美术制作，引擎，性能工具一体化。整体上不打乱美术工作流，程序后续执行优化。使用的技术有Texture Atalas，Texture Streaming，以及各种级别的PBR Shader LOD策略。
再下来可以看到一些常用技术的沿用，比如皮肤用了ssss，角色PBR制作，不同发型的制作，我们会补齐方方面面的引擎特性。维护整个生产管线和制作管线的本身。
可以看到其实我们提供的是一套引擎技术小中台的能力，而不只是技术的本身，包括引擎技术能力，创新赋能，梯队培养，工作流与技术管线，品质与性能保障，与资源与经验的重用。
我们刚刚起步，还有很多问题需要解决，技术上还属于在追赶，做不到引领，我们还是一个小小的，在不断成长的Team，欢迎大家多多指教，也欢迎大家加入我们。这就是我今天分享的内容，谢谢！
Q：在实施引擎中台的过程中遇到过哪些困难，如何协调好项目组与引擎组的关系？
郭智：这个问题在我们这边比较好解决，因为引擎的人组建的时候来源于项目组，这些引擎的同学也是跟着项目一起迭代，大家都奔着帮助这个产品成功来工作的。
同时，我刚才说到了我们70%的需求是服务好产品，30%是来源最前沿的思考，所以在跟项目组处理关系的时候，我们就要思考一下这个产品需要什么技术，这个产品的研发周期要求什么时候发版本，什么时候需要这个技术的提供，整个工作室层面未来会出现一些什么样的产品，需要什么样的技术，这些盘点跟着项目组的节奏来，问题会迎刃而解。
