这要做3层数据，逻辑层数据还是照正常逻辑帧运行，不预测，中间层的数据在逻辑层的数据的基础上做预测未来n帧的位置和方向的变化，不做逻辑运算比如碰撞。渲染层数据平滑到中间层数据。
1赞
我现在是预测下一帧是按玩家当前帧N的操作来执行的，如果预测错误，则回滚到第N帧，然后再执行服务器下发的第N+1帧。
发出去的事件也能回滚么
尽量用观察者模式去做（ecs天然友好支持），渲染帧根据逻辑帧数据去渲染，逻辑帧数据回滚了，渲染肯定也对
可以，按照一般编辑软件 Undo这个逻辑。相当于你按下atrl+z
ctrl+z吧，哈哈。
嗯，手误没检查
还没用过ecs~.~
看来这位哥们也对同步技术深有了解啊，理念和我的都差不多。
我确实是做过几个真实对战游戏项目的开发，翻阅过很多资料，填过一波坑，最后才了解同步技术的原理的。
不过你说引擎的碰撞检测不能用不是因为定点数的原因，是因为这个碰撞检测是基于物体的渲染位置和渲染帧做检测的，而你的渲染位置又要通过插值lerp到逻辑位置，在相同的逻辑帧，每个玩家的渲染帧位置肯定是不同的，还有渲染帧的帧率也不同，所以用引擎的碰撞系统肯定做不了同步。你把浏览器退出到后台，渲染帧会停止，逻辑帧再怎么跑，都不会触发物理引擎的碰撞检测。
楼主的那种做法也不算是状态同步，逻辑各算各的再互相转发结果给对方，但是忽略一点，没有引入一个裁决者，没法判断谁的结果是正确的。比如场景里有个道具，两个玩家同时去抢，双方在几乎同一瞬间碰到道具，并且通知对方我抢到道具了，最后双方在自己抢到道具的同时，之后又接收到了对方也抢到这个道具的消息。那么这个道具到底是谁抢到了？各算各的没有一个裁决者，导致逻辑混乱。像传统的状态同步，逻辑都是运行在服务端的，由服务端通知各客户端当前游戏和各玩家的逻辑状态，每个玩家把这些状态通过画面显示出来，裁决者是服务端，胜负结果也是服务端通知。
1赞
你的说法我感觉对着，那服务器也要去计算碰撞什么的吗，还是只校验一些关键数据，我在做类似球球的那个，反正看起来有多个人的话位置就是有卡顿，大佬有demo能给个么
1赞
状态同步所有逻辑运算都是在服务端，包括你说的碰撞
靠，，，，我们服务器不管 让我一个人搞到像球球那么丝滑。。。。
1赞
你要demo，我也提供不了给你，除非亲自参与这个项目才知道怎么写
1赞
好的 谢谢你啦
我说他的同步是“状态同步”，带了引号了。碰撞检测不能用，定点数是原因之一，物理引擎有的会提供帧驱动API的（好像P2就是，把源码改成定点数，就能用了，不过一般游戏只需要碰撞检测，自己写个难度不大），逻辑帧可以去驱动物理引擎，渲染位置和朝向都可以通过逻辑数据去跟物理引擎的位置同步，我记得unity有个物理引擎就是专门给帧同步写的，叫啥名字忘了，不重要了，哈哈。
1赞
cocos3.0就跟ECS越来越近了，跟unity相比较，也就cache friendly还不行，其它的架构都不错
先Mark为敬
mark。
不错不错 欢迎大家针锋相对 激烈讨论 为更好的明天 讨论吧
一直想做这个，大佬这个很有参考学习的价值，牛
！