私の超シンプルなマルチプレイヤーセットアップはおそらく良いアイデアではないことを知っていますが、なぜですか？

単に楽しみのためにシンプルな小さなMOBAを作成しています。私はすべてをシングルプレーヤーにしていたときに、「マルチプレーヤーを追加する必要があるだろう」と気づきました。

私はこれまでネットワーキングで何もしたことがないので、Lidgrenをゲームに統合する方法を学ぶのは楽しくて素晴らしいものでした。問題は、私が行っている方法が間違っていることはよくわかっています。なぜなら、私が知る限り、メインストリームゲームを使用するには十分に堅牢ではないからです。しかし、何が問題になっていますか？

私がやっていることは、基本的に、プレイヤーがアクションを実行するたびに、「ちょっと、これをやっただけだ」というメッセージをサーバーに送信することです。サーバーとクライアントはどちらも同じシミュレーションを実行しています。次に、サーバーは他のすべてのクライアントにメッセージを送信して、その人がそのことをしたことを伝えます。

いくつかの場合を除いて、ほとんどの場合、プレーヤーが何かをするとき、クライアントはそれがクールであると想定し、自分でそれを進めます。したがって、どこかを右クリックしてそこに移動すると、そのプレーヤーのクライアントは彼の男をそこに移動し始め、それを知らせるメッセージをサーバーに送信します。

だから基本的に：

• プレイヤー1が呪文を唱えると、6秒間100％速く動くようになります
• プレーヤー1のローカルクライアントがそのバフをユニットオブジェクトに追加します
• プレーヤー1のクライアントがサーバーに「この呪文を唱えただけだ」というメッセージを送信します。
• サーバーは、彼がその呪文を唱えるのに十分なマナを本当に持っていることを確認し、もしそうであれば、そのバフをサーバーのそのUnitオブジェクトのコピーに追加します
• サーバーは他のすべてのクライアントに「この男はこの呪文を唱えた」というメッセージを送信します
• 他のすべてのクライアントはメッセージを受信し、「ああ、大丈夫」に進み、そのバフをそのプレーヤーのローカルユニットオブジェクトに追加します

ビッグゲームがマルチプレーヤーでどのように機能するかを確認するために、さまざまな情報をざっと調べてきましたが、この機能に手を出し始めたばかりのユーザーを混乱させるようなものですが、Sourceエンジンは、すべての変更を含むパケットを世界のすべてのダニ？繰り返しますが、これはまったく新しいことですが、それほど多くのデータを頻繁にプッシュできますか

これが少し乱暴である場合は申し訳ありませんが、基本的には、なぜ私のシンプルなシステムが適切な方法ではないのかと思っていました。

Byte56の回答に加えて、考慮すべき事項がいくつかあります。

プレイヤーの動きについてクライアント間でどのようにコミュニケーションをとりますか？他のほとんどのプレーヤーのアクションとは異なり、イベントは孤立しがちであり、頻度は低いと考えられますが、動きは連続しています。更新を送受信できる（そしてそのためにしたい）レートには制限があります。Byte56が言及したクライアント側の予測には、通常、クライアントの位置と速度に関する定期的な更新が含まれます。次に、クライアントは、キュービックスプラインのようなものを使用して、それらの間をローカルに補間します。

前の問題に戻る2番目の問題は、UDPの配信が保証されていないことです。送信するすべてのメッセージが到着するか、正しい順序で到着するかさえ確信できません。パケット1、2、および3を送信すると、サーバーは2ではなく3を受信し、次に1を受信します。多くの場合、パケットは正しい順序になり、到着することもありますが、常に到着するわけではありません。したがって、パケットの損失に強いシステムが必要です。簡単な確認システムで十分です。通常使用されるのは、最後の32メッセージ（32ビット整数の場合）を受信したかどうか、および最後に受信したメッセージが何であったかを他のノードに通知するビットフィールドです。このようにして、メッセージに重要なラベルを付けるかどうかを指定し、重要なメッセージを受信しない場合は再送信できます。 ここでそれについてかなりまともな議論があります。

また、これを行う場合、クライアントが互いに同期しなくなることにも留意する必要があります。最良のシナリオでは、次のフレームに取り組んでいる間、それぞれが前の2つのネットワークフレーム間を補間している他のプレーヤーを表示します。したがって、プレーヤーがアクションを実行したときに見たものが、そのアクションを実行したときのゲームの実際の状態ではなかったことを（公正に）考慮に入れるシステムが必要です。彼は古い、非同期のゲーム状態に反応していました。

最後に、このゲームが競争力のあるものである場合、不正行為についても心配する必要があります。したがって、可能な限り（そして妥当な範囲で）、クライアントを信用せず、クライアントの行動が可能だったことを確認する必要があります。「いいえ、あなたはその壁を通り抜けることはできません。あなたが走る速度より速く歩くことはできません。いいえ、あなたはその目標に到達したと主張することはできません。」等

その他のアイデアについては、2番目のリンクにある他の記事を参照することをお勧めします。

幸運を！

あなたが説明しているのは本質的に クライアント側の予測ですが、サーバーとクライアントが同意しない場合に何が起こるかは言いません。

それは、クライアントが単なるダム端末であり、その入力をサーバーに送信し、サーバーがクライアントに結果を通知した時代から進化しました。ただし、ゲームがLANを超えて移動すると（以前は頻繁に）、この状況では遅延が顕著でした。あなたが説明していることは、クライアント側の予測がそれを修正するために導入されたことです。これでクライアントは、サーバーが応答するのを待つ間、動きもシミュレートします。その後、結果について合意に達します。権限を持つサーバーで。

次のステップは、意見の相違にどのように対応するかです。そのための準備が整っていない場合、クライアントとサーバーが同意しないと、クライアントにラバーバンディングまたはテレポーティングが発生します。

タイミング。他の回答では、サーバーとさまざまなクライアントでのイベントのタイミングについては触れられていません。ゲームによっては、注意が必要な場合があります。レイテンシー（ラグ）は、パケットが送信されてから受信されるまでの間に可変遅延をもたらします。時間は難しい場合がありますが、考えられる問題についてはできる限り説明します。これを気にせずに成功できるゲームもいくつかありますが、問題が発生する可能性がある簡単な例を次に示します。

パケットが到着するとすぐに、全員がパケットを処理するとします。

@ Time 0 (wall time), Player 1 puts up a shield   (Message has been sent, but not received by anyone)
@ Time 1, Player 2 shoots player 1   (Message has been sent, but not received by anyone)

時間0（T0）とT1が近いと仮定します。

次に何が起こるかは、これを誰が見ているか、およびパケットがサーバーに到着する順序によって異なります。サーバーは常に最終的な発言権を持っている必要があります。サーバーが上記の順序でパケットを受信した場合、サーバーはショットとプレイヤー1（P1）が生き残る前にシールドを適用します。P1の視点から見ると、自分でシールドを設置しているので、ショットの前にシールドを確認して生き残ります。しかし、P2はどうですか？彼らはそれを撃ったので彼らはすぐにショットを見ますが、彼らは最初にシールドを見ますか？の場合(T0 + latency between P1 and the server + the latency between the server and P2) > T1、ショットの後にシールドが表示され、P2はショットがP1を殺したと見なします。サーバーはこの状況をどうにかして修正する必要があります。

ただし、サーバーがパケットを逆の順序で受信した場合（T0 <T1の場合でも可能です）、逆のことが起こります。P1は間違っている（そして死んでいる）が、P2は正しい（そして勝利している）。

このような状況に対処するにはいくつかの方法がありますが、最も簡単なのはサーバーにすべてを実行させることです。クライアントでこれをシミュレートすることはできますが、死のような永続的なアクションは許可しません。プレイヤーは、サーバーからの重要なゲーム変更の確認を待つ必要があります。

アクション付きのタイムスタンプを送信すると有益な場合があります。主にクライアントを信頼している場合は、これらのタイムスタンプを使用して、最初の想定に従う代わりに、最初に発生したアクションを特定できます。通常、過去からのメッセージを受信すると、時間を逆にする必要があるため、これは注意が必要です。

時間が楽しいですか？最終的に何をするにせよ、これらの時間の問題を認識しておくと役に立ちます。