一部のネットワークゲームが補間を使用し、一部がリモート移動にパスファインディングを使用するのはなぜですか？

これは少々未解決の質問ですが、私は誰かが両方の正当な理由を提供してくれることを望んでいます。

両方の簡単な例：

補間モデル

クライアントが位置の更新を頻繁に受信し、リモートがこのデータの補間を使用して位置を更新するValveモデルを考えてください。

経路探索

このモデルでは、ユーザーが宛先を送信し、全員がその宛先にパスファインディングすると考えます。

どのタイプのゲームがそれぞれに適していますか？

私は2つのリアルタイムAAAネットワークゲームのネットワークコードに取り組みました。1つはスマートフォン用で、もう1つはハンドヘルドコンソール用です。

「なぜ」という質問に直接答えるために、ゲームによっては、どちらがより適しているのかを選択します。これは、ゲームのタイプだけでなく、話しているネットワークのタイプにも依存します（リンクされたアーケードキャビネットは、3Gでプレイすることを意図したゲームとは異なる条件を持っています）データを同期するためのさまざまなアプローチ！

位置データだけでなく、ネットワーク化された2つのクライアント間で同期できるほとんどすべてのタイプのデータを一般化し、検討したいと思います。

2つの可能性の代わりに、ハードアップデートとソフトアップデートのスペクトルを提案したいと思います。

• 非常にハードな更新は、データが重要な性質であるため（プレーヤーが死亡したため）、補間が適用されるデータのタイプではないため（オンラインであるため）、補間のタイプなしで、他のクライアントの状態を直ちに変更する個別のイベントですチェスゲーム、チャットメッセージなど）、またはネットワークがそれを可能にしているためです（ゲームの状態全体を毎秒60回確実に送信できる可能性のあるリンクアーケードキャビネットを考えてください）。

  この方法を使用すると、ネットワーク遅延は常に更新の遅延として表示され、キャラクターが飛び回るときに現れます。

• インター/外挿によるハード更新は、非常にハードな更新に似ていますが、データが絶えず変化するため、データを変更するたびに確実に送信することは実際上不可能です。位置と速度ベクトルを送信することを考えてください。2つのポイント間でデータを補間し、それらの後にそれを外挿できる必要があります。受信データが外挿と一致しない場合は、緊急時対応計画を立てる必要があります。位置の更新が必要なほとんどのゲームでは、この方法を使用します。

• 同期更新を伴うハードは、相互/外挿を伴うハードに似ていますが、同期を必要とすることはほとんどありません。格闘ゲームのクロックなど、相互/外挿するのが本当に簡単なデータにこれを使用する必要があります（両側に設定すると、後で再度同期する必要はありません）

• 遅延ハードアップデートはハードアップデートと似ていますが、表示されているのは過去のデータです。他の誰かと歌をプレイできる日本の多くの音楽アーケードゲームでは、実際には過去、おそらく数時間、あるいは数日前に記録されたプレーヤーデータと対戦していると思います。もちろん、このタイプの更新は、他のプレーヤーと実際にやり取りしない場合にのみ使用できます。

• ソフト更新は、計画データの送信と、すべてのホストでの計画の実行で構成されます。これが「経路探索」と呼ばれるものです。このようなデータの同期に必要なデータの量ははるかに少なくなります。数百人の敵を同期する場合など、ユーザーへのデータの表示方法に一定の不一致がある場合に、これらのタイプの更新を使用できます。

  もちろん、データ更新の計画自体も、必要に応じてハード/ソフトにすることができます。

• 非常にソフトな更新は、アクションの結果が発生するかなり前に確実に計算できるときに使用されます。結果を送信するだけで、他のクライアントはそれを再生するだけです。たとえば、一部のブラウザゲームやスマートフォンゲームでは他の人と戦うことができますが、実際の戦いは解決に数時間かかります（トラビアンのようなゲームを考えてください）。これらのゲームは、戦闘が開始された瞬間に結果を計算する可能性が非常に高く、その戦闘の結果が表示されるだけです。

  ネットワーク化されていないもう1つの例は、戦闘アニメーションを有効にしたCivilization 4です。誰かを攻撃すると、戦闘の結果がすぐに計算されますが、そのアニメーションが再生されます。戦闘がアニメートされているため、計算されていないことを保証できます。

ご覧のとおり、データを同期するには多くの方法があり、他の多くの方法を想像できると確信しています。最も単純なオンラインゲームを除き、ほとんどの場合、同期するデータの種類、ゲームの種類、さらにはネットワークの状態に応じて、これらの方法を組み合わせて使用​​します（遅延が少ない場合はハードアップデートを使用し、遅延が大きくなったときにソフト更新を行います）。

私はValveの開発プロセスに関する洞察を持っていませんので、これは純粋に私の意見ですが、

補間：プレイヤー間で敵の位置を一定に保つことが重要であるFPSなどの速いペースのゲームの方が良いと思います。補間とは、一部のパケットがドロップされたとしても（ほとんどのマルチプレーヤーFPSはTCP / IPの代わりにUDPを使用します。これにより、パケットの整合性も順序も保証されません）、画面上をスムーズに移動できます。

パス検索：時間はゲームプレイの重要な要素ではなく、アルゴリズムが再実行時に一貫したパスを検索する場合、パス検索は頻繁に送信する必要がないため、各シングルの位置を頻繁に更新する必要がないため、興味深い場合がありますエンティティ。たとえば、これはターンベースのシステムに適しているようです。ネットワーク要求の量を制限できます（1つはターンの開始時に、1つはすべてのクライアントが「正常」になるようにターンが終了したときに「状態。

繰り返しになりますが、私はネットワークゲームや大きなゲームスタジオで働いたことはありませんが、時々読んだことからそれは私がそれについて行く方法です:)

パンダパジャマの答えはかなり良いです。

基本的に問題は、複数のクライアントがお互いの状態を同じように認識できるようにするために送信できるデータの最小量と、その遅延中にクライアントが異なる状態になる可能性のあるラグをどのように処理するかです。

すべての変数が既知である場合、結果が既知であるため、すべての相互作用が事前に既知である手順で生成されるのが最も簡単です。たとえば、部屋で誰かを隔離し、処理方法を知っていて、その人にデータのセットを渡せば、結果を正確に予測できます。したがって、他のクライアントが計算を完了するまで待つことなく、他のすべてのクライアントに結果を提供できます。

しかし、彼は1つの方法について言及しませんでした。強制結果。

システムが何らかのエンティティによるアクションを予期し、他のアクションがそのアクションに依存し、他の計算がそのアクションを考慮に入れ、予想される結果ですでに前処理されている場合。その後、同期を維持するために、システム全体が停止されますが、適切な場所にない1つのエンティティはパスに正しく戻されます。

実世界の例は、適切な補償が私に送られることを確認するために保持パターンの他のすべてのエンティティです。