ひにけにXNA : XNA 2.0

ネットワーク　その１０　オブジェクト所有権

Yuichi Ito — Wed, 13 Feb 2008 05:48:00 GMT

クライアント/サーバーとピア・ツー・ピア型のどちらのネットワーク形態が優れているのかを議論するのが好きな人たちがいます。しかし、個人的にこの議論は間違ったものだと思います。誰が「どちらか一方のネットワーク形態を選ばなくてはいけない」と言ったんですが？私は両方の長所を活かしたハイブリット形式の大ファンです。

ネットワークプログラミングは妥協との戦いです。100%の正確さと、ラグがまったく無いという２つの状態を両立することは不可能で、トレードオフをしなければいけません。

時にはラグが多少大きくっなっても正確さをとる場合もあれば、逆に正確さを犠牲にして高いレスポンスを必要とする場合もあります。

１００万ドルの問題:　　どのマシンがどのデータを管理するか？

ゲーム内のそれぞれのデータについてのコスト/実益の分析を以下の質問に答えることでできます。

そのデータは独立したものですか、もしくはそれ以外のデータと状態を一致させる必要がありますか？
全プレイヤーがそのデータのラグに対して同等に気にする必要がありますか、それともひとりのプレイヤーが他のプレイヤーよりも気にしなければいけませんか？
そのデータのラグはどれだけ重要なものですか？ゲームデザインを変更することによって、その重要度を低くはできませんか？
データ変化を予測することはできますか？間違った予測をした場合、問題になりますか、それともエラーをスムースに訂正することができますか？

この質問の答えによって、どのようにデータを管理すればいいのかが判ります。

沢山のデータの整合性が必要な場合、それらは１台のマシンによって管理されるべき
もしひとりのプレイヤーがデータのラグに対して他のプレイヤーより気にしなくてはいけない場合、そのデータはそのプレイヤーのローカルマシンによって管理されるべき
ラグが大きな問題となる場合は、予測アルゴリズムを適用するべき
予測ミスが大きな問題となる場合は、予測アルゴリズムは適用すべきではない

１と２の質問はどのマシンがデータを管理するかの指標になり、３と４の予測アルゴリズムの適用についての質問は別々のものだということに注意

例えば:

スペースシップの移動

スペースシップを操作しているプレイヤーにとってレイテンシは重要な問題。
それぞれのマシンでスペースシップの位置が多少ずれていても、大体の位置があっているのなら問題はない。最悪ケースとしては２つのスペースシップがぶつかったときに、それぞれのマシンでは多少違った方向に跳ね返るが、ゲーム的には問題はない。
多少の予測ミスは問題にならない。間違った位置から正しい位置へと、誰にも気づかれること無く補正することができる。

結論:それぞれのスペースシップはそれぞれのローカルマシンによって管理されるべき。予測アルゴリズムを適用する。

レースの勝敗

レイテンシは特に重要ではない。あなたがゴールラインを通過してから０．５秒後に結果が表示されても大丈夫(カッコイイアニメーションやカメラワークで、このレイテンシを隠すことができる)。
それぞれのマシンでレース結果が違うのはダメ。勝者は常にひとり。
間違った予測結果は大問題。「優勝おめでとう！！」と表示されて少し経ってから「やっぱり２位でした～」と表示されるのはひどすぎる。

結論:１台のマシンがレース結果を決めるべき。予測アルゴリズムは適用しない

死亡判定

殺されたプレイヤーにとってレイテンシは重要だが、他のプレイヤーにとっては特に重要ではない。
マシン毎に違った結果になるのは問題。もし私が死んでいるのなら、他のマシンでも死んでいなくてはならない。
予測ミスは許されない。「ぐはぁ、やられたー」と叫びながら派手なアニメーションが再生され、血飛沫を撒き散らしながら地面を転がった挙句に「ぐふぅ」と事切れた数秒後に何事もなかったのように生き返るのは問題。

結論:それぞれのマシンがローカルプレイヤーの死亡判定をするべき。他のマシンは死亡判定の予測をしてはいけない。

追記:ここでは視覚的な予測を適用することができる。例えば、私のマシンがヘッドショットだと判定するが、ヘッドショットされたプレイヤーの位置が１００％確実ではないので死亡アニメーションを再生することはできない。その代わりに「ダメージを受けた」というアニメーションを再生することができ、視覚的なフィードバックを即座に得ることができる。もし、ヘッドショットを決めたプレイヤーから死亡か確定したという連絡が届いた場合は死亡アニメーションへスムースに変化させることができる。仮にこの予測が外れた場合でもダメージアニメーションをキャンセルして通常のアニメーションに戻すことができる。

ビークル(乗り物)に乗る

私は一度、キャラクターが徒歩で歩き回り、いろんなビークルに乗り降りすることができるゲームのプロトタイプ製作をしたことがありました。ビークルに乗っている間は「スペースシップの移動」の例で説明したのとまったく一緒です。ただビークルに乗ると言うのは違います。一度に複数のプレイヤーが運転することはできませんから！

この問題を解決するために、まずどのマシンがどのオブジェクトに対して所有権を持っているのかを表すデータをつくりました。これで動的にビークルの所有権の変更ができます。次にどのマシンが所有権を持っているのかを決めなければいけません。

ビークルのステート(操作、物理シム、衝突判定等)は、そのビークルを運転しているプレイヤーがいるマシンによって管理されます。それ以外に、この所有権を誰が持つべきを決める管理マシンを決めました。もしビークルに誰も乗っていない場合は、管理しているビークルの数が最も少ないマシンに所有権があります。

ビークルのとなりに立ち「乗る」ボタンを押した時に以下の処理をします。

クライアントマシンは「乗せてください」というメッセージをビークル所有権管理マシンに送ります
クライアントマシンではキャラクターがビークルに乗り込むアニメーションが再生されますが、まだ所有権がないので運転することはできません。
通常

ビークル所有権管理マシンは要求があったクライアントマシンに所有権を渡します
ビークル所有権管理マシンからの「乗って良いよ」というメッセージはキャラクターんがビークルに乗り込むアニメーションが終わるまでに届き、ビークルを問題なく運転することができます。この乗り込むアニメーションはラグを隠蔽するわけです。

二人同時に乗り込もうとしたとき

ビークル所有権管理マシンは「すまん、君は乗れん」というメッセージを一方に送ります
乗り込み要求を断られたキャラクターは乗り込みアニメーションをキャンセルしてビークルに乗り込む前の位置にもどされます。
先に乗り込み要求を申請したキャラクターはビークルを運転することができます。

ビークルを運転しているときはピア・ツー・ピア形式ですが、大事な決定をするのはクライアント/サーバー形式になっています。

アイディアとしては大事な決定を下す単一の管理マシンが全てのデータを管理する必要がないということです。マシンAはビークルの乗り降りを管理して、マシンBはパワーアップアイテムの管理、そしてマシンCはセッション終了時に誰が勝敗を決定するといった感じに管理するものを割り振ることができます。

これで私がネットワークに関して言わなければならないことの全てです。

THE END

原文:
http://blogs.msdn.com/shawnhar/archive/2008/01/03/network-object-ownership.aspx

ネットワーク　その９　究極の圧縮方法

Yuichi Ito — Tue, 12 Feb 2008 07:12:00 GMT

今まで紹介してきた狡猾な圧縮方法より効果的なデータ圧縮方法があります。それはデータ自体を送らないということです。

もちろん、まったくデータを送らないのでは相手側との同期ができません。でも、時には同期すること自体が重要ではない場合があります。

２つのルール

ゲームプレイに関連するものは同期しなければならない
殆どの物はゲームプレイに関与しない

効果音やアニメーションは殆どの場合は同期する必要がありません。もし、ネットワークを介してキャラクターが前に走って移動する場合、それぞれりマシンではその情報を元に、走るアニメーションを再生させ、そのアニメーションに合わせて靴音を鳴らすことができます。靴音が鳴るタイミングが多少ずれていてもゲームプレイには関係ないのでネットワークを介して足音を同期させる必要はありません。

ケーススタディ:MotoGPでは５%の確立で相手を抜き去った場合、抜いた相手に向かって手を振り上げるアニメーションを再生します。クラッシュした場合、ライダーが吹き飛ぶ複数のアニメーションの中からランダムで再生され、ネットワークにはどのアニメーションを再生したかという情報は送られません。

あるプレイヤーから見ると手を振り上げたアニメーションをしているように見えますが、他のプレイヤー視点からはアニメーションが再生されていないという場合があります。クラッシュシーンでライダーの転がるアニメーションはそれぞれのプレイヤーによって違うアニメーションが再生されます。

これらをネットワークを介して同期するにはネットワーク帯域が足りませんでした。しかし、これらのアニメーションはゲームプレイには関係無いものなので、誰も同期していないということには気づきませんでした。

同じように、FPS等のゲームでは撃った弾の位置、壁に当たったときにできる弾痕の位置、飛び散るガラス片や薬莢の位置を同期する必要はありません。ここでネットワークに送る情報は単に「私はゲーム内で銃を撃っている」というブーリアン(bool)の情報だけです。このシンプルな情報を元に、各マシンではそれぞれにシミュレーションを行います。多少の違いが起きても、それらの平行世界で起きている事柄がほぼ同じである限りは問題がありません。

一度、この「データをネットワークに送らなくても良いんだ」という考え方が身につくと、いろんな事ができるようになります。

ケーススタディ:Moto GPで広告看板やパイロンはコース脇に配置されています。もしバイクがこれらのものと衝突した場合、バイクと一緒に吹き飛びます。もし、ゆっくりとした速度でぶつかった場合は看板やパイロンを押し動かすことができます。

殆どのプレイヤーはレースに勝つことが目的で真剣にレースに参加しますが、中にはレースの邪魔をしようとするグリファー(訳注:オンラインゲームで嫌がらせをするプレーヤーのこと、英語ではGriefer、griefには深い悲しみ、悲痛といった意味があります)がいます。グリファー達はコースを逆走したりして、どうやったらレースをメチャクチャにできるのかを競っています。

グリファー達は広告看板やパイロンをコースの中央に動かしてバリケードを築けることに気付きました。これで真剣にレースをしているライダー達がバリケードに衝突して派手にほこりを撒き散らしながら吹き飛ぶ筈です。

でも、実際にはグリファー達の思い通りにはいきませんでした。

広告看板やパイロンの位置情報はネットワークを介して送られてはいませんでした。単に充分なネットワーク帯域が無かったからです。

以下は実際にあったことです。

あるグリファーはバイクを前後に動かしながら、ゆっくりと障害物を押し進めます

ピア・ツー・ピアを使っていたので、そのグリファーは自分のバイクの動きを完全にコントロールできます。

他のマシンでは予測アルゴリズムを使っているので、グリファーのバイクの座標は大体一緒ではありますが、完全に一緒ではありません。

グリファーのマシン上ではグリファーの思い通りに障害物はコースの真ん中へ移動します。

他のマシンでは最初の押しが少しだけ左にずれました。この段階では障害物の位置はグリファーが移動させた位置に近いですが一致している訳ではありません。更にグリファーが障害物を押し進めるうちにグリファーが実際に移動させた位置とはズレが生じ、最終的に他のマシン上では障害物はグリファーと当たらない位置に移動して、そのまま動かなくなります。それらの障害物の位置は同期されていないので、この矛盾は修正されません。

結果

グリファーのマシン上では立派なバリケードが完成、他のマシン上ではバリケードができていない

レースを真剣にしている人達のマシン上ではバリケードが無いので問題なくレースを楽しむことができます。

一方、グリファーのマシン上では立派なバリケードがあるので他のプレイヤー達はグリファーの思惑通りにバリケードに衝突してライダーは派手に中に舞い、バイクは火花を飛ばしながら滑っていきます。そのしばらく後に新しい情報がネットワークから届きます。あれ？実際には衝突は起きていなかった？この時、吹き飛んだはずのプレイヤーはコース上に配置され、問題なくレースは続行されます。

１００万人ものプレイヤー達が何時間もプレイしたにも関わらず、誰もこの矛盾には気づきませんでした。

グリファーは盛大なクラッシュシーンを見て喜び、

真剣にレースをしている人達は無事にレースを終えることができ、

みんないつまでも幸せにレースを楽しんだとさ、めでたしめでたし

原文:
http://blogs.msdn.com/shawnhar/archive/2008/01/01/network-compression-just-say-no.aspx

ネットワーク　その８　算術符号化圧縮

Yuichi Ito — Sat, 09 Feb 2008 07:40:00 GMT

算術符号化は解りづらく、めったに使われないツールのひとつですが、時々その威力を発揮します。例えるならネットワークデータ圧縮における変なサイズの六角レンチです。

算術符号化はクールです。なぜなら、あまり知られていないし、一見すると動かないように思えるものだからです。パーティーで女の子に好印象を持たせるのに活躍します(訳注:そうか？)

以下のデータがあったとします。

    enum Species    // 種類
    {
        Camel,          // ラクダ
        Cat,            // ねこ
        Caterpillar,    // いもむし
        Cheetah,        // チーター
        Chimpanzee,     // チンパンジー
        Cobra,          // コブラ
        Cormorant,      // 鵜(う)
        Cougar,         // クーガー
        Coyote,         // コヨーテ
        Crab,           // カニ
        Crocodile,      // ワニ
    }

    Species animalA;
    Species animalB;
    bool whoWon;

(そう、私たちは世界中の男の子が一度は思う「クーガーとワニはどっちが強いか？」という疑問に答えるためのゲームを作るんだ(訳注:ねこが最強))

ビットフィールド圧縮を使った場合、animalAとanimalBの変数には１１種類の動物がいるので、その情報を格納するのにそれぞれ４ビットが必要になり、誰が勝ったのかという情報で１ビット必要になるので合計で８ビットを超えてしまいます。

でも、ちょっと待って

animalAに格納する値の組み合わせは１１種類、animalBも１１種類、そしてwhoWonには２種類の値です。全ての組み合わせを考えると１１× １１× ２の合計２４２通りになります。これならbyteに収まりそうです。

ここでは４ビットを動物の種類に割り当てていますが実際は１１種類必要なところに１６種類を表すだけのスペースを用意してしまうというのはビットフィールド圧縮の問題です。この中途半端な組み合わせをコンパクトにする方法があれば良いと思いませんか？

前の記事のビットフィールド圧縮の部分を、乗算、除算、そして剰余算に変更することで解決することができます。

    void ArithmeticEncode( ref int encoded, int valueRange, int Value )
    {
        encoded *= valueRange;
        encoded += value;
    }

    int encoded = 0;
    ArithmeticEncode( ref encoded, 11, (int)animalA );
    ArithmeticEncode( ref encoded, 11, (int)animalB );
    ArithmeticEncode( ref encoded, 2, whoWon? 1: 0 );
    packetWriter.Write((byte)encoded);

そして、読み込み側は、ビットフィールドの時と同じようにパラメーターを逆順に読み込みます。

    void ArithmeticDecode( ref int encoded, int valueRange )
    {
        int value = encoded % valueRange;
        encoded /= valueRange;
        return value;
    }

    int encoded = packetReader.ReadByte();
    whoWon = ArithmeticDecode( ref encoded, 2 ) != 0;
    animalB = (Species)ArithmeticDecode( ref encoded, 11 );
    animalA = (Species)ArithmeticDecode( ref encoded, 11 );

どう？クールでしょ？

原文:
http://blogs.msdn.com/shawnhar/archive/2007/12/30/network-compression-arithmetic-encoding.aspx

ネットワーク　その７　ビットフィールドで圧縮

Yuichi Ito — Fri, 08 Feb 2008 06:44:00 GMT

ビットフィールドは古くから知られている素晴らしいデータパッキング手法です。C#プログラマーがビットフィールドを使う機会は非常に少ないですが、ネットワークパケットの圧縮にはもってこいなので、この機会に使ってみましょう。

バイトは８ビット、intは３２ビット。でも、送るべきデータが８ビットや３２ビットの倍数にならないときはどうします？例えば以下のようなデータを送るとします。

    bool isAlive;       // 生きているか？
    bool isFiring;      // 撃っているか？

    enum Species    // 種類
    {
        Camel,          // ラクダ
        Cat,            // ねこ
        Caterpillar,    // いもむし
        Cheetah,        // チーター
        Chimpanzee,     // チンパンジー
        Cobra,          // コブラ
        Cormorant,      // 鵜(う)
        Cougar,         // クーガー
        Coyote,         // コヨーテ
        Crab,           // カニ
        Crocodile,      // ワニ
    }

    packetWriter.Write(isAlive);
    packetWriter.Write(isFiring);
    packetWriter.Write((byte)species)

これで３バイトになりますが、実際にはそんなにいりません。ブーリアン型は１ビットしか必要としませんし、生物の種類も１１種しか居ないので４ビットで足ります。

それぞれのフィールドにどれだけのビット数が必要かが判れば、ビットシフトすることによって複数のビット群を１つbyteやintにまとめることができます。使いやすいように、指定されたビット群をbyteやintといった値にまとめるメソッドを作るといいでしょう。

ここでは、先の例では３バイトを送っていたところを１バイトにまとめて送ることができます(まだ２ビット余ってる)

    void AddToBitfield( ref int bitfield, int bitCount, int value )
    {
        bitfield <<= bitCount;
        bitfield |= value;
    }

    int bitfield = 0;
    AddToBitfield( ref bitfield, 1, isAlive? 1: 0 );
    AddToBitfield( ref bitfield, 1, isFiring? 1: 0 );
    AddToBitfield( ref bitfield, 4, (int)species );

    packetWriter.Write((byte)bitfield);

AddToBitfieldメソッドは２つのことをします

現在のビットフィールドを左シフト(「<<」演算子を使う)して、新しいフィールドを確保
新しいビット群を設定(「|」演算子を使う)

読み込むためには、逆のプロセスを行います。

    int ReadFromBitfield( ref int bitfield, int bitCount )
    {
        int value = bitfield & ((1 << bitCount) - 1 );
        bitfield >>= bitCount;
        return value;
    }

    int bitfield = PacketReader.ReadByte();
    species = (Species)ReadFromBitfield( ref bitfield, 4 );
    isFiring = ReadFromBitfield( ref bitfield, 1 ) != 0;
    isAlive = ReadFromBitfield( ref bitfield, 1 ) != 0;

書き込んだ順番とは逆に読み込んでいることに注意してください。

ReadFromBtfieldメソッドはAddToBitfieldと逆のことをします。

ビットフィールドの下位ビットからビット群を取り出す(「&」演算子を使う)
残りのビットフィールドを右にシフトする(「>>」演算子を使う)

ビットフィールドはenumやブーリアンをまとめるのに有効ですが、他の数値データも前回紹介した量子化の手法と組み合わせることで格納することができます。

原文:
http://blogs.msdn.com/shawnhar/archive/2007/12/28/network-compression-bitfields.aspx

ネットワーク　その６　量子化で圧縮

Yuichi Ito — Fri, 01 Feb 2008 07:15:00 GMT

ビット数の少ない方が多いものより消費するスペースは小さくなります。

もしint型の値が0～100までの範囲しか取らないと判っているのなら、そのまま４バイトのint型として送るより、byte型にキャストして送ることができます。

場合によっては値が表す範囲を値をずらすことによって減らすことができます。例えば、キャラクターの高さのデータを送る必要があり、高さはcmで表されるとします。このゲーム中のキャラクターの高さの範囲は、ドワーフ(100cm)から巨人(300cm)まであります。

300という値はbyteで表現できる範囲(0-255)を超えているので、キャストすることはできません。

しかし、100cm以下のキャラクターが存在しないと判っているのなら、100cmを基点とすることで値の取る範囲を小さくすることができます。

PacketWriter.Write( (byte)( height - 100 ) );

受信側では値を使う前に100を足すだけです。これで、キャラクターの高さの範囲は0-200になり、byteにキャストすることができます。

他にもスケーリングすることで値の取る範囲を小さくすることができます。例えば、浮動小数点で表されるラジアン角度を送る場合があるとします。ラジアンで円を表す範囲は０～２πになります。この値を０～２５５の範囲に収まるようにスケーリングすれば、byteにキャストして送ることができます。

    float rotationEncodeScale = 255.0f / MathHelper.TwoPi;
    PacketWriter.Write( (byte)( rotation * rotationEncodeScale ) );

受信側では逆数を掛けることで、元の値にします。

    float rotationDecodeScale = MathHelper.TwoPi / 255.0f;
    float rotation = (float)PacketReader.ReadByte() * rotationDecodeScale;

この量子化では、精度が多少失われてしまいますが、通常は４バイトのデータを1/4に減らすことの方が価値があります。

訳注:
原文のコードでは255ではなく256を使っていますが、この場合に変換できる値は上限値未満の時に動作します。もし、上限値を指定した場合、結果は256になり、byteにキャストすると結果は０になってしまいます。ですが、この例で扱っている値はラジアンなので円を表す場合、値が０とMathHelper.TwoPiの時は結果が同じになるので問題なく動作します。

同じ手法はシェーダープログラムなどで使うのですが、この場合に良く用いられるのは０～１までの値で１以下の値を取るので、この場合はスケールを255にしないと動作しません。

以上の理由から、ここではスケール値を255に変更しました。

原文:
http://blogs.msdn.com/shawnhar/archive/2007/12/24/network-compression-quantization.aspx

ネットワーク　その５　圧縮

Yuichi Ito — Wed, 30 Jan 2008 05:38:00 GMT

限られたネットワーク帯域の中では、送信するデータを圧縮することは非常に重要なことです。

Zip等の一般的な圧縮アルゴリズムはネットワークゲーム向けではありません。これらの圧縮はある程度のデータ量がある場合は効率良い圧縮が期待できますが、ネットワークパケットのように小さいデータを圧縮するには不向きです。ここで必要なのは２０バイトのデータを１０バイトにするような圧縮方法です。

初心者がよく考える手法として、送信側で複数のパケットを続けてバイトストリームして一般的な圧縮アルゴリズムを使って圧縮し、圧縮されたデータをパケットに分割して送受信するというものがあります。確かに圧縮率は高くなるのですが、この手法には致命的名欠点があります。この手法では、圧縮したデータを展開するに全てのパケットが失われること無く、順番に配信される必要があります。この為にはSenDataOptions.ReliableInOrderを使う必要があり、レイテンシが増加する原因になってしまいます。

また、変化量(前の状態との差)を送ることで全体のデータを送るより少ないデータ量で済ますことができますが、この手法も一般的な圧縮アルゴリズムを使うのと一緒で、全てのデータが順番に送信されるという保障があるときにのみ使える手法です。

通常は古典的なビットフィールドをまとめたり、量子化を使った方が良い結果になります。これらの手法は4KBのRAMを積んだ8ビットマイコン時代に良く使われたものですが、ギガバイト単位のデータを扱える.Netの世界では忘れ去られた手法でもあります。

例えば、文字列を送るのでなく、整数のIDかenum値を送る。

もし、行列が回転と移動の組み合わせで、スケールや、せん断、射影をしないと判っているのなら行列データを送らない。変わりに１２バイトのVector3であるMatrix.Translateと、１６バイトのQuaternion.CreateFromRotationMatrix(matrix)を送ります。これで６４バイトの行列データが２８バイトに圧縮されたことになります。

以下、次回に続く。

原文
http://blogs.msdn.com/shawnhar/archive/2007/12/22/network-compression.aspx

ネットワーク　その４　帯域　ボイスチャットについて

Yuichi Ito — Fri, 25 Jan 2008 22:43:00 GMT

XNAフレームワークはボイスチャットをサポートしており、ヘッドセットがある場合に自動でチャットができるようになっています。便利な機能ではありますが、使用中はより多くのネットワーク帯域が必要になることに注意が必要です。

音声データは500 B/s以下の帯域に圧縮され、ヘッドセットに向かって喋った時のみにデータ転送を行います。

デフォルトの状態では全てのプレイヤー同士で会話することができるようになっています。もし、ひとりが他の15人のプレイヤーに話しかけた場合、

500 * 15 = 7.3KB/s

ひゃー!!　8KB/sが目標だったことを覚えていますか？これではゲームデータを送る前に殆どの帯域を使い切ってしまいます。

では、この厄介なボイスデータ帯域問題をどのようにして解決することができるのでしょうか？

同時にプレイできるプレイヤー数を少なくする
もしくは、LocalNetworkGamer.EnableSendVoiceを状況に合わせて変更する
- 同じチームにのみ話せるようにする
- 自分の近くにいるプレイヤーに対してのみ話せるようにする。ただし、頻繁にEnableSendVoiceを変更するのは止めましょう。この値を変更する度にその情報をネットワーク上に転送しないといけないので、頻繁に変更してしまうと逆により多くの帯域を使ってしまうことになってしまいます。
- MotoGPではゲーム用のデータ転送量の少ないロビー内では16人全員が自由に会話でき、ゲーム内では最も近い３人のプレイヤーと会話ができるようになっています。

原文:
http://blogs.msdn.com/shawnhar/archive/2007/12/20/network-bandwidth-voice.aspx

ネットワーク　その3　帯域

Yuichi Ito — Thu, 24 Jan 2008 03:53:00 GMT

ネットワーク帯域とは、どれだけの量のデータを送受信できるかを表します。データ量が上限に近づくほどにパケットロスの量が増え、この上限を超えたデータ量を送ろうとした場合、結果的にセッションから切断されることになってしまいます。

XNA Frameworkでは帯域をバイト/秒で表します。まぎらわしいことにネットワークベンダーはビット/秒で表すのが好きで(多分、より数字を大きく見せるため)、さらにまぎらわしいことにどちらの表記もbpsやkbpsを使うことです。この表記が出てきた場合にはバイト/秒なのかビット/秒のどちらのことを表しているのか注意する必要があります。(訳注:私は個人的にバイト/秒は大文字のB/s、ビット/秒はをbit/sと区別して表記するようにしています)

より多くのユーザーに遊んで貰うために色々な家庭のインターネット接続を考慮してXboxのゲームでは最小で上り、下り8KB/sの帯域で動作することが求められます。

ネットワーク帯域と言うと、ゲーム内で送受信するデータ量x接続するマシン数と考えがちですが、ここで忘れてはいけないのはデータパケットのヘッダー部分のサイズです。

20バイトのIPヘッダー
8バイトのUDPヘッダー
～22バイトのLIVEやXNA Frameworkで使われる部分(NAT Traversal、暗号化、Reliable/Ordered転送用の情報)

これで～50バイトのパケットヘッダーサイズになります。

例えばプレーヤー毎にBoolean値を、60フレーム/秒の間隔で転送すると:

1バイトのペイロードデータ
+50バイトのヘッダー = 51バイト
*60パケット/秒 = 3060バイト

ホァ！Boolean値一個のデータ転送だけでも3KB/sになってしまいます(ゴールは8KB/sということを思い出してください)。98%の帯域がパケットヘッダーで無駄に消費されてしまいます。

では、どうやってこの厄介なヘッダー問題を回避することができるのでしょうか？

データ転送頻度を下げる

通常のゲームでは毎フレーム毎にパケットを送るのではなく、1秒間に10～20パケットの割合で送っています
この転送頻度は動的に変化させることができます。例えば遠くのプレイヤーにはより低頻度でパケットを送ります
MotoGPではXbox LIVE上で最大16人同時プレイができます。これだけの人数になると1秒間に4パケットが上限でした。この為により効果的な予測アルゴリズムを使って低レートでも滑らかに動作させる必要がありました。

パケットをまとめる

沢山の小さいパケットを1つの大きなパケットにすることで、パケットヘッダーのサイズの無駄を少なくすることができます。
通知メッセージを即座に送るのではなく、複数のフレームを待たせることによってパケットをまとめる
もし同じフレーム内で複数のパケットを同じ相手に送った場合、次にNetworkSession.Updateを呼んだときに自動的まとめてくれます。
XNA Frameworkは自動的にボイスデータやrealiable UDPの確認などを既にあるパケットにまとめるので、これらのデータは独立したヘッダーを必要としません。

原文
http://blogs.msdn.com/shawnhar/archive/2007/12/18/network-bandwidth-packet-headers.aspx

XNAカスタムコントロール

Yuichi Ito — Fri, 18 Jan 2008 04:47:00 GMT

以前から、XNAを.NetのControl内で使いたいという要望を何度か聞くことがありました。本当はXNA 2.0で導入される予定でしたがテスト期間が間に合わなかったために見送りとなりました。ですが以前書いたようにXNA 2.0でGraphicsDeviceが仮想化されたことによってウィンドウ内でXNAを使う実装が非常にシンプルになったので、Creators Club Onlineにサンプルがアップされました。

WinForms Series 1: Graphics Device Sample

このサンプルでは、XNAをWinFormsのカスタムコントロールとして使う方法が実装されています。単体のコントロールを配置したときに動作するのはもちろん、複数のコントロールを配置した場合でも動作するので3Dゲーム用のエディター等で３面図+カメラビューの四つの画面を表示したりというときに便利です。実装的にはひとつのGraphicsDeviceを使いまわしているので、モデルデータ等は別コントロールであっても同じものが使えます。

WinForms Series 2: Content Loading Sample

ゲームエディタなどを作るときには、コンテントパイプラインを通る前のfbxファイルやxファイルを直接指定できたほうが便利ですが、一度Content.Load<T>に慣れてしまうと自前でNodeContentやMeshContentからモデル描画するのは非常に面倒ですし、パフォーマンス的な問題もあります。そこで、このサンプルではfbxファイルを直接読むのではなく、ツール上でコンテントパイプラインのビルド処理をすることで普段のゲームと同じようにContent.Load<T>を使えるようにしています。コンテントパイプラインのビルド処理はMSBuildを使っているのですが、このサンプルのContentBuilder.csファイル内でMSBuildのタスクを実行することで実現しています。

ある程度規模の大きなゲームになってくると、ゲームエディタなどのツールが必要になってきますが、上の二つのサンプルが参考になるのではないでしょうか？

ネットワーク　その2　パケットロス

Yuichi Ito — Thu, 10 Jan 2008 06:24:00 GMT

ネットワークは信頼できません。

データーパケットを送ったときにはいろいろな事がおこります。

相手側に届くかもしれない
届かないかもしれない
届いたとしても、送った順番とは違う順番で届くかもしれない
届いたとしても、その内容が壊れてるかもしれないし、誰かによって変更されているかもしれない

4つ目はXNAフレームワークベースのゲームでは問題になりません。XNAフレームワークではLiveのライブラリを使っているので送られるパケットは全て自動的に暗号化されているので、データ自体が改ざんされたり、壊れたりということを気にする必要はありません。

2と3の問題についてはSendDataOptions.ReliableとSendDataOptions.InOrderフラグを指定することで解決できます。なぜフラグ指定をしないといけないのか疑問に思う人もいるかもしれません。常にSendDataOptions.ReliableInOrderで送ればいいじゃないか、それ以前になぜ他のネットワークアプリケーションの用にTCPを使わないの？

その理由はゲームでは常にシミュレーション結果をリアルタイムに更新する必要があるからです。TCPやSendDataOptions.ReliableInOrderを指定した場合、以下のような動作をします。

送信側はデータパケットをネットワークに送る
送信側はデータパケットのコピーを内部の送信中キューに保存する
パケットが届いた時に、受信側は「データが届いたよ」という確認メッセージを返信をする
送信者は受信側からの確認メッセージが届いたら、そのパケットを送信キューから取り除く
一定時間、確認メッセージが届かなかった場合は、もう一度同じパケットを送信しなおす
もしパケットが送信順に届かなかった場合、例えばBとCのパケットがAを受信する前に届いたら、受信側はBとCのパケットをキューに保存する
送信順序を保つために、受信側はAが届くまでの間待たなければいけない

この仕組みはウェブページのHTMLデータ等をダウンロードする時などには有効な方法です。何故なら、AのパケットにはHTMLのヘッダーやレイアウト部分を含んでいるわけですが、その情報無しに残りのデータを表示するのは意味がありません。

ゲームの場合を考えてみましょう。例えばプレイヤーの座標をゲームループ内で送る場合は

Aの時間の時のプレイヤー座標を送る
Bの時間の時のプレイヤー座標を送る
Cの時間の時のプレイヤー座標を送る
AとBの座標情報が失われる
Cの座標が届く
受信側はCの情報が届いているのにも関わらず、AとBの座標が再び送信するまでの間、待つことになる

なんて間抜けな…。もし受信者がCの時点での座標を知っているのなら、それより過去の時間であるAとBを気にするのは無意味なことです。この状況ではAとBの情報は無視して、最新の座標に更新するのがより自然な方法です。

SendDataOptions.ReliableInOrderを指定したときにパケットロスした場合、レイテンシは増加します。このフラグを指定しない場合にパケットロスが発生した瞬間だけガクっとしますが、その後は問題なくゲームを続けることができます。しかし、フラグを指定した場合、たった一つのパケットロスでさえ、それに続くパケット全てが失ったパケットが再び届くまでの時間分だけ遅延するこになります。

SendDataOptions.ReliableかSendDataOptions.InOrderのどちらかを指定したときには問題にならないことに注意してください。この問題は両方のフラグを指定した(TCPの振舞いと同じ)時のみに発生します。

転送を確実に行いたいが、パケットの送信順を気にする必要が無い(SendDataOptions.Reliableを指定)場合、パケットAがロスしてBが届いた時はゲーム側では単にBを受信したことになり、Aのパケットは送信しなおされますが続くほかのパケットの遅延には影響ありません。

パケットの送信順は気にするが、パケットロスは気にする必要が無い(SendDataOptions.InOrderを指定)場合、それぞれのパケットには番号がつけられ、番号が古いものが、新しいものより後に届いた場合は古いものは無視されます。この方法が最もレイテンシが少ない方法です。

ショーン(Shawn)曰く

SendDataOptions.InOrderをできるだけ多く使う
SendDataOptions.Reliableは必要なときに使う
SendDataOptions.ReliableInOrderはできるだけ少なく

原文
http://blogs.msdn.com/shawnhar/archive/2007/12/14/network-packet-loss.aspx

ネットワーク　その1　レイテンシ

Yuichi Ito — Tue, 08 Jan 2008 05:44:00 GMT

「さて」とセイウチはいった「ネットワークの話をしましょう」

(訳注:元ネタはルイス・キャロルのセイウチと大工から)

ネットワークゲームプログラマーには以下の三つの不死の敵がいます

レイテンシ データが相手に届くまでに掛かる遅延時間
パケットロス データが相手に届かない現象
帯域送ることのできるデータ量の上限

以上の三つについて順に話しましょう。

レイテンシは物理的理由によって決まります。SFの世界では何十年もの昔に実現しているのに、物理学者は未だに光速を超える手段を発見していません。ですから、秒速３０万キロ/秒を超える速度でデータを送ることができません。これは物理学者のせいです(そんなに難しいことなのか？)

十分に速いだろって？

僕はシアトルに住んでいて、同僚のイーライ(Eli)はニューヨークに住んでいた。その距離はおよそ4,000Km、光の速度で13ミリ秒掛かる。

僕は以前イギリスに住んでいたけど、イギリスからシアトルまでは7,800Km、光の速度で26ミリ秒掛かることになる。

60フレーム/秒のゲームの場合、各フレームは16ミリ秒毎に更新されるので、僕がイギリスの友達と遊んでる場合は2フレーム近い差(ラグ)が生じてしまう。

ちょっと待ってくれ、話はそれだけではないんだ

ネットワークデータは真空中を通らない。光の速度といえば普通は真空中での光の速度を言うけど、実際のデータは光ケーブルや銅線ケーブルを通るので６割程度の速度に落ちてしまう
ネットワークデータは一本線で繋がっている訳ではない。両サイドにモデムがあり、それぞれ10ミリ秒程度のレイテンシがある。また、友人は私と同じISPやスイッチボード上にいる訳ではないので実際にはルーターを介してデータ送られる。それぞれのルーターでは5～50ミリ秒程のレイテンシがある

最悪ケースは？

Xboxのゲームでは最大200ミリ秒(0.2秒)の遅延が合っても動作するよう奨励されている

どうやったら、家で再現できるの？

NetworkSession.SimulateLatency = TimeSpan.FromMilliseconds(200)

どうすればいいの？

0.2秒の遅延があっても問題のないゲームデザインをする。例えばポーカーゲームなんかの場合は0.2秒程度の遅れは無視してもかまわないよね
予測アルゴリズムを使ってラグを隠蔽する。レイテンシがあるお陰でリモートオブジェクトのその瞬間のゲームステートを知ることは不可能。でも0.2秒前の情報、例えば移動速度、加速しているのか、減速しているのか、旋回しているのかという情報を元に0.2秒後の状態を予測することはできる。
その予測が間違っていた場合でも、予測した座標から実際の座標へスムーズに補間することによってガクガク動くのを防ぐことができる。予測の90%くらいがあっていればラグが気にならなくなるね。
ラグを完全に消すことは物理学的に不可能なので、あくまで目的はラグが分からないように隠すということ

ここまでがShawn Hargreaves氏の投稿の翻訳です。

ちなみに日本国内の場合は距離的問題は少ないと思います。例えば東京～札幌間の距離は850Kmで3ミリ秒となりますが、記事の中の通り、問題になるのはルーター間でレイテンシが大きな問題となるでしょう。

予測アルゴリズムですが、以下のサンプルが参考になると思います。

http://creators.xna.com/Headlines/developmentaspx/archive/2007/01/01/Network-Prediction-Sample.aspx

追記:

ゲーム中に表示されるPing値と、この記事で言及しているレイテンシとは違うものです。

レイテンシは片道時間　A地点からB地点にデータが届くまで掛かる時間
Pingは往復時間 A地点からB地点まで、そしてB地点からA地点までデータを送り返すのに掛かる時間

行きと帰りが同じ速度と仮定すると0.2秒というレイテンシは0.4秒のPing値に相当することに注意してください。

XNA 2.0のコンテントパイプライン～その弐～

Yuichi Ito — Sat, 22 Dec 2007 04:05:00 GMT

プロセッサパラメーター

上の画面はテクスチャのプロパティ画面です。Content Processorの脇に+のついた四角いマークに気づいたでしょうか？

クリックすると複数のパラメーターが表示されます。これがXNA GS 2.0の新機能の一つであるプロセッサパラメーターです。XNA GSE 1.0では複数の複数のプロセッサを書く必要がありましたが、XNA GS 2.0ではひとつのパラメーターつきのプロセッサを書くだけで、どのようにコンテントがプロセスされるかを指定できるようになりました。

Textureプロセッサには以下のパラメーターが設定できます。

パラメーター名	用途
Color Key Color	カラーキーの指定
Color Key Enabled	この値がTrueの時にColor Key Colorと同じピクセルのアルファ値が0に変換される
Generate Mipmaps	ミップマップ生成のコントロール
Resize to Power of Two	元のイメージを最も近い2の乗数のサイズにリサイズするかしないか
Texture Format	出力するテクスチャのフォーマット NoChange(変換なし)、Color(32ビットRGBA)、DxtCompressed(DXT圧縮形式)

Modelプロセッサでは以下のパラメータが設定できます。

パラメーター名	用途
Color Key Color	カラーキーの指定
Color Key Enabled	この値がTrueの時にColor Key Colorと同じピクセルのアルファ値が0に変換される
Generate Mipmaps	ミップマップ生成のコントロール
Generate Tangent Frames	タンジェントフレーム、つまりBiNormalとTangenチャンネルを頂点バッファに生成のコントロール
Resize Textures to Power of Two	全てのテクスチャイメージを最も近い2の乗数のサイズにリサイズするかしないか
Scale	モデルのスケール変換
Swap Winding Order	ポリゴンの右回り、左回りの頂点順番の反転
Texture Format	出力するテクスチャのフォーマット NoChange(変換なし)、Color(32ビットRGBA)、DxtCompressed(DXT圧縮形式)
X Axis Rotation	出力するモデルをX軸に沿って回転させる
Y Axis Rotation	出力するモデルをY軸に沿って回転させる
Z Axis Rotation	出力するモデルをZ軸に沿って回転させる

プロセッサパラメーターは自分で作ったプロセッサでも簡単に使えるようになっています。ちなみにコンテントパイプラインを拡張するのに便利な"Content Pipeline Extension Library (2.0)"テンプレートがXNA GS 2.0では追加されました。またカスタムプロセッサや、カスタムインポーターの雛形となるContent Processor、Content Importerテンプレートをソースコード追加時に指定できるようになりました。

カスタムプロセッサーにパラメーターを付ける

プロセッサパラメーターをカスタムプロセッサへ追加するのは簡単でプロパティを宣言するだけです。

[ContentProcessor(DisplayName = "ねこプロセッサ")]
public class NekoProcessor : ContentProcessor<TInput, TOutput>
{
    // プロセッサパラメーター
    public bool NekoMode
    {
        get { return nekoMode; }
        set { return nekoMode = value; }
    }

    bool nekoMode = false;

このままでは味気ないので、以下のようにアトリビュートを指定することによってプロパティ画面でより読みやすい状態にすることができます。これらのアトリビュートはSystem.ComponentModel内で宣言されています。

// 規定値の指定
[DefaultValue(false)]

// 表示される文字列の指定
[DisplayName("ねこモード")]

// パラメーターの説明
[Description("Trueにすると、なんとなくねこっぽくなります")]
public bool NekoMode
{

このプロセッサをコンパイルすると、プロパティ画面では以下のようにパラメーターの説明つきで分かりやすい表示になります(説明自体が分かりやすいかどうかは別問題ですが…)。

今まではどんなに小さなパラメーターでも直接コードで変更するか、インポーターを介して読まないといけなかったのですが、プロセッサパラメータを使うことでそういった煩雑な作業をする必要が大幅に減ることになるでしょう。

原文URL

http://blogs.msdn.com/shawnhar/archive/2007/11/26/content-processor-parameters-in-xna-game-studio-2-0.aspx

ネットワークサンプルの配信

Yuichi Ito — Fri, 21 Dec 2007 05:23:00 GMT

XNA 2.0リリースと同時に配信されたネットワーク対応のスターターキットにNet Rumbleがありますが、もっとシンプルなサンプルが欲しいという人の為に4つのネットワークサンプルコードが配信されました。

Network Architectures: Client/Sever

XNA 2.0上でのシンプルなサーバー/クライアント型のネットワークゲームのサンプルです。このサンプルではクライアントは単に入力情報をサーバーに送るのと、レンダリングするだけの処理をしています。サーバー側はクライアントから受け取った情報を元にシミュレーションを実行し、その結果をクライアントに送るようになっています。

Network Architectures: Peer-to-Peer

上記のサーバー/クライアント形式に対して、このサンプルではピア・ツー・ピア形式のプログラムになっています。それぞれが自分の戦車のコントロールとシュミレーションを行い、その結果をセッションに参加している全てのプレイヤーに送るようになっています。そして、その結果を受け取った側は、その情報を元に処理を行います。

Network Game State Management

このサンプルではネットワークゲームを作る場合のセッション参加のための必要なシンプルなメニューを用いて行います。
シングルプレイヤー、LIVE、またはシステムリンクの選択に始まり、新規セッションの追加、動作中のセッションへの参加などの処理をしています。また、ネットワークに起因するエラーハンドリングの処理も行っているので参考になります。

Network Prediction Sample

上で紹介したクライアント/サーバーとピア・ツー・ピアのサンプルでは1/60秒毎にデータを送っています。これはLAN環境では問題なく動作しますが、インターネットを介して遊ぶ場合には遅延や帯域の問題があります。そこで、このサンプルではピア・ツー・ピアのサンプルを元にしてインターネットを介しても動作するプログラムに改善しています。戦車の動きはパケットロスや遅延があった場合でも滑らかに動くように予測処理がなされています。またLAN環境でもインターネット環境をシミュレートするためにNetworkSession.SimulateLatencyやNetworkSession.SimulatedPacketLossを使っています。

これらのサンプルの他にも英文ですが、Shawn Hargreaves氏のサイトではネットワークゲームに関する有用な投稿が複数あります。

Network Latency

Network Packet loss

Network bandwidth: packet headers

Network bandwidth: voice

ひにけにの方でも、これらの投稿を日本語訳(意訳？)していこうと思います。

それ以外にもXNAチームメンバのブログを日本語で紹介して欲しいという要望があればコメント欄でリクエストを受け付けます。

XNA 2.0のコンテントパイプライン～その壱～

Yuichi Ito — Fri, 21 Dec 2007 04:32:00 GMT

コンテントプロジェクト

XNA 2.0のプロジェクジェクトをソリューションエクスプローラで見ると以下のようになっています。

参照設定の項目が二つあることに気づいたでしょうか？これはContentがWindowsGame1のサブプロジェクトになっているからです。XNA 2.0では、このサブプロジェクト内にコンテントを追加します。その他にも、以前まではメインプロジェクトに記述されていたコンテントに関する情報、例えばコンテントがどのようにインポートされプロセスされるかの情報、カスタマイズされたコンテントパイプラインアセンブリの参照などが含まれます。

以前はWindows、Xbox 360の両対応のゲームを開発している時に、XNA 1.0ではそれぞれのプロジェクトに同じコンテントを追加しないといけませんでした。それだけでもコンテントの管理が面倒だったのですが、XNA 2.0になってプロセッサプロパティ対応になったので、細かいパラメーター設定まで両方のプラットフォームのプロジェクトで設定しないというのは面倒であり、エラーの原因にもなります。

そこで、XNA 2.0ではWindows、Xbox 360の両プラットフォームでコンテント情報を共有するための仕組みとしてできたのがコンテントサブプロジェクトです。

XNA 2.0ではWindowsプロジェクトを作ったときにプロジェクトの右クリックメニューで「Create Copy of Project for Xbox 360...」を選択すると、Windosプロジェクトを元にしてXbox 360用のプロジェクトを作ることができます。この時、両方のプロジェクトにコンテントプロジェクトが存在しますが実際には同じサブプロジェクトを参照しているだけです。

コンテントプロジェクトを共有している訳ですから、Windowsのコンテントプロジェクトにコンテントを追加すると、同じコンテントがXbox 360側のコンテントプロジェクトにも追加されるようになっています。これでWindows、Xbox 360両対応のゲームを作る時の手間が大幅に減ることになります。

コンテントプロジェクトの実体

このコンテントプロジェクト、テンプレートを使ってゲームプロジェクトを作った場合、「プロジェクトフォルダ\Content」フォルダ内にContent.contentprojというファイル名で作られます。

このファイル中身は知らない人には単なるXMLファイルのように見えますが、Visual Studio 2005から採用された新しいビルトツールであるMSBuildのプロジェクトになっています。Visual Studio 2005やVisual C# Express上でビルドした場合、裏ではMSBuildがビルドする仕事を担っています。

実は普段目にしている.csprojファイルもMSBuild用のプロジェクトファイルになっているのでパスの通っている状態でコマンドラインから

msbuild.exe myproject.csproj

と、タイプするとC#のプロジェクトをビルドすることができます。もちろん、Content.contentprojファイルも単独でビルドすることができます。つまり、コンテントビルドだけを単独で行うことができるわけです。

「コマンドラインなんて普段使わないから、関係ないのでは」と思う人もいるかもしれませんが、この仕組みを利用して以前紹介したコンテントパイプラインのデバッグをする第3の方法に使える訳です。

この方法はVisual Studio 2005上でしか使えませんが、コンテントパイプライン拡張用のプロジェクトのプロパティ画面のデバッグ設定を以下のように変更することでコードに変更を加えることなくデバッグすることができます。

外部プログラムの開始にMSBuild.exeを指定する。(私の環境ではC:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\MSBuild.exeとなっていました)
コマンドライン引数にデバッグ対象となるContent.cotentprojファイルをフルパスで指定する
コンテントパイプライン拡張用のプロジェクトを実行する(右クリック/デバック/新しいインスタンスを開始)

これで、カスタムプロセッサのデバッグなどを普通のプロジェクトをデバッグする時と同じようにデバッグすることができます。デバッグ設定は一度設定すれば後は変更する頻度は少ないので、コードを変更する必要のある他の手法に比べるとお手軽かもしれません。

デフォルトではプラットフォームはWindows、Debug状態の設定でビルトが行われます。プラットフォームを変更したい場合はコマンドライン引数でファイル名を指定する前にWindowsならば

/p:XnaPlatform=Windows

Xbox 360の場合は

/p:XnaPlatform="Xbox 360"

と、指定することで異なるプラットフォームでのコンテントビルドをすることができます。

デバッグ、リリースの変更は

/p:BuildConfiguration=Debug

または

/p:BuildConfiguration=Release

と、することで変更することができます。

XNA 2.0でのGraphicsDevice仮想化

Yuichi Ito — Sat, 15 Dec 2007 06:55:00 GMT

消えたデバイスロスト

XNA1.0で作ったソースコードをXNA2.0に移植していて最初に気づくのは以下の警告メッセージだと思います。

warning CS0672: Member 'MyGame.Game1.LoadGraphicsContent(bool)' overrides obsolete member 'Microsoft.Xna.Framework.Game.LoadGraphicsContent(bool)'.

結論から書くと、XNA2.0ではグラフィクスリソースの扱いが簡単になり、Windows上で発生するデバイスロスト等の問題を気にする必要が殆ど無なり、新しく追加されたGame.LoadContent内でグラフィクスリソースを簡単に生成できるようになりました。LoadGraphicsContentメソッドもXNA 1.0との互換性を保つために一度だけ呼ばれます。

Texture2D、VertexBuffer、RenderTargetなどの全てのグラフィクスリソースはXNA2.0上では一度生成したら、そのインスタンスは常に有効な状態になります。もちろん、デバイスロストやデバイスリセットが発生するケース、例えばウィンドウのサイズ変更、フルスクリーンへの切り替え、マルチモニタ環境でウィンドウをモニタ間で移動したときでも最初に作ったインスタンスは問題なく使えます。

ただしDirectX 9のドライバモデルの制限上、RenderTargetやDynamicVertexBufferといった動的に内容を書き換えるグラフィクスリソースの中身はデバイスロスト時に破棄されてしまいます。通常、動的に生成されるグラフィクスリソースの多くは毎フレーム毎に生成されるので、その内容が破棄されても次のフレームで生成されるので特別な処理をする必要がありません。フレーム間でその内容を保持しなければいけないグラフィクスリソース、例えばHDRレンダリングで使われるトーンマッピング用の明度テクスチャ、前のフレームの内容を重ねて描くことによるモーションブラーなどの手法を使うときにのみデバイスロスト時に正しい初期値にする必要があります。

まとめると:

グラフィクスリソースはGame.LoadContent内で生成する
Game.LoadContentが呼び出されるのはプログラム開始時のみ
DrawableGameComponent.LoadContentはコンポーネントの初期化時のみに呼ばれる
グラフィクスリソースのインスタンスは作り直す必要がなくなった
フレーム間でその内容を保持するグラフィクスリソースはデバイスロスト時にその内容が破棄される

インスタンス自体はデバイスロスト時でも有効なまま
GraphicsDevice.DeviceResetイベント時にSetData<T>等を使って初期値に変更するのみ

と、いった感じになります。

XNA 1.0での問題点

XNA1.0ではGameクラスやDrawableComponentクラスにはLoadGraphicsContentとUnloadGraphicsContentメソッドがあり、デバイスリセット時にはUnloadGraphicsContent(flase)、LoadGraphicsContent(false)の順に呼ばれ、デバイスの再構築時にはUnloadGraphicsContent(true)、LoadGraphicsContent(true)の順に呼び出され、その関数の中でグラフィクスリソースの開放と生成をしなければいけませんでした。

ここでの問題はTexture2DやVertexBufferといったインスタンスを生成する必要があるので、ゲーム側のでこれらのオブジェクトを参照している場合、それらの参照を更新する必要がありました。これではゲームが複雑になるに比例してLoadGraphicsContentメソッド内のコードも複雑になるし、予期せぬエラーの原因になってしまいます。

XNA 2.0では、この問題を解決することでグラフィクスリソースの管理が格段に簡単になりました。

どうやってるの？

Texture2DやVertexBufferといったマネージクラスは内部でネイティブのリソースを管理しています。XNA 1.0ではデバイスロスト時にマネージクラス自体を破棄する必要がありましたが、XNA 2.0ではマネージクラスは内部でネイティブリソースに対して処理をするようになっています。マネージクラスはテクスチャのサイズやフォーマットといったネイティブリソースの生成情報を保持しているので、ネイティブリソースの再構築が必要なときでも自動的にネイティブリソースを生成しなおすことができます。

また、デバイスの再構築が必要なとき、例えばウィンドウを他のモニタへ移動させた場合、マネージクラスはD3DPOOL_MANAGEDでつくられたリソースの内容を一旦メインメモリに保持してから、ネイティブリソースの再構築、リソースの内容の復元を行うようになっています。

Xbox 360では？

Xbox 360上ではデバイスロスト自体発生しないので、上記のようなGraphicsDeviceの仮想化処理は最初からする必要がありません。逆に言えば、XNA 2.0ではXbox 360のようにデバイスロストのない開発しやすい環境をWindos上に持ってきたとも言えます。

参考URL:

http://blogs.msdn.com/shawnhar/archive/2007/12/12/virtualizing-the-graphicsdevice-in-xna-game-studio-2-0.aspx