dzf112233 如果世界是平地，并且玩家不多的情况下这样做可以。如果地形起伏较大用插值客户端表现可能会有问题，所以建议客户端用Unity的物理引擎来移动。协议只同步坐标的话，每秒要发很多包才能让表现比较丝滑，玩家多了会遭不住的。你想一下，假设玩家一直按W键方向没变过，在同步坐标的时候把速度和方向带上转发，是不是就可以预测下一次同步之前角色的位置了？那么你同步位置的间隔时间是不是就可以久很多
526077247 您这个意思是说，在我的客户端上的其他玩家的角色，也用unity的物理引擎来控制？这样是不是有点像状态同步？比如A的客户端按下W，客户端给服务端发送这条消息，然后服务端广播。B的客户端收到A的w消息后，给A一个向前的velocity。这个是不是就变成了帧同步了啊？这样是否会有误差呢，如果因网络延迟导致A发送的按下和弹起W的总时长与原本客户端的不一致，就会导致客户端服务端位移距离不一致了
dzf112233 不需要纠结同步的名字，结合二者的优点使用。总时长不一致的问题，你可以选择发送协议时带上客户端的servertime。距离不一致的问题，每次同步都会带上客户端经过物理引擎计算过后的距离，服务端根据本地运算的距离和客户端发送的对比，差值在允许范围内就相信客户端。
526077247 说错了，不用带客户端的servertime，服务端以收到消息的时间为准
526077247 感谢回复，之前说错了，就是感觉这种方案很像帧同步那种“转发操作”的概念，从而会导致一定误差。我先按发包带上时间试试，感谢！
dzf112233 这就是帧同步的不足之处了。但是现在你服务端还有状态，转发操作同时可以把一些状态也发过去，客户端就可以据此修正误差
526077247 按您说的思路实现了纯状态同步，效果很不错，想请问一下服务端没有跑物理，只有速度、位置等基础信息的情况下，有什么好办法防止客户端移动作弊吗？
dzf112233 一个比较简单的思路，用玩家的速度乘两次同步间隔时间得到一个距离，以第一次同步的坐标为圆心，把这个距离作为半径，第二次同步的坐标在这个圆范围内的都是合理的，还可以适当把这个半径扩大点增加容错
dzf112233 你好，请问，你的AOI是怎么处理的呢，是服务端模拟行走然后同步AOI，还是客户端行走的时候间隔发送给服务端服务端根据位置刷新AOI
服务端没物理的话, 怪物AI的移动就不好处理了
BigDeng 没错，我也发现了，而且不能做机器人了。不知道咋办
dzf112233 目前我们这边双端引入了Bullet,还在摸索尝试中. 如果游戏玩法适合的话, 也可以找一个合适的客户端, 把怪物委托给它来进行操作吧