Microsoft DirectX 8.0 (Visual Basic) |
転送トポロジ、音声トポロジ、伝送制御、および 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 プロセッサが最低限必要になる。