作者：周常树

本文摘自腾讯互娱总工程师周长寿分享的《2018腾讯移动游戏技术评审标准与实践案例》手册。《天天酷跑》 手游中如何设计同步机制，解决网络滞后、渲染滞后等问题，提高玩家的游戏实时PK体验。

随着手机游戏的浪潮，实时PK已经成为很多游戏的标配功能。但由于网络延迟的原因，玩家本地状态、服务器状态以及其他玩家电脑的状态可能会不一致。同步问题本质上是一致性问题。游戏中不同玩家看到的状态必须一致。假设两名玩家A 和B 在游戏中移动并同时向对方发出射击命令。如果没有适当的同步机制，可能的情况包括：屏幕A显示B已死亡，屏幕B显示A已死亡。因此，为了给玩家提供更好的游戏体验，需要一种同步机制来解决网络延迟和渲染延迟导致的玩家状态不一致的问题。同步机制有很多种，选择哪种同步机制取决于游戏类型、技术条件甚至历史背景。选择同步机制还可能涉及调整服务器架构。

对于网络游戏同步，常用的两种方案是帧同步和状态同步。

帧同步就是同步玩家的命令。服务器负责转发客户端的动作。每个客户端在固定的逻辑框架中执行所有客户端任务命令。如果您在严格一致的时间线上运行相同的命令序列，您会得到相同的结果。

状态同步和帧同步最大的区别在于服务器不再切换逻辑帧，而是同步玩家状态信息，包括位置、属性和玩法相关数据。通常，底层逻辑运行在服务器上，客户端仅充当显示的作用。使用状态同步的游戏有CFM、LOL等。

帧同步的网络流量虽然较小，但防范攻击、断线重连的难度较大。状态同步时，服务器拥有所有玩家的状态，提供更高的安全性和更可控的游戏运行。是否选择状态同步取决于同步实体的数量。在大规模场景中，当同步设备较多时，状态同步往往会被放弃。例如，《星际争霸》有数百个玩家可以操作的对象，使用状态同步可能会导致非常大的网络流量。

《天天酷跑》（以下简称“酷跑”）是一款横向卷轴跑酷游戏，具有世界对战、多人对战、团队赛等多种PVP玩法。下面针对游戏中一些常见的PVP玩法介绍服务器端同步方案及其架构调整。

1. 世界大战

酷跑在上线三个月后就规划了世界大战玩法，以增加玩家之间的互动。比赛的具体进行方式是，参加比赛的选手两人一组进行比赛，根据分数、距离等因素最终决出胜负。

酷跑作为一款适合所有人的游戏，必须要考虑到玩家的网络状况。下图为《酷跑世界大战》上线时手游的网络连接统计。 2G/3G网络比例很高，网络质量不稳定，全部按流量计费。比赛期间的海量数据同步在当时还是不可行的。同时，早期手游人力投入较小，版本迭代较快。

因此，酷跑在提出玩世界大战玩法时，选择了简单的同步方案——，通过TCaplus数据库（腾讯自研的NOSQL数据库）实现玩家之间的数据同步。世界大战是异步PVP，玩家在游戏过程中不进行交互，只在重要节点进行同步，以节省流量。同步数据量低，协议交互频率低，包括成功匹配、发起、支付、领取奖励等。同时，TCaplus数据库拥有优秀的读写性能，并由专业的运维团队进行维护，保证了开发团队的工作量相对较低，能够满足全球作战的同步需求。

服务器设计了TCaplus数据库表TB_PVPMATCH来记录玩家的世界战斗数据。每次参加世界赛，都会在TB_PVPMATCH表中添加一条记录，并在记录中定义一个状态字段，用于记录玩家状态的变化，例如找到对手、确认对手、或者支付。收取入场费、报告成绩和奖项。

当玩家匹配成功后，TB_PVPMATCH表中会添加一条新记录，并且状态标记为Initialized。比赛成功后，客户端以每秒一次的固定频率向服务器发送战斗状态协议，直至双方扣除参赛费并开始游戏。服务器收到完整的战斗状态同意后，从TCaplus的TB_PVPMATCH表中获取自己和对手对应的记录，并根据双方的状态更新其记录，并将其写入TCaplus和发送客户端。当客户端带来的响应消息表明入场费已被扣除时，游戏开始。

游戏结束后，通过战斗状态协议再次通知本场比赛，服务器获取本场比赛的比赛数据并更新TB_PVPMATCH表中的相应记录。如果对手结束了比赛，你可以自己解决比赛。如果对手仍在参与游戏，玩家可以在结算界面等待对手或立即退出并查看下次游戏结果。结算过程中，可以在TB_PVPMATCH表中查看双方的记录，并根据双方的数据确定结果。

当World Vers推出时，服务器架构相对简单。全局服务只有匹配服务和很少的异步进程，其他逻辑可以由Gamesvr处理。

2.多人对战

2014年底，酷跑推出多人实时同屏对战模式。玩家必须努力击败对手，最大化自己的速度，并在最短的时间内完成比赛。多人对战分为经典对战和道具对战，经典对战比拼的是速度，而道具对战则是利用道具来增减各种效果，玩家利用各种不同功能的道具来控制自己，可以保护和阻碍对手。

多人对战为同步PVP，四名玩家配对后即可开始。由于战斗中玩家不多，我们需要在服务器上执行一些逻辑，所以这里我们选择状态同步的同步方式。在游戏过程中，玩家向服务器报告他们的动作、位置和状态。服务器进行逻辑处理，然后将玩家上报的报文广播给其他玩家。其他收到数据包的玩家知道该玩家的状态并执行相应的逻辑。 游戏过程中，根据游戏场景动态调整同步频率，节省同步包，降低服务器负载。玩家在游戏中平均每秒同步一次。

版本灰度上线过程中，发现多人战服务所在机器的通讯进程进程TBus CPU占用很高。多人战服务是用来创建房间、同步包转发、对战结算的服务。需要与所有gamesvr和TConnd建立通道，单机Tbus通道达到上千个。

TBusd占CPU高，但网络流量又不大。最后发现Tbus通道达到一定数目，性能会急剧下降。Tbusd需要轮询所有通道进行收发包，通道过多时导致大量CPU空转。考虑到后续全局服务会越来越多，通道数会进一步膨胀，Tbus占用的内存、CPU会进一步上升。需要降低通道数，引入中转服务，可以使通道数收敛，同时前后端关系也解耦。

因此对架构进行了调整，逻辑层由2层变成3层，中间加了一个转发层，gamesvr与全局服务，全局服务之间不再直接通信，而是通过转发层中转，这样Tbus通道数得到了收敛，服务器之间的通信关系由网状变成了树状。

三、团队战

2017年初，为了加强玩家间的互动，设计了局内交互更频繁的团队战模式，强化玩家间配合，增加玩家对游戏的粘性。团队战是3V3对战，在比赛结束时，计算队友获得的总分，得到总分较高的团队获胜。玩家在挑战时，队友之间相互有联系。比赛中每过一段时间玩家就会进入到一个小游戏，如在极速前进中需要配合完成吃金币和空心银币的任务、在进击模式中需共同完成砍怪、在天空之城中队友之间分配合理的飞行线路可以获得较高的分数、队友通过巅峰挑战会落下高分流星雨作用于团队所有的队员等。

这是一个强交互的需求，队友间需要共享妖怪总血量、关卡中出现的金币等，给妖怪最后一击的只能是一个玩家、所有队友吃到的金币总和不能超过金币总量等。最初要求每秒15帧的数据同步，同时服务器需要做逻辑，因此团队战选择了状态同步的方案。服务器采取了简单的处理原则，先来先处理，处理时加上校验即可。同时针对不同关卡，动态调整同步频率。

团队战需要有团战服务来同步玩家数据，原有架构上下行包需要在客户端、Gamesvr和团战服务之间流转，团队战中高频的同步请求包对流量和CPU都会带来挑战。因此对架构进行了调整，将同步包独立出来，游戏过程中客户端直接与团战服务通讯。

这是目前的游戏架构，增加了客户端与团战服务直接通讯的能力。3v3匹配成功后，通知团战服务建立房间，同时下发客户端房间所在团战服务的机器ip和端口（映射到tgw的vip和端口），客户端再通过下发的地址信息连接团战服务。游戏过程中，客户端直接向团战服务发同步包，团战服务转发给队伍中的其他玩家。

总体来说，酷跑定位为轻度游戏，PVP中涉及的同步方案比较简单。在不同时期，根据游戏玩法、网络状况等选择了不同的同步机制和服务器架构，满足了设计需求。

《2018腾讯移动游戏技术评审标准与实践案例》下载：https://gameinstitute.qq.com/tech-ebook