ここ XNUMX 週間、私はゲームのオンライン エンジンの開発に取り組んできました。 これまでは、ゲームにおけるネットワークについてまったく知識がなかったので、すべての概念を理解し、独自のネットワーク エンジンを作成できるようにするために、たくさんの記事を読み、多くの実験を行いました。

このガイドでは、独自のゲーム エンジンを作成する前に学習する必要があるさまざまな概念と、それらを学習するための最適なリソースと記事を共有したいと思います。

一般に、ネットワーク アーキテクチャには、ピアツーピアとクライアントサーバーの 2 つの主なタイプがあります。 ピアツーピア (pXNUMXp) アーキテクチャでは、接続されたプレーヤーの任意のペア間でデータが転送されますが、クライアント サーバー アーキテクチャでは、プレーヤーとサーバーの間でのみデータが転送されます。

ピアツーピア アーキテクチャは依然として一部のゲームで使用されていますが、クライアント サーバーが標準です。実装が簡単で、必要なチャネル幅が小さくて済み、不正行為からの保護が容易です。 したがって、このガイドでは、クライアント/サーバー アーキテクチャに焦点を当てます。

特に、私たちは権威主義的なサーバーに最も興味を持っています。そのようなシステムでは、サーバーは常に正しいのです。 たとえば、プレーヤーが自分が (10, 5) にいると思っているのに、サーバーが彼が (5, 3) にいると告げた場合、クライアントはその位置をサーバーが報告している位置に置き換える必要があり、その逆ではありません。 権威のあるサーバーを使用すると、不正行為者を認識しやすくなります。

ゲーム ネットワーク システムには XNUMX つの主要なコンポーネントがあります。

• トランスポート プロトコル: クライアントとサーバー間でデータが転送される方法。
• アプリケーション プロトコル: クライアントからサーバー、およびサーバーからクライアントに何が、どのような形式で送信されるか。
• アプリケーション ロジック: 送信されたデータを使用してクライアントとサーバーの状態を更新する方法。

各部分の役割とそれに伴う困難を理解することが非常に重要です。

トランスポートプロトコル

最初のステップは、サーバーとクライアントの間でデータを転送するためのプロトコルを選択することです。 これには XNUMX つのインターネット プロトコルがあります。 TCP и UDP。 ただし、それらのいずれかに基づいて独自のトランスポート プロトコルを作成したり、それらを使用するライブラリを使用したりできます。

TCPとUDPの比較

TCP と UDP はどちらもベースになっています IP。 IP により、パケットを送信元から受信者に送信できますが、送信されたパケットが遅かれ早かれ受信者に到達すること、少なくとも XNUMX 回は受信者に到達すること、および一連のパケットが正しい形式で到着することは保証されません。注文。 さらに、パケットには、次の値で指定される限られた量のデータのみを含めることができます。 MTU.

UDP は、IP 上の薄い層にすぎません。 したがって、同じ制限があります。 対照的に、TCP には多くの機能があります。 エラーチェック機能を備えた XNUMX つのノード間に信頼性の高い順序付けされた接続を提供します。 したがって、TCP は非常に便利で、他の多くのプロトコルでも使用されています。 HTTP, FTP и SMTP。 ただし、これらの機能にはすべて代償が伴います。 遅れ.

これらの関数が遅延を引き起こす理由を理解するには、TCP がどのように動作するかを理解する必要があります。 送信ホストが受信ホストにパケットを送信するとき、肯定応答 (ACK) を受信することを期待します。 一定時間が経過してもパケットを受信しない場合 (パケットまたは確認が失われたため、またはその他の理由により)、パケットを再送信します。 さらに、TCP はパケットが正しい順序で受信されることを保証するため、失われたパケットが受信されるまでは、たとえ受信ノードがすでに受信していたとしても、他のすべてのパケットは処理できません。

しかし、おそらくおわかりかと思いますが、マルチプレイヤー ゲーム、特に FPS などのアクティブなジャンルでは、遅延が非常に重要です。 そのため、多くのゲームでは独自のプロトコルで UDP が使用されます。

UDP に基づくネイティブ プロトコルは、さまざまな理由から TCP よりも効率的です。 たとえば、一部のパッケージを信頼できるものとしてマークし、他のパッケージを信頼できないものとしてマークすることができます。 したがって、信頼性の低いパケットが受信者に届いたかどうかは気にしません。 または、XNUMX つのストリームでパケットが失われても他のストリームの速度が低下しないように、複数のデータ ストリームを処理することもできます。 たとえば、プレーヤー入力用のスレッドとチャット メッセージ用の別のスレッドが存在する場合があります。 緊急データではないチャット メッセージが失われた場合でも、緊急データの入力が遅くなることはありません。 あるいは、ビデオ ゲーム環境での効率を高めるために、独自のプロトコルが TCP とは異なる方法で信頼性を実装する場合もあります。

では、TCP がダメなら、UDP に基づいて独自のトランスポート プロトコルを構築することになるのでしょうか?

もう少し複雑です。 TCP はゲーム ネットワーク システムにはほぼ最適ではありませんが、特定のゲームでは非常にうまく機能し、貴重な時間を節約できます。 たとえば、ターンベースのゲームや LAN ネットワーク上でのみプレイできるゲームの場合、待ち時間やパケット損失がインターネットよりもはるかに低い場合、待ち時間は問題にならない場合があります。

World of Warcraft、Minecraft、Terraria などの成功したゲームの多くは TCP を使用しています。 ただし、ほとんどの FPS は独自の UDP ベースのプロトコルを使用するため、それらについては以下で詳しく説明します。

TCP の使用を選択した場合は、それが無効になっていることを確認してください ネーグルのアルゴリズム送信前にパケットをバッファリングするため、遅延が増加します。

マルチプレイヤー ゲームのコンテキストにおける UDP と TCP の違いについて詳しくは、Glenn Fiedler の記事を参照してください。 UDP とTCP.

独自のプロトコル

独自のトランスポート プロトコルを作成したいと考えていますが、どこから始めればよいかわかりませんか? Glenn Fiedler がそれについて XNUMX つの素晴らしい記事を書いているので、あなたは幸運です。 それらの中には賢いアイデアがたくさんあるでしょう。

最初の記事 ゲームプログラマーのためのネットワーキング 2008年、XNUMX回目より簡単 ゲームネットワークプロトコルの構築 2016年。 古いものから始めることをお勧めします。

Glenn Fiedler は、UDP に基づいた独自のプロトコルを使用することを強く支持していることに注意してください。 そして、彼の記事を読んだ後、おそらく TCP にはビデオ ゲームにおいて重大な欠点があるという彼の意見を採用し、独自のプロトコルを実装したくなるでしょう。

ただし、ネットワークに慣れていない場合は、TCP またはライブラリを使用してください。 独自のトランスポート プロトコルを適切に実装するには、事前に多くのことを学ぶ必要があります。

ネットワークライブラリ

TCP より効率的なものが必要だが、独自のプロトコルを実装したり、多くの詳細を検討したりしたくない場合は、ネット ライブラリを使用できます。 それらはたくさんあります:

• 用心棒 グレン・フィードラー
• ラクネット、サポートされなくなりましたが、そのフォーク SlikeNet まだ活動しているようです。
• Eネット マルチプレイヤー FPS 用に作成されたライブラリです キューブ
• GameNetworkingソケット バルブによる

すべてを試したわけではありませんが、使いやすく信頼性が高い ENet を好みます。 さらに、初心者向けの明確なドキュメントとチュートリアルも提供されています。

トランスポートプロトコルの結論

要約すると、TCP と UDP という XNUMX つの主要なトランスポート プロトコルがあります。 TCP には、信頼性、パケット順序の保持、エラー検出など、多くの便利な機能があります。 UDP にはそのすべてが備わっているわけではありませんが、TCP はその性質上、一部のゲームでは許容できない高い遅延を持っています。 つまり、低遅延を確保するには、UDP に基づいて独自のプロトコルを作成するか、UDP 上にトランスポート プロトコルを実装し、マルチプレイヤー ビデオ ゲームに適合するライブラリを使用することができます。

TCP、UDP、ライブラリのいずれを選択するかは、いくつかの要因によって決まります。 まず、ゲームのニーズから考えます。低遅延は必要ですか? 次に、アプリケーション プロトコルの要件から、信頼できるプロトコルが必要ですか? 次のパートで説明するように、信頼性の低いプロトコルが非常に適したアプリケーション プロトコルを作成することが可能です。 最後に、ネットワーク エンジン開発者の経験も考慮する必要があります。

ヒントが XNUMX つあります。

• すべてのコードを書き直さずにトランスポート プロトコルを簡単に置き換えられるように、アプリケーションの残りの部分からトランスポート プロトコルを可能な限り抽象化します。
• 過度に最適化しないでください。 ネットワーキングの専門家ではなく、カスタムの UDP ベースのトランスポート プロトコルが必要かどうかわからない場合は、TCP または信頼性を提供するライブラリから始めて、パフォーマンスをテストして測定できます。 問題が発生し、その原因がトランスポート プロトコルにあると確信できる場合は、独自のトランスポート プロトコルを作成する時期が来るかもしれません。

この部分の最後に、次の内容を読むことをお勧めします。 マルチプレイヤー ゲーム プログラミングの概要 Brian Hook。ここで説明するトピックの多くをカバーしています。

アプリケーションプロトコル

クライアントとサーバー間でデータを交換できるようになったので、どのデータをどの形式で転送するかを決定する必要があります。

古典的なスキームでは、クライアントが入力またはアクションをサーバーに送信し、サーバーが現在のゲーム状態をクライアントに送信します。

サーバーは完全な状態ではなく、プレーヤーの近くにあるエンティティを含むフィルタリングされた状態を送信します。 彼がこれを行う理由は XNUMX つあります。 まず、全体の状態が大きすぎて高周波数で送信できない可能性があります。 第 XNUMX に、ゲーム ロジックのほとんどはゲーム サーバー上でシミュレートされるため、クライアントは主にビジュアル データとオーディオ データに関心があります。 第三に、一部のゲームでは、プレイヤーはマップの反対側の敵の位置などの特定のデータを知る必要がありません。それがなければ、パケットを嗅ぎ分けて敵を倒すためにどこに移動すればよいかを正確に知ることができるからです。

連載

最初のステップは、送信したいデータ (入力またはゲーム状態) を送信に適した形式に変換することです。 このプロセスはと呼ばれます 連載化.

JSON や XML など、人間が判読できる形式を使用するというアイデアがすぐに思い浮かびます。 しかし、これは完全に非効率であり、チャネルの大部分が無駄に占有されてしまいます。

代わりに、よりコンパクトなバイナリ形式を使用することをお勧めします。 つまり、パケットには数バイトしか含まれません。 ここで問題を考慮する必要があります バイトオーダー、コンピューターによって異なる場合があります。

データをシリアル化するには、次のようなライブラリを使用できます。

• フラットバッファ グーグル
• キャプテン・プロト 砂嵐
• 穀物 シェーン・グラントとランドルフ・ボーヒーズ

ライブラリがポータブルなアーカイブを作成し、エンディアンを考慮していることを確認してください。

別の解決策は、これを自分で実装することですが、特にコードでデータ中心のアプローチを使用している場合は、それほど難しくありません。 さらに、ライブラリの使用時に常に可能であるとは限らない最適化を実行できるようになります。

Glenn Fiedler はシリアル化について XNUMX つの記事を書きました。 パケットの読み取りと書き込み и 連載戦略.

圧縮

クライアントとサーバー間で転送されるデータの量は、チャネルの帯域幅によって制限されます。 データ圧縮により、各スナップショットでより多くのデータを転送したり、リフレッシュ レートを高めたり、単に帯域幅要件を軽減したりすることができます。

ビットの梱包

最初の手法はビット パッキングです。 これは、目的の値を記述するために必要なビット数を正確に使用することにあります。 たとえば、16 の異なる値を持つことができる列挙型がある場合、バイト全体 (8 ビット) の代わりに 4 ビットだけを使用できます。

Glenn Fiedler が記事の後半でこれを実装する方法を説明しています。 パケットの読み取りと書き込み.

ビット パッキングは、次のセクションで説明する離散化で特に効果的に機能します。

サンプリング

サンプリング 値をエンコードするために可能な値のサブセットのみを使用する非可逆圧縮技術です。 離散化を実装する最も簡単な方法は、浮動小数点数を丸めることです。

Glenn Fiedler が (再び!) 記事で実際に離散化を適用する方法を示しています スナップショットの圧縮.

圧縮アルゴリズム

次の技術は可逆圧縮アルゴリズムです。

私の意見では、知っておくべき最も興味深いアルゴリズムを XNUMX つ紹介します。

• ハフマン符号化 事前に計算されたコードを使用すると、非常に高速で良好な結果が得られます。 これは、Quake3 ネットワーク エンジンでパケットを圧縮するために使用されました。
• ZLIB は、データ量を決して増加させない汎用圧縮アルゴリズムです。 どうやって見ることができますか ここで、さまざまな用途に使用されています。 状態を更新する場合は、冗長になる可能性があります。 ただし、アセット、長いテキスト、または地形をサーバーからクライアントに送信する必要がある場合には便利です。
• ランレングスのコピー はおそらく最も単純な圧縮アルゴリズムですが、特定の種類のデータに対しては非常に効率的であり、zlib の前の前処理ステップとして使用できます。 これは、多くの隣接する要素が繰り返されるタイルまたはボクセルで構成される地形を圧縮するのに特に適しています。

デルタ圧縮

最後の圧縮技術はデルタ圧縮です。 それは、現在のゲーム状態とクライアントが受信した最後の状態との間の差異のみが送信されるという事実にあります。

これは、Quake3 ネットワーク エンジンで初めて使用されました。 その使用方法を説明する XNUMX つの記事を次に示します。

• Quake3 ネットワーキング モデル ブライアン・フック
• Quake 3 ソースコードレビュー: ネットワークモデル ファビアン・サングラース [翻訳 Habré に関する記事、セクション「ネットワーク モデル」を参照]

Glenn Fiedler も記事の後半でこれを使用しました。 スナップショットの圧縮.

Шифрование

さらに、クライアントとサーバー間の情報の送信を暗号化する必要がある場合があります。 これにはいくつかの理由があります。

• プライバシー/機密性: メッセージは受信者のみが読み取ることができ、他のネットワーク スニファーはメッセージを読み取ることができません。
• 認証: プレーヤーの役割を果たしたい人は、自分のキーを知っている必要があります。
• チートの防止: 悪意のあるプレイヤーが独自のチート パッケージを作成することははるかに困難になります。暗号化スキームを複製し、キー (接続ごとに変更される) を見つける必要があります。

これにはライブラリを使用することを強くお勧めします。 使用することをお勧めします リブナトリウム、特にシンプルで優れたチュートリアルがあるためです。 特に興味深いのは、次のチュートリアルです。 鍵交換これにより、新しい接続ごとに新しいキーを生成できます。

アプリケーションプロトコル: 結論

これでアプリケーション プロトコルは終了です。 圧縮は完全にオプションであり、圧縮を使用するかどうかの決定はゲームと必要な帯域幅によってのみ決まると私は考えています。 私の意見では、暗号化は必須ですが、最初のプロトタイプでは暗号化なしでも問題ありません。

アプリケーションロジック

クライアントで状態を更新できるようになりましたが、レイテンシーの問題が発生する可能性があります。 プレイヤーは入力を行った後、サーバーからのゲーム状態の更新を待って、それが世界にどのような影響を与えたかを確認する必要があります。

さらに、XNUMX つの状態更新の間、世界は完全に静的です。 状態の更新レートが低い場合、動きが非常にぎくしゃくしてしまいます。

この問題の影響を軽減するための手法がいくつかあります。それらについては次のセクションで説明します。

遅延平滑化技術

このセクションで説明するすべてのテクニックは、このシリーズで詳しく説明されています。 ペースの速いマルチプレイヤー ガブリエル・ガンベッタ。 この素晴らしい記事シリーズを読むことを強くお勧めします。 これらのテクニックが実際にどのように機能するかを確認するためのインタラクティブなデモも含まれています。

XNUMX つ目の手法は、サーバーからの応答を待たずに、入力結果を直接適用することです。 いわゆる クライアント側の予測。 ただし、クライアントがサーバーから更新を受信した場合、その予測が正しかったことを検証する必要があります。 そうでない場合は、サーバーは権威主義的であるため、サーバーから受信した内容に従って状態を変更するだけで済みます。 この手法は Quake で初めて使用されました。 詳細については記事をご覧ください。 Quake Engineのコードレビュー ファビアン・サングラース [翻訳 ハブレについて]。

XNUMX 番目のテクニック セットは、XNUMX つの状態更新間の他のエンティティの移動をスムーズにするために使用されます。 この問題を解決するには、内挿と外挿という XNUMX つの方法があります。 補間の場合、最後の XNUMX つの状態が取得され、一方から他方への遷移が表示されます。 欠点は、クライアントは常に過去に何が起こったかを確認するため、遅延のごく一部が発生することです。 外挿とは、クライアントが受け取った最後の状態に基づいて、エンティティが現在どこにあるべきかを予測することです。 欠点は、エンティティが移動方向を完全に変えると、予測と実際の位置の間に大きな誤差が生じることです。

最後の最も高度なテクニックは、FPS でのみ有効です。 ラグ補正。 ラグ補正を使用する場合、サーバーはクライアントがターゲットで起動するときの遅延を考慮します。 たとえば、プレイヤーが画面上でヘッドショットを実行したが、実際には遅延によりターゲットが別の場所にいた場合、遅延を理由にプレイヤーの殺害の権利を否定するのは不公平です。 そのため、サーバーはプレーヤーが射撃した時点まで時間を巻き戻し、プレーヤーが画面上で見たものをシミュレートし、射撃とターゲットの間の衝突を確認します。

Glenn Fiedler は (いつものように!) 2004 年に記事を書きました ネットワーク物理学 (2004)で、彼はサーバーとクライアント間の物理シミュレーションの同期の基礎を築きました。 2014 年に彼は新しい記事シリーズを執筆しました ネットワーク物理学では、物理シミュレーションを同期するための他のテクニックについて説明しました。

Valve の wiki にも XNUMX つの記事があります。 ソース マルチプレイヤー ネットワーキング и クライアント/サーバーのゲーム内プロトコルの設計と最適化におけるレイテンシー補償方法 遅延補償の対応。

チート防止

チート防止テクニックは主に XNUMX つあります。

まず、不正行為者が悪意のあるパケットを送信することが困難になります。 上で述べたように、これを実装する良い方法は暗号化です。

次に、権限のあるサーバーはコマンド/入力/アクションのみを受信する必要があります。 クライアントは、入力を送信する以外にサーバー上の状態を変更できません。 その後、サーバーは入力を受け取るたびに、入力を適用する前にその有効性をチェックする必要があります。

アプリケーション ロジック: 結論

クライアントとサーバーが同じマシン上で実行されている場合でも、悪い条件でゲームの動作をテストできるように、高遅延と低リフレッシュ レートをシミュレートする方法を実装することをお勧めします。 これにより、遅延平滑化技術の実装が大幅に簡素化されます。

その他の役立つリソース

ネットワーク モデルに関する他のリソースを調べたい場合は、ここで見つけることができます。

• グレン・フィードラーのブログ — 彼のブログ全体を読む価値があります。そこには多くの優れた記事が含まれています。 それは ネットワーク技術に関するあらゆる記事を集めました。
• 素晴らしいゲーム ネットワーキング M. Fatih MAR 著は、ビデオ ゲーム ネットワーキング エンジンに関する記事とビデオの包括的なリストです。
• В wiki サブレディット r/gamedev 役立つリンクもたくさんあります。

出所： habr.com