Twitter @HigenekoTwitter #XNA
http://creators.xna.comに新しいコンテントが増えました。
スターターキットとして、新たにRacing Gameが追加されました。これは以前からXNAレーサーと呼ばれていたゲームです。もちろん、スターターキットなのでフルソースコード、フルコンテント付です。
また、新しいサンプルプログラムとして以下のものが追加されました。
また、ユーティリティとして以下のものが追加されました。
その他にもアーティクルや、チュートリアルビデオにも有用な情報が追加されているのですが、全て英語なので読みづらいと思います。チュートリアルビデオに追加されたXACTツールを使っての、サウンドエフェクトの音量やピッチを変更する方法や、3Dオーディオの使い方などは映像を見るだけでも、なんとなく判るかも？
GSE 1.0 Refreshは1.0とバイナリ互換、つまり1.0でコンパイルしたものが、そのまま1.0 Refreshで動作するようになっているので、1.0のAPIはそのままで、新しいAPIが追加されています。
ここにRefreshで追加されてAPIのリストがあります。今まで概要は説明してきましたが、詳細は省いていたので、以下に追加されたAPIの詳細を書きます。
この殆どの機能は、フィードバックを元に追加されています。特にMath関連の追加機能は全てフィードバックを元にしたものです。逆に言えば、フィードバックさえすれば、その機能が次のリリースに反映される可能性が非常に高いということです。日本語の報告もMicrosoft Connectにできるようになったので、沢山のフィードバックをお待ちしております。
と、言うわけで
Microsoft XNA Game Studio Express 1.0 Refreshがリーリスされました。主な新機能は
デベロッパー同士でのゲームバイナリの交換は、GSEのビルドメニュー内の「Package "プロジェクト名" as XNA Creators Club Game」を選択すると、Windowsならプロジェクト名-Windows.ccgameがbin/x86/ReleaseまたはDebugフォルダ内に、Xbox360ならプロジェクト名-Xbox360.ccgameがbin/Xbox 360/ReleaseまたはDebugフォルダ内に作られます。このccgameファイルを開発者同士(GSEをインストールしている人)で共有することができます。Xbox360用のパッケージファイルを実行すると、自動的にXbox360に必要なファイルを転送してくれるので、手軽にゲームのやりとりをすることができるようになっています。
ビットマップベースの文字描画サポートでは、日本語を含むテキスト描画ができるようになりました。新しい項目の追加から、SpriteFontを選ぶことで、任意のフォントを追加することができます。但し、予め使用する文字を指定する必要があります。デフォルトで英数字がspritefontファイルの<CharacterRegion>に追加されています。これだと日本語文字、特に漢字を追加するのが面倒になるので、日本語メッセージファイル等からFontDescriptionを作るインポーターを作った方が良いでしょう。実際の文字描画はSpriteBatchに追加されたDrawStringメソッドを使います。他のSpriteBatchと同じようにスケールや回転ができるようになっています。
Xbox360上でのサムネイルは、プロジェクトのプロパティ画面のアプリケーションタブの下のほうにGame thumbnailという項目で任意の画像を指定することで、Xbox360のMy Game画面のサムネイルを変更することができます。また、新規にプロジェクトを作った場合は既定のサムネイルが自動的に追加されます。
コンテント・パイプラインの記事で、どんなカスタムインポーターを書いたら良いのか悩んでましたが、日本語メッセージファイルからFontDescriptionをインポートするというのが丁度良さそうなので、次回はそれを作ってみたいと思います。
前回は、コンテントマネージメントに関する問題の複雑さについて書きました。今回から、その問題を解決する為に設計されたXNAのコンテント・パイプラインの仕組みを紹介していきます。下図は、XNAのコンテント・パイプラインの概念図です。
パイプラインの名から判るように、コンテントが上から下へ流れるように処理され、アセットとしてできあがったものをゲームで使うようになっています。コンテントを川の水、アセットを水道水として考えると、コンテント・パイプラインは、浄水場と配水管に例えることができます。
コンテント・パイプラインは2つのプロセスに分けることができ、ビルド時にコンテントをアセットに変換するオフライン・プロセス、ゲーム実行時にアセットを読み込むオンライン・プロセスとなります。この2つのプロセスは設計目的も明確に分かれていて、オフライン・プロセスではメモリ使用量や実行速度よりも、簡単にコンテントを加工できるように設計されているのに対して、オフライン・プロセスではアセットに対する処理のし易さよりも、メモリ使用量や実行速度重視で設計されています。
オフライン・プロセスの中心となるのは、データを加工しやすい構造で保持するコンテント(Content)です。XNAフレームワークには標準でMeshContent、AnimationContent、TextureContent等のコンテントがあります。コンテントは、その型に対応する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から当たり判定データに変換したりするプロセッサを作ったりということができます。
最大の利点はインポーターやプロセッサはモジュール化しやすいので、作ったものを簡単に皆に使ってもらえる、使えるということではないでしょうか？
次からは、実際にインポーターや、プロセッサの作り方の紹介をしていきます。
ゲーム製作で欠かせない要素として、プログラミングの他にコンテント作成があります。コンテントとは、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の目標であるゲーム開発者がゲーム開発に集中できる環境の提供を実現するために設計されたのがコンテント・パイプラインです。
次回からは、数回に渡ってコンテント・パイプラインの仕組みを紹介していきます。