看一下私信，谢谢
后面讨论了一番，其实最终的问题就是跳帧的处理问题。
目前这套框架的做法是直接抛弃之前的帧，既然是跳帧，肯定是网络有所波动导致。用户也会认为刚刚因为网络卡，导致一个操作没有成功，用户会再发一次就行了。什么意思呢，举个例子：
1、王者农药这类游戏中，如果你一直向前走，然后你想向左走，这时网络如果卡顿了，1秒后恢复网络，这时向左走的消息丢失了，玩家仍然在向前走
2、CSGO这类游戏，如果一直向一个玩家点射，期间因为网络波动导致有一颗子弹消息没有发射，用户会再补一枪，当然如果是甩阻这种需要稍微处理一下
3、魔兽星际这类游戏，因为这类操作的apm相当高，如果产生跳帧问题，有可能导致整套操作出现错误，比如选择编队没成功，可能会出现使用之前的编队然后A出去。这类每个兵种都要作为一个player去同步，不建议使用本框架，不是不能做，而是会导致每次需要整个同步数据很大。量小就无所谓
非常感谢 tangxuanli2014的建议和分享，也希望大家多提建议，讨论一下，希望能把本框架优化更好。
1赞
跳帧是怎么产生的 
，第一次听到这么个词
帧同步 我知道怎么做，想请问一下，帧同步的战斗结束机制是怎么设计的，如果一个玩家突然上报战斗结束，以及上报战斗结果，那么服务器怎么确认这个玩家上报的数据是正确的。
玩家的帧丢了，服务器就认为该玩家在这帧没操作就好了。服务器给客户端的帧丢了，就让客户端主动请求缺失的帧就好了。 游戏开始后，服务器应该对战斗状态是无感知的，只是单纯作为一个转发帧的机器
信任多数1234
比如说A攻击B，A应该发个消息给服务器，服务器会记录，然后原样返回数据给你，客户端收到服务器回调后再把攻击放入下一个帧数据包(其实更合理的应该是服务器收到这个消息后，直接修改该玩家下一个帧数据)，这样结不结束就是服务器那边控制的，同时也可以做防作弊检测
如果此时战斗里只有两个玩家呢，这种情况是很容易存在的，比如一款10人吃鸡游戏，假设每个玩家死了就立马退出，最后省下两个玩家对决，突然其中一个玩家上报游戏结束。
这就是状态同步了吧
这不是状态同步，所有的伤害计算之类的还是客户端计算，服务器只是记录一些基础数据
意思就还是帧同步的大框架，但是服务器需要感知游戏的战斗状态是吧？ 这样就会有一个问题，服务器怎么确保这个玩家A的信息是可信的 ？如果玩家A作弊，直接上报秒杀了B，或者A说自己攻击到了B，但是B说自己已经移到开了，不在A的攻击范围内。
帧同步不是这样的，帧同步服务端是不会有任何游戏逻辑的，当然就不会有游戏信息的记录，服务端只会做玩家的操作转发
状态同步是游戏逻辑由服务端运算，把结果返回给客户端，客户端根据返回结果做画面表现。如果前端也有游戏逻辑那就不是状态同步
那传统的帧同步下，服务器不感知战斗状态，那战斗结束应该怎么设计。看我之前给你的留言
结束机制的验证，如果有多人在线，比如10人，以其中多数的玩家的共同结果为标志，比如有9个玩家的结果是相同的，只有1一个是不同的，就证明这个人是作弊。这种只能做模糊判断，不一定准，如果是1v1就不好办了，两个人结果不同，也不知道谁的数据是真的。最有效的结果就是，结束时，在后端跑一个客户端，把游戏的逻辑帧重新跑一次，以跑出来的结果为准。
你最后一句提到，【结束时】，那么这个结束时的确切时机在哪呢？是第一个玩家上报结束，就开始跑一遍全部帧逻辑，还是等待多数玩家都上报结束后，才认为这是一个结束时机呢。
马克一下~
而且在客户端跑一遍帧逻辑，真的难度不小，游戏是前后端语言不一样的情况下，要写两份战斗逻辑代码
说错了，是后端
说的太死了，网络抖动之类的情况服务端也会处理帧数据，不仅仅是转发客户端消息，我说的这个无法保证决定正确，但信任多数一样无法保证决定正确