通常在这类游戏中所做的事情:
- 预测是“推算”,服务器让客户端以一定的速度移动(当然,为了重力、爆炸和服务器上发生的其他事情调整这个速度),直到客户端更新其当前位置和速度为止。对于一个动作游戏,很难想出比这个速度更高级的预测*时间移动(也就是说,试图预测输入是什么coming).
- Telling,服务器在哪里是一个棘手的问题。如果服务器依赖玩家发送自己的位置和速度,客户端可以欺骗自己的位置以绕过障碍。理想情况下,服务器只需接收客户端输入并直接处理由此产生的移动,因此可以确定人们正在以合法的方式移动。然而,延迟将输入输入到服务器,这是不切实际的,因此您可能需要一个中间的解决方案,客户端说“我在(x,y)将速度更改为(s,t)时就在这里”(即在x,y点按下跳转键),服务器查看这些信息并说:“根据我对这个客户端的预测动作,他实际上在0.7秒前还在那个点附近,所以我相信他确实在那个点改变了他的速度。我对最后0.7秒的预测是不准确的,所以玩家实际上在(x,y) + (s,t)*0.7“如果服务器不同意,它应该告诉玩家它认为她(她)目前在哪里,这样玩家就会重新回到服务器指示的位置。例如,如果在客户端输入到服务器之前在服务器上发生爆炸,那么客户机在世界上对自己的看法就不再准确了。同样,如果客户试图发送一个错误的位置,远离他目前的位置,或一个荒谬的高移动速度。服务器必须放下重击,可以这样说:)
- 服务器向每个客户端发送每个玩家在他或她附近的位置和速度。位置和速度足以充分预测和外推球员的移动。换句话说,其他玩家不关心哪个键被按下,或者诸如此类的事情,服务器已经确认了准确性。NPC移动和AI可以在客户端处理,因此它们不需要是sent.
- Networked游戏,几乎总是用UDP套接字完成。UDP套接字的开销比TCP低得多,因为接收方不承认数据包。如果他们迷路了,他们就永远消失了。虽然这样可以节省确认往返,但您不能假设数据包已到达服务器,反之亦然。这是发送输入事件的棘手之处。最好总是发送当前状态“快照”,而不是状态更改,因为即使数据包在传输过程中丢失,您也可以在数据包一进来就知道正确的状态。换句话说,你总是想说“这是我现在的处境和我目前正在做的事情”,而不是“我按了3次跳”。
因此,总之,客户可以发送速度更新和位置的化身是发生变化。服务器验证所有当前状态的合理值。服务器将这些数据发送给附近的其他玩家(理想情况下,将附近玩家的所有运动信息打包到一个包中),客户端应用相同的预测模型,减去合理运动的验证。
抱歉这太久了..。