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

自動XNBファイルシリアライズ

Yuichi Ito — Tue, 16 Jun 2009 05:39:00 GMT

コンテントタイプライター/リーダーを書くのは面倒

XNA Game Studioのコンテント・パイプラインでのデータの流れは下図のようになっています。オフラインプロセスは開発しているVisual Studio上でビルドしたときにWindows上で処理されるプロセスで、オフラインプロセスはWindows、Xbox 360、Zune上でゲームを実行したときに処理されるプロセスです。

元からサポートされているデータをそのまま扱う場合には良いのですが、カスタムデータを扱う場合に書かないといけないのが、ContentTypeWrite/ContentTypeReaderでした。特に面倒だったのが、読み込みと書き込みという対称的な処理をするのにContentTypeWriterはオフラインプロセス側、ContentTypeReaderはオンラインプロセス側と別々の場所で書かないといけないことでした。

この面倒臭さを解決する為に、XNA GS 3.1では自動XNBシリアライズ機能が追加されました。この機能を使うことで、多くの場面でContentTypeWriter/ContentTypeReaderを書く必要がなくなりました。

自動XNBシリアライズ機能の使い方

自動XNBシリアライズは.Netのリフレクション機能を使って実装されています。ContentTypeWriter/ContentTypeReaderが指定されていない場合、自動XNAシリアライズが発生し、以下のルールに沿って動作します。

公開(public)メンバー、プロパティがシリアライズの対象になる
シリアライズしたくないメンバーがある場合は、[ContentSerializerIgnore]属性を指定することで、シリアライズしないように指定できる
private, protected, internalなどの非公開メンバーをシリアライズしたい場合は[ContentSerializer]属性を指定する
シリアライズしたいデータ構造が再帰的な参照を含む場合は[ContentSerializer(SharedResource = true)]を指定する
コンテント・パイプライン内とランタイム時の型が違う場合、[ContentSerializerRuntimeType(“タイプ名”)]を指定する

シンプルな例

例えば以下のようなデータをゲームで扱うとします。ゲームとコンテント・パイプラインで共有するデータなので、ゲームプロジェクトの他に共有するデータを入れるためのプロジェクトを作る必要があります。例えばMyDataTypesという名前のプロジェクトです。

// ねこクラス
public class Neko
{
    public string Name;     // 名前
    public float Weight;    // 体重
    public int Tails;       // 尻尾の数
}

このデータをコンテント・パイプライン内に読み込むために以下のようなXMLファイル、cats.xmlを書きます。

<?xml version="1.0" encoding="utf-8" ?>
<XnaContent>
  <Asset Type="MyDataTypes.Neko[]">
    <Item>
      <Name>たま</Name>
      <Weight>8</Weight>
      <Tails>1</Tails>
    </Item>
    <Item>
      <Name>ねこまた</Name>
      <Weight>12</Weight>
      <Tails>2</Tails>
    </Item>
  </Asset>
</XnaContent>

作ったXMLファイルをコンテントとして追加した後に、そのデータを読み込むコードをゲーム側のコード(LoadContentメソッド内など)に以下のコードを追加します。

Neko[] cats = Content.Load<Neko[]>("cats");

後は、F5を押すだけで変数catsには必要なデータが読み込まれます。3.0以前のようにContentTypeReader/ContentTypeReaderを書かなくても良いので、データ構造の宣言、データファイルの生成、読み込み部分のコードをゲーム内に追加という単純な作業でカスタムデータをゲーム内で読み込むことができます。

オフラインとランタイムで型が違う場合

XNA GS 3.1のコンテント・パイプライン内で使われる型の図を見ると、コンテント・パイプライン内ではTexture2DContentだけど、ゲーム内ではTexture2Dのように、オフライン時とランタイム時では型が異なるケースがあります。例えば、ゲーム内では以下のデータ構造にしたい場合があるとします。

// ねこクラス
public class Neko
{
    public string Name;         // 名前
    public Texture2D Texture;   // テクスチャ
}

この場合、Textureはコンテント・パイプライン内で使う型がTexture2DContentとなるので、以下のようにContentSerializerRuntimeType属性を使ってランタイム時の型を指定します。

// ねこコンテント
[ContentSerializerRuntimeType("MyGame.Neko, MyGame")]
public class NekoContent
{
    public string Name;         // 名前
    public Texture2DContent Texture;   // テクスチャ
}

パフォーマンス

以上のように自動XNBシリアライズ機能は非常に便利な機能ですが、前述のようにデータの書き込みと読み込み時にリフレクション機能を使用するのでContentTypeWriter/ContentTypeReaderに比べると不必要なメモリ確保や、ボクシングなどが発生し、処理時間も多く掛かるので理論的にはロード時間が以前より長くなります。

ですが、現実的にはカスタムデータの多くがゲーム内のパラメーターなど、他のコンテントに比べると数は少ないものなので、ロード時間が長くなるといっても無視できる範囲のことが多いと思われます。

ただし、カスタムデータを数百、数千の配列で持つようなケースでは極端にロード時間が長くなる場合もあります。その場合は、今までどおりContentTypeWriter/ContentTypeReaderを使うことによってリフレクションによる速度低下を防ぐことができます。便利さを優先するには自動XNBシリアライズ、速度を優先するならContentTypeWriter/ContentTypeReaderといった感じに上手に使い分けましょう。

サンプル・コード

自動XNBシリアライズ機能を使ってコンテント・パイプラインの紹介の時に作った日本語表示のサンプルを3.1用に書き換えてみました。元のサンプルと比べると、共有するデータ型を記述するプロジェクト自体を書く必要がなくなり、ContentTypeWriter/ContentTypeReaderを書く必要が無くなったのでシンプルになっています。

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

元ネタ:http://blogs.msdn.com/shawnhar/archive/2009/03/25/automatic-xnb-serialization-in-xna-game-studio-3-1.aspx

XNA GS 3.1のコンテント・パイプラインで使われる型

Yuichi Ito — Sat, 13 Jun 2009 05:29:00 GMT

以前、Shawn Hargreaves氏のブログでXNA GS 2.0のコンテント・パイプライン内でデータが変換される過程図が紹介されました。

http://blogs.msdn.com/shawnhar/archive/2007/10/10/content-pipeline-types.aspx

XNA GS 3.1がリリースされたので、それに合わせて元の図を翻訳し、SoundEffect、Video等の新しい型を追加した図を作ってみました。アセットファイルがどのようにインポートされ、プロセッサで処理され、ContentTypeWriterからXNBファイルとして書き出されるまに使われる型情報を網羅しているので、カスタムインポータや、カスタムプロセッサを作るときに役立つと思います。

左側の水色の部分はコンテント・パイプライン内で処理される部分で、右側の黄色い部分はゲーム実行時に処理される部分です。

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 — Fri, 22 Feb 2008 16:11:00 GMT

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

以前紹介した英数字以外の文字列表示方法はコンテントパイプラインの全体の流れを説明するという目的もあったので複雑なつくりになっていました。RPGやテキストベースのアドベンチャーゲームなどの大量のテキストデータを扱う場合は、こういったものは必須になってきますが、今回はXNA 2.0から導入されたプロセッサパラメーターを使ってのシンプルな日本語を含む多言語文字列表示方法を紹介します。

とりあえず、前回のサンプルを2.0用に書き直しておきました。

MessageTextSample 2.0

なぜSpriteFontなのか？

Windowsアプリケーションプログラミングを経験した人達にとってXNAに同様の文字列描画APIがないというのは疑問に思うかも知れません。なぜ、普通のWindowsのアプリケーションのようにOSにインストールされたフォントを指定して文字列を簡単にかけないのでしょうか？それには主に以下の理由があります。

容量: 日本語のフォントファイルのサイズは大きくて再配布が難しい
速度: テクスチャ形式のフォントに比べて描画処理に時間が掛かる
法律: 面倒だから放っておくと、後でさらに面倒なことになる罠のこと
娯楽: OSにインストールされいるフォントを使うと事務的な印象を受けてしまう

1については、日本語フォントの殆どは約7,000文字近くのデータを持っています。私のマシンにインストールされているMSゴシックのファイルサイズは８MB近くあります。殆どのゲームでは500～1,500文字程度の文字しか使わないので7,000文字のデータを持つのは効率的ではありません。更に、キャラクターや状況によって複数のフォントを使い分けるのでファイルサイズが大きいというの問題になります。

2は、通常のフォントはTrueTypeと呼ばれるデータ形式で、これは一文字一文字のポリゴンデータを持っているようなものでテクスチャにあらかじめ描画された文字をひとつの四角形ポリゴンで表示するより処理するのに時間が掛かります。また、フォントデータは必要になったときにHDDから読み込むのでリアルタイム性の高いゲームを作ってるときにはその遅延時間を考慮しなければいけないという問題もあります。

3は面倒な問題で、フォントには著作権があり、その使用許諾の形式もフォントを作っている会社によってさまざまなものがありますが、その多くはテクスチャとして文字を使うのは良くてもフォントファイル自体の再配布を禁じているものがあります。それ以外にもいろんなライセンス契約形式があることに注意してください。

4については、フォントと言うのはゲームの雰囲気を伝えるために重要なもので、キャラクターやその場の雰囲気によって複数のフォントを使うことが多いです。例えばおどろどろしい雰囲気を出すために古印体というフォントを使ったりしますが、そういった特徴的なフォントがOSにインストールされていることは殆どありません。また、テクスチャにすることで

のように普通の文字列の間にビットマップで描いた絵を文字として組み合わせることもできます。

以上の理由からXNAではSpriteFontを採用しています。

簡単メッセージプロセッサ

今回のサンプルの基本アイディアは

FontDescriptionProcessorから派生したMessageProcessorを作る
MessageProcessor.Processメソッド内で任意の文字列をFontDescriptionに追加する
追加する文字はMessageFilenameプロパティに指定されたファイルから読み込む

と、シンプルなものです。カスタムプロセッサのプロセスメソッドは以下のようになっています。

public override SpriteFontContent Process(FontDescription input,
                                            ContentProcessorContext context)
{
    // MessageFilenameで指定されたファイル内の文字を追加する
    AppendCharacters(input, context);

    // 文字列を追加した後は単純にFontDescriptionProcessorのプロセスを呼ぶだけ
    return base.Process(input, context);
}

MessageFilenameをプロセッサ・パラメーターとして以下のように宣言しています。詳細はこの記事が参考になると思います。ここではプロパティ画面上で読みやすいようにDisplayNameとDescriptionアトリビュートを使っています。

/// <summary>
/// プロセッサーパラメーター
/// ここに読み込むメッセージファイル名を指定する
/// </summary>
// プロパティ画面で表示される文字列の指定
[DisplayName("メッセージファイル名")]
// プロパティ画面でのパラメーターの説明
[Description("メッセージテキストが含まれているテキストファイル名")]
public string MessageFilename
{
    get { return messageFilename; }
    set { messageFilename = value; }
}

string messageFilename;

Processメソッドから呼んでいるAppendCharactersメソッド内では単にファイルから文字列を読み込み、FontDescription.Characters.Addメソッドを使って使用する文字を追加しています。

/// <summary>
/// FontDescriptionにMessageFilenameで指定されたファイル内の文字を追加する
/// </summary>
void AppendCharacters(FontDescription input, ContentProcessorContext context)
{
    // MessageFilenameは有効な文字列か？
    if (String.IsNullOrEmpty(MessageFilename))
        return;

    if (!File.Exists(MessageFilename))
    {
        throw new FileNotFoundException(
            String.Format( "MessageFilenameで指定されたファイル[{0}]が存在しません",
                            Path.GetFullPath(MessageFilename)));
    }

    // 指定されたファイルから文字列を読み込み、
    // FontDescription.Charctarsに追加する
    try
    {
        int totalCharacterCount = 0;

        using (StreamReader sr = File.OpenText(MessageFilename))
        {
            string line;
            while ( ( line = sr.ReadLine() ) != null )
            {
                totalCharacterCount += line.Length;

                foreach( char c in line )
                    input.Characters.Add( c );
            }
        }

        context.Logger.LogImportantMessage("使用文字数{0}, 総文字数:{1}",
            input.Characters.Count, totalCharacterCount);

        // CPにファイル依存していることを教える
        context.AddDependency(Path.GetFullPath(MessageFilename));
    }
    catch (Exception e)
    {
        // 予期しない例外が発生
        context.Logger.LogImportantMessage("例外発生!! {0}", e.Message);
        throw e;
    }
}

このカスタムプロセッサをコンパイルすると、以下のようにプロパティ画面上でメッセージプロセッサという名前のプロセッサが追加され、そこにメッセージファイル名というプロセッサ・パラメーターが表示されます。

ここにはテキストファイルであればどんなファイル名でも指定できますが、使っている環境に依存しないように相対パスを指定するようにしましょう。通常、コンテントパイプライン実行時のルートパスはContentフォルダになっています。また、多言語が指定できるようにファイルのエンコーディングはUTF-8を指定します。

さて、どんなファイルでも指定できるわけですが、前回の時にも書いたように私がプログラムするときには「エラーが起きにくく、起きたとしても直ぐにエラーの原因が特定、修正ができる」ということを心がけています。ですから、メッセージファイルと実際にランタイム時に使う文字列を別のファイルであるソースコードと別々にすると問題が起きやすく、見つけづらいという状態になってしまいます。

じゃあどうすればいいのか？また前回のように面倒なコーディングをしないといけないのか？と思ってしまいますが、今回はシンプルな解決方法をとります。それはソースコードをメッセージファイルとして指定するというものです。

ソースコードも立派なテキストファイル。そこに使われる文字は殆どが英数字なので日本語のメッセージに使われる文字数に比べると少ないし、既に英数字を使用する文字に指定しているのであれば無駄はありません。気をつけるとすれば、メッセージファイルが更新する度にコンテントビルドが行われるので、頻繁に書き換えるソースコードをメッセージファイルとして指定しないということです。

そこで、今回はサンプル内で使う文字列をまとめたMessageTable.csというソースコードを指定しています。

namespace SimpleMessage
{
    static class MessageTable
    {
        public static string[] Messages = {
            "日本語メッセージテスト\n"+
            "キーボードのEnterキー、コントローラーのＡボタンで\n"+
            "次のメッセージを表示します。",

            ...

            "最初のメッセージに戻ります。",
        };
    }
}

カスタムプロセッサは100行程度のプログラム。ランタイム側は特別なデータタイプを持つことなく、SpriteFontを追加し、そのプロセッサを変更してパラメーターを設定するだけなので、簡単に日本語メッセージを表示できるのではないでしょうか？

簡単(かもしれない)日本語表示サンプル

冒頭で紹介したサンプルも、このサンプルもXNA 2.0用です。XNA 2.0のプロジェクトファイルはC# Express 2005、Visual Studio 2005のどちらでも使えるようになっています。

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 — Sat, 22 Dec 2007 02:11:00 GMT

フォーラムの質問を見て、今まで書いていなかったことに気づいたので遅ればせながらカスタムエフェクトの使い方を説明します。

例によって例の如く、コピー元はShawn Hargreaves氏の投稿からです。

独自に作ったエフェクトを使うには２つの方法があります。ひとつはコンテント・パイプラインが処理したエフェクトをゲーム実行時に切り替える方法。そしてふたつ目はカスタムプロセッサを書くことで、コンテントパイプライン内でコンテントビルド時に独自のエフェクトに切り替える方法です。

後者の方法の方が自由度が高く、ゲーム実行時に余計な処理をしなくて済むようになるので、ここではこの方法を紹介します。

まず最初にModelProcessorから派生したプロセッサーを作り、ConvertMaterialメソッドをオーバーライドします。

/// <summary>
/// ModelProcessorから派生したプロセッサー
/// </summary>
[ContentProcessor(DisplayName = "MyModelProcessor")]
public class MyModelProcessor : ModelProcessor
{
    // ConvertMaterialをオーバーライドして、マテリアル変換時に自分のマテリアルに差し替える
     protected override MaterialContent ConvertMaterial(MaterialContent material, ContentProcessorContext context)
    {
       // エフェクトを含むことのできるEffectMaterialContentを使う
        EffectMaterialContent myMaterial = new EffectMaterialContent();

       // 使いたいエフェクトファイルを外部参照として指定する
        string effectPath = Path.GetFullPath("MyEffect.fx");
       myMaterial.Effect = new ExternalReference<EffectContent>(effectPath);

       // 引数で渡されたmaterialの代わりに、ここで作ったmyMaterialを渡す
        return base.ConvertMaterial(myMaterial, context);
    }
}

ここで指定しているMyEffect.fxファイルは直接読み込んでいるので、Visual Studioのプロジェクトに追加する必要はありません。また、複数のモデルやメッシュから参照されている場合でもこのマテリアルの実体は一度しか作られません。

このサンプルコードでは直接ファイル名を指定していますが、渡されたマテリアル名(material.Name)や、material.OpaqueDataからファイル名を取得したり、ProcessメソッドをオーバーライドしてNodeContentの情報を保持しておいて、以下のコードのようにしてモデルファイルからの相対パスでファイル名を指定することもできます。

string directory = Path.GetDirectoryName(rootNode.Identity.SourceFilename);
string effectPath = Path.Combine(directory, "MyEffect.fx");

これでエフェクトが使えますが、エフェクトにはパラメーターを設定するのが普通です。また、基本的なマテリアル情報は渡されたマテリアルから取得できるので、以下のようなコードを書くことができます。

if (material is BasicMaterialContent)
{
    BasicMaterialContent basicMaterial = (BasicMaterialContent)material;

    // エフェクトで使うテクスチャを設定する
     myMaterial.Textures.Add("DiffuseTexture", basicMaterial.Texture);

    // ここで任意のエフェクトパラメーターの設定もできる
     myMaterial.OpaqueData.Add("Shininess", basicMaterial.SpecularPower * 10);
    myMaterial.OpaqueData.Add("BumpSize", 42);
}
else if (material is EffectMaterialContent)
{
    EffectMaterialContent effectMaterial = (EffectMaterialContent)material;

    // TODO: 渡されたマテリアルがEffectMaterialContentだった
     // 時の処理をここでする(必要ならば)
}
else
    throw new Exception("なんじゃこりぁ？");

ここで設定したエフェクトやそのパラメーターは実行時に自動的に読み込まれ、設定されます。これで実行時の特別な処理いらずで通常のModelを描画するようにして独自のエフェクトが適用されたモデルを描画することができます。

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

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

コンテントパイプラインで使われる型

Yuichi Ito — Wed, 10 Oct 2007 21:31:00 GMT

Shawn Hargreaves氏のブログに、コンテントパイプラインで使われるタイプがどのように使われるかを表した図が記載されています。

図の左側から、ソースアセットからどのインポーターを使ってContent DOM形に変換され、どのプロセッサーがどんな型のデータを出力し、TypeWriterによってXNBファイルに書き込まれ、最後にランタイム時にTypeReaderによってどの型に読み込まれるかというのを網羅しているので、非常に有益な情報です。

何も問題がなければ、この情報は次のXNA Frameworkのドキュメントに記載される予定です。

Content Pipeline その４そのデバッグ

Yuichi Ito — Tue, 08 May 2007 07:10:00 GMT

コンテント・パイプラインのデバッグ

前回は、実際のコードを見ながらコンテント・パイプラインのカスタマイズの方法を紹介しました。前回のように、ロジック自体が簡単な場合は良いのですが、もう少し複雑なプログラムをコーディングしている時に必要になるのが、インポーターやプロセッサのコードをデバッグすることです。

ここで問題なのは、ゲーム本体をデバッグする感覚でブレークポイントをコンテント・パイプラインのコード部分に設定してビルドしたとしても、何事も無かったかのようにビルトが終了してしまうということです。コンテント・ビルドは普通にアプリケーションを走らせるのと違い、GSEが水面下でMSBuildを実行しているので、GSE上で走らせるアプリケーション用のブレークポイントを設定しても意味がないからです。

コンテント・パイプライン用に書いたコードをデバッグする方法としては、JIT(Just-In-Time)デバッガをつかう方法とCLRデバッガをアタッチする二種類の方法があります。

JITデバッガを使う

Visual Studio 2005をインストールしているか、.Net Framework 2.0 SDK(無償)をインストールしたときに使えるようになるCLRデバッガがあるWindows XP環境なら、コード部分に

    System.Diagnostics.Debugger.Launch();

と、書くことで、ビルド実行時に以下のようなJITデバッガ選択ダイアログが開きます。

このダイアログから、CLRデバッガ、またはVisual Studio 2005をデバッガとして起動することで、コンテント・パイプライン用コードのデバッグができます。

CLRデバッガをアタッチして使う

残念ながら、現状では、前述のJITデバッガ機能はWindows Vista上では動作しません。そこでWindows Vista上でコンテント・パイプラインをデバッグするにはCLRデバッガ(Visual Studio 2005でも可)をVisual Studio C# Expressにアタッチしてデバッグする方法を紹介します。CLRデバッガは、.Net Framework 2.0 SDK(無償)をインストールすることで使えます。

まずは、以下のコードのように、デバッガがアタッチしている時にのみ中断するようにします。

    if (System.Diagnostics.Debugger.IsAttached)
        System.Diagnostics.Debugger.Break();

次にVisual Studio C# Expressを実行した状態で、CLRデバッガ(スタートメニューから、Microsoft .Net Framework SDK v2.0/Tools/Microsoft CLR Debuggerを選択)を別に実行し、CLRデバッガ上で「Tools/プロセスにアタッチ」を選択すると以下のようなダイアログボックスが開きます。

この選択可能なプロセスのリストの中から、VCSExpress.exeを選択してから、アタッチボタンを押します。これで、CLRデバッガがVisual Studio C# Expressをデバッグしている状態になります。

この状態で、Visual Studio C# Express上でビルドを実行すると、先に書いたコード部分で実行が中断し、後はCLRデバッガ上でVisual Stuidio C# Express上と同じようにデバッグができます。実行中断したときに逆アセンブルが表示されいる場合がありますが、逆アセンブルウィンドウ上から右クリックして「ソースコードへ移動」を選択することで、C#のソースコードが表示されます。

また、デバッグした後にCLRデバッガ上で続行を選択すると、ビルド作業が続行されるので、一度アタッチしてしまえば何度でも簡単にデバッグすることができます。但し、インクリメンタルビルドが働いているので、単にビルドを複数回実行すると二回目以降は実際にビルド作業が入らないのでデバッグすることができません。コンテントの量が少ない場合はリビルドし、コンテントの量が多い場合はデバッグしたいコンテントファイルを更新してからビルドするのが効率的です。

まとめ

今までは、私もJITデバッガを使っていたのですが、この方法だと常にデバッガを起動しようとするので、急いでいるときにコンテント・パイプラインのデバッグを終えてコードを戻すのを忘れて、他人にコードを渡してしまうなんてことも考えられます。それに対して、CLRデバッガをアタッチする手間はあるものの、逆に言えばデバッガをアタッチしない限りは、普通に動作するのでJITデバッガを使うときの問題は起きませんし、特定の例外が発生したときに中断するようにCLRデバッガ上から設定(Debug/例外メニューを使う)できるという利点があります。欠点を強いていうなら、中断するコードを大量に残したままに…なんてことがあるくらいでしょうか？

以上をまとめると、

Windows Vista上で開発してる場合はCLRデバッガ(Visual Studio 2005でも可)をアタッチして使う
Windows XP上で開発している場合は好みによって使い分ける

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

プログラムが思い通りに動かない時にデバッガを使うことで、問題点を直ぐに見つけることができることが多いので、カスタムインポーターや、カスタムプロセッサが期待通りに動かない時には、今回の方法でデバッグして効率的に問題を解決しましょう。

Content Pipeline その２その流れ

Yuichi Ito — Wed, 18 Apr 2007 06:32:00 GMT

コンテントの流れ

前回は、コンテントマネージメントに関する問題の複雑さについて書きました。今回から、その問題を解決する為に設計されたXNAのコンテント・パイプラインの仕組みを紹介していきます。下図は、XNAのコンテント・パイプラインの概念図です。

パイプラインの名から判るように、コンテントが上から下へ流れるように処理され、アセットとしてできあがったものをゲームで使うようになっています。コンテントを川の水、アセットを水道水として考えると、コンテント・パイプラインは、浄水場と配水管に例えることができます。

コンテント・パイプラインは2つのプロセスに分けることができ、ビルド時にコンテントをアセットに変換するオフライン・プロセス、ゲーム実行時にアセットを読み込むオンライン・プロセスとなります。この2つのプロセスは設計目的も明確に分かれていて、オフライン・プロセスではメモリ使用量や実行速度よりも、簡単にコンテントを加工できるように設計されているのに対して、オフライン・プロセスではアセットに対する処理のし易さよりも、メモリ使用量や実行速度重視で設計されています。

オフライン・プロセス

オフライン・プロセスの中心となるのは、データを加工しやすい構造で保持するコンテント(Content)です。XNAフレームワークには標準でMeshContent、AnimationContnet、TextureContnet等のコンテントがあります。コンテントは、その型に対応するTypeWriterとTypeReaderを記述することによって、どんな型でもコンテントとして扱うことができます。

次にコンテントファイルからコンテントにデータを読み込む役割をするのがインポーター(Importer)です。XNAフレームワークには標準でFbxImporter、XImporter、TextureImporter等のインポーターがあります。3Dモデルファイルなどからのインポートの場合、NodeContentやMeshContentに変換する為の処理が入るので、単なるファイルからの読み込みよりも複雑な処理になりますが、前述のようにNodeContentやMeshContent自体がデータ加工がしやすいように設計されているのに加え、MeshHelperやMeshBuilderといった補助クラスを使うことで、独自インポーター製作の労力を軽減できます。

そして、コンテントに対して様々な処理をしたり、ゲームに最適なデータフォーマット変換するのがプロセッサ(Processor)です。XNAフレームワークには標準でModelProcessor、MaterialProcessor、TextureProcessor等のプロセッサがあります。例えばModelProcessorはNodeContentからModelContentに変換するプロセッサで、実行時のパフォーマンス効率が良いようにマテリアル順に並び替えたり、頂点キャッシャの効率化のための頂点データの並び替えや、Windows/Xbox360のプラットフォームの違いによるデータ変換等が行われます。基本的にプロセッサはコンテントからコンテントへの加工をするのですが、XNAフレームワークでは処理前と処理後のコンテントを区別する為にプロセッサ処理後のコンテントはMicrosoft.Xna.Framework.Content.Pipeline.Processors内で宣言されています。

最後に、コンテント、インポーター、そしてプロセッサの管理をするのが、コンテント・コンパイラ(ContentCompiler)です。主な仕事は、指定されたアセットを生成する為に指定されたインポーターとプロセッサを呼び、最後にTypeWriterを使ってXNBファイルへの書き出しをすることです。その他にも、時間節約の為にビルドや配置(Deploy)を必要なアセットのみだけに対して行うなどの処理もします。

オンライン・プロセス

オフライン・プロセスで殆どの処理がすでに終わっているので、オンライン・プロセスではコンテント・マネージャー(ContentManager)を使い、TypeReaderを介してXNBファイルからのアセットを読み込むだけと、非常に単純なものになっています。ContentManagerは読み込んだアセットを保持しているので、既に読み込まれているアセットを読み込もうとした場合は、保持されているアセットを返すキャッシャ機能があります。読み込んだアセットはContentManager.Unloadメソッドで一括して消去することができるので、システム用、ステージ用といった複数のContentManagerのインスタンスを持つことでアセットのライフサイクルの管理をすることができます。

そしてカスタマイズへ

以上がコンテント・パイプラインの大まかな仕組みです。インポーターやプロセッサは独自のものが作れるように設計されているので、FBXやXファイル以外のモデルデータを読み込むインポーター、単純なパラメーターからフラクタルを使ってテクスチャや地形を生成するインポーター、ModelContentから当たり判定データに変換したりするプロセッサを作ったりということができます。

最大の利点はインポーターやプロセッサはモジュール化しやすいので、作ったものを簡単に皆に使ってもらえる、使えるということではないでしょうか？

次からは、実際にインポーターや、プロセッサの作り方の紹介をしていきます。

Content Pipeline その１その問題点

Yuichi Ito — Tue, 17 Apr 2007 05:33:00 GMT

ゲームにはコンテントが必要

ゲーム製作で欠かせない要素として、プログラミングの他にコンテント作成があります。コンテントとは、3Dモデル、テクスチャ、フォント、サウンド、ゲームのパラメーターといったものの総称です。このコンテントを作るツール、例えばテクスチャならフォトショップ、3DモデルならMayaなどといったツールをDCC(Digital Content Creation)ツールと呼びます。DCCツールというと、高いお金を払って買うものと思われがちですが、自分で撮ったお気に入りの写真をゲームで使えば、その写真を撮るのに使ったデジカメはある意味DCCツールといえる訳です。さらに言えば、ゲームで使われるメッセージなどをWindowsに付いてくるメモ帳を使えば、それも立派なDCCツールとなるわけです。

コンテントは必要だけど管理が面倒

次に、作ったコンテントをゲームで実際に使います。DirectXやMDXではテクスチャやXファイルをファイルから直接読み込むことができ、XNAでもWindows版ではテクスチャをファイルから読み込むことができますが、モデルに関してはXファイルを直接読み込むことはできません。今までDirectX等でゲームを作っていた人の中には「なんでTexture.LoadFromFileメソッドがXbox360上で使えないの？」といった疑問を抱く人もいると思います。XNAでコンテントファイルから直接読み込めないようになっているのには以下の理由があります。

拡張性がない
コンテントファイルにはゲームに不必要なデータが含まれている
読み込み時に余分なリソースを必要とする
コンテント・マネージメント

1つ目の拡張性については、ファイルからの読み込みの場合、決められたファイルフォーマットから、決められたデータフォーマットへの読み込みしかできません。ですから、サポートされていないファイルフォーマットをゲーム上で使うには、ファイルフォーマット変換するツールを作る必要があります。ゲーム製作ではDCCファイルにゲーム独自のメタデータを追加することが良くあるので、仮にフォーマット変換ツールを作ったとしても、このメタデータが使えない場合もあります。

2つ目については、コンテントファイルフォーマットはコンテントを作りやすいように設計されていて、画像ファイルではEXIF、3Dモデルファイルなどではツールの環境データなどのゲームに不必要なデータが含まれていたりします。

3つ目は、2つ目と同じように、ゲームで使うデータフォーマットはコンテントファイルフォーマットと違って、各プラットフォームで最適に動作するように設計されています。ですから、ファイル読み込み時にゲームに適したデータフォーマットへの変換が発生するので、その処理に時間が掛かるのと、変換用のメモリを必要とします。また、ゲーム用のデータフォーマットはプラットフォームの違いによっても変わってきます(例えばWindowsとXbox360ではエンディアンの違いなど)。これらの変換処理が複雑化するほど、読み込み時間も長くなる、つまり、ロード時間が長くなるのでゲームを快適に遊べなくなってしまいます。

そして4つ目は、たとえファイルからデータを直接読めたとしても、開発環境を含めたコンテント・マネージメントのしくみ無しでは快適なゲーム開発環境が実現できないということです。例えば、Xbox360上でゲームを作っている場合、必要なファイルはネットワークを介してファイル転送する必要がありますが、コンテント・マネージメントがない場合、ファイル転送を手作業でしなければいけません。手作業だとファイルを転送し忘れたり、転送場所を間違ったりと、人為的ミスが発生してしまいます。また、大量のコンテントファイルがある場合、全てのファイルを転送したりすると時間の無駄にもなります。

以上のように、ゲームでコンテントを使用するには様々な問題があり、これらの問題を解決し、XNAの目標であるゲーム開発者がゲーム開発に集中できる環境の提供を実現するために設計されたのがコンテント・パイプラインです。

次回からは、数回に渡ってコンテント・パイプラインの仕組みを紹介していきます。

ゲームプログラミング開始

Yuichi Ito — Wed, 07 Mar 2007 08:29:00 GMT

前回は、XNA Game Studio Expressでゲームプロジェクトを新規作成したときに生成されるテンプレートコードの中身の説明をしました。今回は、ゲームプログラムの基本となる以下のものを実装、つまりコーディングをします。

コンテントの読み込み
SpriteBatchを使ったスプライト表示
コントローラーによる移動

今回は、簡単な説明に留めますが、次回からはそれぞれについて詳しく説明していきます。

コンテントの読み込み

XNAにはビットマップ、3Dモデル、オーディオといったゲームを作る上で必要なコンテントを簡単に、効率よく使うためのコンテント・パイプラインというものがあります。全てのコンテントは、プロジェクトをビルドした時に、コンテント・パイプラインによって処理され、Windows/Xbox360上で効率良く使えるデータ形式に変換されるようになっています。また、それぞれのゲームで独自形式のフォーマットを取り扱えるようにカスタマイズできる機能を持っています。

今回使うコンテントは、左の飛行機の絵が一枚だけです。XNAでは全ての画像データはテクスチャとして変換されます。コンテントのプロジェクトへの追加はソートコードの追加と同じで、ソリューションエクスプローラからコンテントを追加するプロジェクトを右クリックしてメニューを開き、その中の追加/既存の項目を選びます。ダイアログボックスが開いたら、ファイルの種類をContent Pipeline Filesにしてから追加したいコンテントを選びます。

GSE 1.0では以下のファイルフォーマット形式がサポートされています。

3Dモデル	2D画像	マテリアル	オーディオ
.FBX .X	.DDS .BMP .JPG .PNG .TGA	.FX	.XAP(XACT)

プロジェクトディレクトリ直下に直接コンテントを追加してもいいのですが、コンテントとコードの区別がつくようにプロジェクトディレクトリの下にContentというディレクトリを作っておくと便利です。また、この場合、ContentManagerの初期化の時(Initializeメソッド内)にコンテントのルートディレクトリを指定しておくと、コンテントの読み込みの時に"Content/アセット名"と書かずに済みます。

        // コンテントのルートディレクトリを"Content"に設定する
        content = new ContentManager(Services, "Content");

実際のコンテントの読み込みをする為には以下のようなコードをLoadGraphicsContentメソッド内に書きます。

        // 飛行機用のテクスチャを読み込む
        airPlaneTexture = content.Load<Texture2D>("air-plane");

ContentManagerクラスにはLoad<T>という、ジェネリクスメソッドがあり、どのような型のコンテントでも同じようにして読み込むことができます。.Net 2.0ならではの機能であるジェネリクスを使うことによって、今までのようにLoadTexture2D、LoadMeshFromFileといった、長い関数名を覚える必要もなく簡単にコンテントを読み込むことができます。

スプライトの描画

XNAでは簡単にテクスチャイメージを描画する為のSpriteBatchというクラスがあります。なぜ単にSpriteではなく、SpriteBatchという名前になっているかというと、このクラスは複数のスプライトをまとめて処理(バッチ処理)する機能をもっているからです。詳細については別の投稿で説明しますが、簡単に言うとWindows/Xbox360の違いを気にせずに、高パフォーマンスを実現しながらも、簡単に使える便利なものといった感じです。

        // SpriteBatchに描画開始を伝える
        spriteBatch.Begin();

        // 飛行機のテクスチャを指定した座標に表示する
        spriteBatch.Draw(airPlaneTexture, airPlanePos, Color.White);

        // SpriteBatchに描画終了を伝える
        spriteBatch.End();

以上のコードをDrawメソッド内に書き加えます。SpriteBatch.BeginとSpriteBatch.Endの間にSpriteBatch.Drawメソッドを書くようにします。BeginとEndの間には何回でもDrawを呼ぶことができます。SpriteBatch.Beginを呼ぶ前にDrawを呼んだり、SpriteBatch.Beginを続けて呼んだりすると、実行時に例外が発生します。

スプライトは回転、スケールといった機能もサポートしていますが、ここでは単にテクスチャを指定した座標に描画しています。座標を表すのがVector2構造体なので、2D描画に浮動小数点を使って大丈夫なの？と思う人もいるかもしれませんが、最近のGPUの殆どがピクセル以下の描画をサポートしていて、画面をゆっくりとスクロールさせる時などの滑らかさに違いが現れます。

ですから、XNAでゲームを作った場合は、昔の日本製パソコンで出てたシューティングゲームのように「脅威の0.5ドットスクロール」と宣伝することが奨励されています(ウソです)。

コントローラーによる移動

ここまでで、画面には飛行機が表示されるようになっていますが、ここではその飛行機をコントローラーによって動かすコードを実装します。

    // 飛行機の座標をコントローラー及び、キーボードの入力によって変更する
    Vector2 dir;
    if (ProcessKeyboardInput(out dir) == false)
    {
        // キー入力が無かったので、コントローラーの左スティックの状態を取得する
        dir = GamePad.GetState(PlayerIndex.One).ThumbSticks.Left;
    }

    dir.Y = -dir.Y; // スクリーン座標のY方向とキー入力の上下を合わせる

    const float speed = 400.0f; // ピクセル/秒の速度
    airPlanePos += dir * (float)gameTime.ElapsedGameTime.TotalSeconds * speed;

上のコードをUpdateメソッド内に書き加えます。日本では北米程にXbox360が普及していない、つまりXbox360コントローラーを持っている人が少ないと思われるので、ProcessKeyboardInputというメソッドでキーボード入力をサポートしましたが、ここでは割愛します。

ゲームコントローラーの入力は、自由な時にGamePad.GeStateを使うことによって、その状態を知ることができます。コントローラーが繋がっていない場合でも、プログラム自体は問題なく動作するので上のように非常に簡単にコントローラーの入力を処理することができます。

ここではThumbSticks.Leftという、コントローラーの左スティックの状態を取得しています。ThumbSticks.LeftはVector2構造体で、スティックの左右はVector2.Xに格納され、左が-1、右の状態が1の値を示し、スティックの上下はVector2.Yに格納され、上が1、下が-1の値を示します。アナログスティックなので傾け方によって、-1から1までの値に変化します。

コントローラーから、移動したい方向を取得した後は、その方向への移動量を現在の座標に加えることによって移動します。ここでは単に一定量の速度で移動させるのではなく、GameTime.ElapsedGameTimeを使うことで、Game.IsFixedTimeStepがfalseの時にフレームレートが変化した場合でも、飛行機が同じ速度で移動するようになっています。Game.IsFixedTimeStepによるゲーム更新の仕方の違いは次の投稿で詳しく説明します。

ゲームの基本ができた

ここまででゲーム製作の基本である、コンテントの読み込み、メインループでの更新、描画、そしてコントローラーの入力といった処理のXNA上でのやり方を紹介してきました。これだけでも、簡単な2Dベースのゲームを作る下地はできたのではないでしょうか？

今回、実装したコードをアップしておきます。下に表示されているAttachmentのSample01.zipをクリックすることでダウンロードできます。Windows用とXbox360用のソリューションファイルが入っているので、どちらのプラットフォームでも動作します。