很多人做帧同步碰撞检测都用偷懒的方法，用引擎自带的Collider做碰撞检测，真的这样做你就输了，Collider是基于渲染帧做碰撞检测的，逻辑帧正常运行与否都不会影响Collider的碰撞检测，这问题就来了，因为每个客户端网络不同的原因，一个客户端可能在第10帧逻辑帧发生Collider碰撞，而另一个玩家可能发生在第15帧逻辑帧发生Collider碰撞，这样客户端的游戏逻辑就不同步了。碰撞逻辑必须要在逻辑帧里根据物体的逻辑位置做判断才行。不是什么碰撞逻辑是你的事情该问你自己，你要先搞清楚碰撞逻辑该在什么地方什么时候执行。
1赞
runAction的action里封装了tween缓动，缓动本来就不是什么高效率的算法，何况你1秒执行2000次缓动，要创建2000个Action对象，这要分配2000块对象内存，js的垃圾回收机制又不是马上释放的，这样做不是灾难吗。而update不同，你不写逻辑在里面它就算个空函数，执行2000次也不消耗什么性能。
就算在update里执行插值跟随
var dir = realPos.sub(this.node.position);
this.node.postion = this.node.postion.add(dir * dt);
这个只是普通的加减函数，没什么消耗性能。怎么可以把update和Action完全等同起来呢
坐看楼上楼下打架
测试了下，这种方式如果摄像头跟着人物动的话，会一顿一顿的，看了眼睛会很花，有什么优化方式吗？（采用同步位置的状态同步，非同步玩家输入的帧同步）。
只同步输入的帧同步效果还好，不会明显卡顿、眼花
经测试，是我自己的代码问题，宝爷的方式是完全正确、有效的，很流畅。
我之所以没有流畅，是因为我客户端上行给服务端帧输入设定的时间是每50ms一次（服务器广播帧消息是50ms一次），这样，因为客户端定时器差异并不能准确在50ms内上行帧输入，很多时候50ms内根本没有给服务端上行包，就造成了服务端返回给客户端的逻辑帧实际上中间会丢失若干帧，也就造成了客户端走路一卡一卡。将客户端上行定时器改为比50ms小，比如30ms、40ms完美解决。再次感谢宝爷！
另外，经测试，我发现帧广播的频率越低，平滑性越好，比如说100ms一次广播，比50ms一次广播要平滑许多。供后人参考。
帧率太快，一帧很快就插值完了，约等于静止状态等待下一帧过来，所以就卡在这里，帧率太慢，有足够的时间去完成一帧逻辑帧的插值，所以显得平滑，但是帧率太慢，游戏响应玩家操作的时间越迟顿，所以把逻辑帧的帧率控制在15帧/s 就好了。
我做帧平滑过渡，不用你们这种方式，这种方式因为需要慢慢插值过渡，所以做逻辑判定时会发生技能离目标还有一定的距离，却提前判定命中了。我的做法是逻辑帧缓冲1-3帧，渲染帧从上一帧的逻辑位置插值到当前逻辑位置，视觉 判定误差比较小，因为做了缓冲，玩家的画面比逻辑帧延迟了1-3帧，当前的操作是对未来几帧的预判
感谢老兄一直在帖子中回复，感谢指导，有时间试试你这种方式
服务器不要等客户端，按服务器的时钟广播即可，没有必要等到收集所有玩家的数据才广播，没有收到就当做没有操作就好了。
你做了逻辑帧的缓存，不就会导致延迟加重么
收到逻辑帧不马上执行，缓冲起来，控制在3帧左右，如果是50毫秒一帧，只是延迟0.15秒左右，这个时间很短的，就是说你的操作会延迟0.15秒播放，这时间很短，你可能感觉不出，但是对画面流畅度有帮助
这种会导致手感很差的
还需要加上操作指令发到服务器再从服务器下发到客户端的时间，也就是你的延迟在0.2秒以上了
联机帧同步 mark
该主题在最后一个回复创建后14天后自动关闭。不再允许新的回复。