ソケットを使用してマルチプレイヤーターン制ゲームを作成した経験はありますが、リアルタイム アクション ゲームを試みたことはありません。どのような追加の問題に対処する必要がありますか? 遅れたプレーヤーが過去に何かをした場合に備えて、プレーヤーのアクションの履歴を保持する必要がありますか? 本当に UDP パケットを使用する必要がありますか? それとも TCP で十分ですか? ほかに何か？
何を作るかはまだ決めていませんが、この質問の目的のために、XY 移動を伴う 10 人用の 2D ゲームを考えることができます。
ターンベースのゲームでは、通常、「サーバーが最終的な権限を持っているので、完了です」と言うのは非常に簡単です。リアルタイム ゲームでは、多くの場合、その設計から始めるのが最適ですが、遅延を追加するとすぐに、クライアントの動き/アクションが応答しなくなったように感じます。そのため、クライアントの入力がキャラクターやユニットにすぐに影響を与えてその問題を解決できるようにする「レイテンシの隠蔽」を追加し、クライアントとサーバーのゲーム状態が分岐し始めたときに調整の問題に対処する必要があります。10回のうち9回は問題なく、クライアントが影響を与えたオブジェクトを権限のある位置にポップまたはラープしますが、10回に1回はオブジェクトがプレイヤーのアバターか何かである場合であり、その解決策は受け入れられないため、開始しますいくつかのアクションに対する権限をクライアントに与えます。ここで、サーバー上の複数のゲーム状態を調整し、悪意のあるクライアントを介した潜在的な「不正行為」に自分自身を開放する必要があります.そのようなことを気にする場合. これは基本的に、すべてのテレポート/だまし/あらゆるバグ/チートが発生する場所です。
もちろん、「すべてのクライアントが「自分の」オブジェクトに対する権限を持っている」というモデルから始めて、不正行為の問題を無視することもできます (ほとんどの場合は問題ありません)。しかし、そのクライアントが脱落した場合、または「シミュレーションについていくのが少し遅れただけ」でさえ、ゲーム シミュレーションに大きな影響を与える可能性があります。遅れているクライアントが追いつくのを待っているか、クライアントが制御するゲームの状態が同期していないという形で、遅れている、またはパフォーマンスが低いクライアント。
すべてのプレイヤーが同じゲーム状態で動作していることを確認するための一般的な戦略は、(上記のモデルの 1 つを介して) プレイヤー入力のリストに単純に同意し、ゲームプレイ シミュレーションをすべてのマシンで同期的に実行することです。これは、シミュレーション ロジックが正確に一致する必要があることを意味します。一致しないと、ゲームが同期しなくなります。これは実際には、思ったよりも簡単で難しいものです。ゲームは単なるコードであり、同じ入力 (乱数ジェネレーターでさえも) が与えられた場合、コードはまったく同じように実行されるため、簡単です。そうでない 2 つのケースがあるため、より困難になります。(1) ゲーム シミュレーションの外でランダムを誤って使用した場合、および (2) フロートを使用した場合です。前者は、どの RNG がどのゲーム システムで使用されるかについて厳密なルール/アサーションを持つことによって修正されます。後者は、フロートを使用しないことで解決されます。(フロートには実際には 2 つの問題があります。1 つは、プロジェクトの最適化構成に基づいて動作が大きく異なりますが、それが解決されたとしても、異なるプロセッサ アーキテクチャ atm 間で動作に一貫性がありません、笑)。Starcraft/Warcraft および「リプレイ」を提供するすべてのゲームは、このモデルを使用する可能性が最も高いです。実際、再生システムを持つことは、RNG が同期していることをテストする優れた方法です。
非同期ソリューションを使用すると、ゲーム ステート オーソリティは、特定の頻度でそのステート全体を他のすべてのクライアントにブロードキャストするだけです。クライアントはそのデータを受け取り、それを自分のゲーム状態に叩き込みます (通常、次の更新を取得するまで単純化した外挿を行います)。ここでは、「udp」が実行可能なオプションになります。ゲーム状態全体を約 1 秒ごとにスパム送信しているため、これらの更新の一部を削除することは無関係です。ゲーム ステートが比較的少ないゲーム (クエイク、ワールド オブ ウォークラフト) では、これが最も簡単な解決策であることがよくあります。
マルチプレイヤーの設定には、いくつかの要素が関係しています
プロトコルについては、TCP と UDP のどちらを使用するかを決定することが重要です。UDP はオーバーヘッドが少ないですが、配信は保証されません。逆に、TCP は信頼性が高くなります。各ゲームには、優先プロトコルがあります。たとえば、UDP は一人称シューティング ゲームでは機能しますが、情報の一貫性が必要な RTS には適していない可能性があります。
ファイアウォール/接続。マルチプレイヤー ゲームで 2000 のアウトバウンド接続を確立する必要がなく、ポート転送が簡単な標準ポートを使用していることを確認してください。Windowsファイアウォールとのインターフェースは、おそらく追加のボーナスになります。
帯域幅。これは重要です。ネットワーク接続を介してプッシュする予定のデータの量はどれくらいですか? これは、再生テストと録音のスループットに帰着すると思います。クライアントごとに 200kb/s を超える速度が必要な場合は、いくつかのことを再考する必要があります。
サーバー負荷。これも重要なのですが、通常のゲームでサーバーがどれだけの処理を必要とするかということです。それを実行するには、16 GB の RAM を搭載したスーパー 8 コア サーバーが必要ですか? 減らす方法はありますか？
もっと山ほどあると思いますが、実際には、ネットワークやさまざまな接続を介して快適にプレイできるゲームが必要です。
計画はあなたの親友です。あなたのニーズが本当に何であるかを理解してください。
データの読み込み: すべてのコンピューターが同じモデルとグラフィックスを持つようになり、名前と場所だけがネット上で移動されます。すべてのプレイヤーがキャラクターやその他のアイテムをカスタマイズできる場合、このデータを移動する必要があります。
不正行為: 心配する必要はありますか? 各クライアントの発言を信頼できますか。そうでない場合、サーバー側のロジックはクライアント側のロジックとは異なって見えます。この単純なケースを想像してみてください。10 人のプレーヤーのそれぞれが、パワーアップのために異なる移動速度を持っている可能性があります。不正行為を最小限に抑えるには、各プレイヤーがサーバーからの通信更新の間にどれだけ移動できるかを計算する必要があります。プレーヤーが一貫して予想より少し速いか、1 回限りのジャンプをしている場合、サーバーは可能な限り最も近い場所にプレーヤーを再配置します。これは、クロック スキューまたは通信の 1 回限りの中断である可能性が高いためです。ただし、プレーヤーが常に可能な限り 2 倍移動している場合は、そのプレーヤーをゲームから追い出すのが賢明かもしれません。数学が多ければ多いほど、
ピア ツー ピアとはどのようなものか: ゲームがピア ツー ピアになる場合でも、1 人のプレーヤーがゲームを開始してサーバーとして使用することをお勧めします。アプローチします。サーバーがない場合は、ゲームの状態が一致しない 2 台のマシン間の論争を解決するためのプロトコルを作成する必要があります。
繰り返しますが、計画はあなたの親友です 計画、計画、計画。問題について十分に考えれば、ほとんどの問題を解決することができます。次に、まだ解決していない問題について考え始めることができます。
不正行為を避けることはどれほど重要ですか? [クライアントからの情報を信頼できますか、または信頼して認証できますか?]
オブジェクト モデル オブジェクトは、あるマシンから別のマシンにどのように伝達されますか? オブジェクトに対してアクションはどのように実行されますか?
クライアント/サーバーまたはピアツーピアを実行していますか?
乱数 ピア ツー ピアを行う場合は、ロックステップを維持し、乱数を同期させる必要があります。
クライアント/サーバーを実行している場合、ラグにどのように対処しますか? 【推測航法？】
ネットワーク コーディングには、多くの重要な問題が伴います。
コードを無料でダウンロードできる RakNet と、ディスカッション グループの両方をチェックしてください。
LAN 上で実行する場合は、TCP で問題ありません。ただし、オンラインでプレイしたい場合は、UDP を使用し、独自の TCP のようなレイヤーを実装する必要があります。throw NAT ルーターを渡す必要があります。
ピア ツー ピアまたはクライアント サーバー通信のいずれかを選択する必要があります。クライアント サーバー モデルでは、同期と世界の状態を簡単に実装できますが、オンラインでの反応性が不足する可能性があります。Pee-to-peer ではより複雑ですが、プレイヤーにとっては高速です。
ゲームの目的でプレイヤー アクションの履歴を保持しないでください (保持しますが、リプレイ機能のみに使用します)。必要なポイントに到達した場合は、すべてのプレイヤーを待たせることをお勧めします。