王者荣耀的技术修炼之路
5 月 11 - 13 日，Unite 2017 Shanghai 在上海国际会议中心举行，在案例分享专场上，腾讯王者荣耀项目技术总监邓君为我们带来了《王者技术修炼之路》的主题演讲。
以下为演讲实录：
大家好，我是王者荣耀的邓君，很高兴今天能够有这样一个机会跟在座的同行一起聊聊技术，互相交流，也感谢 Unity 提供这样的机会，可以由一个互动。
这次的主题主要是讲一下王者荣耀从立项之初经历的惨淡时期到华丽的翻盘，这里不管碰到技术方面的问题，还是游戏方向上的改变，我是技术出身的，整个课题也是技术面的，会重点介绍王者荣耀和现在见到大部分不同的技术方案，它实际原理、问题和优化的思路。
先简单自我介绍一下，我是 2004 年加入腾讯，在腾讯做了 4 年多的应用层面开发，还包括 Web 各种各样后台都做过，经历比较丰富，在 2009 年我回成都，刚好成都的岗位也就只有游戏部门是比较合适的，就转行做游戏了。在成都这边，参与过一个《QQ 封神记》的开发，从封神记出来之后，又开发了一款游戏，这款游戏开发了三年多，游戏从 1.0、2.0、3.0，这个时候再转型做手游，直接做的王者荣耀。
我们介绍一下王者荣耀，现在了解王者荣耀或者在玩王者荣耀的人确实比较多，但是我们曾经也没有想过王者荣耀有这样的结果。当时端游很久都没有做出来成绩，业绩和收入都面临比较大的问题。霸三国做到 1.0 之后，要操作多个单位，2012、2011 年的时候，大家觉得特别费操作，要控制很多单位的游戏，操作起来很难，一开始可以操作 5 支单位然后变成 3 支持，3 支完了觉得也很痛苦，这个游戏策略性很强，慢慢把 5 个单位的技能合在一个身上。你要做创新，你要脱颖而出，是很难的事情。在 2014 年年底的时候，2015 年我们准备开一个手游团队。为什么开手游团队？国内环境里面，基本上都在开发手游，能够继续开发端游或者要准备立项端游的非常少，包括腾讯也就是 2、3 款端游在开发，端游还是有希望的，开发的团队比较少，手游也是一个机会，希望在 2015 年把我们的霸三国端游在手游上呈现。这个时候我们进行了一个初期 Demo 的验证，Demo 验证只有三个人，引擎的、框架的、后台的，大概做了两周到三周，把 Demo 做出来，里面有基本的进游戏、选人，然后可以释放技能，正常的战斗，到结算。但是是用 Unity 来做的，两、三周做完之后，觉得 Unity 很好用，开发确实比较高，简单的先这样，2015 年才开始进行一个真正的独立招聘 20、30 人做手游项目，当时是这样的想法。2014 年年底的时候，我们制作人去公司开会，当时这是一个非常明智的决策，我们需要马上暂停端游的开发，直接做手游。就是这样的一次决策，真正的是扭转了我们整个团队的命运。如果晚一年，可能今天的游戏就是另外一个，应该不是王者。
我们从端游转型做手游，做手游肯定要面临选择什么样的引擎，采用什么样的方案进行手游的开发。当时的环境，周边包括腾讯还有成都的创业团队，基本上都是 Unity，我都不知道，大概在 2013、2014 年出来很多游戏都是 Unity，我们做 Demo 的时候，也会选择大家用的，已经有产品进行验证了，同时我们也考察它适不适合我们的团队。Unity 我们当时做 Demo 的理解，它确实对中小团队，包括作为一些大型项目，它有几个比较明显的优势。在两三周你就可以做出 Demo，易上手是一个非常大的优势，在座可能都理解。另外，它的工具都是很完善的，能够做到一站式解决，你不需要在这里面下载工具，那里面额外补充一些插件。另外还有它插件资源很丰富，我们从最开始做 Demo 的时候，基本上都是找一些我们可以用来验证我们想法的，它肯定可以加快我们开发的效率。上面这三点加起来，是它非常明显的优势，开发效率特别高。还有跨平台，那是肯定的，它本是就是跨平台的引擎。还有你能够对人员的补充，非常容易，因为在周边包括社会上招聘都很容易招聘到熟悉 Unity 的开发人员。我们这边直接对比以前自己做引擎，或者用过其他的引擎，从效率上来讲，我们选择了一个开发效率最高的引擎。这里面回过头来，从端游转换到手游是在 2014 年底，我们真正开始的时候在 2015 年 3 月份就进行开发，这个时候我们开发的周期，老板要求是 6 个月，我们需要在 6 个月把手游做上线，要多少人给多少人的情况。我们本身霸三国开发大概有 40、50 个人，后面把周边的兄弟部门还有成绩不太好的都合并在一起了，里面有一些会 Unity、会手游的，还有一部分没有手游开发经验的，组合在一起，形成了 100 多人的团队，进行了游戏的开发。
还有一个很重要的选择，我们本身是一个网络游戏。当时在 2013、2014 年的时候，游戏在 pvp 上面比较弱，大部分是卡牌游戏、单机游戏，我们本身是一个端游，它的生命力包括趣味性也是很足的，我们做手游的目标，即使我们里面有创关，但是我们里面有最核心的东西，我们要把 pvp 做好，让玩家有真正的对抗，玩家与玩家有交流，体会到游戏的乐趣。所以在选择 pvp，它是一个网络游戏，网络游戏我们选择用什么样的同步机制呢？最常见的应该是 cs 状态同步，我们端游也是这样做的。后面我们为什么会选择帧同步，后面再说。
先看一下状态同步的优缺点，它的安全性非常高，基本上外挂没有什么能力从中收益，基本上都是服务器校验。另外状态同步对于网络的带宽和抖动包有一个更强的适应能力，你有一个输入延迟 200、300 后面又好了，你其实感受不出来它不太舒服的地方，还有一个状态同步比较好的地方，在开发游戏过程中，比较容易体会到的好处，它的断线重回比较快。如果我的游戏崩溃了，回来之后需要服务器把所有重要对象的状态再同步一次过来，重新再创建出来就可以了。还有一个，它的性能上优化也比较明显，我说的性能优化是客户端的。客户端在做性能优化的时候，它可以做裁剪，我看不到的角色我可以不用创建，也可以不用对它进行运算，这是它的优点。
说完了优点，再说一下我认为的缺点。一个就是开发效率要相对帧同步差一些，很多时候你要从服务器客户端的每一个角色对象的状态之间保持一致，你很难做到它是一致的，包括客户端和服务器端更新的频率，他们对优化的一些裁剪，包括网络的一些抖动，你要让每一个状态在客户端有一个同步，是比较难，你要想调试这些东西，出现的漏洞、不一致的现象，调试周期比较长，想要达到优化好的水平，也是比较难的。另外一个，它比较难做出动作类游戏打击感和精确性。比如说你要做一个人是射击类，他的子弹每秒钟要产生几十颗，基于状态同步是比较难的事情，因为在很短时间会产生很多角色，要通过创建、销毁包括位置和运算。另外还有一个缺点，它的流量会随着游戏的复杂度，角色的多少它会是一个增长的过程。你做手游，也是想追求你在 3G、4G 也能够玩 pvp，对你付费流量的消耗，我们希望能够做到一个比较好的水平，不希望能够打一局游戏需要消耗几十兆的数据流量。
我们再看一下帧同步，大部分人应该还是了解的。最初大家玩的心计、魔兽 3 都是帧同步，他们是基于局域网，网络非常好，也不需要服务器，他们直接用新型的网络就能够搞定。帧同步的优点是一个开发效率比较高，为什么说开发效率比较高？如果你整体的框架是验证通过，你把它的缺点解决了的话，你完全开发思路就跟写单机一样，你只需要遵从这样的思路，尽量保证性能，该怎么写就怎么写，相对于我们经验来说，以前要在状态同步下面做一个复杂的技能，有很多段位的技能，也许可能要开发好几天，才能有一个稍微过得去的结果，可在帧同步下面，英雄做多段位技能很可能一天就搞定了。另外它的打击感确实比较强，打击感强除了我们说的各种反馈、特效、音效，还有它的准确性。你游戏里面看到这些挥舞的动作，它能够在比较准确的时刻就能够有反馈，包括它的密度可以做到很高的频率，是状态同步比较难做的。还有一个优点，它的流量消耗是稳定的。大家应该看过星际的录像，它的录像只有几百 K，这里面就是网络流量里面全是驱动游戏的输入序列。帧同步只会随着玩家数量，流量才会增长，如果玩家固定的话，流量不管你的游戏有多复杂，你的角色有多少，它基本上都是稳定的。还有帧同步比较好的一点，可以做观战，录像的存储、回放，包括基于录像文件后续的处理都比较容易做。
说了这么多优点，它肯定也有缺点。它的缺点第一个最致命网络要求比较高，如果你的网络稍微有抖动，它是一个锁帧的，如果有这样的抖动，一段时间调用次数是不稳定的，网络命令的延迟会有挤压和舒展。另外一个缺点，它的反外挂能力很弱，帧同步逻辑都在客户端里面，你可以查得到它有没有作弊。游戏的逻辑是在客户端，你可以修改它。为什么王者敢用这样一个东西，当时选型的时候，半年的开发周期需要做出来，要做上线，要有几十个英雄，有时间的压力。另外一个这样一个游戏类型，不像成长类的游戏，它是基于单局的，单局你修改这个东西，顶多影响这一局的胜负，不会存档，你刷多少钱穿比较好的装备，这本身是一个弱成长的游戏，我们认为它不是一个致命的缺点。
你在这上面可以做到收益不明显，你做完之后我们可以发现你有没有作弊，作弊了一样有惩罚。反外挂虽然缺点在，在王者这样游戏类型下面不是特别明显。还有一个缺点，短线重回时间很长，我估计下面有王者非常多的玩家，也碰到过如果你玩着玩着最后闪退你回来有多痛苦，第二个 100%等到完成你游戏进去了，游戏也结束了，这个帧同比是比较致命的，每一帧的盐酸最后才能算到正确的状态。还有一个比较大的缺点，它的逻辑性能优化有很大的压力。大家应该没有见到哪一款大型游戏用帧同步来做的，每一个逻辑对象都是需要在客户端进行运算。如果你做一个主城，主城里面有上千人，上千人角色虽然看不到它，但是你需要对它进行有效的逻辑运算，这就是它无法做非常多的游戏对象需要更新的游戏场景，这是它的缺点。
为什么我们选择了帧同步而放弃了状态同步呢？前面提到它两个优点缺点是相对的，这边的优点对于那边来说就是缺点。对于我们手游立项的时候，最重要就是时间。当时市面上正在开发的包括腾讯内部的都不止王者一款在开发，大家都在争取上线的时间，我们可能会选择一个开发时间周期最短的方案。然后我们做端游也有一个深刻的体会，做有趣的英雄，有趣的技能，它在状态同步上面很难调出一个比较满意的效果。它的优点包括我们自己对于状态同步的体会上面，最后我们依然选择帧同步的方案。选择帧同步方案，确实现在回过头来讲，我们把缺点优化掉规避掉，它带来的好处是比较明显的。我们的游戏比较好玩，除了英雄的设计包括整个技能的感觉，还有很重要的一点，它确实在做一些非常有特色的英雄，它的技能、反馈、体验上面都是做的不错，这是基于帧同步技术方案的优势。
我们选择了方案之后，当时觉得很嗨，觉得这样一个技术方案开发起来得心应手，效率如此之高，做出来的效果也很好。但是它也有好的一面，也有坏的一面，我们开发了 6 个月，第一个版本上线在 8 月 18 号，同时上线公司也有一款超神，我们惨败，惨败的原因很多，技术层面应该就是这上面的三座大山。第一个同步性，同步性这块容易解决，其实也解决了；最大一个问题是网络问题，帧同步它的网络问题导致我们对它技术方案的原理没有吃透，碰到了一些问题，那时候游戏感觉延迟很重，画面卡顿，你明显感觉走路抖动的现象；第三性能问题始终存在，也一直在优化。
先看一下第一座大山，最容易解决的，说一下帧同步的技术原理，相当简单，10、20 年前就有了，它要一个相同初始的状态，后面你需要有一个相同的输入，我往下一帧执行，执行的时候我所有代码的流程，大家走的是一样的，有了相同输入之后，输入包括第一帧、第二帧、第三帧，有了输入然后要执行相同流程，大家走的一模一样，这个结果调用完了以后，又有一个新状态，下一个状态大家又有一样，完成了循环，相同的状态，相同的流程，不停的这样循环下去。这个原理虽然简单，但是你要去实现它的时候，还是会有很多坑。
右边写的是实现要点，这是我们在解决第一座大山经验的总结，也是我们实际开发过程当中做的事情。
我们所有的运算都是基于整数，没有浮点数。浮点数是用分子分母表达的。我们可能还会用到第三方的组件，帧组件也要需要进行一个比较严格的甄别。我们本身用的公司里面关于时间轴的编辑器里面，最初也是是浮点数，我们都是进行重写改造的。你初次接触帧同步里面出问题，就是写逻辑的时候和本地相关、和我相关，这样就导致走到不同分支，真正客户端跟逻辑的话，要跟我这样一个概念无关。还有随机数，这个要严格一致。这是实现的要点，严格按照这上面的规则写代码还是有可能不同步，本身就很难杜绝这样的问题。真正一个比较重要的是提升发现不同步的能力，什么时候不同步了，不同步你还要知道不同步在什么点，这是最关键的。你需要通过你的经验和总结提升这样的能力。这个能力还是通过输出来看不同客户端不同输出，找到发生在什么点。特别是在概率比较低，我说了不同步，在座有没有碰到不同步，王者的不同步是什么样的？
观众：王者刚上的时候，我打了一个 3v3，这个 3v3 感觉就是不同步的，表现形式已经乱套了，后来因为有一个 AI 的装备不一样，导致不太一样。
有一个未知网络错误，本身未知网络错误就是你和别人不一样的弹框，很难用不同步的措词告诉大家，所以叫未知网络错误。
观众：下面的结果有一个手机就不动了，剩下一个还在运转。
我们看到不同步的现象应该是这样，有人对着墙跑，它首先会弹出未知网络错误，点完之后应该重来，如果屏蔽掉了，你看到就是你和别人玩的游戏是不一样的，进入平行世界。本身这一块，最开始上的时候，希望不同步率达到 1%，就是 100 局里面有 1 局出现不同步，我们就算游戏合格，其实对于这么大一个体量游戏来说是有问题的，经过我们不停的努力，现在是在万分之几。一万局游戏里面，可能有几局是不同步的，你会收到未知网络错误。这个问题不一定是代码原因或者没有遵循这些要点写出来的，包括你去修改内存，包括你去加载资源的时候，本地资源有损害或者缺失，或者是异常。异常说白了，你没有办法往下执行，大家走了不同分支，这都可能引起最终是不同步的。如果你不同步概率比较低，这种万分之几概率的时候，很难通过测试来去还原，去找到这样不同步的点。
最开始我们游戏出现不同步的时候，就是周末，随着你的概率越来越低，基本上你就自己还原不出来了，只能依靠玩家帮你还原这样的场景，来分析这样的不同步。
同步性遵循这样的要点，按照这样的思路来写，加上你不同步定位的能力，有了监控手段能够去发现，这个问题其实就解决了。解决之后，你就可以好好享受帧同步的开发优势。
我们再看一下第二座大山就是网络，818 出台的时候，延迟非常大，而且还是卡顿，现在看一下帧同步里面比较特别的地方。帧同步有点像在看电影，它传统的帧同步需要有 buffer，每个玩家输入会转发给所有客户端，互相会有编号，第几帧，第几帧的输入，假如说我现在收到第 N 帧，如果我收到第 N+1 帧的话，N 帧这一帧我是可以执行的，是这样一个情况。服务器会按照一定的频率，不同的给大家同步帧编号，包括这一帧的输入带给客户端，如果带一帧给你的数据你拿到之后就执行，下一帧数据没来就不能执行，它的结果有可能你网络非常稳定，绝对理想值的情况下还好，现实网络不是这样的。帧同步要解决问题就是有 buffer，以前有动态的 buffer，它有 1 到 n 这样的缓冲区，根据网络抖动的情况，收入然后放到队列里面。这个 buffer 的大小，会影响到这两个东西，一个就是延迟还有卡顿。如果你的 buffer 越小，你的延迟就越低，你拿到以后你不需要缓冲等待，马上就可以执行。但是如果下一帧没来，buffer 很小，你就不能执行，最终导致的结果你的延迟还好，但是卡顿很明显。你会调到帧同步的 buffer，假如我们认为网络延迟是 1 秒，你抖动调到 1 秒，那得到的结果虽然你画面不抖动了，但是你的延迟极其高。最坏的网络情况都考虑进去，buffer 足够大，跟看视频是一样的，平行的东西，看你调大条小。一些局部的措施我们都做过，都是一样的问题，让我们差点死掉的问题。旁边那幅图的意思，就是如果今天解决不好，明天我们就回家了。
我们怎么优化卡顿这方面呢？本身刚才也提到了，帧同步有 buffer，这个 buffer 可以是 1 也可以到 n，我们要解决我们的延迟问题，我们就让 buffer 足够小，最后我们做到 buffer 是零，它不需要 buffer，服务器给了我 n，马上知道是 n，我收到 n，我知道下一次肯定是 n+1，所以我收到 n 之后马上就把 n 这一帧的输入执行了，下一步可能就涉及到了为什么不卡顿了，画面不抖动了，是最后一条，是本地插值平滑加逻辑与表现分离。客户端只负责一些模型、动画、它的位置，它会根据绑定的逻辑对象状态、速度、方向来进行一个插值，这样可以做到我们的逻辑帧率和渲染帧率不一样，但是做了插值平滑和逻辑表现分离，画面不抖了，延迟感也是很好的。做了这些，我们还做了 TCP 换成 UDP，在手机下面，弱网的情况下，TCP 很难恢复，UDP 本身作为游戏也有优势，之前还用过 RUDP，没有优化到最后，不是很理想，最后用了 UDP 来做。整体来说，在网络好的情况下，它延迟也是很好的，在网络比较差的情况下，做插值，网络情况差的话，也是传统 cs 的表现，我们经常见到角色 A 和 B，有些客户端 A 在左 B 在右，有些是 A 在右 B 在左，帧同步逻辑上面 AB 之间的距离和坐标都是完全一样，但是画面上看到他们可能会不重合，那就是你把它们分离之后的表现。网络极其好的情况下，它应该是重合的，但是在网络差的情况下，可能会有些偏差。这里面是最重要的一块优化。
下面是我们对性能优化，本身帧同步逻辑上面在优化上面存在一些缺点，所有的角色都需要进行运算。这里面还是用的 Unity，里面也有很好的特性，如果你想追求性能上的极致，有些东西你需要寻求好的方式。比如讲热点的处理，我们是不用反射的，它都有 GC 性能开销，你可能经常会隐藏或者把它显示出来，我们的做法里面，把对象的显示隐藏放在不同的渲染层里面，尽量让整个游戏帧率是平滑的过程。还有我们本身有自己的系统，还有 AI，这样的一个游戏类型里面的角色比较多，你如果想要做比较好，它的 AI 是比较复杂的。要去优化热点，我觉得就只有这三个步骤可以走。
从程序的结构上面能找到更优的，它的效果是最明显的，如果你的结构都是用的最好，就在挖掘局部的算法，调整你代码的一些写法。如果局部的算法都已经调到最优还是没有什么办法，那只有一条路，就是牺牲整个质量，就是分帧降频。GC 这块刚才说不用反射，还有装箱和拆箱的行为也是尽量少用。Unity 指导过我们的优化，从 GC 上面的考虑，他们建议每一帧应该在 200 个字节以内是比较好的状态，其实很难做到，王者也是每一帧在 1k 左右，很难做到 200。还有 Drawcall，这些传统的优化手段大家都用的很熟了。还有裁剪，帧同步里面是不能裁剪的，表现里面我看不到的可以降低频率或者不更新它，这在表现里面可以做的。还有我们的血条、小地图上面叠的元素比较多，比较丰富，这块我们用了 31UI 的方式来优化，没有用 UGUI 里面进行血条方面的处理。我们也牺牲了一些东西，我们把所有东西都加载了，在游戏过程当中，我们希望不要有任何 IO 行为，包括输出我们都是要布局的。你处理的决策和复杂度，如果在一帧里面放出 100 颗子弹，在放 100 颗子弹的时候一定要掉帧的，一定要在力所能及的时候把这些东西做到极致。
前面提的是第一代，去年 5 月份以前做的优化方案。5 月份的时候我们还做了另外一件事情，为什么觉得 iOS 比Android高一些，本身一个是 iOS 的 CPU 架构包括系统确实都优化的比较好，另外我们用的 Unity4.6，在 iOS 下面 IL2CPP 它本身效率高一些，在Android端的机器各种各样，性能也是千差万别，我们只能用性能比较差的方式。因为本身已经做到逻辑和表现是分离的，我们能不能把逻辑独立出来，做成一个 C++的东西，我们在去年开始这样做了。做之前也测试过 C++和 Mono 性能的差别，大概是 2.5 左右，本身我们的逻辑占比游戏消耗 20%多，逻辑不是一个大头，我们做了这件事情之后，还是有效的，帧率提升了 2 到 3 帧，花的时间很长。整个时间大部分都消耗在了引擎和 CPU 的交互、调度，不是我们做 GameCore 就没有意义，做了这块我们有很显著我们以前逻辑上的 GC 没有了，我们有自己内存的管理、对象的管理，包括里面所有的容器类这些东西都是我们自己实现的，包括反射整个一套。它有了自己的内存管理，它本身效率就比较高，其实还是一个比较明显的优势，有了 GameCore 之后，有很多应用场景，这个东西就是玩法的服务器版本，应用场景运行服务器要做很多的分析，还有第三方使用都是可以的。GameCore 可以做成一个多线程的版本。
我们接下来看一下我们后面可能打算考虑的一些事情，一个就是我们想能不能在热更新上面有所突破。因为王者这样一个游戏类型，包括它的体量，我们对于性能有一个比较极致的追求，不会轻易使用脚本层面在性能层面本身就不是最好的。这个我们要去研究的就是热更新，性能最好的方式。另外的话，包括硬件厂商也沟通，他们其实也是希望游戏能够真正发挥多核性能上的优势，大部分的游戏在单核上面，把一个核吃的满满的，很多时候我们现在得出的结论，GPU 性能也很强，王者并没有对 GPU 占满，可能只用了 30%，CPU 反而吃的比较满，吃满以后它还有另外一个坏处，它的发热、降频，你如果用多线程、多核去尽量平坦，让它不要处于高频的工作方式，反而会有更好的效果。我们现在用 Unity4.6，Unity 进化到 5.7，后面他们还会推出新的特性，我们希望结合一些 Unity 新特性，现在已经有些游戏用 5.6 可以提升性能。不光是提升性能问题，Unity 在多线程的渲染，也有很好的作用，使用引擎优势也是很必要的。随着性能的提升，我们会对王者的画质进行提升。
今天我的分享就到这里，谢谢大家。
了解最新移动开发相关信息和技术，请关注mobilehub公众微信号（ID: mobilehub)。
