以下为演讲实录：
“引擎”和“中台”这两个词是近两年来是一个比较热的词汇，今天我会以一个中台的视角去介绍一下我们在《使命召唤手游》里面所做的一些工作。
一、引擎公共能力的建设
这部分是天美J3工作室引擎技术组整个搭建过程的简单复盘，我们这个组成立了一年，才刚刚开始，今天只是抛砖引玉和大家一起探讨，一起进步。
2018年其实可以说是手游3A化的元年，我们一起看一些业界游戏技术的变化。
首先是引擎技术移动化，我们在手游上大肆的使用端游时代的技术。大家都在使用线性空间光照及HDR管线；大世界成为热潮，很多开发者不断地讨论多地貌的地形制作，地形渲染；TOD日夜变化大肆流行，雾和大气也是标配；图形上都使用基于物理的渲染，以及在移动端实现一些拟合的动画光照GI效果。
同时，引擎与工具也在不断升级：UE4普及，Unity也升级到了2019，以Houdini与Substance为代表的美术工具被大家广泛使用。
硬件也在进步：高通GPU已经到了855+，苹果进入了A13，性能与几年前的PC无限拉近。PC显卡已经进化成光线追踪的RTX，各大引擎厂商都在更新自己的光追烘焙器。
此外，各种3A大作前沿技术被手游使用，比如Destiny的VisualEffect技术，《Far Cry 5》和《幽灵行动》的大世界技术，各个游戏公司也在各大技术峰会和大作中吸取技术经验。
综合起来，其实是就端游技术在手游延伸，引擎工具的发展，硬件的发展，再加上整个业界技术的分享和传承，引发整个手游技术不断往3A化发展。
技术深厚的公司出现了一大堆的高质量的手游，比如说像《天堂2》、PUBG Mobile这样一些高质量游戏在国内外都取得了不俗的成绩。在未来也会有更多高质量的手游出现，技术竞争也会越来越激烈。我们制作的《使命召唤手游》会在今年海外进行上线，大家也可以看一下这款产品，我们在上面做了很多深度技术的改造。
再看看传统游戏开发团队的架构。它的组成很简单，按照岗位划分会出现一些美术团队、策划团队、服务器开发和客户端开发。同时，在技术团队中会有那么一小波同学会做一些引擎的开发工作，称为“引擎工程师”，他们在负责一些面向于项目需求的特性的开发，性能优化，解决一些技术的难题，去参与攻坚一些项目，这样的架构能够很好的服务团队，这一波人也能为项目解决各种各样的疑难问题。
两年前这样的运作模式出现了很多很多的爆款，甚至于腾讯内部很多成功产品也是由这种架构延伸出来的。但是，长远来看这样的架构还是会出现瓶颈。
在手游3A化的今天，对于品质和创意要求越来越高的今天，技术已经成为胜败的关键。以前游戏开发团队往往会存在这样的问题，技术积累比较缓慢，技术管线需要升级，人才需要升级。
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在不断的成长，欢迎大家多多指教或者加入我们。这就是我今天分享的内容，谢谢！
