2012-04-05 84 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

另一種方式是握手數據包並重復發送,直到達到握手。當然你需要在兩個方向上做這個。在串行的舊時代,這可以通過四條控制線來完成,每條控制線兩條。