同一client和server之间的通信，接受顺序一定等于发送顺序吗?

冷俊逸

RT，小白想做一个联网游戏(socket nb!)，第1版游戏至少要实现同步玩家移动数据。0基础，正在构思/学mv代码，现在暂时想到的业务逻辑是

如果 客户 加入房间
     给客户发送房间内已有玩家的位置数据
当 客户 给 服务器发消息（移动、对话等）
      广播客户的消息

但是如果 玩家1 电脑里的 玩家2 数据还没初始化，而 玩家2 决定移动一格的信息却已经收到了，那么就容易产生错误。另外如果一条路只能先上在右，可是向右的信息比向上的信息先到，那也会出现显示错误。所以想问一下这个顺序是固定的吗，还是说会随网络条件变化（当然，多加一个缓存栈就行）

另外，想问一下以下几种同步玩家信息的方式哪种好呢？
1. 玩家本人操作时即时更新本地坐标并告知服务器移动信息，其他玩家的移动信息被延迟发送到本地。这样的话反馈即时，但是如果后期加入ARPG功能，可能会由于延迟导致“明明已经移动出了敌方攻击范围却还被打到了”的bug。
2. 玩家本人操作时向服务器发送移动数据，直到服务器传回数据才进行移动操作。这样的话，如果玩家和服务器之间有稳定延迟，那么显示出的画面不会有上一点所阐释的错误。同时，这种方式的移动数据在云端计算，不容易出现由于不同客户端数据不同造成的显示bug（比如地图中某个装饰用的不可通行事件不小心被消除）。缺点是可能走路会一卡一卡的（必须本地单步移动结束才能进行下一次按键操作）
3. 玩家在按键按压/松开时上传按键信息，云端计算移动路线，同时发送回去，类似王者荣耀。优点似乎是如果你中间不小心断开了连接，还可以继续走路。以及不会有上一步说的一卡一卡的毛病。缺点暂时没发现。

guoxiaomi

你用的MV可以直接使用WebSocket了连接服务器。WebSocket是保序的，意思是你客户端和服务端的通讯是保序的，但是客户端之间的通讯如何保序，需要你自己在服务端进行协调。

剩下的我就不懂了，反正我也不做ARPG……所以用的是第一种方案。不过在我看来如果是Pixel的移动，可能没有那么明显的卡顿感。

还有一点是，即使是在敌方攻击范围外，却还被打到了应该很正常吧，这不就是所谓的“卡顿”吗？网不好玩什么ARPG……