ひにけにXNA : XNA 3.0

デバッグコマンド

Yuichi Ito — Fri, 23 Jan 2009 10:36:00 GMT

注:今回紹介するコンポーネントはデバッグサンプルに入っています。

開発中にいろんなものを実行したい

ゲーム開発中には様々な情報が欲しくなる場面が沢山あります。シンプルな情報であればブレークポイントを設定して変数を調べたりすることができますが、３Ｄゲームで画面に表示されている数十体もある敵のうちからひとつの敵の情報をデバッガを使って得るのは大変です。また、スタンドアローン実行している状態、例えばVisual StudioからCtrl+F5で実行した時や、友達の家でテストプレイしているときにバグが発生したときにも、ある程度の情報を知りたい場面があります。それ以外にも開発中に実行したいことはパッと思いつくだけでも以下のものがあります。

シーン全体のポリゴン数
指定したシェーダーのみの表示
カメラの視錐体表示してビューカリングのチェック
シーン内を自由に移動できるデバッグ用カメラへの切り替え
敵の数の表示
シーン内のコリジョン情報の表示
イベントトリガー等の表示
AIテスト用に任意の敵を出現させる
任意の敵を即死させる
AIステートの表示
指定した武器を出現させる
指定したステージへの移動
プレイヤーのHP設定
Godモード (無敵モード)

これだけの機能を実現するシステムとして、以下の方法が考えられます。

欲しい機能ごとにソースコードを変更してコンパイルする
コントローラーのボタンに割り当てる
簡単なデバッグメニューを作る
WindowsみたいなUIを表示させるAPIを作る

１は単純な方法ですが、いちいちソースコードをコンパイルするというのは面倒だし、スタンドアローン実行時には使えません。２は表示、非表示といったことには使えますが、数に限りがあり管理するのも大変です。３も表示のコントロールなどには使えますが、任意の敵を指定した場所に出現させるといったことには不向きです。４については、Windowsの場合は既存のUIを使えば良いのですが、Xbox 360上では自作する必要があるし、仮にそういったAPIがあったとしても機能ごとのGUIを作るのに手間が掛かります。また、GUIの弱点としてはバッチ処理をするのが難しいという面もあります。

デバッグコマンド

こういった要求を満たすためにゲーム開発現場で昔から使われているのがデバッグコマンドです。本来は開発時のみの機能で商品化されたゲームで見かけることは少ないのですが、PCゲームではDOOM時代からあるものなので知っている人も居ると思います。

デバッグコマンドの利点は文字列を入力実行し、出力するというシンプルさにあります。ゲーム中にコマンドを入力して実行するのはもちろん、ネットワークを介して文字列を転送して実行することができます。このことを利用して開発PCとXbox 360間をNetworkSessionで繋ぎ、Windows上ではGUIを使い、その情報を文字列にしてXbox 360に転送するという使い方もできます。この手法はPC上で作ったマップエディターから実機上への通信にも利用されています。特にPC画面上と開発機から出力された画面では色が違うのでBrute Force開発時にはライティングの最終調整などで使っていました。

デバッグコマンドを使う

サンプルではDebugCommandUIコンポーネントを使用します。DebugCommandUIコンポーネントはDebugManagerにあるフォントを使用するので、DebugCommandを追加する前にDebugManagerコンポーネントを追加する必要があります。

// デバッグマネージャーの初期化と追加
debugManager = new DebugManager( this );
Components.Add( debugManager );

// デバッグマコマンドUIの初期化と追加
debugCommandUI = new DebugCommandUI( this );

// デバッグコマンドUIを最上面に表示させる為にDrawOrderを変更する
debugCommandUI.DrawOrder = 100;

Components.Add( debugCommandUI );

DebugManagerコンポーネントを追加した後に、DebugCommandUIコンポーネントを生成、デバッグコマンドを最上面に描画させる為にDrawOrderを変更してから追加するだけで、デバッグコマンドを使用することができます。ゲーム中にTABキーを押すことでデバッグコマンドを表示してコマンドを入力することができます。

新しいコマンドを追加するにはDebugCommandUI.RegisterCommandメソッドを使います。このメソッドにはコマンド名、コマンドの説明、そしてコマンド実行じに呼び出されるデリゲートを指定します。デバッグサンプルではposコマンドを追加しています。

// サンプルコマンドの登録
debugCommandUI.RegisterCommand(
    "pos",              // コマンド名
    "set position",     // コマンド説明
    PosCommand          // コマンド実行用デリゲート
    );

登録したデリゲートはコマンドが実行された時に自動的に呼び出されます。デバッグサンプルでは"pos"というコマンドが入力されるとPosCommandが呼び出されます。引数のhostはコマンドを実行したIDebugCommandHost、commandは入力されたコマンド文字列(ここではpos)、そしてargumentsは入力された他の引数を文字列の配列になっています。

void PosCommand( IDebugCommandHost host, string command,
                                            IList<string> arguments )
{
    if ( String.Compare( arguments[0], "show", true ) == 0 )
    {
        // show オプションで現在座標を表示する
        host.Echo( String.Format( "Pos={0},{1}", debugPos.X, debugPos.Y ) );
    }
    else
    {
        // "pos x座標 y座標"と入力されたものを処理する
        debugPos.X = Single.Parse( arguments[0] );
        debugPos.Y = Single.Parse( arguments[1] );
    }
}

各コマンドは単なる文字列なのでテキストファイルとしてログを取っておいて、後で複数のコマンドをバッチ処理したりすることができます。Gamefest Japan 2008 デモプログラムの中ではデモを切り替えたときに以下のようにして３つのコマンドを呼び出していました。

debugHost.ExecuteCommand( String.Format( "demo {0}", demoNames[curdemo] ) );
debugHost.ExecuteCommand( "fps on" );
debugHost.ExecuteCommand( "tr on reset log:on" );

デバッグコマンドは、その名が示すとおり、デバッグ時の機能なのでリリース時に外すことを忘れないようにしてください。Godモードのように無敵になるくらいだったらいいのですが、ゲームバランスを崩したり、ゲームの進行ができなくなるようなコマンドが残ったままリリースされるのは避けるようにしましょう。デバッグコマンドを外すもっとも簡単な方法は単にDebugCommandUIを追加しないようにするだけです。

と、いうわけでFPSカウンター、TimeRuler、そしてデバッグコマンドを紹介してきました。これら３つのコンポーネントをゲーム開発時に役立ててみてはどうでしょうか？

タイムルーラー

Yuichi Ito — Tue, 30 Dec 2008 03:25:00 GMT

注:今回紹介するコンポーネントはデバッグサンプルに入っています。

時を測る

前回紹介したFPSカウンターではゲーム全体のパフォーマンスを測定するには使えますが、どの処理がどれだけ時間が掛かっているかを判定するには不向きです。

例えば、ねこが大勢の敵をなぎ倒す「ねこ無双」というゲームを作っていて、敵が沢山出てきた時に処理落ちになった場合に最適化をする必要があったとします。

最適化ルールその３:「最も負荷の高い部分(ボトルネック)の処理を最適化する」

これは当然の話で、１フレーム内で10%しか消費していない処理よりも、50%消費している部分を最適化する方が効果的です。では、この高負荷の処理を発見するにはどうしたら良いでしょうか？ねこ無双の場合だと、敵が増えると処理落ちがするんだから真っ先に思いつくのは敵AI、敵のアニメーション、敵のコリジョン判定、敵の描画処理部分です。

しかし、必ずしもそうとは限りません。もしかしたら、敵の数ではなく戦っている場面の描画部分がもともと負荷が多かったのかもしれないし、敵を表示するレーダー部分かもしれません。

このボトルネックを発見するのに有用なのがリアルタイムプロファイラー、TimeRuler(タイムルーラー)です。TimeRulerでは、複数の処理時間を測定することができ、その結果をグラフでリアルタイムに表示してくれます。

上図の例では、青い部分が更新処理、黄色い部分が描画処理になっています。この状態で最適化する場合は更新処理部分を最適化するのが効果的だと言うことが一目で判ります。

アルゴリズムのチェック

理想的なアルゴリズムは計算量のオーダーがO(n)、もしくはO(n log n)になることです。例えば、敵を10体出現させたときの処理時間が1msだった場合、敵が100体になった時の処理時間が10ms~20ms以内に収まっていれば理想的なアルゴリズムを使っているということになります。逆に敵１００体の処理時間が1,000msになってしまうのは、計算量オーダーがO(n^2)になっているアルゴリズムを使っている可能性があります。良くあるケースでは、コリジョン判定を単純な多重ループにしている時などです。

特に最近のゲームでは大量のオブジェクト数を処理するので、アルゴリズムの選択を間違えると、あっという間に処理が間に合わなくなってしまうので注意が必要です。

TimeRulerを使ってオブジェクトの数を10,20,...100と順々に増やしていき、それぞれの処理時間を測定してグラフにすることで問題のあるアルゴリズム部分を発見することができます。

瞬間最大負荷を測る

TimeRulerはリアルタイムプロファイラーなので、瞬間的な負荷も視覚的に見ることができます。例えば同じフレーム内で大量の敵を一気に発生させると、敵の初期化処理に時間が掛かりすぎて、そのフレームだけ処理落ちするということがあります。こういった瞬間的な負荷はFPSカウンターで発見することは不可能ですが、TimeRulerを使うとグラフが一瞬大きくブレるので判ります。

また、TimeRulerを表示した状態でビデオに録画したり、動画をキャプチャーしておけば、こういった瞬間的な負荷を細かく調べることもできます。

TimeRulerを使う為の準備

TimeRulerコンポーネントはDebugManagerにあるフォントを使用するので、TimeRulerを追加する前にDebugManagerコンポーネントを追加する必要があります。

// デバッグマネージャーの初期化と追加
debugManager = new DebugManager( this );
Components.Add( debugManager );

また、必須ではありませんが、TimeRulerはインスタンス生成時にGame.ServicesにIDebugCommandHostインターフェースが追加されていると、trデバッグコマンドを登録します。DeubgCommandUIはIDebugCommandHostインターフェースを実装しているので、このコンポーネントを追加した後にTimeRulerを追加することでtrコマンドを使うことができます。

// デバッグマコマンドUIの初期化と追加
debugCommandUI = new DebugCommandUI( this );

// デバッグコマンドUIを最上面に表示させる為にDrawOrderを変更する
debugCommandUI.DrawOrder = 100;

Components.Add( debugCommandUI );

デバッグコマンドUIをTabキーを押して表示させた後に、trとタイプするとTimerRulerの表示/非表示の切り替え、"tr on"で表示、"tr off"で非表示にすることができます。

また、trコマンドには以下のオプションがあります。

log	ログの表示/非表示の切り替え。例) tr log
reset	ログ履歴の初期化例) tr reset
frame	TimeRulerのバーの長さをフレーム単位で指定する(既定値:1) 例) tr frame:2

プログラム側でも、これらの操作はできるようになっていて、表示の切り替えはTimeRuler.Visibleプロパティ、Logの表示はTimeRuler.ShowLogプロパティ、表示フレーム数はTimeRuler.TargetSampleFramesプロパティ、そしてログのリセットはTimeRuler.ResetLogメソッドを呼ぶことでできます。

最後に、TimeRulerをComponentsに追加することでTimeRulerが画面下に表示されるようになります。ただし、DebugCommandUIが先に登録されていると、初期状態では表示されません。

// タイムルーラーの初期化と追加
timerRuler = new TimeRuler( this );
Components.Add( timerRuler );

TimeRulerの使い方

上記の初期化を終えれば、TimeRulerを使う準備ができました。まず、TimeRulerにフレームの開始時点を知らせるStartFrameメソッドを呼びます。場所はGameクラスのUpdateメソッドの先頭に記述するのが良いでしょう。

// タイムルーラーにフレーム開始を伝える
timerRuler.StartFrame();

次に測定したい部分をBeinMarkとEndMarkメソッドで囲みます。BeginMarkメソッドには表示するバーのインデックス値(0~７)、マーカー名、バーに表示されるときの色を指定し、EndMarkではバーのインデックス値とマーカー名を指定します。マーカー名はCaseセンシティブなので、大文字小文字が違うと違うマーカー名と認識されることに注意してください。バーのインデックス値は省略するとインデックス値を0として呼び出した事になります。

// 更新期間、"Update"の測定開始
timerRuler.BeginMark( 0, "Update", Color.Blue );

// Updateの処理をここでする
...

// 更新期間、"Update"の測定終了
timerRuler.EndMark( 0, "Update" );

BeginMarkは以下のコードのように階層的に呼び出すこともできます。デフォルトでは最大３２階層になっていますが、TimeRuler.MaxNestCall定数値を変更することができます。ただし、Begin A, Begin B, End B, End Aのように呼べますが、Begin A, Begin B, End A, End Bのように呼ぶことはできません。

timerRuler.BeginMark( "Update", Color.Blue );

    timerRuler.BeginMark( "Character Update", Color.Azure );

        timerRuler.BeginMark( "Character Animation", Color.BurlyWood );
        // キャラクターアニメーション処理
        ...
        timerRuler.EndMark( "Character Animation" );

        timerRuler.BeginMark( "Character Collision", Color.DarkOrchid );
        // キャラクターコリジョン処理
        ...
        timerRuler.EndMark( "Character Collision" );

    timerRuler.EndMark( "Character Update" );

timerRuler.EndMark( "Update" );

TRACE定数でTimeRuler機能のコントロール

TimeRulerはその性質上リリースビルドでも動作するようになっていますが、実際にゲームをリリースするときには実行する必要はありません。ゲームコード内に埋め込んだBegin/EndMarkを手で消したりするのはあまりにも不効率過ぎるので、簡単にそれらのメソッドの呼び出しを制御するためにTimeRulerの殆どのメソッドにはConditional属性を使ってTRACE定数が宣言されているときのみに呼び出されるようになっています。TRACE定数はプロジェクトプロパティのビルドタブにある「TRACE定数の定義」のチェックボックスによってコントロールすることができます。

C/C++ではコンパイラ最適化の一つとして呼び出し先が空の関数の場合には関数呼び出しのコードを生成しないようになっていますが、.Netでは呼び出するメソッドが空のメソッドであっても、メソッド呼び出しコードを生成します。代わりにConditional属性を使い、指定された定数が宣言されていない場合は、そのメソッドに使われた引数も含めて呼び出しコードを生成しないようになっています。

マシン性能のクセを知る

ここではTimeRulerなんていう格好つけた名前をつけてはいますが、同様の仕組みは8ビット機時代から使われていたものです。例えばPCエンジンでは、あるパレットの色を変更するとTVの画面外の色を変更することができるので、処理毎に色を変えることで画面の両脇に縦に伸びるバーを作ることができました。

実装方法は変わりましたが、バーが振り切らないようにゲームを作るという目的は今も昔も一緒です。特に、最近のシステムでは幾重ものパイプラインステージやキャッシュといった複雑な仕組みがあるので、必ずしもコード量が実行速度に比例するわけではありません。ですから、常にTimeRulerを使うことでどの処理がどれくらいの負荷になるのかを実感できることができます。

次回はデバッグコマンドを紹介します。

FPSカウンター

Yuichi Ito — Sun, 28 Dec 2008 04:20:00 GMT

注:今回紹介するコンポーネントはデバッグサンプルに入っています。

正確な測定には注意が必要

FPSカウンターは、一定時間内に(数秒程度)何フレーム更新できたかを計測した結果から、１秒間のフレーム数、FPS(Frame Per Second)を表示するという、非常に簡単な機能です。

ですが、正確なFPSを測定するには幾つかの注意が必要です。Game.IsFixedTimeStepの既定値はtrueになっているので、ゲームの更新と描画に掛かる時間が1msだとしても、見かけ上は16.6ms、つまり60FPSになってしまいます。また、描画時にV-Syncに同期するようになっているので、IsFixedTimeStepだけをfalseにしてもやはり60FPSになってしまいます。

FPSを正しく測定するにはゲームクラスのコンストラクタ内で以下の様なコードを実行する必要があります。

graphics = new GraphicsDeviceManager( this );

graphics.SynchronizeWithVerticalRetrace = false;
IsFixedTimeStep = false;

これでFPS自体は正しく測定することができますが、IsFixedTimeStepをfalseに変更するということは、ゲームの更新の仕方が固定更新から、可変更新に変えるということです。もし、キャラクターを移動するコードが以下の様になっている場合に可変更新に変更すると、キャラクターの移動が速すぎてゲームがプレイ不可能になる場合があります。

pos += speed;

この問題を解決するには以下の様に、経過時間によって移動するようなコードになっている必要があります。

float dt = (float)gameTime.ElapsedGameTime.TotalSeconds;

pos += speed * dt;

固定更新、可変更新の振る舞いの違いについては、この投稿が参考になると思います。もし、既に固定更新でゲームを作っている場合にはFPSカウンターを使う意味はあまりありません。

GPUとCPUバランスに注意

また、CPUとGPUの負荷バランスが違う場合には、FPS値は参考になりません。例えば６０フレームのゲームを作っている時にFPS値が丁度６０フレームになっているからといって、必ずしもこれ以上の処理を追加できないと言うわけではありません。例えば、１フレームあたりの処理時間が、CPUが50%、GPUが100%近く消費している場合、CPU側にはまだ５０%の余力があるにも関わらずFPSの値は６０になるので、余力が無いように見えてしまいます。逆にCPU100%、GPU50%の状態でも同じです。

CPU、GPUバランスを調べる簡単な方法は、GPUの負荷を測定するにはUpdate内では何も処理をせずにDrawだけ実行し、CPUの負荷を測定するには逆にDrawの処理をしないようにする方法があります。ただし、Draw内にもCPU部分の処理があるので、もっと正確にCPUの負荷を測定するにはDrawPrimitiveのメソッドのみをコメントアウトする必要があります。

６０FPSにならないんだけど

IsFixedTimeStepとSynchronizeWithVerticalRetraceをtrueにした状態で、明らかにゲーム全体の処理が16.6ms以内で済んでいるのにも関わらず、FPSにはいつも59.xxしか表示されない。というのはおかしいと思う人もいるかもしれません。

これには３つの理由があります。ひとつめはTVの60フレームというのは実際には59.94(厳密に言えば60/ 100.1%)になるので、理論的に60と言う数値にはならないこと。ふたつめは、測定する場合に１フレーム以下の余りの時間分で誤差がでるということ。そして、ハードウェア的には59.94でフレームを更新していても、ソフトウェア的に測定ポイントまで戻ってくるまでの時間が微妙に変わってくるということです。

ですから、59.xxと言う数値を見たときには約60FPSと考えても問題ありません。

FpsCounterコンポーネントの使い方

FpsCounterコンポーネントはDebugManagerにあるフォントを使用するので、FpsCounterを追加する前にDebugManagerコンポーネントを追加する必要があります。

// デバッグマネージャーの初期化と追加
debugManager = new DebugManager( this );
Components.Add( debugManager );

また、必須ではありませんが、FpsCounterはインスタンス生成時にGame.ServicesにIDebugCommandHostインターフェースが追加されていると、fpsデバッグコマンドを登録します。DeubgCommandUIはIDebugCommandHostインターフェースを実装しているので、このコンポーネントを追加した後にFpsCounterを追加することでfpsコマンドを使うことができます。

デバッグコマンドUIをTabキーを押して表示させた後に、fpsとタイプするとFPSの表示/非表示の切り替え、"fps on"で表示、"fps off"で非表示にすることができます。

// デバッグマコマンドUIの初期化と追加
debugCommandUI = new DebugCommandUI( this );

// デバッグコマンドUIを最上面に表示させる為にDrawOrderを変更する
debugCommandUI.DrawOrder = 100;

Components.Add( debugCommandUI );

最後に、FpsCounterをComponentsに追加することでFPSが画面左上に表示されるようになります。ただし、DebugCommandUIが先に登録されていると、初期状態では表示されません。

// FPSカウンターの初期化と追加
fpsCounter = new FpsCounter( this );
Components.Add( fpsCounter );

FpsCounterはDrawableGameComponentから派生しているので、プログラム上から表示/非表示をコントロールするにはVisibleプロパティを変更することでできます。

fpsCounter.Visible = true

次回はリアルタイムプロファイラーであるTimerRulerコンポーネントを紹介します。

招待サンプル

Yuichi Ito — Wed, 26 Nov 2008 04:38:00 GMT

今日は招待サンプルを紹介します。

Xbox Live!の機能のひとつに、フレンドリスト内の友達と一緒にネットワークゲームをプレイしたいときに誘える招待機能があります。XNA GS 3.0ではこの招待機能がサポートされています。招待するケースとしては以下の二つのケースがあります。

同じゲームをプレイしている時(In-Title Invites)
違うゲームをプレイしている時(Cross-Title Invites)

XNA GS 3.0上では、このどちらのケースでもNetworkSession.InviteAcceptedイベントが発生します。このイベントを受け取った時に、NetworkSession.JoinInviteメソッドを呼ぶことで招待された側が招待した側のセッションに接続できるようになっています。以下はイベントハンドラへの登録と、ハンドラ内での処理の例です。

NetworkSession.InviteAccepted += InviteAcceptedEventHandler;

void InviteAcceptedEventHandler(object sender, InviteAcceptedEventArgs e)
{
    // 現在のセッションから抜ける
    if (networkSession != null)
    {
        networkSession.Dispose();
        networkSession = null;
    }

    // 招待されたセッションに入る
    networkSession = NetworkSession.JoinInvited(maxLocalGamers);
}

同じゲームをプレイしている場合は、通常のNetworkSessionの振る舞いと殆ど同じですが、違うゲームをプレイしている場合は振る舞いの仕方が変わってきます。ただし、これらの処理は全てOS側で行われるのでゲーム開発者は前述のInviteAcceptedイベントの実装をするだけです。

Xbox 360上で同じゲームが既にインストールしている場合は自動的にゲームが起動され、その直後にInviteAcceptedイベントが発生します。
クリエーターゲーム(開発中のゲームやピアレビュー中のゲーム)の場合は、招待した人が同じゲームを持っていない場合に、その旨を伝えるメッセージが表示されます。
コミュニティゲームの場合、ユーザーがそのゲームを持っていない場合はマーケットプレースに自動的に移動、該当するゲームをダウンロードするかのメニューが表示され、ダウンロード後に自動的にゲームが起動されます。
Windows上の場合、上記のように自動的なダウンロードや起動するといった機能がないので、ユーザーが手動で行う必要があります。

テスト時の注意

招待機能はXbox Live!の機能なので、ネットワークゲームのテストの様にシステムリンク(ローカル)を使ってテストできるのと違い、クリエータークラブ会員になっているゲーマータグが二つ必要なことに注意してください。

セーフエリア・サンプル

Yuichi Ito — Sat, 22 Nov 2008 06:45:00 GMT

今回はセーフエリアサンプル(Safe Area)の紹介をします。

世の中には様々なTVがある

ゲームをプレイする人達のTV環境は実に様々なものがあります。

オーバースキャンとアンダースキャン
HDTVとSDTV
ワイドスクリーンと4:3
コンポーネント接続とコンポジット接続
60cm(2フィート)と3m(10フィート)

オーバースキャンとセーフエリア

PCモニタなどのイメージ全体を表示するアンダースキャン方式に対して、HDTV、SDTVのどちらも、その多くがイメージ全体を表示することのできないオーバースキャン方式を採用しています。

イメージ全体を表示することができないので、ゲームでスクリーン座標の左上(0, 0)に文字を表示したりするとオーバースキャン方式のディスプレイでは文字が読めなくなってしまいます。

こういったオーバースキャン方式のディスプレイには以下の二つのタイプのセーフエリアがあります。

タイトルセーフエリア(80%の領域)
アクションセーフエリア(90%の領域)

タイトルセーフエリアには文字などの大事な情報を表示する領域で、下図の青い色の領域になります。アクションセーフエリアは殆どのディスプレイで表示される領域です数では緑色の枠内の領域になります。そして、赤い部分はディスプレイによっては全く表示されない領域です。

この画像は1280x720の画像なので、ゲームのインターフェースのデザインなどをするときにガイドラインとして使えるようになっています。

さて、タイトルセーフエリアに大事な情報を表示するからといって、Xbox 360、PCの両方で文字列をタイトルセーフエリアに描画した場合、Xbox 360上での見た目は良いとしても、PC上だと無駄にまわりのスペースが空いてしまいます。

そこで、XNA GS 3.0から追加されたViewport.TitleSafeAreaプロパティを使います。このプロパティPC上では元のビューポートのサイズと一緒になりますが、Xbox 360上ではビューポートの80%の領域、つまりタイトルセーフエリアを返します。

Safe Areaサンプル内にあるAlignedSpriteBatchクラスでは文字列をタイトルセーフエリアの右端、左上といった位置情報を指定して描画できるようになっています。

また、SafeAreaOverlayはコンポーネントになっていて、Xbox 360、デバッグの設定の時のみにタイトルセーフエリアの外側の領域を赤く表示するようになっています。

実際のゲーム開発の場合に気をつける事としては、

3Dゲームの場合、操作するキャラクターが画面中央に描画しているかぎりはセーフエリアを気にすることがありません。
スクロールタイプの2Dゲームの場合、メインキャラクターはタイトルセーフエリア内に表示するようにします。サンプルでは猫を移動することで画面をスクロールするようになっていますが、猫は常にタイトルセーフエリア内にいます。
通常は全ての画面全体を描画するべきですが、シューティングゲームのようなものだと、あらかじめアクションセーフエリア外の部分を黒く表示して自機の移動範囲を判りやすくするという方法もあります。
インターフェースの全てをタイトルセーフエリアに納める必要はない。下図はRoboGameをXbox 360上で実行したときの画面にセーフエリアを重ねた画像です。ゲームプレイにとって大事なプレイヤーのHPや武器の残弾数などの表示はタイトルセーフエリアに表示されていますが、ゲームプレイに支障のないインターフェースのデザイン的な部分はアクションセーフエリアに表示されています。

解像度とアスペクト比

TVモニタの場合は標準解像度の640x480から、1080pの1980x1080まで様々な種類があり、またアスペクト比も16:9と4:3の二種類があります。

Xbox 360向けのゲームで様々な解像度とアスペクト比に対応するもっとも簡単な方法は720p、つまり1280x720を使うことです。Xbox 360には1/4～4倍の解像度にスケーリングしてくれるハードウェアがあるので、720pを設定するとどの解像度でも自動的にスケーリングしてくれます。また、720pのアスペクト比は16:9ですが、4:3のTVを使った場合にはTV上では以下のようにレターボックス表示になります。

モニタとの距離

ゲーム開発中、PCモニタとの距離は60センチ程度ですが、実際にリビングルームでゲームをする場合は3メートル程の距離があります。と、米国では言ってますが日本の住宅事情を考えると、もうちょっと短い距離になりそうですが、要点としては自室でPCモニタを見ている感覚でゲームを作ってしまうと、リビングルームでプレイする時に文字が小さくて読めないという問題が発生します。目安としては720pの解像度で20ポイント以上の大きさの文字列をつかうことです。

TVとの距離の他にも

細い線を描画しない、特に水平線を書いた場合にインターレース方式のTVではちらつきが発生します。
明るい赤い文字を使用しない。NTSCの場合、にじみの原因になります。
大事な情報は色だけでなく、サイズや形を変えたり、アニメーションするようにする。これは赤と緑の色の区別がつきにくいという色覚障害が日本人では男性の20人に１人、女性は500人に１人という低くない割合でいるので、こういった配慮をすることでより多くの人達が快適に遊べるようになります。パズルゲームで色を合わせるといった場合は、色だけでなく模様や形状を変えると良いでしょう。

レイアウトに注意

3Dゲームのシーンを描画する時には気にする必要はあまりありませんが、メニュー画面などをデザインする時にはセーフエリアを意識してデザインする必要があります。特に、パズルゲームやテーブルゲームなどの固定画面型の2Dゲームの場合にはレイアウトがそのままゲームプレイに影響するので、画面一杯使ってレイアウトした結果、TV上ではゲームをプレイするのが不可能になってしまったなんて事にならないよう注意しましょう。

元ネタ:Safe Areaに含まれるドキュメントファイルから

ローカライゼーション・サンプル

Yuichi Ito — Mon, 17 Nov 2008 13:59:00 GMT

Creators Club Onlineに以下の３つの新しいサンプルが追加されました。

一気に紹介すると長くなるので、三回に分けてそれぞれのサンプルを紹介していきます。今回はローカライゼーションサンプルについて紹介します。

ローカライゼーション

コミュニティゲームでゲームを投稿する場合、配信地域を選ぶことができます。現状ではアメリカ、カナダ、イギリス、フランス、イタリア、そしてスペインの６カ国で、2009年の前半には日本が加わり７カ国になります。世界の複数の国々の人達に自分の作ったゲームを楽しんで貰うためには必要な作業としてローカライズがあります。そこで、このサンプルではローカライズされた文字列とアセットの使い方のコードが含まれています。

ローカライズされた文字列表示

このサンプルでは言語別のリソースファイル(.resxファイル)を用意し、ゲームクラスコンストラクタの中で実行環境の言語情報を以下のコードのように指定して文字列を変更しています。

Strings.Culture = CultureInfo.CurrentCulture;

SpriteFontDescriptionクラスから派生したLocalizedFontDescriptionクラスに複数のリソースファイルを指定できるようになっていて、ここに各言語の文字列が入ったリソースファイルを指定し、コンテント･パイプライン内でLocalizedFontProcessorによって変換されます。

言語別のリソースファイルは、リソース名.言語コード.resxのようになっています。このサンプルではリソース名がStringsになっていて日本語のリソースファイル名はStrings.ja.resxとなっています。この言語コードはISO 639-1で定義されているアルファベット２文字になっています。

殆どの場合は言語コードを指定するだけで済むのですが、言語コードだけでは足りなくなる場合もあります。例えば、同じ英語でもアメリカの場合はcolorでもイギリスの場合はcolourと違いがあります。その場合は言語コードと国名コードの組み合わせを使います。国名コードはISO 3166-1で定義されているアルファベット２文字を使います。アメリカの英語の場合はen-US、イギリスの英語の場合はen-GBとなります。

この言語コード-国名コードの組み合わせをカルチャ名と呼び、カルチャを表すCultureInfoクラスを生成する時に以下のコードのようにして使用します。

Strings.Culture = new CultureInfo("en-GB");

ローカライズされたアセット読み込み

ローカライズ作業の大半は文章の翻訳になりますが、中にはテクスチャ等のアセット自体をローカライズしたい時があります。このサンプルでは読み込むアセット名を前述のリソースファイル名と同じように、アセット名.カルチャ名の組み合わせであることを前提として使うGetLocalizedAssetNameメソッドがゲームクラスに宣言されていて、国別の国旗テクスチャを変更しています。

以下はコミュニティゲームがサポートする国と言語の表です。

国名	公用語	言語コード	国名コード	カルチャ名
アメリカ	英語	en	US	en-US
カナダ	英語、フランス語	en,fr	CA	en-CA,fr-CA
イギリス	英語	en	GB	en-GB
フランス	フランス語	fr	FR	fr-FR
イタリア	イタリア語	it	IT	it-IT
スペイン	スペイン語	es	ES	es-ES
日本	日本語	ja	JP	ja-JP

特徴として、カナダでは公用語が英語とフランス語の２つの言語が使われていることです。

このサンプルは複数の言語へのローカライズの参考にもなりますが、リソースファイルを使った日本語表示の方法としても参考になるサンプルだと思います。

XNA Game Studio Connect関連の新機能

Yuichi Ito — Fri, 31 Oct 2008 13:48:00 GMT

XNA Game Studio Connectに関連する新機能として以下の二つがあります。

スクリーンキャプチャー機能
配置の高速化

スクリーンキャプチャー

以前から要望として多かった機能の一つとしてXbox 360上で動作しているゲームのスクリーンキャプチャーがあります。XNA GS 3.0ではこのスクリーンキャプチャーが使えるようになりました。

スクリーンキャプチャーはゲームをデバッガにアタッチした状態、つまりVisual Studio上からF5キーを押して実行した時と、XNA Framework Remote Performance Monitorを使った時にしか使えないことに注意してください。

キャプチャ自体は非常に簡単でXNA Game Studio Device Centerでキャプチャーしたいデバイスのアイコンの右クリックメニューからTake Screen Captureを選択するだけです。

スクリーンキャプチャーされた画像はピクチャフォルダにデバイス名-番号というファイル名、PNG形式で保存されます。複数のスクリーン画像を続けてキャプチャーすると、デバイス名-1.png、デバイス名-2.pngといった感じに複数の画像ファイルが作られます。

Xbox 360上で動作しているゲーム画面をブログなどで紹介するときには、今まではデジカメで画面を撮ったり、自前でキャプチャープログラムを書かないといけませんでしたが(こんな方法もあったりしました)、これからはキャプチャー、ブログ書き込みプログラム上にドラッグ＆ドロップするだけで、以下のようなスクリーンショットをブログに載せることが簡単になりました。

配置の高速化

XNA GS 2.0以前ではXbox 360上でゲームを開発している時にゲームの配置、特にコンテントの配置に時間が掛かるという問題がありました。XNA GS 3.0ではこの問題を解決するために二つの改良が施されました。

一つ目はファイルの圧縮です。

XNA GS 3.0ではプロジェクトプロパティにContent Buildタブが追加され、その中にコンテントパイプラインの出力ファイルの圧縮オプションが追加されました。

デフォルトではWindows用プロジェクトでは圧縮せず、Xbox 360用プロジェクトでは圧縮するようになっています。Windows用とXbox 360用のプロジェクトでデフォルトの設定が違うのは次の理由があります。PCにはXbox 360より高速で大容量なHDDがあり、圧縮に掛かる時間に見合うだけのメリットが少ないのに対して、Xbox 360ではコミュニティゲームの150MBという容量制限があるのと、圧縮した方がコンパイルと配置の全体時間の短縮になるからです。もちろん、このオプションは自由に変えられるようになっています。

圧縮率はコンテントによって左右されますが、通常は元のサイズの70%～50%程度です。中には元のサイズの25%まで圧縮されたというケースもありました。この圧縮効果によって、配置に掛かる時間は三割から二倍程度速くなりました。

そして、二つ目は配置用のプログラムのチューニングです。

XNA Game Studio Connectの待機画面では、メインスレッド以外の5つのスレッドは暇を持て余していたので配置プログラムをマルチスレッド用に特化させることで配置に掛かる時間が大幅に短縮されました。

この二つの相乗効果によって、Xbox 360へのコンテントの配置が劇的に速くなりました。

XNA Game Studio 3.0がリリース

Yuichi Ito — Fri, 31 Oct 2008 11:54:00 GMT

XNA Game Studio 3.0がリリースされました。ここからダウンロードすることができます。細かい注意点などはReadmeページが参考になりますが、ここではPCへのインストールと、Xbox 360用の新しいXNA Game Studio Connectの導入の仕方について説明します。

XNA Game Studio 3.0がサポートしてる開発環境はVisual Studio 2008とVisual C# 2008 Express(無償)です。これらの開発環境を持っていない場合はXNA Game Studio 3.0をインストール前にあらかじめインストールする必要があります。

XNA Game Studio 3.0 Beta版をインストールした人への注意点

XNA Game Studio 3.0のベータ版をインストールしてた人は、リリース版をインストールする前にベータ版をアンインストールする必要があります。ベータ版がアンインストールされていない状態でリリース版をインストールしようとすると以下のメッセージが表示され、インストールが終了します。

ベータ版では以下の3つのコンポーネントがインストールされています。

Microsoft XNA Framework Redistributable 3.0(Beta)
Microsoft XNA Game Studio 3.0(Beta)
Microsoft XNA Game Studio Platform Tools(Beta)

これらのコンポーネントを全てアンインストールしてください。特に３番めのコンポーネントはアンインストールし忘れることが多いようです(私もよく忘れてました)。

XNA Game Studio Connectの導入について

Xbox 360上でゲームを開発するには、1.0と2.0で別々のプログラムを実行する必要がありましたが、3.0の新しいXNA Game Studio Connectは2.0と3.0の両方のゲームを実行、開発することができます。

Xbox 360の通常のゲームの場合、ゲームのバグなどを修正することができるタイトルアップデートという仕組みがありますが、新しいXNA Game Studio Connectはバグ修正ではないこと、そしてタイトルアップデートの枠内に収まりきらないということで、新しいXNA Game Studio Connectをインストールするには古いXNA Game Studio Connectを消して、新しいXNA Game Studio Connectをダウンロードするという二つのステップを踏む必要があります。

古いXNA Game Studio Connectを消す

古いXNA Game Studio Connectを起動しようとすると、アップデートを促す画面が表示されるだけになっています。

Xbox 360のダッシュボード画面のゲームブレード内で、ゲームライブラリーを選択、そしてマイゲームを選択する
XNA Game Studio Connectを選択し、ゲームを消すを選択する。

重要:新しいXNA Game Studio Connectをダウンロードする前に、古いXNA Game Studioを消すようにしてください。新しいXNA Game Studio Connectをダウンロードした後に古いXNA Game Studio Connectを消した場合、Xbox 360自体がフリーズするので電源ボタンを押して電源を切る必要があります。

新しいXNA Game Studio Connectをダウンロードする

Xbox 360のダッシュボード画面のマーケットプレースブレード内でゲームストアを選択し、すべて: ゲームを選択。
XNA Creators Clubを選択後にXNA Game Studio Connectを選択。ダウンロードしなおすを選択すると、新しいXNA Game Studio Connectがインストールされます。

先に新しいXNA Game Studio Connectをダウンロードしてしまうと、画面上には二つのXNA Game Studio Connectが表示されますが、新旧のXNA Game Studio Connectではアイコンが違うので見分けがつきます。


新しい	古い

ClickOnce その２

Yuichi Ito — Thu, 23 Oct 2008 07:29:00 GMT

スタートメニューの登録名を変更する

デフォルトの状態でClickOnceを使うと、インストール時にスタートメニューにはプロジェクト名/プロジェクト名のように登録されます。前回の例ではSuperCatsというプロジェクトを作ったので、SuperCats/SuperCatsのようになります。

この設定の変更はプロジェクトプロパティの発行タブで行います。

発行タブページは上図のようになっていて、この中のオプションボタンを押すと、以下の発行オプションダイアログが開きます。

このダイアログ内の発行者名と製品名を変更することで、スタートメニューには発行者名/製品名のように登録されます。ここでは、発行者名を「ひげねこ」、製品名を「超猫」とします。

この状態で発行されたパッケージをインストールすると、上図のようになります。

配置マニフェストにマシン名とユーザー名が記載されるのを防ぐ

ここでは、デフォルトの状態で配布するパッケージにはパッケージを作ったマシン名と、ユーザー名が含まれている問題を解決する方法を紹介します。これでも構わないと言う人は読み飛ばして下さい。

アプリケーションを発行すると、発行先のフォルダにはアプリケーション名.applicationという配置マニフェストファイルが生成されます。このファイルはXMLファイルで中には発行者の情報が書かれおり、デフォルトの状態では発行者の情報はマシン名/ユーザー名のようになります。

なぜこうなっているかを簡単に説明すると、ClickOnceは発行者が発行したアプリケーションが第三者によって発行者の意図しない変更がされるのを防ぐために電子署名をするようになっていて、配置マニフェストには署名に使われた証明書の発行者名が記載されるようになっているからです。

デフォルトでは自動的に電子署名が作られ、上図のようにプロジェクトにテンポラリ証明書が追加されます。

この証明書の詳細は、プロジェクトプロパティの署名タブで見ることができます。上図では、私がテストに使っているノートブックのマシン名とユーザー名が発行者情報になってしまっています。

殆どの場合は問題ないのですが、個人的な情報、例えば彼女やお嫁さん(現実、非現実含む)の名前とかをマシン名やユーザー名に使ってい場合には、その情報をネットに流出するといろいろと問題があるという人も居ると思うのでここでは電子証明書の生成のしかたを紹介します。

個人でゲーム制作をしている場合、電子証明書を取得するには以下の二種類が考えられます。

VeriSignなどの電子証明書発行サービスを利用する(有料)
自己署名証明書を作る

作ったゲームを商品として販売するには1にするべきですが、ここでは自己署名証明書の作り方を紹介します。ただし、この証明書は誰にでも作ることができるので信頼できる証明書では無いことに注意して下さい。

証明書を作るにはmakecert.exeを使います。このツールは.Net Framework SDKやWindows SDKに付属しています。SDKのコマンドプロンプトを開いて、以下のコマンドを実行します。

makecert -r -n "CN=John Smith" -b 01/01/2008 -e 12/31/2008 -sky exchange -ss my

それぞれのオプションの意味は以下のようになっています。

-r	自己署名証明書を作成
-n	X.500 標準に準拠した証書名、ここでは発行者名を"John Smith"としている。
-b	証明書の有効期間開始日月/日/西暦で表される
-e	証明書の有効期間終了日月/日/西暦で表される
-sky	サブジェクトのキーの種類
-ss	作成した証明書を格納するストア名

ここでは、発行者名を"John Smith"としましたが、自分の好きな名前に変更することができます。また、Windows OSには電子証明書を入れておくストアと呼ばれる金庫のようなものがあり、ここでは生成した証明書をこのストアに格納しています。

証明書を作ったら、プロジェクトプロパティの証明タブにあるストアから選択ボタンを押して以下の証明書選択ダイアログを表示します。

ここに、先ほど作った証明書が表示されるので、使いたい証明書を選びます。署名タブに選択した証明書が表示されているのを確認したら、発行タブを開いて、今すぐ発行ボタンで発行すると配置マニフェストには新しい発行者が記載されることになります。

まとめ

二回に渡って、ClickOnceの使い方を簡単に紹介してきました。ClickOnceはもともと.Net 2.0から導入された.Netベースのアプリケーションを簡単に配布する為の仕組みです。より細かい仕組みについて興味がある人は以下のURLが参考になると思います。

ClickOnceの真実
http://www.atmarkit.co.jp/fdotnet/clickonce/index/index.html

ClickOnceを使うことで手軽にXNA Game Studio 3.0で作られたゲームを配布することができ、配布先でも必須コンポーネントを自動的にインストールしてくれるので、ゲームを遊ぶ側の負担が大幅に減っています。

また、ClickOnceのサポートに伴ってXNA Framework 3.0のランタイムを必須コンポーネントとしてインストーラープロジェクトから参照できるようになったのでClickOnceではサポートされていない細かいカスタマイズを含むインストーラーも作りやすくなっています。

ClickOnce その1

Yuichi Ito — Sat, 18 Oct 2008 04:36:00 GMT

XNA Game Studio 3.0の新機能の一つにClickOnceのサポートがあります。今まではWindows用に作ったゲームを配布するには多くのランタイムを手動でインストールする必要があり、非常に不便だった問題を解決するためのものです。

ClickOnceの他にも、Visual Studio上でプログラムインストール用のプロジェクト用のコンポーネントも用意されているので、簡単にXNA Game Studioで作られたゲームを再配布できるようになりました。

今回は、ClickOnceを使ったゲーム配布の流れを紹介します。

配布用のパッケージ作成
パッケージの内容
インストール時の振る舞い
注意点

ゲーム配布用のパッケージを作る

ゲームが完成したら、Visual Studio 2008上のビルドメニューから{プロジェクト名}の発行を選択します。ここでは例としてSuperCatsという名前のプロジェクトを使います。

以下の様な発行ウィザードが表示されます。もっとも手っ取り早い方法は、アプリケーションを発行する場所を適当な位置を指定した後に、完了ボタンを押すだけでプロジェクトのビルドと、配布用のパッケージが作られます。

パッケージの内容

ウィーザードで発行先に指定したフォルダ(ここではtmp/public)には以下のフォルダやファイルが作られます。

Application Filesフォルダ
setup.exe
{プロジェクト名}.application

パッケージ全体のサイズは元々のゲームのサイズ+500KB程度になります。注:ベータ版では+5MB程になっていました。

後はこの二つのファイルとフォルダをzipファイルなどにまとめて自分のサイトにアップするだけです。

インストールの振る舞い

配布用のパッケージをダウンロードし、setup.exeを実行するだけで、ゲームのインストール、そして実行までが自動的に行われます。

この時、setup.exeはゲームを実行するのに必要な以下のコンポーネントがインストールされているかをチェックします。

.Net Framework 3.5
XNA Framework 3.0

もし、これらのランタイムがシステムにインストールされていない場合は、自動的にそれらのコンポーネントをネットからダウンロードし、インストールします。.Net Framework 3.5をインストールしていない環境の場合、最初のインストールに時間が掛かる事に注意して下さい。

XNA GS 2.0の時にはフレームワークが使っているDirectXのランタイムは別途インストールする必要がありましたが、XNA GS 3.0ではそれらのコンポーネントもXNA Framework 3.0のランタイムにまとめられています。

また、インストールされたプログラムはデフォルトの状態ではスタートメニューにのプロジェクト名のフォルダと、その下にショートカットが作られます。

アンインストールする場合は、他のアプリケーションと同じようにプログラムの追加/削除メニューからアンインストールすることができます。

注意点

ClickOnceのサポートによってゲームの配布が簡単になりましたが、残念ながらGame for Windows Liveのランタイムは再配布パッケージの中には含まれないので、ネットワーク対応のゲームやGamerServices名前空間の機能を使っているゲームを他のマシンで遊ぶにはXNA GS 3.0をインストールする必要があります。

また、今回紹介した方法だと.applicationファイル内に発行したマシン名とユーザー名の情報が記録されるので、これらの情報を公開したくない人は注意して下さい。この解決方法と、スタートメニューに登録される名前をプロジェクト名から好きな名前に変更する仕方などは次回紹介します。

XNA Game Studio 3.0のリリース日が正式決定

Yuichi Ito — Sat, 18 Oct 2008 02:58:00 GMT

XNA Game Studio 3.0のリリース日が正式決定されました。

北米西海岸時間で１０月３０日、日本時間の１0月30日の夕方～31日早朝頃までにリリースされます。

また、１１月の１９日のXbox 360アップデートと同時に北米、カナダ、イギリス、フランス、イタリア、そしてスペインの6カ国でコミュニティゲームが正式運用開始になります。

コミュニティゲームへ投稿するゲームはXNA GS 3.0で作られている必要があるので、サービスが開始される国に住んでいて、サービス開始初日にゲームを投稿したい人達にとっては20日間ほどの2.0から3.0へ移行、そしてテスト期間があります。

日本でも来年前半にコミュニティゲームが正式運用される予定なので、日本への配信はもちろん、世界へ向けての配信もできるので自分の作ったゲームを配信してみたいという人は是非3.0を使ってみて下さい。

XNA Game Studio 3.0 CTP公開

Yuichi Ito — Thu, 08 May 2008 03:51:00 GMT

XNA Game Studio 3.0 Community Technical Preview (CTP)が公開されました。CTPは正式リリースでは無くベータの前段階、つまりアルファ版といった感じです。主な機能は以下のようになっています。

Zuneのサポート(市販のZuneがあれば無料でゲーム作成できる)
- SpriteBatchベースのグラフィクス
- Ad-hoc WiFiのサポート(既存のネットワークAPIがそのまま使える)
- メディアライブラリAPI
Visual Studio 2008のサポート
wav,mp3,wmaなどのオーディオメディアの再生機能

Zuneは北米で発売されている携帯メディアプレイヤーで、それに合わせてXNAフレームワークにはZune内にあるオーディオファイルの列挙と再生ができるAPIが追加されています。

ZuneはXACTがサポートされていませんが、変わりにシンプルなオーディオ再生機能であるSoundEffectクラスが追加され、この機能はWindows上でも使うことができます。このSoundEffectはメモリから効果音などを再生するのに適しています。そして、BGMなどに適しているのは新しく追加されたSongクラスです。

どちらの場合も、他のコンテントと同じくプロジェクトにwav,mp3,もしくはwmaファイルを追加することで実行時に使用することができます。

using Microsoft.Xna.Framework.Media;

Song song = Content.Load<Song>("MySong");
MediaPlayer.Play(song);

この新しく追加されたAPIによって、XACTを介さずにオーディオ再生ができるようになりましたが、これらはXACTの機能を完全に代替するわけではないので、3DオーディオやRPCといつたより複雑な処理をする為には今まで通りXACTを使う必要があります。

Visual Studio 2008のサポートはXNA GS 3.0はC#をサポートしているVisual Studio 2008のどのエディションでも使うことができ、それにはVisual C# 2008 Express Edition(無料)も含まれています。

他にXNA GS 3.0 CTPを使うのに必要なのこととして

VS 2008かVisual C# 2008 Express Editionが必要。XNA GS 3.0はVS 2005はサポートしません。XNA GS 3.0は XNA GS 2.0とサイド・バイ・サイドで動作するので、XNA GS 3.0を使うのにVS 2005をアンインストールする必要はありません。
CTP版ではXbox 360をサポートしておらず、WindowsとZuneのみの対応になっています。Xbox 360で開発するにはXNA GS 2.0を使う必要があります。
現状ではZune開発環境は64bit版OS上では動作しません(Zuneとの接続に失敗する)。

と、いうわけでCTPの主な機能はZuneサポートに関するものですが、VS2008対応とオーディオメディア再生機能は他のプラットフォームでも使える機能なので、ホリデーシーズンの正式リリースまで待てないという人にはダウンロードする価値はあると思います。

XNA GS 3.0 CTPは以下のリンクからダウンロードできます。

http://www.microsoft.com/downloads/details.aspx?FamilyId=DF4AF56A-58A7-474C-BFD0-7CF8ED3036A3&displaylang=en

XNA Game Studio 3.0の新機能

Yuichi Ito — Thu, 21 Feb 2008 02:20:00 GMT

GDC2008で、XNA Game Studio 3.0の新機能の１つが発表されました。それはWindows、Xbox 360に加えて新たにZuneがサポートされるようになったことです。

日本では未発売のものですが、Zuneは携帯メディアプレイヤーですが他のプラットフォームと同じようにXNA Game Studioを使ってゲーム開発をすることができます。Xbox 360のように贅沢なGPUとかは搭載していませんし、スクリーンの解像度は違いますが、2Dベースのゲームであれば他のプラットフォームで書いたコードがほぼそのまま使えるようになっています。

そして、Zune独自の機能として自分のお気に入りの音楽をゲーム中にBGMとして流したり、映像データをテクスチャとして使うことができるメディアAPIが追加されました。

XNA Game Studio 3.0は春頃にレビューリリース予定で、最終リリースは今年のホリデーシーズンを予定しています。