Platform SDK: DirectX

DirectPlay プロトコルを使用した非同期ネットワーキング

ネットワーク対応のゲーム アプリケーションを設計するときは、ネットワーキング コードのオブジェクトが、同期されたゲーム環境の基盤を多数のプレーヤーに提供する。ネットワーキング コードでは、多数の異なるネットワーク環境を処理する必要がある。これらの環境は、待ち時間、帯域幅、信頼性の程度が異なる場合がある。

DirectPlay を利用する前に、ゲーム開発者は、ネットワーク リンクの性質を判断し、ゲームを適切に適応させる必要がある。通常、開発者が採用する解決策は、送信するデータの量と頻度を最小限に抑えるというものだ。この方法は過酷な環境でもうまく機能するが、エンド ユーザーに最高のゲーム体験を提供することはできない。多くの場合は、ゲームでより多くのアップデートまたはアップデートごとの情報を送信することにより、ユーザーの体感を向上させ、ゲーム環境をより密に同期させることができる。

ネットワーク コードの目標は、利用可能な帯域幅をすべて利用してゲーム状態を更新することである。同時に、リンクの処理能力を超えてデータを速く送信することにより発生する接続のバックログを防ぐ必要がある。バックログが発生すると、待ち時間が増えたり、ゲームの同期がうまくいかなくなる。

DirectPlay プロトコルと非同期メッセージングが提供する環境では、アプリケーションのネットワーク コードが、リンクの能力を判断し、利用可能な帯域幅を最大限に活用できるように自らの動作を適応させることができる。

DirectPlay プロトコルは、受信側からのフィードバックを使用し、受信側に届いたデータ量を把握する。既存のネットワーク プロトコルと違い、DirectPlay プロトコルはフィードバックを使用することにより送信レートを正確に制御し、送信側と受信側の間でメッセージ パケットのバックログが作成されないようにすることができる。

DirectPlay プロトコルは、このフィードバックを非保証メッセージにも適用する。送信メッセージのスロットリングは、クライアント アプリケーションがバックログを作成することによりゲームに余分な待ち時間を発生させないようにするだけでなく、クライアントが自らをメッセージに適応させることを可能にする。クライアントは、送信キューを確認することにより、リンクの転送能力よりも速くデータを送信している状態や、クライアントが利用可能な帯域幅をいっぱいに使用している状態を認識することができる。これにより、クライアントは既存のリンクの能力に応じて、送信方法を調整することが可能になる。

DirectPlay プロトコルを最大限に活用するには、メッセージを非同期的に送信する必要がある (この方法の詳細については、「非同期メッセージング」を参照)。非同期的に送信されたメッセージは、制御を占有しない。メッセージを非同期的に送信すると、SendEx が戻る時点では、送信は完了していない。後で送信が完了すると、完了メッセージが受信キューに送られる。

非同期送信を利用すると、DirectPlay プロトコルは、保証付きおよび保証なしの両方のメッセージを、リンク上で同時に多数送信することができる。つまり、あるメッセージの完了を待機せずに、次のメッセージを送信できる。これにより、単一のパケットが失われたことによってリンクを使用できなくなるという事態を防ぐことができる。また、保証付きのパケットが 1 つ失われたことによってほかの保証メッセージの転送が遅れるということもなくなる。

従来、ネットワーク ゲームでは、リアルタイムのゲーム状態を転送する場合に限り、保証なしのメッセージを利用するのが一般的だった。これは、保証なしのメッセージを送信すると、通常は制御が占有されず、多数のメッセージを待ち時間なしで送信できるからである。DirectPlay プロトコルを使用すると、制御を占有しない保証メッセージを送信し、各接続に対する多数の送信を未完の状態にしておくことができる。つまり、ゲームで保証送信を利用し、なおかつ非保証送信を利用するゲームと同程度の応答性を確保できる。これにより、ゲーム状態の更新に関する設計が大幅に簡素化され、インクリメンタルな更新が可能になる。これを非保証送信で実現するのは、ほぼ不可能である。

DirectPlay プロトコルを使用するときには、以下の事項に注意する必要がある。