ゲームのネットワーキングですか？

Question

自分のゲームを完全にサーバー側にしたい。つまり、クライアントはキーストロークのみを送信します。次に、変更されたオブジェクトの位置をサーバーから更新します。その後、クライアントはすべてのフレームをすべてレンダリングします。 BOX2Dを使用してその間のフレームを計算し、サーバがあることを行って、実際にある場所を予測しようとしないでください：

これは、2Dゲーム

私はこのような何かを考えていたです。

ServerPos - > ClientPos - > ServerPos - > ...その後、私たちは、クライアント上の次のフレームをシミュレートする一定の時間によって我々は（ドロップまたは何か）パケットをもらっていない場合は

。この考えは、サーバーが常に私たちの立場を修正するのを避けることです。私たちは、クライアントが仲間を埋めることを望みますが、サーバーがどこになるかを予測しようとはしません。

クライアントがシミュレートされているため、プレーヤーを反対方向に移動することは避けたいので、結果のベクトルに0.98のようなスカラーを掛けることができます。クライアントはサーバーよりもわずかに遅くなります。サーバーの位置へのスムーズな移行を確実にします。

おかげ

Answer 1

だけと思ったが、私はあなたがネットワークの遅延を忘れるかもしれないと思います。

実際には、クライアントが送信したものに応答して、1秒間に60回データを送信しているとします。あなたの最大レイテンシーは1 second/60 = 17msです。これは、あなたのアプリケーションが何らかのレイテンシを導入することに拘束されているので、ちょうどあらゆるインターネット接続の問題です。だから...もしこのようなことをしたいのなら、この遅れをとらえるために小さなバッファウィンドウを持たなければならないでしょう。そして、それは反応が少ないと感じるようになります。

ほとんどのオンラインゲームには、接続が少し落ち込んだ/停止した場合のために、いくつかの予測アルゴリズムが用意されているという理由があります。

私はこのアイデアは素晴らしいと思っていますが、実際にはうまくいきません。あなたはすべてのサーバー側をコントロールしている場合

Answer 2

号

ネットワーク遅延は、ゲームがいななき再生できないようになります。 LaTaleのように、これを既に行っているゲームを見るだけでよいです。入力遅延は恐ろしいです。だけLAN上の、または非常にいくつかの低ホップサーバーからクライアントへの接続上で動作することができます

Answer 3

。いくつかの公開サーバへの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に応じて、（1つのフレーム）遅延がゲームが使用できなくなるだろう。

Answer 4

できるだけシンクしてください。毎秒60回はあまりにも多く、必要ではありません。 LANの場合、100msごとに1回で十分です。 WANの場合、200msごとに1回は通常のケースです。

そして、あなたはゲームのようなものを作っていますか？このポリシーはゲームによって大きく異なります。ゲームの同期ポリシーをカスタマイズする必要があるかもしれません。あなたはキーストロークがサーバに到達することがかかりますどのくらいかわからないので、

Answer 5

あなたはこのようにそれを行うことはできません。そして、物理学がオブジェクトの状態を時間の経過とともに変化させると、予期しないタイミングの側面は、サーバーの表現がクライアントのものと引き続き一致することを保証できないことを意味します。一方の側は信頼できるものでなければならず、もう一方は予測するか、待つか、あるいはその両方でなければなりません。