《王者荣耀》能够成为当今国内最成功的手游，其背后成熟的技术团队的支持可以说功不可没。

这支曾经在端游时代主导RTS游戏《三国志》框架搭建的技术团队，在转型到MOBA手游《王者荣耀》后，为游戏提供了巨大的支持，但这个过程并没有一直一帆风顺。

在今年刚刚结束的腾讯TGDC上，《王者荣耀》技术总监孙逊在技术环节对游戏进行了技术回顾，从技术角度向观众讲解了游戏的引擎、整体网络架构和技术。看法。 网络同步解决方案的实验和变化。

孙逊表示，目前游戏的服务器架构主要由“游戏厅”和“PvP”两部分组成。 在不断探索中，后来在架构中加入了Proxy传输服务器。 正是这个服务器的加入，构成了“游戏厅”和“PvP”的基础。 《王者荣耀》解决了后来在“Android和iOS”服务器中出现的一系列问题。

此外，他还介绍了《王者荣耀》在网络协议和同步方案上的一些尝试，并一一回顾了这些尝试的优缺点。

为大家解答一下为什么，最终游戏会放弃《三国志》中曾经使用的TCP协议（传输控制协议）和客户端-服务器结构（C/S结构），而改用UDP协议（用户数据报协议）和帧同步方案。

本文为腾讯王者荣耀项目技术总监孙逊的主题演讲《王者荣耀技术架构》内容整理。 本文将分几个部分向大家介绍《王者荣耀》后端开发过程中的一些内容和思考：包括《王者荣耀》整个背景的介绍、后端架构、上线后的调整、还有网络同步方案、反作弊方案等。

目前《王者荣耀》后端机器有4600多台，我们的产能也有了一定程度的扩大，进程数达到了4万多。

《王者荣耀》游戏背景

2012年，我们当时正在制作的PC游戏《三国志OL》就是《王者》的前身。 这个产品本来是一款RTS为主的游戏，后来我们把它改成了PC游戏MOBA，再后来又变成了手游MOBA，也就是现在的《王者荣耀》。

从2012年我们开始制作RTS游戏到2013年，我们从多控制单元的RTS游戏转向MOBA游戏。 2014年，我们开始了MOBA手游的预研。 然后在2015年2月，我们投入了大量的人力（大约100人）到游戏中。 人）投入了《英雄传说》（《王者荣耀》的前身）的开发，并没有持续多久。

《三国争霸》的玩法是，玩家可以在游戏内通过战前排兵布阵形成自己的策略，通过控制多个单位、释放技能、释放兵种特性来形成对抗。

我们刚做《三国志》的时候，客户端引擎是虚幻的，但是当我们做《王者荣耀》的时候，我们就改用了unity引擎。 在3到4个月的开发过程中，从代码层面来说，产品本身并没有什么。 是从《三国志》搬来的，所有代码都需要重写。

《三国志OL》的一些灵感

制作PC游戏《三国之战OL》的经历给了我们很多相应的王者启发，比如策划、编程以及整个团队对MOBA的理解。

另外，我们在做PC游戏《三国志》的时候，采用的是Client-Server模型，但其实过程中我们也借鉴了类似帧同步的概念：比如回场的过程断开连接后的视图。

传统的做法是在重连时发送当前图像以及后续的其他下行通知消息。

这种方法有一个问题。 如果在场景中添加其他模块，根据场景中包含的当前的各种物体以及它们的状态的各种信息，这些东西都需要打包发送。 开发和维护的时候会很麻烦。

我们的做法是缓存服务器发送的所有序列包，并按顺序重新发送，让客户端进行快速转发。 其概念类似于帧同步。

还有一点就是保留设计的灵活性。 在最初的RTS中，每个玩家最多可以操作5-8个单位进行对抗。 后来改为MOBA游戏时，只能操作一名英雄，并添加了各种单位。 在这种场景下，我们自己的技术框架不需要做颠覆性的改变。

《王者荣耀》整体架构

目前《王者荣耀》后端的整体架构设计都是源于产品的需求。 如果你玩过《王者荣耀》，你就会知道PvP对抗不涉及分区。

微信一区的玩家可以和微信二区的玩家对战，甚至iOS平台也可以和安卓平台的人对战。 不过，有些共享区域也保留了区域的概念，比如基于“区域”概念的战队和排名。 “区”是游戏中的数字，可以理解为印在玩家新创建的角色上的标志。

当我们最初实现该架构时，服务器相对简单。 从原型来看，只保留了大厅和PvP服务器，并将两者分开。

PvP服务器使用类似CGI调用来分配资源的使用，然后在使用后回收它们，并且不负责其他事情。 从大厅拿走需要的东西，用完后还给大厅，让大厅写回DB。

我们在大厅和PvP之间做了直连，后来把直连改为中间转发。 在《王者荣耀》中，我们称之为Proxy，相当于一个代理服务器，屏蔽了后端进程分发的很多细节。 因为游戏本身有很多机器和进程，以及不同的路由规则。

一些排名或团队根据逻辑区域的数量来确定要处理哪台或多台机器。 有些消息是随机转发或者多播的，由Proxy负责路由。 后来又增加了房间服务器，负责《王者荣耀》中的匹配、排名等相关功能。

房间匹配服务器负责如何将能力相似的人组合在一起进行比赛，因此团队将与其他服务器的团队进行匹配。

最后我们在上面添加了一个Adapter，用于利用我们已经部署的区域资源实现跨服务器匹配。

游戏的后端架构中，除了队伍等服务器外，其他模块都可以在线扩展，或者当发现故障导致在线掉线时，自动屏蔽整个架构。

因为路由方式会限制比如区域一、区域二、区域三到本机进行处理，所以如果出现故障，也只会影响某些逻辑区域内玩家请求的处理，减少了故障范围。

目前《王者荣耀》的机器数量可能每周都会被发现坏掉，至少有一台机器宕机了。 架构中保证模块的自动屏蔽和在线扩展非常重要。

整体结构更像是MMO的三层结构。 MMO在腾讯具有典型的三层结构。 大厅服务器会根据玩家所在区域登录特定区域的大厅服务器。

单个大厅进程可以容纳 20,000 人，单个 PvP 可以容纳 12,000 人。 当社区登录微信第一区或第二区时，玩家身上会显示人物标志。

《王者荣耀》目前外网有安卓手Q、安卓微信、iOS手Q、iOS微信四大区，此外还有抢占式服务器。

在大版本发布之前，我们将使用程序切换来优先更新抢占式服务器。 目前无法与官方服务器玩家匹配，因为版本不一致。 当全服发布且版本更新一致时，我们将开启开关，让早期服务器的玩家可以与正式服务器的玩家进行PvP匹配。

此外，我们还有专门的体验服务器，用于规划和验证相关设计。 体验服务器保留了删除文件的可能性，但在正式环境中这是绝对不允许的。

另外，过去的传统手游单机较多，要兼容很多协议，所以客户端版本不更新就玩不了。 不过，《王者荣耀》的主要玩法是PvP。 同时结合实现方式，不同版本的播放器无法匹配到一起，所以我们并没有做出多版本协议的兼容。

上线后的调整

上线之后，《王者荣耀》本身的后端结构整体上并没有发生太大的变化。 这是因为我们在做客户端游戏的时候，对结构有了更清晰的认识。 我们知道哪里可能会出现问题，所以整个结构已经比较稳定了。

但我们做了相应的微调，其中做的最多的就是网络本身的优化。 《王者荣耀》刚推出时，市场上对网络时效性要求较强的实时PvP游戏相对较少。

我们做了各种尝试，比如优化网络上的CPU性能、延迟、丢包等。 网络本身花费的时间最多。

架构的微调，像刚才提到的中转模块，我们的架构中有很多大厅机和PvP机。 每个进程不需要了解架构中的详细信息。 例如，大厅服务器不需要知道它后面有多少个房间服务器，它只需要知道后面有一个房间服务器，所以如果可以访问它就可以了。

如何划分和均衡负载，如何屏蔽后端故障节点，都是Proxy路由功能负责的。 由于大厅和PvP机器太多，我们使用Proxy将整个架构划分为彼此没有交集的“分支”概念。 每组Proxy只负责一部分大厅和PvP服务器。

这两类服务器在《王者荣耀》服务器中最为常见，但除了后端通信之外，还在Proxies之间建立连接，以减少单个Proxy通道的数量，同时保持整个结构的通信。

代理适配器是在发布后添加的。 最初上线的主要区域只有四大区，分别是手Q、微信、Android、iOS。 最早的Android玩家无法用iOS玩游戏。

Android和iOS的分离也是有一定原因的。 我们之前假设Android先更新，iOS后更新，以保持版本更新的稳定性。 但后来我们希望Android和iOS玩家可以因为关系链一起玩黑。

因此，当Android和iOS版本的更新频率相同时，我们希望不需要部署太多额外的机器资源和开发，可以直接利用Android和iOS现有的PvP服务器和区域资源来打通Android 和 iOS 之间的 PvP。

当Android玩家登录Android区域时，他们将连接到Android大厅。 登录iOS后，将连接到iOS区域的大厅。 当他们需要开黑的时候，我们用Adapter桥接中转模块中的所有区域，通过一定的算法传送到大厅。 某个地区。 配送方式的选择与区域资源比例直接相关。

网络同步解决方案

之前我们做《三国志》的时候，采用的是Client-Server模式，服务器判断客户端的性能。 那么我们在做《王者荣耀》的时候为什么要选择帧同步方式呢？

客户端-服务器模式的优点是：

第一，安全。 因为都是服务器计算，客户端只负责性能层面的功能，不会影响各种判断的结果。

另外，由于Client-Server模式是基于结果性能的，所以中间可能会出现丢包的情况。 丢包是可以接受并处理的，只要最终重发结果一致即可。

帧同步常用于客户端游戏中。 我们熟悉的DotA和《星际争霸》都采用了帧同步技术。

帧同步本身对网络有更严格的要求。 下发的执行顺序不允许丢包，需要严格保证顺序。 如果数据包是12345，则必须是12345。如果数据包丢失，则必须等待直到丢失的数据包到达。 随后执行该序列。

MOBA本身就有很多单元，客户端同屏最多可以有近100个单元。 如果AOE技能达到20个单位，然后植入debuff，客户端-服务器状态模式需要发送此信息，这可能会导致同步。 有很多状态信息。

Client-Server模型本身的另一种发展方式是，客户端性能和服务器的判断很难完美匹配。

以前我们做PC游戏MOBA的时候，我们要花两三周的时间来开发一个英雄技能。 当时《王者荣耀》的开发周期是三四个月。 在这样的时间压力下，我们无法使用Client-Server的方式来处理，因为我们没有足够的时间。

当时团队相当紧张，因为当时市面上还没有一款手游采用这种方式强化PvP且时效性很高。

帧同步网络的抗抖动能力相对较弱，因为不能丢包。 如果你对帧同步的基本原理感兴趣的话，可以下来自己学习一下。

网络模式和主机模式通常是有区别的。 这项技术的关键点在于游戏内的计算全部基于客户端计算。 这10个人中，每个人都会计算出自己的份额。 它们具有相同的起点、相同的输入以及完全相同的中间计算逻辑。 不存在随机过程。 这个运行结果理论上应该是一致的。

即使浮点运算也不应该存在，它也存在精度问题。 很多碰撞、动画、基本的数学运算库都是在后台实现的。 需要浮点整形以避免客户端的本地逻辑。 这是最常见的错误，也是最常见的不同步原因。 。

如果一个经验不是很丰富的客户端程序在编写程序时使用本地代码来做相应的逻辑，可能会跑得越来越远，10个人都在平行世界。

整体网络结构一般分为三层：服务器、客户端逻辑层、客户端表示层。

服务器主要负责两个功能：

客户端逻辑层理解为客户端的本地服务，即所有客户端操作的结果必须强一致，不能存在真正的随机性、本地逻辑或浮点计算。 给定相同的输入，结果必须一致。

客户端表现层会根据逻辑层的数据进行复制或镜像，然后在表现层进行平滑处理。 帧数不同，但不会影响最终的计算结果，只会影响动画和动作的表现。

当PvP刚推出时，我们使用TCP技术。 TCP在局域网中表现良好，没有任何问题。 但当外网出现丢包或抖动时，受到实现方法的限制。

比如由于windows、启动慢等各种原因，你会发现重新连接时游戏很卡，所以后来我们没有使用TCP，改用UDP。 如果发生丢包，服务器会在应用层重传。

UDP 受到 MTU（最大传输单元）大小的限制。 如果大于MTU，就会发生分包现象，整个数据包可能会丢失。

因此，我们也会有一些比较大的包，会被服务器在App层进行分包。 如果中途出现丢包，服务器会重发。 碎片包将被组装成完整的包，然后拆包。

更有价值的是UDP数据包。 如果手机因为信号抖动等原因丢包，通过冗余发送是比较有效的解决方案。

帧同步消息相对较小。 按照每秒15个驱动帧的理论，20分钟的视频约为10M。 但根据我们外网统计，一场正常的5V5比赛持续20分钟，视频大小在3M左右。

服务器会将玩家的操作存储在纯内存中。 当发生丢包时，服务器会通过号码快速找到缓存信息并下发。 同时，根据丢包情况，我们会计算出发送给这个人的冗余量的变化。

最初，当发送每个数据包时，前三帧的信息将是冗余的。 如果丢包严重，我们会尝试冗余更多的信息再发送出去。 客户端拿到之后，会尽量压缩逻辑执行流程。

帧同步模式比较麻烦的是它不像客户端-服务器模式来来去去。 崩溃后，恢复必须从头开始，中间的计算过程不能省略。

当然，我们也尝试过其他方法。 例如，客户端上线后，服务器不需要定期采集和下发数据。 相反，它直接通过染色帧号传递数据。 这样，响应更及时，操作反馈更强更快。

我们当时做出的结果是，手感的提升很小，但是带来的负面问题却是巨大的，因为不是固定每秒投递15个包裹，而是投递的包裹数量非常多，这完全是一个问题。与此人有关。 这和你的操作习惯有关系。

一个人有可能一秒钟产生十多个、二十多个输入，这些输入需要打包发送给客户端。 由于客户端收到大量数据包，设备会明显发热。

我们也和其他部门合作开发了类似TCP的技术。 大家直观的认为如果一个数据包丢失了，那么在IO层就会重传。

但实际结果会发现该技术水平比较低，因此对丢包的控制没有那么灵活，结果可能不如TCP本身。

传统的帧同步方式会进行延迟传送，我们也尝试过。 如果间隔期间出现丢包，或者下行时出现网络波动，可以通过延迟投递来平滑抖动和丢包。

我们之所以尝试过这种方案但最终没有这么做，是因为《王者荣耀》中的一些英雄感觉更注重动作，需要更快的反应。 延迟交付虽然具有良好的抗抖动和抗丢包能力，但手感不佳。 不符合我们的要求。

另外，在实现Client-Server方式时，通常都有一个套路。 客户端提前执行，并根据服务器的性能进行平滑或拉取。

我们也尝试过这种方案，但最终放弃了，因为这种技术会让角色的表现有点波动。

当客户端在本地移动时，客户端的性能会立即跟随，但根据服务器的下行链路，实际上会进行一些偏移或修正。 当出现网络抖动时，人物会有些晃动，所以我们放弃了这个方案。

在帧同步方案中，所有客户端都执行计算并期望产生一致的结果。 但是，如果由于错误或某人使用修改器，结果将与其他人不同。 当差异出现时，我们说它不同步。 。

我们会定期提取一些关键信息并进行哈希处理。 未同步的人的哈希值将与其他人的哈希值不同。

《王者荣耀》上线时的不同步率约为2%，这意味着在100场游戏中，有1人或多人可能会得到与其他人不同的结果。 我们现在已经实现了万分之三的不同步率，而这种情况只发生在万分之三的游戏中。

这是如何改进的？ 如果使用帧同步，肯定会遇到不同步的问题。 如果客户端写错了，使用了本地逻辑，那么浮点数的计算误差可能会达到这样的临界点，从而产生不一致的计算结果。

我们有很多方法：自动化测试、用机器人持续运行。 例如，在推出新英雄之前，我们会有脚本测试不断运行，看看是否会出现不同步的结果； 我们有专门的体验服务器和早期服务器区域来发布到正式版本。 提前测试网络，先暴露问题，然后修复问题。

另外，当不同步的时候，我们会上传并保存整个录制和客户端之间的日志，这样我们就可以根据录制和中间执行的日志顺序快速定位问题。

我们还相应地监控单轮的延迟和质量。 这一轮有没有卡顿或者卡了多少次，有没有丢包，丢包有多少，最大时延和最大抖动是多少，我们都有相应的记录。 和统计数据。

运营部的同学给我们提供了很多帮助。 我们会集成相关的SDK进行网速测试和问题分析。

根据我们自己的统计，造成游戏卡顿的原因主要有以下几个：

我们在网络优化方面做了很多尝试，比如根据丢包增加冗余，然后优化我们执行的各个方面的效率来降低CPU的使用率。

在《王者荣耀》的后端方面，我们一直在努力的有两点，网络优化和匹配机制。 我们尝试使用各种方法，甚至后期我们会尝试使用AI深度学习的方法，更加准确。 玩家真实等级的定位让他能够匹配到更真实的同等级对手和队友。