我希望我的遊戲完全是服務器端。意思是，客戶端只發送他們的擊鍵。然後，他們會從服務器獲得已更改對象位置的更新。客戶端然後渲染每一幀的一切。網絡遊戲？
這是一個2D遊戲
我在想是這樣的： 計算使用的Box2D的插圖中框，也不要試圖預測，其中服務器是實際上將是。
ServerPos - > ClientPos - > ServerPos - > ...
如果在一定的時間，我們還沒有得到一個數據包（丟棄或某事），那麼我們就模擬客戶端下一幀。這個想法是爲了避免服務器總是糾正我們的立場。我們希望客戶填寫中間人，但不要試圖預測服務器將在哪裏。
我們希望避免不惜一切代價向相反的方向移動播放器，因爲客戶端的模擬效果非常好，所以我們可以通過像0.98這樣的標量乘以合成向量，這意味着客戶端會比服務器略慢，有助於確保順利過渡到服務器的位置。
感謝
只是一個想法，但我想你可能忘記了網絡延遲。
假設您真的每秒發送60次數據來響應客戶端發送的內容。比你的最大延遲時間可以是1 second/60 = 17ms。這對於任何互聯網連接都是個問題，因爲你的應用程序必然會引入一些延遲。所以......如果你想要這樣的工作，你將不得不有一個緩衝窗口來趕上這個延遲。這會讓它感覺不到敏感。
有一個原因，即大多數在線遊戲都有一些預測算法，以防連接丟失/停頓一段時間。
我認爲這個想法很好，但實際上它可能不會那麼好。
號
網絡延遲會使遊戲不能玩嘶如果你控制一切的服務器端。你只需要看看已經這樣做的遊戲，比如LaTale。輸入延遲非常糟糕。
這樣做並且只能在局域網上工作，或者在一些低端的服務器到客戶端連接上異常工作。嘗試TRACERT一些公共服務器 - 這裏有一個例子：
C:\Users\mosh>tracert -d -w 3000 www.google.com
Tracing route to www.l.google.com [209.85.149.104]
over a maximum of 30 hops:
1 46 ms 99 ms 99 ms 192.168.1.1
2 * * * Request timed out.
3 10 ms 9 ms 10 ms 172.29.16.133
4 10 ms 9 ms 10 ms 195.29.110.230
5 41 ms 41 ms 95 ms 80.81.193.108
6 46 ms 47 ms 127 ms 209.85.255.176
7 49 ms 47 ms 47 ms 216.239.48.11
8 47 ms 47 ms 47 ms 216.239.48.5
9 54 ms 53 ms 54 ms 209.85.254.21
10 51 ms 42 ms 40 ms 209.85.149.104
Trace complete.
你有你的服務器和您的客戶將增加幾毫秒，這取決於17MS（一幀）延遲之間的每個路由器將會使遊戲無法使用。
同步越少越好。每秒60次是太多而沒有必要。對於局域網，sycn每100ms一次就足夠了;對於WAN，每200ms一次是正常情況。
而且，你正在製作哪種遊戲？這個政策對於不同的遊戲是非常不同的。您可能需要爲遊戲定製同步政策。
用Box2D Physics製作2D沙盒遊戲 – jmasterx 2010-12-18 15:51:37
@Milo - 看看這個http://gafferongames.com/game-physics/networked-physics/ – 2010-12-18 15:59:13
你不能這樣做，因爲你不知道按鍵到達服務器需要多長時間。考慮到物理學隨着時間的推移會改變對象的狀態，這種不可預知的時間方面意味着你不能保證服務器的表示將繼續匹配客戶端。一方必須具有權威性 - 另一方必須預測，等待或兩者兼而有之。
+1 - 打我吧=）我說的是幾乎相同的事情，但向後大聲笑。 @Milo - 我特別就**延遲**這個主要敵人發表了同樣的看法，而不是帶寬或服務器/客戶端能夠處理它。 – BeemerGuy 2010-12-18 03:44:23
@Milo - 請記住：如果我們假設數據以光速傳播，那麼您可以實現從地球上的A到B的_longest_通信線的_best_延遲爲66ms，這非常有限！ – BeemerGuy 2010-12-18 03:47:10
+1，也打我。我打算建議**從客戶端ping到服務器 - 這會給你難以超越的硬fps限制。此外，您忽略了UDP丟包的問題，或者TCP突然間一下子突然獲得最後10秒的數據包，導致擁塞和滯後。 - 編輯補充說：我想你可以做一些預測性的工作，並在未來的一段時間內發送所有的可能性。但是，你很快就在談論一些嚴重的帶寬！ – 2010-12-18 03:47:41