2012-04-05 83 views
3

我正在通过UDP实现联网小行星。我打算限制客户端发送的用户输入消息为变化。因此,只有在箭头键或空格键上存在键或键时才发送消息。这将大大减少从客户端发送的数据包数量。在网络游戏中通过UDP发送键盘输入

但是,现在我已经重读了Gaffers关于网络物理的文章他关于使UDP消息可靠的更复杂的一个我正在反思。他指出:

The key to making this input stream tolerant of packet loss and out of order delivery is the inclusion of a floating point time in seconds value with every input rpc sent. The server keeps track of the current time on the server and ignores any input received with a time value less than the current time. This effectively drops any input that is received out of order. Lost packets are ignored.

所以,如果一个数据包丢失是不关心。现在我正在想,指示keydown向前推进船的重要数据包可能会被丢失,并且永远不会怨恨,从而打破游戏。

我,因此我说得对客户端,而不是被迫派遣更多的定期(高达每物理学更新,每秒50次)转储实际键盘的状态而不是国家改变以配合这容忍丢包的方案?还是有更高尚的方式?

+0

这是网络多人游戏中最困难的事情之一。没有适用于每场比赛的通用解决方案。许多动作游戏使用近似和预测这些东西。之前我已经编制了一款多人跳板/打砖块/乒乓球克隆,而且很难流利地做到这一点。像素动作游戏通常在定位方面要求相当高的准确性,但也要求定时。 – 2012-04-05 07:29:12

+0

游戏将在我的家庭网络CAT 5E或大学校园播放。我的滞后性会很低。目前使用C++进行测试的时间<3 ms。 – ScrollerBlaster 2012-04-05 07:47:39

回答

0

基于一个相同的问题,我问过上gamedev响应:https://gamedev.stackexchange.com/questions/26840/send-regular-keyboard-samples-or-keyboard-state-changes-over-network的concensus似乎是只有当它(在关键的时刻向下或向上键只)改变发送键盘状态。这几乎不会产生任何流量。它需要确保这些消息是可靠的。由于时间紧迫,这将是一个挑战。即使客户可以继续移动他们自己的玩家(ala客户端预测),也需要通过服务器并且以“实时”方式告知其他客户端其竞争对手的状态改变。

2

正如我在我的评论中已经指出的那样,没有答案来统治他们。

但在你的情况,我可能不会转移按键,但物理变化,而不是:

  • 转移只在物理变化,例如当物体(玩家,小行星)的加速度变化并改变为一般游戏状态时(小行星/玩家爆炸,击球,得分)
  • 当你这样做的时候,同时传递该物体的当前位置以补偿滞后只有3ms,对象的位置会有所不同),并更新适当对象的位置(有时看起来像对象会稍微跳跃一些,但几乎每个游戏都有这个问题)。
  • 其他一切(像引力一样的世界物理)可以在客户端本身进行计算,不需要通过网络进行传输。
+1

尽管我问了这个问题,而你回答了这个问题,但我倾向于强烈反对。根据着名的专家,传输关键状态是客户端所做的,而服务器*是物理上的权威,并且可能是碰撞。 – ScrollerBlaster 2012-04-05 10:49:18

+1

嗯,你是对的 - 服务器应该是整个游戏状态的**权限**,主要是为了避免作弊。但是为了显示目的,在客户端预测/近似移动以减少所需带宽(如果知道对象当前速度和加速度矢量,则不需要每秒更新一次对象50次)。 – 2012-04-05 10:57:21

+0

我打算用来自服务器的授权更正(timne permitting!)来做客户端预测,*但是*我的问题是只有当发生更改时,是否定期传输当前键盘状态或键盘状态*更改事件*。如果后者那么一个不幸的数据包丢失可能会破坏游戏。 – ScrollerBlaster 2012-04-05 11:16:04

0

另一种方式是握手数据包并重复发送,直到达到握手。当然你需要在两个方向上做这个。在串行的旧时代,这可以通过四条控制线来完成,每条控制线两条。