你的update算法里面没有用上自带参数dt对吧，这样的话在不同的手机，每次执行update的时间都是不一致的，是不是就是因为这点导致有的手机会卡一下
严格一点说我的是状态同步，即同步玩家位置的xy坐标信息
1、就是在update中，你先计算人物本帧移动后的位置坐标xy，如果xy不在障碍物内，将人物坐标发送给服务端，如果在障碍物内，此时，可以2种操作方法，一种是人物停止不动，一种是让人物沿着障碍物贴墙滑动，一般来说2d游戏我们障碍物比较简单，都是长方形，贴墙滑动要不就是x=x+v,要不就y=y+v，v是人物移动速度，具体是x还是y要自己判断，另外，如果复杂点，还要继续判断x+v或y+v后是否还在障碍物内。
2、如第一点，玩家移动流程是这样的：玩家位置信息xy计算后将结果发给服务器（玩家的node此时并不移动），玩家真正的位置移动需要在收到帧消息并处理好帧逻辑后，在玩家node的update里渲染的。
3、子弹同步：玩家在客户端点击射击键后，此时客户端将这个开枪信号flag=1传送给服务端，服务端广播给所有客户端，客户端收到后判断玩家开枪信号flag是否等于1，决定玩家是否射出子弹，然后子弹飞行时间是1个逻辑帧还是多少个逻辑帧需要你自己处理，并且还要计算该逻辑帧下是否和玩家、障碍物碰撞了。flag只是举例，现实可能flag很有可能包含比如子弹射击的方向、速度等，具体看你情况。
我之所以用位置同步，是因为如果只同步玩家输入，那么每个玩家和障碍物的碰撞都要在每个客户端计算，我的10人游戏就要计算10遍，机器效率跟不上，所以改成了每个客户端只计算自己和障碍物的计算，这样效率提高了很多，不会这么卡，如果你也是多人游戏，建议你用这个方式。
另外，定点数在这个地址下载，我的跟他几乎完全一样的，我邮箱也不发你了。
是的，是状态同步
mark，我先看看
谢谢。有个疑问，比如2个玩家，在第0帧的时候，大家都没有移动。到第1帧时，玩家1移动了，到第6帧同步到服务器，这个时候服务器正好第100ms下发给其他玩家，玩家2在第9帧收到了玩家1的移动，而玩家1在这个时候已经又发生了移动，玩家2在第10帧向玩家1发射了一发子弹，而这个时候玩家2看到的玩家1的位置和玩家1看到自己的位置是一致的吗？
我现在是以帧数，也就是6作为除数来平滑移动，我之前也用过dt作为除数来平滑移动，但是发现这样卡顿更严重，我现在的方法反而流畅多了
在第1帧移动了，那么就会在第1帧同步，不可能到第6帧才同步的。
第一帧移动：收到服务端下发的第0帧–>验证操作，如果没有则无视，获取摇杆方向、A键按下并发送到服务端–>服务端下发第1帧–>验证操作，得到摇杆方向和A键按下，移动人物1帧，创建子弹（假设A键是射击）
以上的帧是指逻辑帧（根据服务端帧频，一般15fps-30fps，固定的），不是渲染帧（客户端帧频一般60fps，根据性能不固定）
dt是不可能卡顿的，等于把帧跟帧之间不固定的时间差给平滑碎片化了，如果缓存逻辑帧几帧，那么不可能不平滑。。我现在不缓存也非常平滑。
你是没有区分好逻辑帧和渲染帧update的区别。逻辑帧做计算，而渲染帧只处理渲染不做任何计算，任何计算都在逻辑帧中处理，比如说玩家在该逻辑帧后的位置、子弹是否与人物碰撞，将计算结果放到渲染帧update里面显示就可以了。由于逻辑帧都是每100ms同步一次，每100ms计算一次位置、碰撞，所以所有客户端可以在同一个逻辑帧保持同步，这就是帧同步、状态同步的原理。你这里的描述是明显都是在渲染帧update处理了计算了，所以没法同步。
你的游戏摄像机会跟随主角玩家移动吗
抱歉，回复错人了
您的玩家移动是先表现出来，再上传给服务器的吗？
玩了一下，穿墙很频繁，有时都穿墙到地图外面去了
现在这样的体验也就ok了，要再优化，就得网络延时的时候做预测，而预测就会有纠正，纠正又涉及到平滑修复，涉及的点还是很多的。
你看上面几楼回复你的第二点，是先将位置上传给服务端，服务端广播帧消息到客户端，然后客户端再表现
感谢提醒，我也有发现这个bug，但是好像并不频繁吧
帧同步不应该上传位置，而应该上传操作
mark,回头学习一下
如果同步位置那就是状态同步了
1赞