ネットコード

この問題に対する古典的な解決策は、遅延ベースのネットコードを使用することです。リモートプレイヤーの入力が遅れて到着すると、ゲームはローカルプレイヤーの入力をそれに応じて遅延させて、2 つの入力を同期させて同時に実行します。この追加の遅延はプレイヤーにとって邪魔になる可能性があります (特にレイテンシが高い場合) が、全体的な変化はあまり目立ちません。ただし、これらの遅延は、現在のレイテンシの急激な変動により一貫性がなくなる可能性があります。プレイヤー間のレイテンシがリモートプレイヤー用に設定されたバッファウィンドウを超えると、ゲームは待機する必要があり、画面が「フリーズ」します。これは、遅延ベースのネットコードでは、問題のフレーム内のすべてのプレイヤーからの入力を受信するまでシミュレーションを継続できないためです。^{[ 4 ]}この可変遅延は、オフラインプレイ (またはLANゲーム)と比較して一貫性がなく応答性が低いエクスペリエンスを引き起こし、格闘ゲームなどのタイミングに敏感でペースの速いジャンルではプレイヤーのパフォーマンスに悪影響を与える可能性があります。^{[ 5 ]}

以前のネットコードに代わるシステムとして、ロールバックネットコードがあります。このシステムは、オフラインゲームのように、ローカルプレイヤーの入力を即座に実行し（遅延ベースのネットコードのように遅延させません）、リモートプレイヤーの入力を待つ代わりに予測します（前のティックと同じ入力を行うと想定）。これらのリモート入力が到着すると（たとえば、45 ms 後）、ゲームは 2 つの方法で動作します。予測が正しければ、ゲームはそのまま完全に連続的に続行されます。予測が間違っていた場合は、ゲームの状態が元に戻され、修正された状態からゲームプレイが続行されます。これは、他のプレイヤーへの「ジャンプ」（例に従って 45 ms に相当）として認識されます。^{[ 1 ]}一部のゲームでは、これらの「ジャンプ」（プレイヤー間のレイテンシが増加すると、他のプレイヤーのアクションに反応する時間がますます少なくなるため、問題になる可能性がある）を隠すために、固定入力遅延とロールバックを使用するハイブリッド ソリューションを採用しています。ロールバックは、ラグスパイクやユーザーの接続の不整合に関連するその他の問題を隠蔽するのに非常に効果的です。予測が正しいことが多く、プレイヤーはそれに気づかないからです。しかし、クライアントのゲームが遅くなると（通常は過熱が原因で）、このシステムは厄介な問題を引き起こす可能性があります。リフト問題が発生し、マシン間でチケットの交換速度が不均等になる可能性があるためです。これにより、入力の速度が遅いプレイヤーのゲームプレイを中断する視覚的なグリッチが発生する一方、ゲームが遅くなったプレイヤーは、他のプレイヤーから通常の速度で入力を受け取ることで、他のプレイヤーよりも有利になります（これは片側ロールバックとして知られています）。^{[ 6 ]}この不均一な入力フロー（そして結果として不均一なフレームフローも）に対処するために、遅延したエントリがすべてのマシンに到着するまで待つ（遅延ベースのネットコードモデルと同様）などの標準的な解決策や、現在Skullgirlsで使用されているようなより独創的な解決策があります。後者は、7 フレームごとに 1 フレームを系統的に省略することで、ゲームが問題に遭遇したときにスキップされたフレームを復元し、さまざまなマシン上のゲームのインスタンスを徐々に同期させるものです。^{[ 7 ]}

ロールバックネットコードでは、ゲームエンジンが状態を元に戻せるようにする必要があり、そのためには既存の多くのエンジンに変更を加える必要があるため、このシステムの実装はAAAタイプのゲーム（通常は堅牢なエンジンと高トラフィックのネットワークを備えている）では問題が多く、コストがかかる可能性があると、『ドラゴンボール ファイターズ』のプロデューサーである広木智子氏らが指摘している。^{[ 8 ]}

このシステムはピアツーピアアーキテクチャや格闘ゲームと関連付けられることが多いが、ロールバックネットワークの形態はクライアントサーバーアーキテクチャ（例えば、データベース管理システムにある積極的なスケジューラにはロールバック機能が含まれている）や他のビデオゲームジャンルでも一般的に使用されている。^{[ 1 ]}

ゲーム（主に格闘ゲーム）にロールバックネットワークを実装するのに役立つように設計された、 MITライセンスのGGPOという人気のライブラリがあります。 ^{[ 9 ]}

オンラインゲームでは遅延は避けられず、プレイヤーの体験の質はこれに大きく左右されます（プレイヤー間の遅延が大きいほど、ゲームが入力に反応していないように感じられます）。^{[ 1 ]}プレイヤーのネットワークの遅延（これは大部分がゲームの制御外です）だけが問題なのではなく、ゲームシミュレーションの実行方法に内在する遅延も問題となります。遅延（特に高い遅延値）を隠蔽または対処するために、いくつかの遅延補償方法が使用されています。 ^{[ 73 ]}

ゲームシミュレーションの単一の更新はティックと呼ばれます。サーバー上でシミュレーションが実行されるレートは、サーバーのティックレートと呼ばれることがよくあります。これは基本的に、レンダリングシステムがない場合のクライアントのフレームレートに相当するサーバーです。^{[ 74 ]}ティックレートはシミュレーションの実行にかかる時間によって制限され、変動するティックレートによって引き起こされる不安定性を減らし、CPUとデータ伝送コストを削減するために、意図的にさらに制限されることがよくあります。ティックレートが低いと、サーバーとクライアント間のゲームシミュレーションの同期の遅延が増加します。^{[ 75 ]}一人称シューティングゲームなどのゲームのティックレートは、1秒あたり128ティック（Valorantの場合）、 1秒あたり64ティック（ Counter-Strike: Global OffensiveやOverwatchなどのゲーム）、1秒あたり30ティック（ FortniteやBattlefield Vのコンソール版など） ^{[ 76 ]} 、1秒あたり20ティック（ Call of Duty: Modern Warfare、Call of Duty: Warzone、Apex Legendsの議論の的となっているケース）の間であることが多い。^{[ 77 ] [ 78 ]}ティックレートが低いと、当然シミュレーションの精度も低下するが、^{[ 74 ]}極端に低くしたり、クライアントとサーバーのシミュレーションが著しく異なるレートで実行されている場合は、それ自体が問題を引き起こす可能性がある。

利用可能な帯域幅の量とネットワーク通信に要するCPU時間の制限のため、一部のゲームでは、重要度の低い情報の頻度と優先度を制限しつつ、特定の重要な通信を優先します。ティックレートと同様に、これは同期遅延を効果的に増加させます。ゲームエンジンは、帯域幅の使用を助けるために、特定のクライアントやゲーム世界の特定のオブジェクトに（シミュレーションの）更新を送信する回数を制限するほか、ネットワーク経由で送信される一部の値の精度を低下させる場合があります。この精度の低下は、場合によっては顕著になることがあります。^{[ 74 ] [ 79 ]}

マシン間のさまざまなシミュレーション同期エラーも「ネットワークコードの問題」という包括的な概念に含まれる可能性があります。これには、あるマシンでシミュレーションが別のマシンとは異なる進行をするバグや、ユーザーが通信されるべきだと認識しているのに通信されないバグが含まれる場合があります。^{[ 2 ]}従来、リアルタイム戦略ゲーム（ Age of Empiresなど）は、すべてのクライアントでシミュレーションがまったく同じように実行されることを前提としたロックステッププロトコルピアツーピアネットワークモデルを使用してきました。しかし、何らかの理由で1つのクライアントが同期から外れると、同期ずれが累積して回復不能になる可能性があります。^{[ 74 ] [ 80 ]}

ゲームにおけるトランスポート層プロトコルの選択（およびその管理とコーディング）も、認識されるネットワークの問題に影響を与える可能性がある。

ゲームが伝送制御プロトコル（TCP）を使用する場合、プレイヤー間の遅延が増加します。このプロトコルは、2台のマシン間の接続に基づいており、マシン間でデータの交換と読み取りが可能です。このような接続は非常に信頼性が高く、安定しており、順序立てて実装できます。しかし、このタイプのプロトコルはデータを自動的にパケットにグループ化するため（このアルゴリズム（Nagleアルゴリズム）が無効になっていない限り、一定量の情報に達するまでパケットは送信されません）、マシン間で確立された接続を介して直接送信されるため（セキュリティのために速度が犠牲になります）、高速アクションゲームに必要なネットワーク速度には適していません。また、このタイプのプロトコルは、パケットが失われたり、パケットが間違った順序で到着したり、重複して到着したりすると、応答が非常に遅くなる傾向があります。これは、リアルタイムのオンラインゲームにとって非常に有害です（このプロトコルは、このようなソフトウェア向けに設計されていません）。

ゲームが代わりにユーザーデータグラムプロトコル（UDP）を使用する場合、マシン間の接続は非常に高速になります。これは、マシン間で接続を確立する代わりに、データが直接送受信されるためです。このプロトコルは以前のものよりはるかに単純ですが、信頼性と安定性に欠け、TCPで処理されるマシン間の通信に不可欠な機能（パケットによるデータ分割、自動パケット損失検出など）を処理するために独自のコードを実装する必要があります。これによりエンジンの複雑さが増し、それ自体が問題を引き起こす可能性があります。^{[ 81 ]}