5

リアルタイム3Dゲーム用のC++プラグインを作成しようとしています。UDPの理論、その仕組み、長所と短所は何かをしっかりと把握していると思いますが、私の主な関心事は、パフォーマンス、スケーラビリティ、および可能性のある統計です。私はおそらく、UDP、さらにはTCPに関しては、価値のある海の低下についてしか知らないことを知っています。

質問：

特定のシナリオを考えると、一般的な専用サーバーが一度に対処できるプレーヤーの数。

今シナリオのために...

すべてのプレイヤーが「ゲームの世界」のどこにでもいることができるMMORPGゲームがあると想像してみてください。誰もが同じサーバー/サーバーハブにデータを送受信します。これは、誰もが最終的にパスが交差するときに、他のすべての人を見て対話できる必要があるためです。これはリアルタイムの一人称ゲームであるため、プレーヤーの位置は非常にタイムリーに最新である必要があります。

オンラインに1000人（または10000人）のプレーヤーがいるとしましょう...

ここでは、次の3つの主要なことが発生する必要があります。

  1. 各プレーヤーは、UDPを介してデータをゲームサーバーにストリーミングします。たとえば、1秒あたり14回の送信です。一言で言えば、このデータには、各プレーヤーが誰で、どこで、何であるかが含まれます。送信されるデータは、帯域幅の使用を最小限に抑えるために、サイズと速度が正規化および最適化されています。

  2. サーバーは、たとえば、これらのパケットを1秒間に最大1000個（架空の数字ではない）受信するため、1秒あたり14,000個のパケットを処理します。この処理フェーズには通常、中央メモリデータ構造の更新が含まれます。この場合、プレーヤーの古いx、y、z位置データは、新しい位置とタイムスタンプで更新されます。サーバー上のこのデータ構造には、ゲームの世界全体のすべてのプレーヤーのすべてのデータが含まれています。

  3. サーバー（場合によっては別のスレッド、場合によっては別のマシン）は、パケットを他のすべてのプレーヤーにブロードキャストする必要があります。これにより、サーバーは画面を更新して、マップ上に他のプレーヤーを表示できます。これも1秒間に14回発生します。（14は通常動的な数値であり、使用されているCPU容量、ビジー状態のCPU、フレームレートの低下、またはその逆に基づいて変化します）。

重要なことはこれです：プレーヤーXの場合、彼の位置の視覚範囲内の他のプレーヤーのデータのみがそのそれぞれのプレーヤーにディスパッチされます。したがって、プレーヤーYが2マイル離れている場合、彼のデータはXに送信される必要がありますが、プレーヤーZが惑星の反対側にいる場合、帯域幅を節約するために彼のデータはXにディスパッチされません。もちろん、これには、可能な限り最も効果的なインデックス作成ソリューションを使用してデータを繰り返しフィルタリングする必要があるため、もう少し処理が必要になります。

私の懸念はこれです。クライアントマシンからデータパケットを送信し、サーバーのRAMに入れ、データを更新するためのわずかな処理を実行し、他のプレーヤーに情報を選択的にブロードキャストするには時間がかかります。これは、サーバーが処理できる特定のしきい値があることを意味します。もちろん、実装の有効性、使用されているハードウェアの速度と能力、そしてもちろん、インターネット速度などの他の外部要因によって異なります。 、トラフィックおよびnr。毎秒地球に当たる太陽フレアの数...冗談です。

私は、このプロセスを経験した他の人たちから、落とし穴とは何か、そしてマルチプレイヤープラグインを作成するときに期待できる典型的なパフォーマンスを見つけようとしています。

「同じサーバーで同時にプレイする10000人に対応したい」と簡単に言うことができ、「サーバーごとに100がより現実的でありそうな数字です」と言うかもしれません。

そのため、何千ものリクエストとディスパッチを処理し、処理負荷を複数のマシンに分散するために、複数のサーバー/クラウドコンピューティングハブを考え出す必要があるかもしれないことを認識しています。したがって、データの受信のみを処理するマシンがいくつかあるかもしれません。巨大な中央ボックスは、すべての受信マシンとディスパッチマシン、そしてもちろん一連のディスパッチマシンによって何らかの形で共有されるインメモリデータベースのようなものです。

明らかに、技術的な限界があり、私はそれらが何を期待し、何であるかを本当に知りません。また、問題に追加のCPUとサーバーボックスを投入しても、必ずしも問題が解決するわけではありません。マシン間の相互通信が増えると、プロセスが少し遅くなるためです。より多くのCPUを投入すると、効果が低下し、あるしきい値でCPUの生産性が低下する可能性があると思います。

マルチプレイヤー用のP2P（Peer To Peer）を検討できますか？

一度に2500人のプレイヤーに対応できると言っているのは現実的ですか？

数年以内に10000人のプレイヤーにスケールアップすることは可能でしょうか？

この質問は非常に長いことを知っていますので、心からお詫び申し上げます。

4

5 に答える 5

2

スケーリングの質問は完全に正当です。ただし、UDPへの焦点は見当違いです。それはあなたにとって主な問題にはなりません。

その理由は、プレイヤー間の相互作用は基本的にO（N * N）の問題であるためです。一方、サーバーの帯域幅はO（N）の問題です。最新のWebサーバーがHTTPoverTCPを使用して1ギガビットイーサネットを安定化できることを考えると、UDPのオーバーヘッドが低いということは、計算が維持されている限り、UDPを使用して1ギガビットイーサネットを飽和させることができる可能性があることを意味します。

于 2009-11-02T15:29:24.963 に答える
1

スケーリングの問題は、MMOにとって最も難しい課題の1つであり、部分的に解決されたものです。ユーザー情報を追跡および更新する方法の例はたくさんあります。

ただし、歴史的にゲームは社会的なものであり、大多数の人々が中央または単一のエリアに集まる傾向があるというパターンがあります。したがって、この最悪の場合に備えて設計する必要があります。

いくつかのゲームは本当に壮大な感覚を求めており、すべてのユーザーがグループ化して一緒に束ねることを許可することは、コアデザイン要件です。このタイプのゲームでは、すべてのユーザーがまったく同じ場所にいることを計画します。他のゲームの場合、それらをより小さなグループに分割し、分割統治することができるはずです。

于 2009-11-02T15:43:31.267 に答える
1

  • マルチプレイヤー用のP2P（Peer To Peer）を検討できますか？p2pテクノロジーがゲームネットワーキングのリアルタイムの側面を処理できるとは思いません。また、通常のp2pネットワークでは、一度に数千のメンバーに接続することはありませんが、通常はいくつかのアップストリームノードに接続するため、非常にフラットなツリーというよりもグラフになります。

  • 一度に2500人のプレイヤーに対応できると言っているのは現実的ですか？単一のサーバーではありません。ただし、ユーザーを複数のサーバーに分散させることで、ゲームの世界が非常に大きい場合は、ゲームの世界内の地理的地域（大陸や国など）でユーザーをフィルタリングできます。低遅延の場合は、とにかくサーバーをユーザーの実際の場所の近くに配置する必要があります。米国に住んでいる場合はヨーロッパのサーバーでプレイせず、その逆も同様です。

  • 数年以内に10000人のプレイヤーにスケールアップすることは可能でしょうか？データのエンコードと送信の方法を最適化する方法はたくさんあります。ゲームの世界の状態のデルタのみを送信し、プレーヤーの動きをクライアント側で予測し、ネットワークレベルでブロードキャストし、サーバー側でクラウドコンピューティングを行うなど、今後数年間でさらに多くのことが行われる予定です。ゲーム業界がOnLiveのようなクラウドベースのコンピューティングプラットフォームに手を差し伸べると、その量に対処するためのより効率的なアルゴリズムとインフラストラクチャが必要であることが明らかになります。

于 2009-11-02T15:29:36.210 に答える
1

P2Pの問題は、最終的にはエンドユーザーの接続です。ISPは通常、多くのアップロードを提供しません。多くの場合、ダウンロード速度の1/10未満です。多くのユーザーがNATの背後にいるため、クライアントが接続を開始するために何らかの形式のプロキシを設定する必要があります。ユーザーの切断とパケット損失を処理する必要があります（パケットの半分をドロップする安っぽいワイヤレス上にある避けられないノードの場合）。また、クライアントをISP /場所でグループ化して、クライアント間で200ミリ秒以上のpingが発生しないようにするための優れた方法が必要になります。

IMOそれは起こるのを待っている災害のように聞こえます。よく知られているネットワークライブラリ（および従来のクライアント/サーバーアーキテクチャ）を使用して、四角い車輪を発明しようとする方がおそらく良いでしょう。更新が必要なものだけを送信します（ほとんどのMMOには、動的オブジェクトがほとんどない大きな静的ワールドが含まれていることに注意してください）。

于 2009-11-02T15:32:15.010 に答える
1

マルチプレイヤー用のP2P（Peer To Peer）を検討することはできますか？これは、未開封のままにしておくのが最適なワームの缶です。ただし、それが懸念事項である場合は、コンテンツの配布に役立つ可能性があります。

一度に2500人のプレイヤーに対応できると言っているのは現実的ですか？-確かに、しかし、それをどのように実装するかに重点が置かれています。90年代半ば、Realms of DespairやMedieviaなどのテキストゲームは、オンラインで数百人のプレーヤーを同時に処理していました。彼らは1秒間に14回すべての人にデータを送信しませんでしたが、1秒間に数回それらのプレーヤーを更新しました。それ以来、計算能力は約250倍に増加しました。思考の糧。

数年以内に10000人のプレイヤーにスケールアップすることは可能でしょうか？-帯域幅の要件を緩和して、常に1秒間に14の更新を送信するわけではない場合、またはすべてのユーザーが1台のサーバーで処理されるという要件を緩和すれば、今すぐ実行できます。「C10K問題」は10年以上前に対処されました。明らかに、FTPクライアントはリアルタイムゲームではありませんが、その一方で、スループット要件はより高くなります。より高い帯域幅と引き換えに少し余分な遅延を許容できる場合は、勝者になります。

于 2009-11-17T10:32:03.233 に答える