ひにけにXNA : ゲーム開発

アバターを使おうその4:カスタムアニメーション

Yuichi Ito — Wed, 22 Jul 2009 04:35:00 GMT

Creators Club Onlineサイトでアバターのカスタムアニメーション関連のサンプル等が公開されました。内容的には以下の三つになります。いずれもプレミアムコンテントになっているので、ダウンロードするにはCCO会員になっている必要があります。

Custom Avatar Animation Sample

このサンプルではアバターを自分のゲーム内で自由にアニメーションさせるための有用な情報が提供されています。3Dモデリングツール上でアニメーションリグを使って作ったアニメーションデータを作り、カスタムコンテントプロセッサーを介してFbxファイルから読み込み、CustomAvatarAnimationPlayerを使って任意のアニメーションをゲーム内で再生するという流れになっています。

Avatar Animation Rig

キャラクターアニメーションを作るときにひとつひとつのボーンをアニメーションさせるのは非常に面倒で時間の掛かる作業なので、その作業時間を軽減するためにリグ(Rig)と言われるものを使います。ここではMayaとSoftimage Mod Tool用のアニメーションリグをダウンロードすることができます。

Softimage Mod Toolの画面

Maya 2008上での画面

Avatar Animation Pack

これはゲームなどでよく使われるアニメーションデータをダウンロードすることができます。アニメーションデータはFbxファイル、Maya、そしてSoftimage Mod Tool用の三種類のファイル形式が用意されています。

アニメーションは21種類あり、歩く、走る、ジャンプといった基本的な移動アニメーションの他にも座る、倒れる、泳ぐといったものがあるので、アニメーションを作るときに参考にしたり、ゲームの雛形を作るときに仮データとして使えます。

アバターを使おうその2:基本アニメーション

Yuichi Ito — Fri, 26 Jun 2009 04:23:00 GMT

アバターの基本アニメーション

AvatarAnimationを生成するときに指定するAvatarAnimationPreset列挙型には31種類の基本アニメーションが宣言されています。内訳として、11種類の男女共通のアニメーションと、性別毎に違うアニメーションが10種類となっています。

男性アバター向けのアニメーションはMaleで始まり、女性アバター向けのアニメーションはFemaleで始まるようになっています。通常はAvatarDescription.BodyTypeによって性別ごとにアニメーションを切り替えて使用しますが、アニメーションは性別に関係なく使えるので、意図的に男性アバターに女性アバターのアニメーションを再生させるということもできます。

男女共通のアニメーション

以下は男女共通アニメーション名と、その説明です。

アニメーション名	説明
Stand0	基本姿勢アニメーション、身体的アニメーションは殆どなく、瞬きする程度。
Stand1	基本姿勢アニメーションに加えて、数秒間軽く上を見上げる動作。
Stand2	基本姿勢アニメーションに加えて、左、上方向に顔を向ける動作。
Stand3	基本姿勢アニメーションに加えて、左右を見渡した後に軽く首をかしげる動作。
Stand4	軽く右足を上げて、つま先を見つめる。
Stand5	両手を広げて、前後に振る。
Stand6	足元を見回す動作。
Stand7	頭を左右に傾けた後に、首を回す動作。
Clap	笑顔で拍手する。
Wave	笑顔で手を振る。
Celebrate	喜びの動作。アバター生成画面でアバターを選択したときにするアニメーションと同じもの。

性別によって違うアニメーション

以下は性別によって異なるアニメーションをまとめた表です。殆どのアニメーションはMaleLaugh、FemaleLaughといった感じで同じタイプのアニメーションが用意されています。例外としてはMaleIdleCheckHand,FemaleIdleCheckNails,MaleIdleStretch,FemaleIdelFixShoeの四つのアニメーションがあります。

同じタイプのアニメーションでも、例えば笑うアニメーションの場合、男性はひざを叩いて笑う動作をするのに対して、女性は手を前にかざして笑うといった違いがあります。

男性用アニメーション名	女性用アニメーション名	説明
MaleIdleCheckHand	FemaleIdleCheckNails	男性は肩を軽くまわした後に自分の手を見つめる動作。女性は爪を見つめる動作。
MaleIdleLookAround	FemaleIdleLookAround	あたりを見回す動作。
FemaleIdleShiftWeight	MaleIdleShiftWeight	重心を左右の足に移動する動作。
MaleIdleStretch	FemaleIdleFixShoe	男性はストレッチ動作、女性は靴の様子を見る動作。
MaleAngry	FemaleAngry	怒る。
MaleConfused	FemaleConfused	困惑。
MaleLaugh	FemaleLaugh	大笑い。
MaleCry	FemaleCry	泣く。
MaleSurprised	FemaleShocked	驚き。
MaleYawn	FemaleYawn	あくび。男性は手を口に当ててあくび。女性は手を広げてあくび。

百聞は一動画にしかずということで、全ての基本アニメーションを再生した動画を作ってみました。男性、女性アバターを並べて、それぞれのアニメーションを二回再生するようになっています。

AppWeek

Yuichi Ito — Tue, 16 Jun 2009 04:12:49 GMT

XNAプラットフォーム＆ツールチームの主な作業はXNA Game Studioを作ることですが、リリースの直前には、実際に作ったものに問題がないか、また使いやすいかを確認するために開発中のフレームワークを使って実際にゲームを作ってみるAppWeekというものがあります。

XNA GSE 1.0の頃に作られた物の中にはCatapult、Minjiといったサンプルとして公開されているものもあります。XNA GS 3.0の時は忙しすぎてAppWeekをする暇がなかったのですが、今回のXNA GS 3.1ではAppWeekがありました。

今回のAppWeekは４日間という短期間でしたが15個のゲームが作られました。特に3.1で追加された機能のテストを兼ねているので今回はアバターとビデオを使ったゲームが殆どでした。

Shawn Hargreaves氏はCreators Club Onlineサイトにあるサンプルコードを組み合わせて作った「Super Avatar Sample Smashup EXTREME! ‘Capture the Cat’ edition」を作りました。このゲームではフィールド内の相手陣地のねこを自陣までつれてくるのが勝利の条件で、一匹のねこをめぐって宇宙船やら、戦車を使った争奪戦を繰り広げるネットワーク対応のゲームでした。

Brandon Bloom氏の作った「Avatar Boxing」は、アバターを使ったボクシングゲームでした。アバターの各ボーンを自由に変更することで任意のアニメーションを設定で機能を使ったものでした。ちなみにこのゲームを作るときにはBoundingSphere.Transformがサポートするのは平行移動のみの行列でしたが、それでは不便ということで3.1では平行移動、回転、スケールの行列もサポートするようになりました。

私も３日間だけ時間が取れたので、アバターを使ったゲームを作ってみました。タイトルは「Columns Flash」、落ちものパズルゲームにアバターを組み合わせたものです。今回は贅沢にすべてのブロックを3Dにしてみました。

ブロックを消すと、下のスクリーンショットのようにアバターが拍手するアニメーションしたり、

コンボゲージが溜まったときにYボタンを押すと、下のスクリーンショットのようにコンボアタックを発動して対戦相手に対していじわる攻撃を繰り出すことができます。

こちらはLv1コンボアタックの「ゆさぶり」で、相手のボード全体がふらふらと揺れてプレイししづらくなります。もちろん、アバターも困った顔をしています。3Dで描画しているので、コンボアタックも3Dならではの攻撃になっています。

こちらは、Lv2コンボアタックの「ちぢこまり」です。ボードが小さくなるだけなのですが、この攻撃をされた対戦相手は画面が良く見えなくなるので、モニタの前に張り付く姿が笑えます。

で、こちらはLv3コンボアタックの「ひっくりがえし」です。ボードが180度回転して、ブロックの上下が逆さまになります。この手のゲームでは連鎖のタネをばら撒くのが勝つコツですが、そういった計画を文字通りひっくりがえしてしまう攻撃です。アバターも驚いた表情をします。

対戦が白熱してくると、やられたらやり返すという場面が増えてくるので、二人同時にコンボアタック発動して下のように派手な画面になることもしばしばあります。

そして、ゲームオーバーになると、下の画面のように負けたほうのブロックが飛び散り、勝ったプレイヤーのアバターは喜びのアニメーション、負けた方はうなだれたアニメーションをするようになっています。

このゲームではアバターの基本描画と、基本アニメーションセットしか使っていませんが、それでも自分のアバターがそのままゲーム内でさまざまなリアクションをするというのは楽しいものでした。また、今回のゲームは絵も含めてフルスクラッチ(背景の写真はハイキングへ行ったときに撮った写真)で制作しましたが、３日間という短期間でここまでのゲームを作ることができるという、C#を使った開発効率の高さにはいまだに感心させられます。

デバッグコマンド

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 — Sun, 28 Dec 2008 01:45:00 GMT

2009/06/25 追記: XNA GS 3.1用のサンプルを http://higeneko.net/hinikeni/sample/xna31/DebugSample.zipにアップしました

2009年1月24日追記: サンプルプログラムのキーボード処理部分でテンキーの０を押すと１が入力されるバグを修正、アップデートしました。バグがあった場所はGameDebug/KeyboardUtils.csファイル内のInitializeKeyMapメソッド内の初期化コード部分です。AddKeyMap( Keys.NumPad0, "10" )となっているのをAddKeyMap( Keys.NumPad0, "0" )にする事で修正できます。連絡してくださったDERNAさんに感謝します。

デバッグ３種の神器

ゲーム開発現場で最も使われているゲーム内で動作するデバッグ用の機能といえば以下の３つがあります。

FPSカウンター
リアルタイムプロファイラー
デバッグコマンド

市販されているPCゲームの中にはオプション画面でFPSカウンターを表示できるようになっているものもあるので、パフォーマンスの指標として有名です。後のふたつについては一般にはあまり知られていませんが、ゲーム開発現場、特に北米のゲーム開発現では良く目にする機能です。

前回紹介したGamefest Japan 2008のデモでも、これらの機能を使っています。そこで、今回は前回のデモからデバッグ機能だけを抜き取ったサンプルを作りました。

http://higeneko.net/hinikeni/sample/DebugSample.zip

前回と同じく、フォントはConsolasを使用しています。Consolasフォントが無い場合はビルドエラーになるので、以下のURLからConsolasフォントをダウンロードするか、フォント名を変更するようにしてください。

https://www.microsoft.com/downloads/details.aspx?familyid=22e69ae4-7e40-4807-8a86-b3d36fab68d3&displaylang=en

使い方

サンプルを起動すると、画面右上に使い方が表示されます。

FPSカウンターの表示
- Aボタン、またはAキー
TimeRulerの表示
- Bボタン、またはBキー
TimeRulerログ表示
- Xボタン、またはXキー
デバッグコマンドUIの表示
- Tabキー
サンプルプログラムの終了
- Backボタン、またはEscapeキー

デバッグコマンドUIはキーボード入力からデバッグ用コマンドを実行します。Xbox 360でもUSBキーボードを本体に繋げることで使うことができます。デバッグコマンドUIには元々使えるコマンドとして画面をクリアするclsコマンド、登録されているコマンドを表示するhelpコマンドがあります。基本的にWindowsにあるコマンドシェルと使い方は一緒で、上下キーで最近使ったコマンドのヒストリを表示する機能もあります。

このデモでは、DebugSampleGame.cs内には独自のデバッグコマンドを追加するサンプルコードが含まれていて、ここではposコマンドを追加して、画面上に表示される「+」マークの位置を表示したり、変更できるようになっています。下の動画では見づらいですが、最初は左上にあった白い点がposコマンドによって画面下中央に移動しているのが判ると思います。

サンプルに含まれるファイル

このサンプルに含まれるファイルには、デバッグ機能の使い方のサンプルコードが入ったDebugSampleGame.csファイルの他に、デバッグ機能を提供する以下の８つのファイルがあります。

DebugSample/GameDebug/DebugCommandUI.cs	デバッグコマンドUIクラス
DebugSample/GameDebug/DebugManager.cs	デバッグ用のコンテントを格納する為のゲームコンポーネント
DebugSample/GameDebug/FpsCounter.cs	FPSカウンター
DebugSample/GameDebug/IDebugCommandHost.cs	デバッグコマンド用のインターフェース
DebugSample/GameDebug/KeyboardUtils.cs	キーボード入力用ユーティリティクラス
DebugSample/GameDebug/TimeRuler.cs	タイムルーラー
DebugSample/Utils/Layout.cs	画面レイアウト用構造体
DebugSample/Utils/StringBuilderExtensions.cs	StringBuilder用拡張メソッド宣言クラス

自分のゲームにデバッグ機能を追加するには、上記の８つのファイルをプロジェクトに追加し、DebugManager、FpsCounter、TimeRuler、そしてDebugCommandUIコンポーネントをゲームのInitializeメソッド内で以下の様に追加する事で使用することができます。

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

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

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

Components.Add( debugCommandUI );

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

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

DebugManagerとDebugCommandUIは自分自身をサービスとして登録するので、この二つは他のデバッグ用コンポーネントの前に追加する必要があります。

次回から、それぞれのデバッグコンポーネントの使い方に付いて説明していきます。

Gamefest Japan 2008 デモプログラム

Yuichi Ito — Fri, 12 Dec 2008 15:20:00 GMT

2009/06/25 追記: XNA GS 3.1用のサンプルを http://higeneko.net/hinikeni/sample/xna31/GamefestJapan2008Demo.zipにアップしました

2008/12/26 追記: デモプログラムの更新、キーボード入力で操作できるようになりました。

やっと終わりました

今年の９月に行われたGamefest Japan 2008のプレゼンテーション資料が先月公開されました。

http://msdn.microsoft.com/ja-jp/xna/cc723908.aspx

私も僭越ながら２つのセッションを担当させて頂き、そのプレゼンテーション資料も公開されています。XNA Game Studioでのゲーム開発においてのパフォーマンス改善について戦略的手法と実践的な手法、主にシステムレベルでの最適化の効果の程を紹介させていただきました。

http://download.microsoft.com/download/0/4/2/04291420-033b-4f46-b87d-de64a2dc6bac/X5.zip

本当はプレゼン時にサンプルプログラムの配布したかったのですが、本業の方のXNA Framework作業の方が佳境の最中で、その合間に書いたコードだったので非常に汚いコードであったのと、先月のXNA Game Studio 3.0のリリースまでその忙しさが続いたので、なかなか公開することができませんでした。っていうか、コメントを追加するのは当然として、他にも3.0対応にしたり、再利用可能なコンポーネントを使いやすく書き換えたりして、発表時のコードよりも4,000行近く増えてしまったのも、今まで時間が掛かった原因でした。

ともかく、なんとか人に見せられる程度の体裁は整えたので、デモプログラムを公開します。

http://higeneko.net/hinikeni/sample/GamefestJapan2008Demo.zip

解凍したフォルダの中には以下の３つのソリューションファイルがあるので、好きなソリューションファイルを使ってください。いずれのプロジェクトを開くのにもXNA Game Studio 3.0が必要です。また、Windowsで実行するにはシェーダーモデル2.0以上のビデオカードが必須になります。

DemoWin.sln
- Windows用のソリューションファイル
DemoXbox.sln
- Xbox 360用のソリューションファイル
Demo.sln
- Windows/Xbox 360の両方のプロジェクトが入ったソリューションファイル

フォントは私がプログラムする時に使っている等幅フォントのConsolasを使用しています。Consolasフォントが無い場合はビルドエラーになるので、以下のURLからConsolasフォントをダウンロードするか、フォント名を変更するようにしてください。

https://www.microsoft.com/downloads/details.aspx?familyid=22e69ae4-7e40-4807-8a86-b3d36fab68d3&displaylang=en

このサンプルプロジェクトのコード、アセットは非商用、商用に関わらず、自由に使ってかまいません。ただし、一部のコードはクリエータークラブオンラインのMesh Instancingのコードを流用、または変更しているので、それらのコードのライセンスについては付属されるMicrosoft Permissive License.rtfに沿います。

http://creators.xna.com/en-US/sample/meshinstancing

で、お約束ですが、このサンプルコードやアセットを使用したことで発生したいかなる問題にも当方は責任を負いません。

デモの内容

デモを起動すると、おなじみのCornflowerBlueが表示されます。ここでコントローラーのスタートボタンで４種類のデモの切り替えをし、Aボタンで手法の切り替えをします。また、デモによっては左右のトリガで表示オブジェクト数の増減ができます。以下に紹介する測定結果は全てXbox 360上で測定したものです。パフォーマンス測定をする時にはビルド設定をリリースにし、デバッグにアタッチしていない状態(Ctrl+F5)で実行することを忘れないでください。

操作方法

デモの切り替え
- スタートボタン、またはEnterキー
手法の切り替え
- Aボタン、またはスペースキー
オブジェクト数の増減
- 左右のトリガ、またはUp/Downキー
デモの終了
- Backボタン、またはEscapeキー

配列デモ

.Netには様々な配列のタイプがあり、慣れていないとどれを使ったら良いのか悩むと思います。このデモでは、様々な配列を使って5,000個のスプライトの移動させるときに掛かる時間を測定しています。画面左下にある青いバーが更新時間に掛かった時間でログ表示中の"Update"です。

この配列デモの結果を見るとArrayListを使うのは避けるべきで、それ以外の手法による速度差は30~40%程度なので、後に続くデモの効果に比べると少ないものなので、用途に合わせて使いやすい配列を使いましょうということになります。

このデモのソースコードはDemo/ArrayDemoフォルダの中にあります。

動的頂点バッファデモ

動的頂点バッファの扱いはXNA GSでは簡単になっているものの、CPUの書き込みとGPUの読み込みがどんなタイミングで衝突するのかを理解して正しく使わないと思わぬパフォーマンス低下の原因になります。また、2Dゲームのパフォーマンス問題として頂点変換をはじめとするシェーダーでするべき仕事もCPUでしてしまい、CPU速度の遅いXbox 360では速度が出ないという問題があります。

このデモでは、動的頂点バッファの使い方と、シェーダーを使った場合の効果を紹介しています。スケール、回転といった基本的なパラメーターを持ったパーティクルを3,000個描画したときに掛かる時間を測定しています。

CPUで頂点変換処理をした時に比べて、単純なシェーダー処理をするだけで8.5倍、vfetchを活用すると30倍、更にDirectMappingを使うと142倍という桁違いな速度アップになります。ただし、比較対象のCPUで頂点変換するコードは全く最適化されていないので、実際にはそこまで大きな数字は出なくとも0.09ミリ秒で3,000個のパーティクルの描画命令を発行できるというのは大きいと思います。

世の中ではマルチコア、マルチスレッドが騒がれているので、どうしてもマルチスレッドプログラミングに手を出したくなってしまいますが、Xbox 360上でXNA GSが使えるHWスレッド数は４つまでなので、どんなにうまくプログラムしたとしても元の４倍以下の速度にしかならないことを考えるとシェーダーの活用がいかに効果的な手法なのかが判ると思います。

このデモのソースコードはDemo/GameVertexフォルダの中にあり、シェーダーコードはDemo/Content/GameVertexの中にあります。

インスタンスモデルデモ

Xbox 360上で数万ポリゴンのモデルが数十個描画できるなら、数百ポリゴンのモデルを数千個描画できるはずと思って試してみると、数百個も描画すると処理落ちしてしまうという問題を何度か聞いたことがあります。これは、XNA GSというより、Direct X、というよりも昨今のGPUで共通の問題で、この問題を解決する為の手法がインスタンス(Instancing)です。Xbox 360はもちろん、Windowsでも非常に効果的な手法の一つです。

インスタンスモデルのサンプルはクリエータークラブオンラインにもありますが、このデモではWindowsで使えるHWインスタンスをXbox 360でvfetchを使って実装していて、InstancedModelクラスを介してWindowsとXbox 360の両方で全く同じゲームコードを記述することができるようになっています。ただし、シェーダーコードのフェッチ部分はXbox 360用のコードが必要になりますが、フェッチ部分のみなので他のシェーダー処理部分は共通で使えます。

このデモでは、３つのスペキュラ付き平行光源処理をした、12ポリゴン、24頂点のモデルを500個描画したときの時間を測定しています。

最適化されていない状態とHWインスタンスを使った場合で50倍、DirectMappingを使うと115倍の速度になっています。このデモでは3万６千個のボックスを描画した時点で60fpsを切りますが、これはボックスを移動する更新部分がネックになりGPUにはまだ余裕があります。そこで、試しに1,245ポリゴンのモデルを表示してみたのですが、その場合は最大3,440個のモデルが表示できました。これは１フレームあたり428万ポリゴン、秒間で２億5千万ポリゴンを描画できることになります。

このデモのソースコードはDemo/GameModelフォルダの中にあり、インスタンスモデルクラスの実装はDemoTypesフォルダの中にあり、シェーダーコードはDemo/Content/GameModelの中にあります。

インスタンスモデルアニメーションデモ

シェーダーモデル 3.0の機能として浮動小数点テクスチャと頂点シェーダーからテクスチャを読み込む頂点テクスチャがあります。このデモでは、アニメーションデータを浮動小数点テクスチャに格納し、アニメーション処理をCPUではなくGPUでしています。CPU側の処理としてはオブジェクトの移動と、アニメーションフレームの更新です。それぞれのオブジェクトのアニメーションスピードはランダムです。

このデモでは、３つのスペキュラ付き平行光源処理をした、84ポリゴン、186頂点のモデルを500個描画したときの時間を測定しています。

Xbox 360上では大体16,000個のオブジェクトを描画することができます。

ソースコードはDemo/GameAnimeフォルダの中にあり、シェーダーコードはDemo/Content/GameAnimeの中にあります。

他にも役に立ちそうなもの

４種類のデモの紹介をしましたが、このデモコードの中には他にも役立ちそうなものがあります。

TimeRuler (Demo/GameDebug/TimeRuler.cs)
Fpsカウンター (Demo/GameDebug/FpsCounter.cs)
デバッグコマンド (Demo/GameDebug/DebugCommandUI.cs)
Layout (Demo/Utils/Layout.cs)
StringBuilder拡張メソッド (Demo/Utils/StringBuilderExtensions.cs)

これらについては追々紹介していきます。

招待サンプル

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

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

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

PIXを活用する　その２

Yuichi Ito — Fri, 07 Nov 2008 07:02:00 GMT

前回に続いてPIXの機能と、私が実際にどんな状況でPIXを使って来たかを交えて紹介します。

ちなみにPIXはピクスと呼びます。たまにピックスと呼ぶ人もいますが私のまわりではピクスが多いです。

RenderウィンドウからDebug This Pixelメニューを使って表示されるDebuggerタブで、前回はDebug VertexやDebug Pixelをクリックしてのシェーダーのデバッグを紹介しましたが、今回はEvent部分をクリックして表示される情報について説明します。

Debuggerタブ内のそれぞれのピクセル情報の上の部分には、そのピクセルを描画したイベントが表示されます。上の場合はDrawIndexedPrimitiveとなっています。ここをクリックすると、左下にあるイベントウィンドウ内で該当するイベントが選択されます。

描画順序のチェック

PIXは描画に関する全てのイベントとその情報を記憶しているので、好きなイベントを選択することで描画の課程を調べることができます。これはVisual Studio上でブレークポイントを設定するといった未来時間一方向へのデバッグに対して、PIXではキャプチャーしたフレーム内での時間を自由に移動できるデバッグをすることができます。

イベントを選択した状態でRenderタブを選択すると、選択されたイベント処理が終わった直後の描画結果、つまりフレーム描画の途中結果を見ることができます。

不透明のオブジェクトを描画する場合、手前から奥にむけて順に描いていくのが効果的なのですが、普通にゲームをプレイしている限りでは描画順序は判らないし、描画コードを追いかけるのにも負担が掛かります。PIXを使うとそういった描画順序をここで簡単に確認できます。例えば、おっさんを描いている途中のこの段階で、遠景によく使われるスカイドームのオブジェクトが既に描画されている場合は、最後に書くべきスカイドームが先に描画されているという問題を発見することができます。

Meshデータの表示

Draw系のイベントを選択した時、Meshタブにはその描画がどの様に行われたかの詳細な情報が表示されます。Meshタブの上の方には三つのワイヤーフレーム画面が表示され、左から順に以下のようになっています。

Pre-Vertex Shader
Post-Vertex Shader
Viewport

Pre-Vertex Shader画面には頂点シェーダーに送られる頂点、通常はローカル座標のモデルが表示されます。Post-Vertex Shader画面には頂点シェーダー処理後、つまり射影座標内でのモデルが表示されます。そして最後は透視変換後のビューポート座標でのモデルが表示されるViewport画面となっています。

そして、それら三つの画面の下には頂点シェーダーに入力頂点のリストを表示するPreVSタブと、頂点シェーダー処理後の頂点リストを表示するPostVSタブがあります。

頂点シェーダーを書いている場合に良くあるのが頂点変換ミスです。この場合、画面に変な形のモデルが表示されている場合は頂点シェーダーに問題があるというのはすぐに判るのですが、画面に何も表示されない場合は頂点変換ミスの他にもピクセルシェーダー内でのミスという場合もあるので、Viewport画面にちゃんと表示されているかを確認することで、頂点シェーダー、ピクセルシェーダーのどちらに問題があるかを絞り込む事ができます。

頂点リスト内の頂点はクリックして選択することができ、選択された頂点は下図の様にモデル表示画面内と頂点リスト内で黄色で表示されます。また、頂点リスト内では選択された頂点が属する三角形の他の頂点が赤色で表示されます。

Deviceのステートの表示

Meshタブ内で頂点シェーダーが正しく動作しているのを確認したけど、まだモデルが表示されない。そんな時に調べるのがDeviceステートです。この情報はEventsウィンドウに表示されているイベントの左側にある数字(下図の黄色い部分)をダブルクリックすることで表示されます。

Detailsウィンドウには新たにDeviceタブが追加表示されます。このDeviceタブの中には更に複数のタブが追加されます。それぞれのタブにはカテゴリ別のDeviceのステート情報が記載されています。

私がここでよく使うのはPixel StateタブとOutput Stateタブです。Pixel Stateタブ内ではCullingやViewport、そしてAlphaテストなどの情報が役に立ちます。特にCullingが逆になっているとモデルがちゃんと表示されないし、Alphaテストに間違った値を設定しているとモデルが全く表示されないということもあります。また、Samplersセクションでは、どんなテクスチャが設定されているかを調べることができます。このSamplers部分で設定されているテクスチャの数字をダブルクリックすると、以下の様に設定されているテクスチャの詳細を見ることができます。

グロスマッピング、ディテールテクスチャといった、描画結果への反映が少ないようなテクスチャや、テクスチャに色以外の情報を入れている場合はここで調べたりしています。

Output Stateタブ内ではデプステストの有無、ブレンディングステートを調べるのに使っています。特にアルファブレンドを使っている場合の見た目では判りづらいステートの違いはここで調べています。

PIXを活用しよう

急ぎ足でしたが、二回に渡ってPIXの機能を紹介しました。2Dゲームと違って3Dの場合は実に様々なステートがあり、2Dゲームの場合はトライ＆エラーでどうにかなった問題も3Dゲームの場合はトライ＆エラーをするには時間が掛かりすぎてしまいます。そういった問題を解決するのにPIXは非常に強力なツールです。シェーダーのサンプルは沢山ありますが、シェーダーサンプル単体では問題なく動いたのにゲームに組み込んでみたら、動かなくなったなんて話を良く聞きます。そんな時にもPIXを使うと、なぜ動かないのかを調べることができます。

また、Xbox 360向けに開発している場合でも、開発しているPCにShader Model 3.0のビデオカードがあれば、Windows用のプロジェクトに変換して実行できるようにしておけば、殆どの場合は描画に関するデバッグは問題なくできます。そのままデバッグできない例としてはXbox 360限定のvfetchを使った場合ですが、vfetchはあくまで頂点データのフェッチ用の命令なので、シェーダー全体のコード量に比べると非常に小さく、頂点データをフェッチした後のシェーダーはWindows上でもデバッグできます。

私は、初代Xboxの頃からPIXを使って７年くらい経ちますが、今では描画に問題があったらすぐにPIXを立ち上げて調査するというのが習慣化していて、私にとってPIXはゲーム開発に必須のツールとなっています。

綺麗な絵を出すシェーダープログラミングに比べると地味なものですが、これを機にPIXに触れてもらえば幸いです。

PIXを活用する　その１

Yuichi Ito — Thu, 30 Oct 2008 05:06:00 GMT

PIXとは

3Dゲームを開発している時に必ずといってあるのが、モデルが意図しない状態で表示されるという問題です。「色が変」や「形が変」と言う比較的原因が予想しやすい問題から「画面になにも出ない」といった原因を判断するのが困難な場合まで様々な問題があります。特にシェーダープログラムを使っているとこういった問題に直面する機会は多くなります。

こういった問題の原因を見つけるのに非常に有用なツールとして、Direct X SDKに付属するPIX for Windowsがあります。このツールは元々、初代Xbox用に開発されたPerformance Investigator for Xbox (PIX)だったのですが、これを使った人達からの強い要望でWindows版が作られました。

XNA FrameworkはDirect X上で動作しているので、XNA GS用に作られたゲームもPIX for Windowsを使うことができます。

PIXの主な機能としては

１フレーム、もしくは複数のフレームのレンダリング情報のキャプチャ
レンダリングに使われたDirect Xの描画関連命令の表示
リソース使用量の表示
各段階でのグラフィクスリソースの状態表示
- レンダーステート
- テクスチャ、レンダーターゲット
- 頂点情報
- シェーダー情報
シェーダーデバッガ

があります。

PIXの基本的な使い方

Direct X SDKをインストールした状態で(ここではAugust 2008を例にします)、スタートメニューからMicrosoft DirectX SDK (August 2008)/DirectX Utilities/PIX for Windowsを選択してPIX for Windowsを起動します。

FileメニューからNew Experimentを選択すると以下の画面が表示されます。

Program pathに対象となる実行ファイルを指定し、"A single-frame capture of Direct3D whenever F12 is pressed"のラジオボタンを選択して、右下にある"Start Experiment"ボタンを押すと、Program pathに指定した実行ファイルが実行されます。ここではSkinningSampleを使っています。

単独で実行させるのと違うのは、画面の左上にフレーム数などの情報が表示されています。キャプチャしたいシーンになったらF12キーを押してフレーム情報をキャプチャします。レンダリングするシーンの複雑さによってキャプチャに掛かる時間は変わってきます。

キャプチャした後にゲームを終了させると、PIX for Windowsに複数のウィンドウが表示されます。

この複数のウィンドウは上から順にCPUの作業時間をグラフで示すTimelineウィンドウ、グラフィクスリソース確保状況を表示するObjectsウィンドウ、左下はキャプチャしたフレーム内で起きたイベントを表示するEventsウィンドウ、そして右下が詳細を表示するDetailsウィンドウとなっています。

ここで、Eventsウィンドウで調べたいフレームを選択したあとに、Detailsウィンドウ内のRenderタブをクリックすると以下の画面になります。

PIXをシェーダーデバッガとして使う

このRenderタブにはフレームのレンダリング結果が表示されます。また、Eventsウィンドウの選択したフレームを開くと中には複数のイベントが表示されていますが、ここにはXNA Frameworkではなく、Direct Xのイベントが表示されます。ここからデバッグしたいDrawIndexedPrimitiveメソッドを探し出すのは面倒なので、今回は簡単な方法を紹介します。

それはRenderタブに表示されている画面上でデバッグしたいモデルの場所で右クリックして表示されるメニューからDebug This Pixel...を選択する方法です。ここでは、おっさんのアーマー部分を選択しました。

Debug This Pixel...を選択すると、DetailsウィンドウにDebuggerタブが追加され、選択したピクセルがどのようにレンダリングされたいるかの情報が表示されます。レンダリング開始時のフレームバッファーの色、クリアーした時の色、モデルをレンダリングしたときの色と、時系列に表示されています。もし、ここで表示されるリストが多い場合は重ね塗りが何度も起こっているのでフィルレートに影響しているということが判ります。

今回デバッグしたいのはおっさんのアーマー部分のシェーダーなので、リストの中からDrawIndexedPrimitiveメソッドを使って赤っぽくなっているピクセルを探します。

DrawIndexedPrimitiveを使っているピクセルでは、そのピクセルを描画するのに使われた三角形の各頂点の頂点シェーダー、そしてピクセルシェーダーをデバッグすることができます。ここでは"Debug Vertex 0"をクリックして頂点シェーダーのデバッグをすることにします。"Debug Vertex 0"をクリックすると以下のように、Debuggerタブ内に更にシェーダーアセンブリを表示するDisassemblyタブ、ソーソコードを表示するタブ(ここではSkinnedModel.fx)が表示されます。

ここで、ソースコードをPIX上で表示するにはシェーダーソースコードにコンパイル元のファイル情報が記載されている必要があります。XNA Frameworkではデバッグ設定でシェーダーをコンパイルすると、この情報を自動的に追加するようになっているので、プロジェクトをデバッグ設定でコンパイルすることでPIX上でソースコードレベルでのデバッグができるようになっています。逆に言えば、アセンブリしか表示されない場合はプロジェクトのコンパイル設定がリリースになっているのが原因と思われます。

Visual Studio上で提供されているデバッグ機能には及ばないにしても、ステップ実行や実行後の変数の状態表示など、デバッグするのに必要最低限の機能はあるので、シェーダーコードのデバッグをするのに大いに役立ちます。

PIXをシェーダーデバッガとして使うときの注意点

ソースコードレベルでのデバッグをするときには、プロジェクトをデバッグ設定でコンパイルする

次回に続く

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 : ゲーム開発

アバターを使おう その4:カスタムアニメーション

Custom Avatar Animation Sample

Avatar Animation Rig

Avatar Animation Pack

アバターを使おう その2:基本アニメーション

アバターの基本アニメーション

男女共通のアニメーション

性別によって違うアニメーション

AppWeek

デバッグコマンド

タイムルーラー

FPSカウンター

デバッグサンプル

Gamefest Japan 2008 デモプログラム

招待サンプル

セーフエリア・サンプル

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

PIXを活用する その２

PIXを活用する その１

ClickOnce その２

ClickOnce その1

アバターを使おうその4:カスタムアニメーション

アバターを使おうその2:基本アニメーション

PIXを活用する　その２

PIXを活用する　その１