マルチプレイヤーリアルタイムゲームで交換するデータは何ですか?


8

私は趣味のプログラマーであり、現在、マルチクラフトセッションでstarcraft 2のようなリアルタイムゲームでどのデータが交換されるのか知りたいです。たくさんの検索を行いました。私はgafferongames.comが検討すべき問題の非常に良い概要を提供しているのを見つけました。

Glennの記事とコメントでは、UDP over TCPを使用する非常に強力な例を示していますが、SC2は明らかにTCPを使用しています。グリーンをQouteするには、

ゲームにTCPを使用する場合の問題は、Webブラウザーや電子メールや他のほとんどのアプリケーションとは異なり、マルチプレイヤーゲームのパケット配信にリアルタイム要件があることです。ゲームの多くの部分、たとえばプレーヤーの入力やキャラクターの位置では、1秒前に何が起こったかは関係ありません。最新のデータのみに関心があります。

したがって、彼の発言から、彼のアプローチは各フレームのすべてのユニットの完全なゲーム状態送信することだと思います。サーバーが現在のフレームでプレイヤー入力を受信しない場合、それはそのプレイヤーの幸運です。God of War:Acensionでは、彼はリードネットワーク開発者であり、これはかなりうまくいくと思います。

SC2の場合、再生機能があるため、基になるエンジンは確定的な固定タイムステップの「ユーザー入力再生マシン」であり、交換されるデータはプレーヤー入力のみです。したがって、グレンの発言はSC2とはまったく無関係です。プレーヤーの入力は重要であり、入力シーケンスはさらに重要です。SC2が200ユニット以上のゲーム状態を30〜60 FPSで送信するのは現実的ではないと思います。

質問:私は間違っている可能性がありますが、2種類のデータを特定しようとしました。他のテクニックは何ですか?あなたがするなら、ゲームをqouteするのが良いでしょう。

編集:スタークラフトネットワーキングモデルに関するこのリンクを見つけました


1
多くのゲームでTCPを使用する理由の1つは、UDPがブロックされることが多いためです。
Matsemann、2012年

回答:


12

Glennの記事とコメントでは、UDP over TCPを使用する非常に強力な例を示していますが、SC2は明らかにTCPを使用しています。

Glennは主に物理学主導のゲームについて話します。一人称シューティングゲームとドライビングゲーム。これらは、あらゆる論理ステップでの正確なユニット位置が重要であるリアルタイム戦略ゲームとは異なる要件を持っています。したがって、コミュニケーション戦略は必然的に異なります。

「リアルタイム」とは、状況によってさまざまなことを意味します。メッセージが遅れるとすべてが壊れるという点で、ゲームはリアルタイムで「難しい」ものではありません。(たとえば、原子力発電所や医療機器などとは異なり、ソフトウェアのみのシステムは処理の遅延から回復できるはずなので、ゲームがそれほど厳しいものになる理由はありません。)ゲームは本当に「ソフト」または「確定」リアルタイム。(いつものようにWikipediaでの定義。)ゲームのタイプは、情報がどれだけ速く必要か、情報を失ってそれから逃れることができるかどうかなどに違いをもたらします。TCPは多くのゲームに十分であると言って十分ですが、他のゲームでは、UDPが推奨されます。

彼のアプローチは、各フレームですべてのユニットの完全なゲーム状態を送信することだと思います。

彼は、変更されたユニットの関連するゲーム状態を再構築するのに十分な情報を送信します。

  1. 変更されていないものに関する情報を送信する必要はありません。
  2. 受信者が古い状態から新しい状態を構築するのに十分な情報を送信できる場合は、完全な状態を送信する必要はありません。(たとえば、古い状態に関連するデルタ値を送信するだけです。または、変更された状態の部分のみを送信し、残りの部分は送信しないでください。)
  3. 2つのゲームがまったく同じアルゴリズムを実行し、まったく同じデータを持っている場合は、入力を送信するだけで、受信者が効果をローカルで再シミュレーションして、新しい状態を導出できます。

ほとんどのゲームは3の基準を満たさないため、代わりに1と2を使用します。ただし、多くのRTSゲームは3を使用できます。

また、必ずしも「すべてのフレーム」である必要はありません。フレームのコンセプトも曖昧です。レンダリングのフレームですか?ロジックのバッチですか?送信されているネットワークデータのフレームですか?3つは常に1対1で整列しますか、それとも固定グラフィックレートで可変グラフィックレートを取得しますか?一部のゲーム、特にStarcraft 2のようなリアルタイム戦略ゲーム、または(タッチすると)リプレイ機能のあるゲームは、定期的なネットワーク更新(他の意味での「フレーム」と一致する場合と一致しない場合があります)によってすべてを完全なロックステップに保ちたいが、これはすべてのゲームの要件ではありません。多くのゲームは、クライアントが実行できる程度に応じて、半定期的にアップデートを送信します。

プレーヤーの入力は重要であり、入力シーケンスはさらに重要です。SC2が200ユニット以上のゲーム状態を30〜60 FPSで送信するのは現実的ではないと思います。

多くのゲームは、レンダリングフレームを必ずしも論理フレームとして扱いません。グラフィックスに60FPSが含まれている場合がありますが、1秒間に10のロジック更新しかなく、それぞれに1つのネットワーク更新を送信します。ただし、「入力の送信」メソッドを使用する場合は、1秒あたり30回のネットワーク更新でも妥当です。

私は2つの可能なタイプのデータを識別しようとしました。他のテクニックは何ですか?あなたがするなら、ゲームをqouteするのが良いでしょう。

明確なテクニックがあることはそれほど多くありませんが、システムに対するいくつかの異なる制約があり、各制約の重要性はゲームごとに異なります。したがって、自分に合ったシステムを選択する必要があります。

  • 少数のユニットで、ユーザー入力を介して迅速かつ不規則に移動します。レイテンシは敏感であり、システム間の正確な同期は重要ではありません-信頼性のないプロトコル(UDPなど)を介して位置をブロードキャストし、最大速度を取得します。すぐ入ります。物理をローカルでシミュレートしてレンダリング品質を向上させますが、新しい情報が到着したときに位置を修正します。シューティングゲームやドライビングゲームに最適です。
  • 多くのユニットですが、ほとんどは無関係であり、ゆっくりと移動します-受信者の近くのユニットの更新のみを送信し、完全な状態ではなく変更として送信し、比較的頻繁に送信せず、信頼性の高いプロトコル(TCPなど)を介して送信します。見逃された更新を処理する方法について心配する。MMOに適しています。
  • 多くのユニットは、以前のユーザー入力に基づいてAIによって移動され、システム間の正確な同期が非常に重要です。信頼できるプロトコルを介してタイムスタンプ付きのユーザー入力を送信し、ローカルで再シミュレーションして、ゲームアルゴリズムの状態を同期させます。RTSやターンベースのゲームに適しています。

4

知っておく必要のある主なテクニックは、「1500アーチャー」テクニックです。Age of Empiresでよく使用されていましたが、(オープンソース)OpenTTD(Transport Tycoon Deluxeベース)などの他のゲームでも使用されています。

明確にするために:この手法を使用すると、ゲームのプレイ中にゲームの状態を送信する必要はありません。ゲーム全体の状態は、最初の起動、接続、および再同期時に送信されます。定期的に送信する必要があるのは、時報と同期チェックだけです。プレイヤーコマンドのみが通常クライアントからサーバーに、そしてその逆に送信されます。プレーヤーがコマンドを実行しない場合(ほとんどのティックの場合)、データを送信する必要はありません。

このリンクを参照してください。

http://www.gamasutra.com/view/feature/3094/1500_archers_on_a_288_network_.php

更新:回答では、Kylotanはこれを「テクニック3」と呼んでいます。


うん、いつもの1500アーチャーのリンクを忘れたので、提供してくれてありがとう。
カイロタン2012年
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.