ワーキング セットについてのガイドライン

ワーキング セットについてのガイドライン

転送トポロジ、音声トポロジ、伝送制御、および CODEC の最適な構成は、開発するゲームの種類やジャンル、1 つのゲーム セッションに参加するプレーヤの数、およびターゲットとなる接続の種類に基づいて判断する。

ボイス セッションに参加するプレーヤの数は、ゲーム セッションに実際に参加するプレーヤの数と等しいとは限らないので、注意が必要である。たとえば、対面型のシューティング ゲームを開発する場合は、ゲーム内で期限付きのパワーアップ アイテムとして提供される無線機や発信機で、音声通信を表現できる。無線機として表現すると、車内や移動しない司令部内にある無線機に、通信を制限できるという利点もある。

2 番目の例として、同時に 4 人がプレーするオンライン ブリッジ ゲームについて考えよう。ワーキング セットが小さいので、ピアツーピア ネットワーク トポロジ上でピアツーピア音声トポロジを転送する方法が適している。この小さなワーキング セットでは、伝送制御のモードとして、音声をアクティブにすることもできる。ピアツーピア音声トポロジは、実装が容易で、プレーヤがサーバーの役割をしないでよい。4 人のプレーヤ全員が Voxware SC6 CODEC を使うと、最大帯域幅は、CODEC のプロトコル オーバーヘッドを含め、スピーチ ストリームあたり 4.2 Kbps となる。さらに、ゲーム データに必要な帯域幅が無視できる程度に小さいとすると、話者それぞれの流出における最大の帯域幅要件は、残り 3 人へのストリーム 3 つ (つまり 12.6 Kbps) となる。また、流入における帯域幅は、どのクライアントでも 0 (残り 3 人が黙っているとき) ～ 12.6 Kbps (残り 3 人全員が話しているとき) となる。CPU は、エンコードのために 8 %、デコードのために 0 ～ 12 % が必要である。この結果、最悪の場合の要件は 25.2 Kbps となる。したがって、各プレーヤは 14,400 ボー以上のモデムを使う必要がある。

もう 1 つの例として、32 人までのプレーヤが 2 チームに分かれて戦うチーム対戦型コンバット ゲームについて考える。ゲーム データには、28,800 ボーのモデムが必要なものとする。この例では、プレーヤ数が多いので、転送サーバー音声トポロジが適している。ここでも、プレーヤ全員が Voxware SC6 CODEC を使うとすると、最大帯域幅は前述のブリッジ ゲームと同様に 4.2 Kbps となる。この例では、話しているときの送信は 4.2 Kbps となり、チームからの受信は最大 12.6 Kbps となる。CPU は、Pentium 200 であれば、エンコードのために 最大 8 %、受信のために最大 12 % が必要である。したがって、ゲーム データのための 28.8 Kbps と、大きくなった流入帯域幅 12.6 Kbps のために、各プレーヤは 41,400 ボー以上のモデムを使う必要がある。

転送サーバー自体にとって最悪のケースは、32 人が全員同時に話す場合であり、このときには 134.4 Kbps が必要になる。サーバーの CPU 使用量はごく限られている。これは、サーバーがストリームのエンコード/デコードを行わないためである。サーバーはストリームをリダイレクトするに過ぎない。通常は、16 人が同時に話すものとして、67.2 Kbps が必要になる。

ミキシング サーバー音声トポロジを選ぶ場合と、転送サーバー音声トポロジを選ぶ場合の差異を説明するため、ここでも前述のプレーヤ 32 人による対戦型コンバット ゲームについて考える。ミキシング サーバー音声トポロジを使うと、各クライアントでは、送信のために 4.2 Kbps、受信のために 4.2 Kbps が必要になる。最悪の場合の帯域幅要件は、8.4 Kbps に下がる。また、CPU 要件は、200 MHz で動作する Pentium プロセッサの 12 % である。この結果、クライアントのモデム要件も 33,600 ボーに下がる。

サーバー側では、CPU 負荷が変わる。サーバーは、流入するストリームをすべてデコードおよび再エンコードし、必要に応じてストリームのミキシングも行う。ストリームをミキシングするための CPU 負荷は、比較的低いので無視する。最悪のケースは、同時に 32 のストリームをデコード/エンコードする場合である。この場合、音声サービス単独でも、400 MHz で動作する Pentium II プロセッサが最低限必要になる。