《天涯明月刀手游》开发历程：让技术成为创新的驱动力

以下文章来源于腾讯游戏学堂 ，作者腾讯游戏学堂腾讯游戏学堂.

讲师丨Luke

腾讯互动娱乐 专家工程师

本文系腾讯游戏“Rocket Plan”引擎技术沙龙-北京大学专场分享内容摘录，分享主题为《〈天涯明月刀〉手游技术研发分享》。敬请期待后续更多精彩内容上线。

《天涯明月刀手游》2017年开始，历经4年研发，2020年10月份正式上线。这里我们将回顾一下整个项目的开发历程，使大家对《天涯明月刀手游》在技术层面有更深入的了解。

首先我们来看看《天涯明月刀手游》一些比较有特色的游戏内容。

高品质的捏脸系统：

捏脸系统向来是MMO游戏必备的系统。《天涯明月刀手游》在这个系统上表现了极高的品质，不仅完美还原了端游的品质，甚至很多细节超过了端游。

导致后续很多玩家反过来向端游的开发组要求手游的一些效果。

高开放性的战斗系统：

《天涯明月刀手游》的战斗系统战斗表现上有着不输动作游戏的战斗效果，以及炫丽的技能表现。这套战斗系统从端游开始有8、9年的沉淀，但是在表现出色的同时整个系统也非常的复杂。

这么复杂的战斗系统，在多人战斗时对性能的压力是非常大的。底层的性能优化可能是玩家看不见的，但却能给很多玩家看得见的内容提供了基础。

主机级别的场景渲染：

《天涯明月刀手游》在场景的表现上也是非常出色的。大气、植被、水面都有非常好的效果，在我们的PBR2.0架构下的夜景光照更真实，更能让玩家感受到真实的武侠世界。场景的大视距和远处细节的高精度非常让玩家有沉浸感。以及我们的美术生产管线提供给美术极大的发挥空间，可以创作一些高度风格化的场景效果。

《天涯明月刀手游》是一款以主机游戏的画面为目标的产品，因此我们在任何细节上都没有放松。

无论是画面效果、战斗系统、精致的捏脸都是构建在天手引擎的基础之上的，技术在整个产品的研发里扮演了很重要的角色。

我们在技术方面有很多突破，这对行业产生了推动级的影响。我们研发周期大约是三、四年，但背后是有完整的十年的技术积累。

天涯明月刀引擎组是非常注重团队技术积累的，在引擎技术的各方面都有详细的knowledge graph，积累了各种技术实现和经验总结。无论任何一项技术，无论团队里的任何同学，都很快能上手去开发，这是非常重要的。

时至今日，游戏开发已经是一个非常复杂的系统性工程了。

游戏开发，谁都想创新。而真正制作的时候才发现捉襟见肘，无法实现的想法太多。

接下来是靠技术发力解决问题还是限制创新做一个能做得出来的产品，是很多团队需要解答的问题。

《天涯明月刀手游》的整个开发历程也是经历了这样的起伏。

《天涯明月刀手游》开发历程回顾

这是2017年刚开始研发时的画面，美术在尝试资源规格和效果，程序在添加各种基础功能。

2018年游戏已经展现了比较高的美术品质。但大量的细节也使性能问题突显了出来。在这个镜头下，Drawcall达到800-1000，在当时骁龙835的CPU只能跑10fps左右。

对整个团队来说，这是一个是否要妥协的关键点。对于《天涯明月刀》这样一个IP来说技术上的妥协是不可接受的。

我们对Unity引擎做了大量的研究和分析，最终决定重写整个底层的渲染管线架构以及使用Vulkan作为Android平台默认的图形接口。这是一个正确的决定，我们也因此在同期的产品中取得了很大的技术优势，并为未来打下了基础。

2019年我们又在多线程架构和Vulkan的基础上引进了大量新技术。不断的性能优化，给美术效果和游戏内容留出了空间。

上面的画面正是2017年的位置，可以说效果已经是天翻地覆了。

2020年是我们最后冲刺的一年。在这一年里，《天涯明月刀手游》又完成了大量的内容开发，以及不断的适配调优，使我们能适配的机型不断下探。我们也希望将游戏能提供给更多的用户。

要知道MMORPG在手游开发里面，可以说是最高难度的挑战。

首先我们要面对海量的资源，而且这些高品质高规格的资源还要大量堆砌在游戏中。尤其是团战的时候，大量的玩家和特效进一步推升了性能压力，而这个时候往往最需要保证性能的时候。

《天涯明月刀手游》为了应对这样的挑战可以说引入了非常复杂的技术栈。

一张图展现《天涯明月刀手游》技术栈

在引入这些技术的时候我们是有着明确的技术思路的。

数据处理的并行能力可以说是整个业界未来的方向，同时也是天手引擎技术的大方向。我们通过架构调整以及引入大量新技术，将引擎的并行处理能力推到最大。

在真正的项目开发中控制好如此复杂的技术栈是非常大的挑战，对于关键性技术我们秉持了逐渐推出，不断测试，不断迭代的原则，以此来保证《天涯明月刀手游》开发顺利进行。

正是在这样的思路的指导下我们完成《天涯明月刀手游》一次比一次惊艳的四次对外测试。

这四次测试不仅是游戏内容和品质的测试，也是我们比较大的技术里程碑，在每个测试阶段我们均安排了一些关键的技术点对外验证。

这里面很多工作其实也并不是一开始就考虑到的，在四年的开发和测试周期里，我们也不断迭代，不断提出更高的要求。

小楼一夜听春雨

第一次测试我们主要对外验证的是多线程渲染框架。

在与原生Unity的对比上我们可以看出在drawcall达到1000左右时原生Unity的渲染大约需要80ms一帧。

在《天涯明月刀手游》最后上线时，我们通过各方面技术加持的优化将一帧的时间优化到16ms以内，有一个整体5倍的提升。

引擎设计的核心是对数据的处理，在重写底层框架之初我们对整个引擎的数据处理做了详细的设计。

我们将数据分为三部分：

• Renderer——供主线程游戏逻辑使用，游戏逻辑对这部分数据做直接修改。

• TranscriptRenderNode——供渲染线程使用，与主线程的Renderer对应，只保存Renderer的渲染相关的属性。

• 渲染命令和GPU Resource——提交线程是负责调用图形API的线程，在这里关心的只有要执行什么渲染命令和对应的数据与GPU资源。

同时需要对这些数据的使用解耦，保证不同线程只使用自己的数据，对多线程架构的稳定来说最重要的就是数据的线程安全。这里我们提供了两种方式的数据转换：

• Context形式，拷贝提交的方式

• Change-Update形式，数据改变以命令形式在不同线程的对象之间传递和更新的方式

同时针对一些需要在不同线程之间使用的数据我们提供了保证其生命周期正确的数据流控制方式。

比如一个RenderPipelineContext，由主线程生产，生产之后会以加引用计数的方式保证其不被销毁。RenderPipelineContext后续会被渲染线程使用，做为一帧画面渲染的上下文，并在渲染流程结束后减引用计数将其转移至销毁队列。最后由提交线程真正销毁，保证Context内的所有资源在当帧渲染命令全部结束后销毁。

另外我们还引入Data-Oriented Design（DOD）的代码设计思想。

DOD与OOP不同的地方是在于，OOP是一个建立模型，让复杂的问题更有逻辑更易于理解的程序设计思路，而DOD则是完全面向性能，以对数据的处理性能最优的方式去设计程序。

在这些设计的指导下，我们对引擎底层进行了大量的重写，最终实现了一套更好的架构。

除了对引擎架构的重构，性能优化也非常依赖于对硬件的理解。

手机的硬件环境是非常复杂的，最新的CPU骁龙865、855都是4小核-3大核-1超大核的架构，再往前的CPU大部分是4大核-4小核的架构，再早的还有4小核-2大核等等不同的CPU架构。

由于对移动硬件来说温度是非常重要的指标，因此手机厂商的控温策略也是不一样的，手段包括降频甚至关核。

在如此复杂的硬件条件下我们要如何做好性能和发热的均衡，这就需要对硬件做深入的了解和大量的实测。

通常来说手机厂商是不建议调整Thread Affinity的，CPU会有自己的调度策略以保证性能和温度的平衡，但这也并不是一个绝对正确的选择，真正什么样的方式是对项目有益的还是要理论结合实际的进行测试。

我们经过大量的测试之后，最终的方案是将除了主线程和提交线程以外，性能负载不算很高的其他线程都绑定在小核上。这样做在多人战斗的时候帧数会有轻微的下降，但换来的是温度上2-3度的收益。这在产品体验方面可以说是更优的选择。

另外测试比较多的是线程时序的调整。

提高硬件并行程度，在短时间内更充分的利用CPU，被证明是更适合手机硬件的方式。我们在没有任何代码优化的情况下仅靠线程时序的调整就在不同手机上得到了3-9度的温度降幅。

这种情况在我们团队内部通常被称为“低垂的果实”，即在大量底层工作都已经铺垫好的基础上能用很低的代价得到很好的收益。如此大的温度降幅正是建立在天手引擎大量并行化的架构基础上的。

整个天手引擎的开发过程也不是一蹴而就的，从一个项目开发的角度来说，一边开发项目一边做引擎的彻底重写是非常困难的。因此我们在天手引擎的开发过程中也是非常小心地从项目收益最大化的角度去考量这个问题的。

在第一阶段“内部测试版本”完成之后，我们有了一定的性能收益，但仍然有很多可见的优化空间。但我们并没有继续钻在优化这一个点上，而是交付了一个版本给QA进行测试，保证这个版本的稳定。最终QA给出的测试数据无论是性能还是稳定性都得到了团队的认可。

天手引擎正式加入版本构建之后很长一段时间我们都是双线维护，即同时维护原生Unity和天手引擎两个版本，美术和策划仍在使用原始版本。

在这个阶段我们不断完善编辑器相关功能以及各种版本制作相关的功能，到2019年下半年，天手引擎才全面替代了原始版本。

这样的开发节奏势必对引擎组的效率有一定影响，但却能最大程度的保证整个项目的顺利进行。

江湖何处不飞花

Vulkan是我们第二次测试的技术里程碑

目前业界主流的仍然还是OpenGLES，Vulkan 2016年投入使用，但在《天涯明月刀手游》开发的时期，Vulkan API还并不成熟。

Vulkan在理念上是有着巨大的进步的，在对GPU的使用上也给开发者更大的空间，但同时也提高了使用难度。我们从17年其实就开始关注vulkan了，但直到2018年才正式决定拥抱Vulkan。

通过引入Vulkan API，我们在大量渲染drawcall的情况下，性能进一步提升了20%-30%，并且使我们得以受益于后续其他新技术带来的性能提升。

Vulkan真正使用起来难度是非常高的，相当于技术团队来实现部分原来由驱动层实现的功能。在解决兼容性问题和各种GPU hung问题的过程中，我们付出了大量的时间和精力。不过我们从这个过程中得到的经验也是其他团队无法比拟的。

更令人兴奋的是在我们和硬件厂商紧密的合作当中反过来也使Vulkan更加成熟。高通、华为这些厂商都对天手引擎都给予了很高的评价。

与谁把酒邀明月

GPU Driven和Virtual Texture是第三次测试的技术里程碑。

在vulkan的基础上，以及我们对引擎架构并行化的方向下，GPU Driven顺理成章的成为了天手引擎后续开发的一个主要技术点。CPU和GPU之间的并行进一步优化了性能。

在图形方面有了Vulkan之后，天手引擎就开始可以去挑战主机平台最前沿的一些技术了。

比如说AdaptiveVirtualTexture，它是主机平台上面的地形渲染比较好的一种技术。应用这项技术可以在提升地貌丰富性的同时不增加渲染开销。

但在手机上落地是非常的困难，里面有大量的细节，天手引擎组的一位专家级工程师做了大约一年到一年半的时间，反反复复迭代优化细节。最后才在手机平台上去跑通，使得地形渲染上能获得平均约两倍的收益。

另一个技术GPUDriven也是最新一代主机上比较重要的技术，将原来在CPU上的流程完全搬到GPU上，以数据驱动的方式实现，比如说地形剔除和渲染。

这部分做好后天手引擎就获得了另一个非常强的技术优势，原来可能都是十几个渲染指令完成的事情现在只要一个，少了90%的开销。同时由于可以在GPU上做更精细的剔除，渲染的顶点数据量数少了75%。

将我行兮向天涯

在所有这些性能的提升之后，天手引擎拥有了更大的发挥空间。于是引擎组跟美术一起在进一步提升《天涯明月刀手游》的效果上开始发力。

当性能上有了足够的空间后，负责渲染feature开发的同学和美术同学开始可以发挥实力了，将整体的光照水准大大的拔高一个层次。

《天涯明月刀手游》的整个PBR2.0系统大致可以分为以下几部分：

• BRDF，这部分除了一些优化算法，不做大的简化，保证物理正确。

• LookDev制作管线，保证美术在各个环境下都能得到最终游戏内的视觉效果，制作正确的材质。

• 完整的光照分量，充分考虑各种光照分量的物理正确性，通过对光照分量的拆分在游戏中体现Time of Day，体现动态的光照变化，体现遮挡信息。

• 物理正确的渲染流水线，在材质信息、光的方向和遮挡等信息被正确计算的基础上，如何在相机里正确的表现亮度、颜色等最终被玩家接收到的信号也是非常重要的。符合物理的光源照度以及参考相机曝光原理为美术提供曝光设置可以保证美术能正确的设置亮度。再加上后期对Tonemapping算法的调整，使得玩家能看到非常自然真实的光照效果。

以下是一些效果的对比图：

PBR2.0系统下的夜景对比

原始场景：

PBR2.0的场景：

你想要的未来终会实现

《天涯明月刀手游》四年的开发下来，从测试到上线得到了玩家的认可，得到了行业内的认可。在这个背后是技术不断创新，不断积累的结果。因此我们也不会止步于此，未来我们也会不断的追求更高的目标。

接下来是一个撸猫系统的视频，这个系统可以说是技术驱动创新最好的例子。最初只是从一个需求出发。美术想要更好的毛皮效果，然而我们在猫上面迭代出满意的效果之后，美术和策划就爱上了这只猫，为了它一个系统被设计了出来。

最后是《天涯明月刀端游》在做的一些技术探索。