RTS同期エンジンと非同期履歴

StarCraftやSupreme Commanderのようなゲームをプレイし、「同期が検出されませんでした」などのエラーメッセージが表示された後、ゲームが終了したことがありますか？ なぜこれが起こっているのか知りたいですか？ これは、リアルタイム戦略でよく使用されるゲームエンジンアーキテクチャの遺産です。 ¹



この分野での私の経験は、Gas Powered GamesでSupreme Commanderエンジンを使用して得られたものです。 ベータテスト中に、StarcraftとWarcraft 3にも同期の問題があったため、一般に同じように機能すると言えます。 簡単にするために、最高司令官エンジンについて説明します。 他のゲームとの類似点を見つけることは、読者のための演習として残します:)

必要条件

まず、ゲームの要件は何ですか？ これをお知らせするために、Supreme Commander（2006）の最初の部分のビデオがあります。







このゲームは、インターネットを介したネットワークゲームで8人のプレイヤーをサポートする必要があり、各軍には数百のユニットがあります。 これらは1ゲームで数千単位です。 ヨシュキン猫。 シューティングゲームの典型的なクライアント/サーバーアプローチは、ここでは明らかに適切ではありません。 ユニットが非常に多いため、ほとんどのプレイヤーが使用できるよりもはるかに多くの帯域幅が必要になります。



では、どのようにタスクにアプローチできますか？..

同期エンジンアーキテクチャ

... 1ステップで完全に同期化されたアーキテクチャで！ 同期エンジンで

各クライアントは同じコードを同じ速度で実行します。 少し考えてみてください。 Supreme Commander 8プレイヤーゲームでは、各プレイヤーは同じ状態のゲームを保存し、同じコードを実行します。 ユニットの状態（位置、健康など）に関する情報をネットワーク経由で送信する代わりに、プレイヤー²が入力したチームのみを送信できます。 すべてのプレイヤーが同じゲーム状態であり、同じ入力が処理される場合、結果の状態も同じである必要があります。



同じ原理で、シューティングゲームを含むトリガーされたゲームの繰り返しが動作します。 リプレイファイルのサイズがなぜこんなに小さいのか疑問に思ったことはありませんか？ これは、このようなファイルにはユーザー入力のみが保存されるためです。 次に、ゲームを開始し、リプレイファイルから入力し、元のゲームと同じ結果を取得します。 そのため、ゲームを更新するときに繰り返しファイルが動作を停止することが多く³ 、巻き戻しできないことがよくあります⁴ 。 ちなみに、同じ理由で、多くの戦略はゲーム中の新しいプレイヤーの接続をサポートしていません-新しいプレイヤーを接続するには、ゲームの完全な状態を彼に転送する必要があります。 3000単位のゲームの場合、これには時間がかかりすぎます。

レベル

最初にビデオを見てください。 ゲームは毎秒いくつのフレームで進行していると思いますか？ 正解は10 fpsです。 「待って？ 彼女はずっと滑らかに見えます！ はい-同時にいいえ。 一般的に、ゲームは2つの周波数を同時に使用します。



SupComエンジンは、シミュレーションとユーザーという2つのレベルを使用します。 シミュレーションレベルは、10フレーム/秒の固定周波数で実行されます。 「本物のゲーム」と見なすことができます。 すべてのユニット、すべてのAI、およびすべての物理学は、毎秒10回実行されるSimTick関数で更新されます。 各SimTickは100ミリ秒未満で動作するはずです。そうしないと、ゲームはスローモーションで動作します。 マルチプレイヤーゲームでは、一部のプレイヤーが100ミリ秒でSimTickを完全に処理できなかった場合、他のすべてのプレイヤーは停止し、遅れているプレイヤーを待つ必要があります。



ユーザーレベルはフルフレームレートで実行されます。 このレベルは排他的にグラフィックと見なすことができます。 ユーザーインターフェイス、レンダリング、アニメーション、さらにユニットの位置も60 fpsで計算できます。 各UserTickは、デルタ中に更新されます。デルタは、ゲームの状態を中間値（たとえば、中間ユニットの位置）に補間するために使用されます。 メインエンジンコアはかなり低い周波数で動作しますが、ゲームがスムーズに表示およびプレイできるのはこのためです。

決定論

「ちょっと待って！」賢い読者は叫ぶだろう。 「各プレイヤーがゲームの状態を個別に更新する場合、これはゲームのシミュレーションが完全に決定論的であることを意味しますか？」 これを達成するのは難しいですか？ はい 特に今日のマルチスレッドの世界では。



エンジンの開発者にとって多くのトラブルが浮動小数点数をもたらします。 このトピックを詳細に説明する代わりに、Glenn Fielder- Floating Point Determinismによる素晴らしい投稿へのリンクを提供します。



彼へのコメントの中で、エリヤは最高司令官について議論しています。 プロセッサがIEEE754標準に厳密に従うことを強制すると、ほとんどの問題が解決します。 しかし、そのような解決策は生産性の低下を意味し、ゲームは不確実な結果で計算を実行できません（ただし、これはとにかく行われるべきではありません）。

内部遅延

同期マルチプレイヤーゲームには、いくつかの欠点があります。 巨大で完全に決定的なシミュレータを作成する複雑さに加えて、入力処理に遅延があります。 マルチプレイヤーゲームの各ユーザーが、同じ入力を使用してゲームの同じ状態を更新する方法については既に書きました。 これは、すべてのクライアントがそれを処理するシミュレーションのステップに同意した場合にのみ、新しい入力が処理されることを意味します！



たとえば、A、B、Cの3人のプレイヤーがSimTickを起動します[1]。 この時点で、プレイヤーAはユニットに攻撃するコマンドを与えます。 UIはすぐに応答を表示します。 UserTickは毎秒60回実行されます。 シングルプレイヤーゲームでは、このコマンドはSimTick [2]で処理されます（遅延0〜100ミリ秒）。 ただし、3人のプレーヤー全員が同じ結果を得るには、同じSimTick実行でチームを処理する必要があります。 SimTick [2]でコマンドを処理しようとする代わりに、プレーヤーAはSimTick [4]で実行するデータと共にネットワークパケットをプレーヤーBとCに送信します（遅延200〜300ミリ秒）。 これにより、すべてのプレイヤーにチームを獲得する時間が与えられます。 入力情報が受信されなかったり、時間通りに確認されなかったりすると、ゲームがクラッシュする可能性があります。 SupComでこれに使用されたメカニズムはわかりませんが、判明した場合はこの投稿を更新します。 入力を処理する必要があるSimTick実行の特定の数は、p2p ⁵トポロジを使用して動的に決定されます。



ユーザーがクリックしてからユニットが反応するまでの遅延は、常に少なくとも0〜100ミリ秒（次のSimTick）です。 これはいくつかの方法でマスクできます。 インターフェースは通常すぐに反応します-何かが点滅し、適切な音が聞こえます：「Life for Ayur！」または「Zug Zug」。



シングルプレイヤーゲームではこれは正常ですが、マルチプレイヤーバトルでは遅延が顕著になり始め、数百ミリ秒に達します。 UserTickでインスタントレスポンスアニメーションを試してみたかったのです。 たとえば、移動するコマンドを指定すると、ユーザーレベルはユニットをゆっくりと移動し始め、コマンドが実際に実行されるときにシミュレーションで示されるポイントの方向に移動を「ミックス」します。 これは、DOTAやDemigodのような「ぎくしゃくした」ゲームで非常に役立ちます。 特に処理しなければならない極端なケースが本当にあるので、私は実際に実装を取り上げませんでした。 誰かがこれを行った場合は、コメントで登録を解除してください。 :)

非同期-地獄からのバグ

ユニバースで最も難しいバグの1つは、非同期バグです。 これらはかなり邪悪な野郎です。 エンジンの主な前提は、すべてのプレイヤーが完全に同期していることです。 そうでない場合はどうなりますか？ 異なるプレイヤーのシミュレーションが異なる場合はどうなりますか？ カオス。 怒り。 苦しみ⁶ 。



SupComでは、ゲームの状態全体が1秒に1回ハッシュされます。 一部のクライアントでハッシュが一致しない場合、コンサートは終了します。 ゲームオーバー 終わり。 ウィンドウがポップアップし、「同期エラー」というメッセージが表示されます。ゲームを終了する必要があります。 SimTickの結果の一部が一致しなかったため、ゲームの状態が異なります。 シミュレーションのパスは分岐し、さらに悪化します。 ここでは回復メカニズムは提供されません。



同期外れは通常、プログラマーのエラーの結果です。 同期解除は、60分間以上続くゲームの5％で再生できます。 このようなエラーを見つけて修正するには、通常、ゲーム中にコンソールに出力されたメモリステータスのハッシュのバイナリ検索が必要です。 再生の可能性が低い非同期では、これによりコンソールに膨大な数のメッセージが表示されますが、6台のマシンがシミュレーションをできるだけ速く計算し、中断するのを待ちます。 これで十分でない場合、同期が取れていない最も一般的な理由の1つは、宣言されていない変数であると付け加えます。

デミゴッドの歴史

SupComエンジンに関する私の作業のほとんどは、Demigodでの作業中に行われました。Demigodはエンジンの修正バージョンを使用していました。







開発の最後に長い間、私に割り当てられた、まれに繰り返される非同期バグがありました。 デミゴッドでは、小さな大砲の餌の群れが地図の周りを走り回りました。 また、非常にまれなケースでは、異なるマシン上の個々のレミングの位置が数センチメートル異なりました。 無害に聞こえますが、本質的には蝶の羽ばたきであり、そこから問題のハリケーンが始まります。



このバグを修正できるかどうかわからなかったことを正確に覚えており、リードプログラマーは次のように述べています。 私はあなたを信じています。 毎朝10分間の会議があり、毎日私のレポートは短くてシンプルでした：「非同期のハント」。 ほぼ1週間の狂気の深さへの降下の後、エラーの原因を見つけました。 予告編を視聴した場合、一部のヒーローでは敵を空中に投げ出す能力を見ました。 巨大な歩行城がハンマーを下げると、ユニットが飛び回ります。 バグはパス検索システムのポインタの1つにあり、どこにもポイントしていませんでした。その理由は、着陸後にユニットが単純に姿を消したためです。



しかし、これは同期が取れなくなるほど十分ではありませんでした。 まず第一に、ユニットはいくつかの特別なスキルの1つによって殺されなければなりませんでした。 これは彼をパスファインダーから外し、宙ぶらりんのポインターを残しました。 メモリマネージャは、リモートコンポーネントのメモリを、その内容を変更せずに、リンクされた空き領域のリストに移動しました。 その後、ユニットが着陸する前に、メモリの新しい割り当てが発生する必要がありました。 この選択は、最近削除されたブロックに影響するはずです。 その後、非同期が発生しました。 ポインターをNULLに設定すると、問題が解決しました。

最終的な考え

これは、最高司令官が使用する同期エンジンの非常に短い概要でした。 私は、多くの古いゲームがほぼ同じ方法で配置されたことを知っています。 おそらく最後の世代は、特に入力遅延と戦うために、何らかの新しいトリックを使用しているでしょう。 私はStarCraft 2に同期がとれていないことを知っているので、おそらく同様に動作します。 他に見るべきゲームは、ヒーローズオブニューアースまたはリーグオブレジェンドです。 それらはSupComほど複雑ではなく、非常にスムーズに動作しますが、私はそれらを分解しませんでしたし、これに使用する方法がわかりません。

1. Haloは、Campaign Co-opモードとFirefightモードで同時ステップの同期モデルを使用します
2. SupComでは、入力はユニットグループへのコマンドとして処理されます。 移動、攻撃、防御、能力の使用などのコマンド
3. 古いデータで古いコードを実行できる場合は、古い再試行ファイルがサポートされる場合があります
4. Haloでの巻き戻しは、特定の時点でのゲームの状態を保存する「セーブポイント」を使用して行われました。 スムーズに巻き戻すことはできませんでしたが、前のセーブポイントに移動してそこから前進することはできました。 EMNIP。
5. SupComは、ピアツーピアネットワークアーキテクチャを最大限に活用します。
6. 残念ながら、Lightning Forceは付属していません