Megapack: Factorio が 200 人のプレイヤーによるマルチプレイヤーの問題をどのように解決したか

今年のXNUMX月に選手として出場しました。 キャサリンオブスカイ MMO イベント。 プレイヤーの数が一定の数に達すると、数分ごとに何人かが「脱落」することに気づきました。 あなたにとって幸運なことに（私にとってはそうではありませんでしたが）、私もそうしたプレイヤーの一人でした 毎回接続が良好であっても。 私はこれを個人的な課題として捉え、問題の原因を探し始めました。 XNUMX 週間のデバッグ、テスト、修正を経て、最終的にバグは修正されましたが、その道のりはそれほど簡単ではありませんでした。

マルチプレイヤー ゲームの問題は追跡するのが非常に困難です。 これらは通常、非常に特殊なネットワーク パラメーターおよび非常に特殊なゲーム状態 (この場合は 200 人を超えるプレイヤー) で発生します。 また、問題を再現できたとしても、ブレークポイントを挿入するとゲームが停止し、タイマーが狂い、通常はタイムアウトにより接続がタイムアウトするため、問題を適切にデバッグすることはできません。 しかし、忍耐力と、という素晴らしいツールのおかげで、 不器用な 何が起こっているのかを理解することができました。

つまり、バグとレイテンシー状態シミュレーションの不完全な実装が原因で、クライアントは、400 クロック サイクルで約 200 のゲーム エンティティのプレーヤーの入力選択アクションで構成されるネットワーク パケットを送信しなければならない状況に陥ることがありました (これを「メガパケット」と呼びます)。 サーバーは、これらの入力アクションをすべて正しく受信するだけでなく、他のすべてのクライアントに送信する必要があります。 クライアントが XNUMX 社ある場合、これはすぐに問題になります。 サーバーへのリンクがすぐに詰まり、パケット損失と再要求パケットのカスケードが発生します。 入力アクションが遅延すると、さらに多くのクライアントがメガパケットを送信することになり、雪崩がさらに大きくなります。 幸運なクライアントはなんとか回復しますが、他のクライアントはすべて落ちてしまいます。


この問題は非常に根本的なもので、修正するのに 2 週間かかりました。 かなり技術的なので、以下で重要な技術的な詳細を説明します。 しかしまず、0.17.54 月 4 日にリリースされたバージョン XNUMX 以降、一時的な接続の問題はあったものの、マルチプレイヤーはより安定しており、遅延の非表示のバグは大幅に減少しています (ブレーキやテレポートが減少しています) ことを知っておく必要があります。 また、戦闘の遅延を非表示にする方法を変更しました。これにより、遅延が少しスムーズになることを願っています。

マルチプレイヤー メガ パック - 技術的な詳細

簡単に言うと、ゲームのマルチプレイヤーは次のように機能します。すべてのクライアントは、プレイヤーの入力 (「入力アクション」と呼ばれる) のみを送受信することによって、ゲームの状態をシミュレートします。 入力アクション）。 サーバーの主なタスクは転送です。 入力アクション そして、すべてのクライアントが同じサイクルで同じアクションを実行するようにします。 詳細については、投稿をご覧ください。 FFF-149.

サーバーはどのようなアクションを実行するかを決定する必要があるため、プレーヤーのアクションは次のパスに沿って移動します: プレーヤーのアクション -> ゲーム クライアント -> ネットワーク -> サーバー -> ネットワーク -> ゲーム クライアント。 これは、プレーヤーの各アクションは、ネットワークを往復するパスを作成した後にのみ実行されることを意味します。 このため、ゲームが非常に遅いように見えたため、ゲームにマルチプレイヤーが登場した直後に、遅延を隠すメカニズムが導入されました。 レイテンシー隠蔽は、他のプレイヤーのアクションやサーバーの意思決定を考慮せずに、プレイヤーの入力をシミュレートします。

Factorio にはゲーム状態があります ゲームの状態 マップ、プレーヤー、エンティティ、その他すべての完全な状態です。 これは、サーバーから受信したアクションに基づいて、すべてのクライアントで決定的にシミュレートされます。 ゲームの状態は神聖なものであり、サーバーや他のクライアントと異なる状態になり始めると、非同期が発生します。

除く ゲームの状態 遅延が発生している状態です レイテンシー状態。 これには、メイン状態の小さなサブセットが含まれています。 レイテンシー状態 これは神聖なものではなく、プレイヤーからの入力に基づいて将来のゲームの状態がどのようになるかを示すものにすぎません。 入力アクション.

これを行うために、生成されたファイルのコピーを保存します。 入力アクション 遅延キューにいます。

つまり、クライアント側のプロセスの最後では、次のような図になります。

1. 申し込み 入力アクション すべてのプレイヤーに ゲームの状態 これらの入力アクションがサーバーから受信された方法。
2. 遅延キューからすべてを削除します 入力アクション、サーバーによれば、すでに適用されています ゲームの状態.
3. 消去 レイテンシー状態 とまったく同じになるようにリセットします ゲームの状態.
4. 遅延キューからのすべてのアクションを レイテンシー状態.
5. データに基づいて ゲームの状態 и レイテンシー状態 ゲームをプレーヤーにレンダリングします。

これすべてが小節ごとに繰り返されます。

難しすぎる？ リラックスしないでください、それだけではありません。 信頼性の低いインターネット接続を補うために、次の XNUMX つのメカニズムを作成しました。

• スキップされたティック: サーバーが判断したとき 入力アクション 試合の合間に処刑されますが、受け取らなかった場合は 入力アクション 一部のプレイヤー（たとえば、遅延が増加したため）、彼は待つことはありませんが、このクライアントに「あなたの意見を考慮していませんでした」と通知します。 入力アクション, 次の小節に追加してみます。 これは、XNUMX 人のプレイヤーの接続 (またはコンピューター) の問題により、他のプレイヤーのマップ更新が遅くならないようにするために行われます。 注目に値するのは、 入力アクション 無視されるのではなく、単に延期されるだけです。
• 完全な往復遅延: サーバーは、各クライアントのクライアントとサーバー間の往復遅延がどの程度であるかを推測しようとします。 5 秒ごとに、必要に応じて (接続の過去の動作に応じて) クライアントと新しい遅延についてネゴシエートし、それに応じて往復遅延を増減します。

これらのメカニズム自体は非常に単純ですが、組み合わせて使用​​すると (接続の問題でよく発生します)、コード ロジックの管理が難しくなり、多くのエッジ ケースが発生します。 さらに、これらのメカニズムが機能する場合、サーバーと遅延キューは特別な機能を正しく実装する必要があります。 入力アクション と呼ばれる 次のティックで移動を停止。 このおかげで、接続の問題が発生した場合、キャラクターは自力で走ることはできません（電車の下など）。

ここで、エンティティの選択がどのように機能するかを説明する必要があります。 伝達されるタイプの XNUMX つ 入力アクション エンティティの選択状態の変化です。 これにより、プレイヤーがどのエンティティ上にマウスを移動したかが全員に通知されます。 ご覧のとおり、これはクライアントから送信される最も頻繁な入力アクションの XNUMX つであるため、帯域幅を節約するために、占有スペースができるだけ少なくなるように最適化しました。 これは次のように実装されます。各エンティティが選択されると、ゲームは絶対的な高精度のマップ座標を保存する代わりに、前の選択からの低精度の相対オフセットを保存します。 マウスの選択は通常、前の選択に非常に近い位置で行われるため、これはうまく機能します。 これにより、次の XNUMX つの重要な要件が生じます。 入力アクション 決してスキップしてはならず、正しい順序で実行する必要があります。 これらの要件が満たされるのは、 ゲームの状態。 しかし、その任務以来、 レイテンシー状態 プレーヤーにとって「見た目は十分」ではありますが、遅延状態では満足できません。 レイテンシー状態 考慮しない 多くの境界例これは、クロックのスキップと往復伝送遅延の変更に関連しています。

これがどこに向かうのかはすでに推測できます。 ついに、メガパッケージ問題の原因が見え始めました。 問題の根本は、エンティティ選択ロジックが以下に依存していることです。 レイテンシー状態、この状態には常に正しい情報が含まれているとは限りません。 したがって、メガパケットは次のように生成されます。

1. プレーヤーで接続の問題が発生しています。
2. サイクルをスキップし、往復伝送遅延を調整するメカニズムが機能します。
3. 遅延状態キューでは、これらのメカニズムは考慮されていません。 これにより、一部のアクションが途中で削除されたり、間違った順序で実行されたりして、不正な動作が発生します。 レイテンシー状態.
4. プレーヤーには接続の問題はなく、サーバーに追いつくために最大 400 サイクルをシミュレートします。
5. 各サイクルで、新しいアクションが生成され、サーバーに送信される準備が整い、エンティティの選択が変更されます。
6. クライアントは、400 を超えるエンティティ選択の変更を含むメガパケットをサーバーに送信します (また、他のアクション: 発砲状態、歩行状態などもこの問題の影響を受けます)。
7. サーバーは 400 個の入力アクションを受け取ります。 単一の入力アクションをスキップすることはできないため、すべてのクライアントにこれらのアクションを実行するように指示し、ネットワーク経由で送信します。

皮肉なことに、帯域幅を節約するように設計されたメカニズムにより、ネットワーク パケットが膨大になってしまいました。

すべての更新エッジ ケースと遅延キューのサポートを修正することで、この問題を解決しました。 かなり時間がかかりましたが、簡単なハックに頼るのではなく、最終的に正しく理解することができた価値がありました。

出所： habr.com