ネットワーキングポンクローン

私はTCPソケット、UDP通信などの基本を持っていますが、これらをリアルタイムゲーム環境に適用する方法についてはあまりわかりません。

私は4プレーヤーのPongクローンを持っていて、3つのクライアントとサーバーの間でパドルの位置を同期する必要があります（サーバーは4番目のプレーヤーです）。現在、UDPを使用してリアルタイムの更新（パドルの動き）を送信し、TCPを使用してゲームロビーを設定しています。

大量のUDPトラフィックをスパム送信するのは悪いことですか？輻輳機能については、DCCPのようなものを検討する必要がありますか？それとも、これはこのような小規模プロジェクトでは本当に問題ではないのですか？

クライアント/サーバー間で同期メッセージを送信する必要があるのはいつですか？現在、サーバーは、現在のゲーム状態のUDPパケットを管理可能な限り速くスパム送信しており、クライアントは、パドルの位置をできるだけ早くサーバーに送信しています。これはそれを行うための最良の方法ですか？Xミリ秒ごとにメッセージが送信されるように追加する必要がある遅延のようなものはありますか、またはイベントが発生したときにのみメッセージを送信する必要がありますか？（例えば、ユーザー入力によりパドル速度が変化した）

クライアントにパドル位置をピアツーピアで通信させる方が良いでしょうか？

私はPongのコンテキスト内でこれらの質問をしていますが、これらの問題が他のゲームまたは一般化されたソリューションでどのように克服されるかにも興味があります。

構成可能な更新間隔（毎秒5パケットまたは20を微調整して試すことができます）を用意し、各フレームで更新を送信するタイミングかどうかを確認します。イベントごとにパケットを送信する単純なゲームで大丈夫かもしれませんが、より複雑なゲームではこれは実用的ではありません。また、パケットのオーバーヘッドがあるため、小さなパケットの束を送信する場合は、帯域幅を浪費することに注意してください。

各更新間隔では、各クライアントがパドル位置をサーバーまたは各クライアント（ピアピア）に送信します。サーバーにボールの位置と速度ベクトルも送信してもらいます。各クライアントは、シングルプレーヤーと同じ画面描画コードを実行できるため、ボールの動きがスムーズになります。マルチプレーヤーでは、サーバーのみが定期的にボールの位置/速度の更新を送信します（そして、何かがヒットするたびに好きな場合）。

ボールの位置の更新がすべてのクライアントのゲーム時間を参照するようにして、順序の乱れたパケットを破棄し、ボールの位置の補間をより正確にすることもできます（過去の特定の時間における位置と速度がわかっているため、新しい補間を行うことができます）ポジション）。

ラグゲームのあるこのモデルを使用すると、ボールが時々後方に移動したり、少し飛び回ったりすることがあります。しかし、まともな接続があれば、かなりスムーズになるはずです。

トラフィックの問題について-ピアごとに1秒あたり20〜30を超えるパケットを送信しないようにします。一般的なケースでは、送信するパケットが小さくて少ないと、遅延が（わずかに）少なくなり、パケットがドロップされる可能性が低くなります。

プレーヤーは違いを知ることができないため、フレームレートよりも速い速度で更新を送信したくはありません。実際、1秒に10回だけパケットを送信し、受信側で結果を内挿/外挿すると、 、ほとんどのプレイヤーは違いに気付かないでしょう。

これはかなり大まかな質問ですが、重要な側面を要約してみます。

ゲームのネットワークコードで行う最初の決定は、ピアツーピア配置のクライアント/サーバー設定が必要かどうかです。RTSが唯一の注目すべき例外であるほとんどのゲームは、おそらくクライアント/サーバーアーキテクチャを使用しています。主な利点は、この構成の方がフォールトトレラントであり、各クライアントが受信するデータをより詳細に制御できることです。ピアツーピアでは、はるかに少ないデータを送信できますが、各ピアが他のすべてのピアと同じように世界を完全にシミュレートする必要があります。1つのピアが遅延または非同期化した場合、全員が回復するまで待たなければならないか、単に失われるだけです。

UDPは一般に正しい選択ですが、確かにどのクライアント/サーバーモデルにも当てはまります。ピアツーピアゲームにはTCPが実用的かもしれませんが、それでもUDPの方が適しているかもしれません。基本的に、UDPが処理する処理は少なくなります。つまり、より多くの労力が必要になるだけでなく、障害への対処方法をより詳細に制御できます。

Pongの場合、私が選択するのはクライアント/サーバーです。つまり、アクション指向のゲームです。ここで注意すべき点の1つは、1人のプレイヤーが "サーバー"であると言っても、基本的にローカルサーバーを実行し、クライアントとして接続するようにコードを構築することです。

あなたは間違いなく、どの方向にも更新を「スパム」することを望んでいません。フレームごとのサーバーからの1つの更新が必要なすべてであり、サーバーは固定フレームレートで実行されている必要があります。それはあなた次第ですが、船外に行く必要はありません。50msフレーム（20 FPS）は、スムーズなゲームプレイを実現するのに十分です。クライアント上で物事をスムーズに保つには、補間を利用する必要があります。クライアントはサーバーフレームのスナップショット間で常に移行している必要がありますが、これは別の問題のトピックになる可能性があります。

クライアントの更新も制限する必要がありますが、クライアントがまともなフレームレートで実行されている場合、フレームごとに1つでは多すぎる可能性があります。

あなたは浮気を気にしますか？

そうでない場合、ピアツーピアにすると、A <-> B <-> CではなくA <-> Cになるため、ラグが半分になります。もしそうなら、同期の公平性のために、ローカルプレーヤーやほとんどのゲームが行うことに対してやや遅れた応答を行いたい場合があります-サーバーの結果がローカルでシミュレートされたものと異なる場合は、プレーヤーにローカルで何でもさせ、スナップバックします。

ほとんどのゲームとは異なり、開発者は片方にヒットを表示させ、もう片方にヒットを表示させないことで不正行為を行うことはできないため、ピンポンクローンは実際には少しトリッキーです。

一般化されたものについて、聞いたことはあるが必要ではない（アクションゲームの場合もある）テクニックの1つは、実際のタイムスタンプ（受信時間-ping / 2）でアクションを保持し、サーバーをロールバックする（ snap）以前の時間のイベントが発生した場合、その後のアクションを再適用します。このようにして、さまざまなプレーヤーの相互作用による競合がない限り、全員がローカルで一貫しています。唯一の危険は、接続が遅れている場合に「時間をロールバック」する機能です。

グーグルデッドレコニング。4人のプレーヤーにアップデートを送信することは重要ではありません。送信されるデータ量はバイトのオーダーになります。つまり、頻繁に更新しても問題ないということです。推測航法では、クライアントとサーバーでプレーヤーを移動します。サーバーが権限です。クライアントの位置がサーバーから離れすぎた場合、位置合わせに戻る必要があります。 http://trac.bookofhook.com/bookofhook/trac.cgi/wiki/Quake3Networking UDPを使用する方法があります。Bupdateは頻繁に送信され、失われたデータはすぐに受信データに置き換えられます。TCPのパケット再送信は、プレーヤーの位置にとっては価値がありません。クライアントとサーバーを同期させる方法の詳細については、この記事を参照してください。

数週間前に2プレイヤーローカルネットワークポンゲームをプログラミングしました。

-片方がサーバーを開き、もう片方が自動的に接続する-両方がパドルのx位置を互いに60fps以下でスパミングしている[UDP]-片方がボールを打った場合、ボールの新しい速度と位置について決定し、それを送信する他の1つに[TCP]-ボールがパドルを越えて飛ぶ場合、ボールを逃したプレーヤーはスコアの増加メッセージで他のボールに接触し、ボールはリセットされます[TCP]-ボールは常に独立してシミュレーションされます。ピンポンの単純なボール物理学に適しています

これにより、60 fpsで約0.3〜0.5 KByte / sのトラフィックが作成され、プレーヤーは知覚に遅れを生じません。ただし、ボールの新しい位置を送信する必要があるため、pingが特定のしきい値を下回る場合のみです。

また、このシステムでは不正行為は簡単で、非常に損失の多い接続と同期が取れなくなる可能性が高くなりますが、ピンポンでの不正行為を気にする人はいますか？