本文探讨了帧同步，特别是帧锁定同步在游戏同步方案中的应用，主要以火影手游为例。介绍了服务器如何每66ms收集指令并下发帧，以及帧丢失时的重传机制。还提到了乐观锁的概念，防止网络卡顿时导致所有客户端等待。同时，文章讨论了不同步处理、gamecore的设计及其在反作弊中的作用，强调gamecore在保证状态同步和高效性方面的重要性。
最近毕设准备做一个关注游戏同步方案的 demo，准备选用帧同步。正巧所在组火影手游绝大部分的玩法都是使用帧锁定同步来做的，所以在这记录一下。
概述
帧同步，或者更详细的说是帧锁定同步，是将前端的表现划分为每秒n次的逻辑关键帧，客户端的表现根据关键帧完成展示。客户端将指令经由或者不经由服务器广播到所有相关的客户端上，相邻的指令将会被封装为帧并被客户端理解执行。所有元素在某一时刻的状态，都是由各个客户端独立计算出来的。
帧同步方案
这里我们讨论cs架构下的帧同步方案。
下图反应了火影手游pvp玩法中的同步逻辑。
可以看到，服务器端每 66ms 会将接收到的所有客户端指令封装成帧并下发到各客户端中。如果某个帧在传输中丢失了，将会随下一帧重传。同时，使用 seq 和 ack 对每个帧进行确认。如果 99ms 内客户端还没有收到包含自己已发出指令的帧，就要将丢失的指令重传。
无论是客户端发送的 action，还是服务器端的 frame，都要有确认重传机制。frame 的确认就是通过客户端附带的 ack 字段来确认。
乐观锁
标准的帧同步，是要求客户端定时发送指令，服务器必须等待收集到所有客户端的包之后再下发，这个等待帧信息的过程称为帧锁定。如果一个客户端网络卡顿，那么所有客户端都要等待这个客户端的帧同步信息。
乐观锁就是无论是否收集到客户端的信息，都将目前为止收集到的指令封装
最低0.47元/天 解锁文章
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
