之前公司做一款类皇室战争游戏，实时性操作要求不是那么强，最近在找工作，自己做了一个demo，模仿王者荣耀的moba游戏，实时性操作非常强，两个游戏都是帧同步，因为实时操作的问题，导致两个项目架构有很大不同。例如：服务器给客户端同步间隔时长，客户端逻辑层驱动，操作执行时间各不相同等。今天总结一下。
1. 类皇室战争游戏：
直接说架构了，稍后再进行解释。服务器每间隔一个关键帧：200ms也就是4个逻辑帧，向房间内所有玩家推送上个关键帧内，所有玩家的操作信息，和该关键帧的帧号。客户端会根据服务器发送过来的关键帧帧号推算出服务器帧同步开始时的开始时间戳。然后根据这一时间，客户端本地也进行逻辑帧同步计时，客户端每间隔一个逻辑帧就把自身逻辑帧计数器加一。玩家操作的时候，客户端根据当前帧 + 一个关键帧 + 网络延迟帧，计算出该操作的执行帧，然后把操作消息立刻发送给服务器。当到达执行帧的时候，客户端执行操作。客户端逻辑帧的驱动严格意义上说，不是靠服务器来驱动的，是靠客户端本地的逻辑帧计数，来驱动的。服务器发来的关键帧，只是用来同步操作。
为什么这样设计呢？
1). 因为塔防类游戏玩家操作不会很频繁
2). 建造的建筑，开始出兵不是建造完之后立马出兵的，是等待每一个回合开始的时候，才开始出兵。这就使得对客户端操作的相应可以等待服务器下一个关键帧传来的时候，在执行。
3). 如果客户端逻辑帧改成服务器驱动，那服务器就得每一逻辑帧都向客户端推送消息，消耗的流量肯定很大，而且没有必要。
综合上面的原因上个项目，同步架构设计为：服务器间隔四个逻辑帧向客户端推送操作消息，客户端每一个逻辑帧处理由本地驱动。
2.moba游戏（我自己的demo）：
设计架构：
服务器每间隔一个逻辑帧（50ms）向客户端推送操作消息，客户端每一个逻辑帧处理完全由服务器驱动。玩家摇杆控制消息会很频繁的发送给服务器，优化为客户端间隔50ms将玩家在此50ms内进行的操作，发送给服务器。
这样设计的原因：
1. 摇杆控制的moba游戏，玩家操作频繁，而且必须尽可能快有反馈，这就要求服务器必须将玩家操作尽快推送出去。
2. 玩家进行的摇杆控制，操作太过于频繁，如果每次都直接向服务器发送操作，会导致传输流量过大。客户端每间隔50ms，发送一次。而且，还有一个优化，如果客户端按住一个方向不动，不松手，而且不改变方向，就不会发送操作，只有在方向改变的情况下才发送。
总结：
两种方案不同之处：
1. 客户端逻辑帧处理的驱动不一样，类皇室是靠客户端自身驱动，moba是靠服务器驱动。
2. 玩家进行操作的频率不同，导致操作命令执行的时间不同，类皇室的执行帧数是当前帧 + 关键帧 + 网络延迟等帧数，moba是客户端收到消息立马执行
3. 玩家进行操作后，客户端发送把玩家操作指令给服务器的即时性不同：类皇室是立即发送，moba是客户端50ms（一个逻辑帧）发送一次。这样也就是说moba游戏执行帧是当前帧 + 一个逻辑帧 + 网络延迟帧。
这就是两个项目帧同步方面，给我的一些启示，每一个项目，根据需求、玩法的不同，有不同的方案架构，只由最符合项目要求的方案才是最好的方案。