已经在市场上取得巨大成功的《王者荣耀》一直是业界各方关注的对象，而我们也知道这款产品在成为之前也经历了一段鲜为人知的调教时期国家级比赛。 即2015年8月18日不删档正式测试版上线后，被腾讯评为六星以下。

据了解，8月份后的两个月时间里，《王者荣耀》技术团队对这款产品进行了非常深度的优化，克服了局内同步、网络要求、性能三大难点，成功登陆腾讯。 六星级产品的标准。 比如出现延迟、卡顿等不同步问题的概率从过去的1%降低到了0.01%，极大提升了游戏体验。

在今天Unity举办的Unite 2017开发者大会上，《王者荣耀》项目组技术总监邓军回顾了这款游戏的调优过程，回顾了这款产品在技术层面遇到的三大问题。 以及他们的解决方案。

值得一提的是，参加会议的开发者们也非常关注本次演讲的内容。 不仅主席座无虚席，包围了整个演讲会场，演讲结束后，葡萄先生一路上还听到了很多开发商的声音。 浅谈《王者荣耀》的技术经验。

以下内容由游戏葡萄整理发布。

大家好，我是《王者荣耀》的邓军。 很高兴今天有这样的机会和同行们一起聊技术，互相交流。 也感谢Unity提供了这样一个互相交流的机会。

这次的主题主要是聊《王者荣耀》从立项到华丽翻盘所经历的惨淡时期，包括遇到技术问题和游戏方向的转变。

我是技术出身，整个话题也是技术性的。 我会重点介绍一下王者荣耀以及我现在看到的大部分不同的技术方案，它的实际原理、问题和优化思路。

我先简单介绍一下自己。 我是2004年加入腾讯的，在腾讯工作了4年多，从事应用级开发，包括各种Web背景，经验丰富。 2009年我回到成都的时候，恰巧只有游戏部门更适合成都的职位，所以我就转而做游戏。 在成都，我参与了《QQ封神记》的开发，随后又开发了《三国志OL》游戏。 这款游戏已经开发了三年多了。 经历了从1.0、2.0，再到3.0的游戏版本迭代，然后转型为手游，直接做出了《王者荣耀》。

现在确实有更多的人了解《王者荣耀》或者正在玩《王者荣耀》，但我们没想到它会有这样的结果。 当时端游已经很久没有出成绩了，无论是业绩还是收入都面临着比较大的问题。 2012年和2011年左右，《三国志OL》达到了1.0版本。 游戏中，玩家需要控制多个单位，操作难度较大。 一开始他们可以控制5个单位，然后变成3个，但即使只有3个单位，操作起来也让人感觉很痛苦，所以我们逐渐将5个单位的技能结合在一个英雄身上，并不断优化。 可见，在MOBA领域，你想要创新并脱颖而出是非常困难的。

2014年底、2015年初，我们计划组建手游团队。 因为当时国内市场基本都是在开发手游，能够继续开发或者计划立项的端游少之又少。 包括腾讯在内，正在开发的端游也只有2、3个。 手机游戏是一个机会。 我们希望在2015年推出我们的《三国志OL》手机客户端游戏。

这时我们进行了初步的demo验证。 做demo的只有三个人，引擎，框架，后台。 制作一系列作品大约需要两到三周的时间。 在这个demo中，基本步骤是进入游戏、选择玩家、然后释放技能、正常战斗、结算。

我们使用Unity作为demo的引擎，做完之后我们也感觉Unity非常好用，而且开发效率确实比较高。

2014年底，我们的制作人去公司开会王者荣耀辅助购买平台下载，做出了一个非常明智的决定：我们需要立即暂停客户端游戏的开发，直接开发手机游戏。 就是这样一个决定，真正扭转了我们整个团队的命运。 如果是一年后，也许如今流行的MOBA游戏又是另一个，而不是王者了。

所以在2015年，我们就有了想法，开始为这个手游项目独立招募20到30人。

从端游向手游转型，必须面临一个选择，用什么样的引擎，用什么样的解决方案来进行手游开发。 当时腾讯以及成都周边的创业团队基本都用的是Unity。 我们做demo的时候，也选择了大家用过的、有产品的引擎进行验证。 同时我们也考察了是否适合我们团队。

根据我们做demo时对Unity的了解，它对于中小型团队，甚至对于一些大型项目来说，确实有几个明显的优势。

1、简单易用，我们三周就可以做出一个demo，可以看出，简单易用是它的一个非常大的优点。

2.它的工具非常齐全，可以一站式解决。 您不需要在这里下载工具，也不需要向其中添加一些额外的插件。

3.拥有海量的插件资源。 从demo开始，我们基本上就可以从Asset Store中找到一些可以用来验证我们想法的资源，这样可以加快我们的开发效率。

4、以上三点结合起来就可以体现出它非常明显的优势，那就是开发效率特别高。

5.它还有跨平台的优点，它是一个跨平台的引擎。

6.最后还可以让你更方便的补充技术人员，社会招聘也可以轻松招募到熟悉Unity的开发者。

与之前自己制作引擎或者使用其他引擎相比，从效率上来说，我们最终选择了Unity这个开发效率最高的引擎。

我们在2014年底从端游转向手游，但2015年3月才开始开发《王者荣耀》。此时项目的要求是尽可能缩短开发周期并推出手游。尽快游戏。 我们《三国志OL》的开发团队原本有40、50人左右。 再加上后来加入的人，就组成了100多人的团队来开发游戏。

2013年和2014年，手游在PvP方面相对较弱，且以卡牌游戏和单机游戏为主。 我们本来是做一款客户端游戏，充满活力和乐趣，所以我们做手游的目标是，即使游戏中会有PvE突破的内容，但我们的核心是做好PvP，这样玩家进行真实的对抗，让玩家与玩家进行交流，并且可以体验到这样的游戏的乐趣。

既然我们选择PvP，那么这个产品就是一款网络游戏，选择网络游戏的同步机制是我们首先考虑的。 最常见的同步机制应该就是CS状态同步，我们的客户端游戏中也是这样做的。 当然，状态同步也有其优点和缺点。

我们先来看看状态同步的优点。

首先，它的安全性非常高，插件基本上没有能力从中受益。

其次，状态同步对网络带宽和抖动数据包有更强的适应性。 即使出现200、300的输入延迟然后恢复正常，玩家也不会感到不舒服。

第三，在游戏开发过程中，其断线重连速度比较快。 如果我的游戏崩溃了，客户端重新启动后，我只需要服务器再次同步所有重要对象的状态，并重新创建它。 。

第四，其客户端性能优化优势也比较明显。 比如优化时可以裁剪，玩家看不到的角色不需要创建或计算，节省消耗。

我来说说我的缺点吧。

首先，它的开发效率比帧同步低。 很多情况下，你需要保证服务端和客户端各个角色对象的状态一致，但实际上你很难做到一致性。

比如客户端和服务端的更新频率，一些优化的剪裁，网络抖动等等。你很难在客户端同步每个状态，你想调试这些东西来优化它带来的东西。 漏洞和不一致，周期时间会更长，更难达到良好的优化水平。

其次，动作游戏的冲击感和精准度较难实现。 例如，如果你想成为一名射击角色，他的子弹每秒会产生数十发子弹。 基于状态同步很难做到，因为系统会在短时间内产生大量数据，需要创建、销毁、位置操作来同步。

第三，它的流量会随着游戏的复杂程度，比如角色数量的增加而逐渐增加。 我们做《王者荣耀》的时候，希望能够在3G、4G网络条件下进行PvP，所以我们希望它的付费流量消耗能够控制在一个合理的水平，我们并不想消耗一个游戏几十兆字节。 数据流量。

另一种同步策略是帧同步。

这项技术被广泛使用。 最早的《星际争霸》和《魔兽争霸3》都采用了帧同步。 它们都在局域网的基础上运行。 网络条件很好，不需要服务器就可以完成。 帧同步的优点有几个：

首先，它的开发效率比较高。 如果你的开发思路的整体框架经过验证、可行，并且解决了它的缺点，那么你的开发思路就和写单机是一模一样的了。 你只需要遵循这个思路，尽量保证性能即可。 怎么写。

比如我们曾经做过一个状态同步下的复杂技能。 技能有很多级别。 可能需要几天的时间才能得出稍微还过得去的结果。 但在帧同步的情况下，一个英雄做多级技能可能需要半天的时间。 搞定了。

二是可以达到更强的冲击感。 除了我们提到的各种反馈、特效、音效之外，强烈的冲击感还有它的准确性。 使用帧同步，看到游戏中的这些挥手动作可以在更准确的时刻产生反馈，而且动作本身的密度也可以达到很高的频率，这是状态同步下更难做到的。

三是流量消费稳定。 你应该看过《星球大战》的视频，它只有几百K大小，而且只有驱动游戏的输入序列。 帧同步只会随着玩家数量的增加而增加流量。 如果玩家数量固定，那么无论你的游戏有多复杂，角色有多少，流量消耗基本上都是稳定的。 延伸这一点还有一个好处，那就是更方便地实现比赛的观察、视频的存储和播放以及基于视频文件的后续处理。

帧同步也有其缺点。

首先，最致命的缺点是对网络要求比较高，帧同步是帧锁定的。 如果一段时间内出现网络抖动、调用数量不稳定，就会挤压网络命令的时延，导致卡顿。

其次，它的反作弊能力很弱，帧同步的逻辑都在客户端，修改起来相对容易。 但为什么《王者荣耀》敢于使用帧同步，一方面是因为立项时开发周期很短，上线需要半年时间，也就几十个英雄辈出，而且还有时间压力。 和数值成长游戏一样，它的玩法也是以单回合为基础，单回合的作弊修改最多只会影响本回合的结果。 而且，我们可以很容易地发现作弊并给予应有的惩罚，所以我们不认为这是一个致命的缺点。

第三，断线恢复时间长。 相信观众中有很多王者玩家。 他们也遇到过闪退后重新加载时间很长的情况。 即使加载完毕，游戏也快结束了。 这是帧速率。 同步是一个致命的问题。

第四，其逻辑性能优化压力较大。 你应该没有见过使用帧同步的大型游戏，因为这些游戏的每一个逻辑对象都需要在客户端进行计算。 如果做一个主城的话，主城里就有几千人。 虽然玩家看不到这几千人，但游戏仍然需要对他们进行有效的逻辑运算，因此无法做到帧同步。 许多对象需要更新。 游戏场景。

那么为什么我们选择帧同步而放弃状态同步呢？

前面我们提到，它的两个优点和缺点是相对的，一方的优点就是另一方的缺点。 对于我们的手游项目来说，最重要的就是时间。 当时，市场上正在开发的MOBA手游不止一款。 大家都在争夺上线时间，所以我们必须选择开发周期最短的方案。

然后我们在做PC游戏的时候也有很深的体会。 如果我们想做有趣的英雄、有趣的技能，在状态同步方面很难拿出令人满意的效果。 所以最终我们还是选择帧同步方案。

现在来看，选择了帧同步方案后，我们可以优化或者避免它的缺点，那么它带来的好处是非常明显的。 除了英雄的设计和技能的手感之外，《王者荣耀》也很重要。 确实造就了一些非常有特色的英雄。 它的技巧、反馈、经验都做得很好。 这些都是基于帧同步技术方案带来的优势。

我们选择方案后，当时的心情非常高涨。 我们觉得这样的技术方案很容易开发，效率很高王者荣耀辅助购买平台下载，效果也很好。

但事实上，它也有好的一面，也有坏的一面。 技术测试版上线后质量不佳。 技术层面遇到的问题有以下三座大山。

首先是同步。 同步很容易解决，也确实解决了；

第二个也是最大的网络问题。 帧同步的网络问题导致我们没有完全理解其技术方案的原理。 我们遇到了一些问题。 当时游戏延迟很重，画面卡顿，能明显感觉到行走抖动的现象；

第三是性能问题。 这个问题一直存在，我们一直在优化。

第一座大山，最容易解决的同步问题。

帧同步的技术原理非常简单。 这项技术在10、20年前就已经应用。 从相同的初始状态开始，获得相同的输入，并逐帧执行下一帧。 在执行过程中，所有代码的流程都很顺利。 全部都是一样。 调用结果后，有一个新的状态来完成循环。 同样的状态，同样的过程，就这样循环下去。

这个原理虽然简单，但是想要实现的时候还是存在很多陷阱。

右边写的是实现要点。 这是我们解决第一座大山的经验总结，也是我们在实际开发过程中所做的事情。

首先，我们所有的操作都是基于整数，而不是浮点数。 浮点数用分子和分母表示。

其次，我们也会使用第三方组件，框架组件也需要经过比较严格的筛选。 我们公司用的时间轴的编辑器里，本来是浮点数，我们都重写了。

还是那句话，很多人首先接触到的是帧同步中的问题，就是在写逻辑的时候，与本地和“我”相关联，导致不同的客户端去不同的分支。 事实上，真正的客户端与逻辑无关，像我这样的概念。

然后是随机数，必须严格一致。 这是实施的要点。 严格按照上面的规则写代码可能还是会不同步。 此类问题很难消除。

最后，真正重要的是开发人员应该提高发现不同步问题的能力。 当它们不同步时，您需要知道它们在哪里不同步。 这是最关键的。 你需要通过你的经历和总结来提高这个能力。 这个能力还是通过输出看不同客户端的不同输出，找出发生在哪里。

比如在《王者荣耀》中，我们看到的不同步现象应该是这样的。 当有人撞墙时，你看到的和别人玩的游戏不一样，就像进入了一个平行世界。

《王者荣耀》测试之初，我们希望失步率能达到1%，即100款游戏中就有1款出现失步，我们会考虑游戏合格，但实际上，对于这么大规模的游戏来说，这个比率是有问题的，经过我们不断的努力，已经控制在了万分之几。 在 10,000 场比赛中，可能会有少数比赛不同步。

这个问题不一定是由代码或未遵循这些要点引起的。 可能是修改内存或加载资源时，本地资源损坏或丢失，或者出现异常。 说白了，你没有办法执行下去，大家都跑到了不同的分支，这可能会导致最终的不同步。

如果你不同步的概率比较低，当概率达到万分之几的时候，就很难通过测试来恢复并找到这样的不同步点。

一开始我们游戏不同步的时候是周末，黑游戏的玩家太多了。 随着你的概率越来越低，基本上你自己解决不了这些问题，只能依靠玩家来帮你解决。 这样的场景，来分析这样一个同步问题。

同步就遵循这样的关键点，按照这样的思路写，加上你异步定位的能力，用监控手段就能发现，这个问题其实就解决了。 一旦解决，您就可以享受帧同步的开发优势。

第二座大山是网络。 《王者荣耀》技术测试版发布的时候，延迟非常大，而且还卡住了。 现在我们来看看帧同步中有什么特殊的地方。 帧同步有点像看电影。 其传统的帧同步需要缓冲区。 每个玩家的输入都会转发到所有客户端，彼此之间会有编号，帧会按顺序输入。

比如我现在已经收到了第N帧，只有当我收到第N+1帧时，我才能执行第N帧。 服务器会按照一定的频率给每个人不同的同步帧号，包括这个帧输入到客户端。 如果你给你的数据带一个框架，拿到之后就可以执行。 下一帧数据到达之前无法执行。 ，其结果就是卡顿。

绝对理想的情况下网络是可以的，但实际的网络环境却并非如此。 解决帧同步问题就是调试缓冲区。 以前有一个动态缓冲区，有从1到n的缓冲区。 根据网络抖动的情况，将收入放入队列中。

该缓冲区的大小将影响延迟和滞后。 如果您的缓冲区较小，则延迟会较低。 拿到之后不需要缓冲等待，可以立即执行。 但如果下一帧没有到来并且缓冲区很小，则无法执行它。 最后，你的延迟很好，但滞后很明显。

如果是调整到帧同步缓冲区的话，如果我们认为网络延迟是1秒，你把抖动调整到1秒，那么结果是虽然你的屏幕不抖动，但是你的延迟极高。 如果即使考虑到最糟糕的网络条件并且缓冲区足够大，那么记住缺点就和观看视频一样。 对于平行的东西，就看你调整条的大小了。 我们在当地做了一些措施，但都存在同样的问题。

具体来说，我们如何优化卡顿的问题呢？

刚才提到了帧与缓冲区同步。 缓冲区可以是 1 或最多 n。 为了解决延迟问题，我们需要使缓冲区足够小。 其实《王者荣耀》最后的缓冲区是零，它不需要缓冲区，服务器给了我n，立刻就知道是n，我收到了n，我就知道一定是n+1下次，所以收到n帧后，立即执行第n帧的输入。

那为什么不再卡顿，屏幕也不晃动了呢？

最后一个关键点是局部插值平滑与逻辑和性能的分离。 客户端只负责一些模型、动画及其位置。 它会根据绑定的逻辑对象的状态、速度、方向进行插值，这样我们的逻辑帧率和渲染帧率是不同的，但它确实把平滑插值和逻辑表现分开了，画面不抖动，而且延迟感也很好。

完成此操作后，我们还将 TCP 替换为 UDP。 在手机和网络较弱的情况下，TCP很难恢复重连，所以我们最终使用了UDP来做。 整体来说，网络好的时候它的时延也很好，网络差的时候进行插值，这也是传统CS的表现。

我们经常会看到角色A和B，有的客户A在左边，B在右边，有的客户A在右边，B在左边。 帧同步逻辑中A、B之间的距离和坐标是完全一样的，只不过是在屏幕上看到的。 可能不会重叠，这就是将它们分开后会发生的情况。 在网络极其好的情况下，应该是重合的，但在网络较差的情况下，可能会出现一些偏差。 这是最重要的优化部分。

第三座大山是我们对性能的优化。

帧同步逻辑本身的优化存在一些不足，需要对所有角色进行计算。 这方面我们也利用了Unity的特性。 如果你想追求极致的性能，有些事情就需要找到好的方法。

第一点是热点的处理。

我们不使用反射，反射会带来 GC 性能开销。 在我们的方法中，对象的显示和隐藏将被放置在不同的渲染层中，以尽量使整个游戏帧率成为一个平滑的过程。 我们有自己的系统，比如人工智能。 在《王者荣耀》这样的多角色游戏中，如果想要创造更好的体验，那么AI就必须更加复杂。

但要优化热点，我认为只需采取这三个步骤。

首先，你可以从程序的结构上找到一个更好的，它的优化效果是最明显的； 第二，如果你的结构是最好的，就挖掘出本地的算法，调整你代码的一些写法。 最后如果局部算法都调整到最优了还是没有办法，只有一个办法，那就是牺牲整个质量，也就是逐帧降低频率。

第二点是GC，刚才说了不需要反射，装箱和拆箱的行为也尽量少用。 Unity 指导了我们的优化。 从GC的考虑，他们建议每帧应该在200字节以内，这是一个比较好的状态。 事实上，这是很难实现的。 王者也是每帧1k左右，这是非常难达到的。 200.

第三点是Drawcall。 这些传统的优化方法大家都很熟悉。

第四点是裁剪。 无法在帧同步中进行裁剪。 如果在表演中看不到，我可以降低频率或者不更新。 这可以在表演中完成。

第五点是3D UI的优化，比如《王者荣耀》的血条、小地图上的元素堆叠等等，这些UI都比较丰富。 我们用31UI的方法来优化这块，血条没有用UGUI。 处理方面。

我们也牺牲了一些东西。 我们装载了所有东西。 游戏过程中我们希望不要有任何IO行为，包括输出。 我们都需要布局。 你处理的决策和复杂性，如果你在一帧中释放100颗子弹，当你释放100颗子弹时帧必须下降，并且你必须在可以的情况下将这些事情做到极致。

上面说的是我们第一代，也是去年5月份之前制定的优化计划。 5月份之后，我们还做了另一件事：GameCore。

首先，为什么我们认为iOS的优化效率高于Android？ 一方面，iOS的CPU架构，包括系统，确实优化得更好。 另一方面，我们使用Unity4.6，在IOS下效率更高。 Android端的机器种类繁多，性能也千差万别。 我们只能使用性能比较差的方法。

既然我们实现了逻辑和性能的分离，那我们是否可以把逻辑分离出来，做成一个C++的东西呢？ 事实上，我们从去年就开始这样做了。 做之前我还测试了C++和Mono的性能差异，大概是2.5左右。 我们的逻辑本身就占了游戏消耗的20%以上。 逻辑不是个大头。 我们这样做之后，仍然有效，而且帧率提高了。 2到3帧，需要很长时间。

其次，做了GameCore之后最明显的变化就是我们之前的逻辑GC没有了。 我们有自己的内存管理和对象管理，包括里面所有的容器类。 这些东西都是我们自己去实现的，包括整套的反思。 它有自己的内存管理，本身的效率会比较高，这已经是比较明显的优势了。

再次，有了GameCore，应用场景就更多了。 这东西就是服务器版的玩法。 应用场景下运行服务器需要做很多分析，第三方使用也是可以的。

最后，GameCore 具有扩展到多线程的潜力。

未来我们也有几个计划。

首先我们考虑热更新能否有所突破。 因为像王者这样的游戏类型，包括它的体型，我们对性能有一个比较极端的追求，我们不会轻易使用脚本关卡。 性能水平本身并不是最好的。 我们要研究的是热更新，最好的表现方式。

第二，我们也在和硬件厂商进行沟通。 他们希望游戏能够真正发挥多核性能的优势。 大多数游戏在单核上运行，填满一个核心。 很多时候我们得出的结论是GPU的性能也很强。 王者不占用GPU，可能只有30%，但是CPU却满了。 满了之后，还有一个缺点。 它的发热和频率降低。 如果使用多线程，多核要尽可能的扁平化，这样虽然不会工作在高频模式下，但是会有更好的效果。

第三，我们目前使用的是Unity 4.6，但是Unity已经发展到了5.7版本，他们将来还会引入新的功能。 我们希望结合Unity的一些新功能。 Now some games can use 5.6 to improve performance.

Finally, it is not only about improving performance, Unity also plays a very good role in multi-threaded rendering, and it is also necessary to use the advantages of the engine. With the improvement of performance, we will upgrade the picture quality of the king.

Alright, that's the end of my speech today.