XNA 2.0のネットワーク機能

XNA TeamブログにXNA GS 2.0におけるネットワークサポートについての投稿がありました。元の投稿では各シナリオについて細かい説明がありますが、ここではできるだけシンプルなルールを書いていこうと思います。 XNA Game Studio 2.0ではネットワーク対応のマルチプレイヤーゲームを作れるような仕組みが提供されます。このネットワークの接続形態はシステムリンクとLive!接続の二つがあります。 システムリンクは、同じサブネット内同士でのマルチプレイヤーゲームを可能にします。一般的なのは同じネットワークハブにPC、Xbox 360を繋げた時に使うことができます。 Live!接続ではXbox 360上ならばXbox Live!、Windows上ならばGames for Windows – LIVEを通す、つまりLive!サーバーを介してのマルチプレイヤーゲームを可能にします。離れた場所からのネットワーク接続を可能にする方法です。 ここで注意しないといけないのはLive接続によってゲームを遊ぶ為にはXbox 360、Windowsの両方ともLiveゴールド会員であることとXNAクリエーターズクラブ会員である必要があるということです。   マルチプレイヤーゲームを遊ぶのに必要なものをまとめると以下の用になっています。   システムリンク Live Windows なし Liveゴールド、XNA CC Xbox 360 XNA CC Liveゴールド、XNA CC 注:XNA CCはXNAクリエーターズクラブの略 WindowsでのLive接続にXNA CCは必要ないのでは?と思ってしまいますが、そこらへんは色々と解決しないといけない問題があるので現状のようになっています。 ともかく、XNA 2.0のベータ版をはもうすぐでますので、より良いものにするためにバグ報告、要望などを言って貰えると有難いです。


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

Shawn Hargreaves氏のブログに、コンテントパイプラインで使われるタイプがどのように使われるかを表した図が記載されています。   図の左側から、ソースアセットからどのインポーターを使ってContent DOM形に変換され、どのプロセッサーがどんな型のデータを出力し、TypeWriterによってXNBファイルに書き込まれ、最後にランタイム時にTypeReaderによってどの型に読み込まれるかというのを網羅しているので、非常に有益な情報です。 何も問題がなければ、この情報は次のXNA Frameworkのドキュメントに記載される予定です。

1

クリエーターズクラブオンライン更新 07年9月号

クリエーターズクラブオンラインのサイトが更新されました。先月はGameFestの開催と重なったので数が少なかったのですが、今月は4つのサンプル、3つのユーティリティ、そして1つのアーティクルが追加されました。そんな訳で例によって例の如く私なりに紹介させて頂きます。   Collision Series 4: Collision with a Heightmap このサンプルはコンテントパイプライン上でビットマップイメージから生成されたハイトマップ上での衝突判定をするサンプルコードです。コリジョン判定自体は単に指定した座標の高さを取得するシンプルなものですが、カメラも衝突判定を使っているのでカメラが地面にめり込んでしまうという不具合を回避しています。   Custom Model Class このサンプルでは、ランタイム時に独自フォーマットのモデルデータを扱う為に、コンテントパイプラインのDOMに格納されたモデルデータの取得、カスタムコンテントの作り方、そしてランタイム時のデータの読み込みとモデル描画のコードが含まれています。自分なりの独自フォーマットデータを作るときの雛形として有用なサンプルです。   Mesh Instancing   通常、複数のモデルを描画するにはDrawPrimitive等のメソッドを複数回呼びますが、描画するモデルの数が大量に増えた場合、GPUが実際に描画するよりもDrawPrimitiveの呼び出し自体に掛かるオーバーヘッドの方が大きくなる場合があります。 この問題を解決する為にWindows上ではモデルインスタンスと呼ばれる手法が使われます。このサンプルでは同じモデルを複数の行列で示される位置に描画するようになっています。私のPC環境ではモデルインスタンス使用時と、インスタンス無しステートバッチング無しの状態と比較すると8倍程のフレームレート差がでています。 Xbox 360上ではvfetchと呼ばれるシェーダーのインラインアセンブラを使って実現しています。   Shatter このサンプルでは任意のモデルに使われている三角形ポリゴンをひとつずつアニメーションさせることで、モデルがバラバラになっていく視覚効果をだしています。 コンテントパイプライン内で指定されたモデルを独立した三角形ポリゴンのモデルデータに変換し、必要なパラメータを追加しています。ランタイム時は頂点シェーダー内で指定された時間によって三角形の位置や回転状態を計算しているので時間の逆再生などもできるようになっており、CPUリソースを使わないという利点もあります。   Curve Editor   XNAフレームワークにはHermiteベースの一次曲線を使うためのCurveクラスがあります。このクラスの使い道として代表的なのはPosition値を時間として扱うアニメーションカーブで、モデルのアニメーションに使われるのはもちろん、例えばゲーム内の時間によって太陽の位置やフォグ等のパラメーターを変化させたりするときに使います。 簡単な曲線や直線の場合はプログラムで直接書くだけで済みますが、複雑になってくると欲しくなってくるのがエディタです。 このユーティリティには単体で動作するCurveEditorがあり、このエディタ内では以下の機能があります。 複数カーブの同時編集 タンジェント値の自動計算 タンジェント値の視覚的編集 コンテントパイプラインでそのまま使えるXMLファイルへのCurveの読み書き 任意のキーのPositionとValueを直接編集できるテキストボックス Undo/Redoサポート また、CurveEditorが使っているCurveControlは使い回しができるユーザーコントロールとして設計してあるので、自分で作ったゲームエディタ内で使ったり、デバッグビジュアライザーを作る時に便利です。   Input Reporter   このユーティリティーではXbox 360コントローラーの入力情報をリアルタイムに見ることができます。振動モーターの有無や複数のコントローラーの接続状態も右上のアイコンで表示されるようになっています。 基本的にXbox 360用の入力機器は標準コントローラーとしても使えるようになっています。ですから、ダンスパッドやギターコントローラーを繋げた時に、標準コントローラーのどのボタンやキーに割り当てられているかを調べる時に便利なユーティリティではないでしょうか?   Xbox 360 Controller Button Glyphs…

3

XNA Game Studio 2.0

GameFest 2007でXNA Game Studio 2.0のアナウンスがありました。XNAチームブログに詳細がありますが、ここでは個人的な意見(つっこみ?)を交えて説明してみたいと思います。   XNA Game Studioの新機能 全てのバージョンのVS 2005で動作するようになる これで仕事でVS2005にはあるけど、XNA GSEでは使えなかった、マルチスレッドのデバッグや、デバッグ時に自動的にローカル変数を表示してくれたり、更に個人的に外せないはキーボードマクロとか使えるようになります。 Xbox 360との接続するための手続きが簡単になった ノーコメント コンテントビルドが使いやすくなる ノーコメント コンテントパイプライン用のプロジェクトテンプレートを追加 コンテントパイプラインの拡張コードを書くときには色々と煩雑な手続き多かったので、これでカスタマイズするのが楽になるかも? コンテントプロセッサーにカスタムパラメーターを追加することができるようになる 現バージョンでは、複数のテクスチャ処理用のプロセッサーがありましたが、これをひとつのプロセッサとしてパラメーターによって処理方法を変えるといったことができるようになります。また、今まではちょっとしたパラメーターでもXMLファイルから読み込むコードを書く必要がありましたが、カスタムパラメーターの導入で簡単になります。   XNA Frameworkの新機能 Xbox Live!のサポート Xbox Live!を通しての、Xbox 360間はもちろん、Xbox 360とWindows間で動作するネットワークゲームを作るのに必要な機能があります 機能的にはロビーへの参加、セッションの生成、ゲーム中のデータパケットのやりとりなどを簡単にできるようになっています。 System Linkもサポートしているので、Xbox Live!を介さないでLAN上でも動作します。 新しいXACTエディター DirectX SDKに付属しているのがアープデートされてるので、追いつかないとねいけませんしね(笑) Windows Form上で動作するようになった これでレベルエディターとか、非ゲームアプリも手軽に作れるようになります。 GraphicsDeviceの仮想化 デバイスのリセットや再生成を意識せずに使えるようになります。 新しく追加されたGame.LoadContentメソッド内でデバイスがリセット時か生成時か気にしなくて良いのはもちろん、グラフィクス、非グラフィクスのリソースかを気にしなくてもよくなります。 Windows、Xbox 360間でのRenderTargetの振舞いの統一化と、Xbox 360上でのMRT(Multiple Render Target)のサポート ポストプロセス系の処理、特にブルームとかの処理をしているとWindowsとXbox 360上での振舞いの違いを考慮しないといけないのでプログラムが煩雑になってしまうという問題を解決します。 GameComponentを階層構造にするのが簡単になる ゲームを作るときに、タイトル画面、メニュー画面、ゲーム画面といった数種類の画面を行き来する必要があるのですが、この時にそれぞれの画面をGameComponentとして使い、その中で更に複数のGameComponentを扱うようにすると各画面の管理が簡単になります。現バージョンではGameComponentCollectionが、このシナリオを想定していない作りになっているので実現するのが難しかったという問題を解決します。   と、いった感じです。リリース時期は年末を目指していて、リリース時期が近づくにしたがった更に詳細な情報がリリースされます。

1

Content Pipeline その4 そのデバッグ

コンテント・パイプラインのデバッグ 前回は、実際のコードを見ながらコンテント・パイプラインのカスタマイズの方法を紹介しました。前回のように、ロジック自体が簡単な場合は良いのですが、もう少し複雑なプログラムをコーディングしている時に必要になるのが、インポーターやプロセッサのコードをデバッグすることです。 ここで問題なのは、ゲーム本体をデバッグする感覚でブレークポイントをコンテント・パイプラインのコード部分に設定してビルドしたとしても、何事も無かったかのようにビルトが終了してしまうということです。コンテント・ビルドは普通にアプリケーションを走らせるのと違い、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…

1

クリエーターズクラブも更新

http://creators.xna.comに新しいコンテントが増えました。 スターターキットとして、新たにRacing Gameが追加されました。これは以前からXNAレーサーと呼ばれていたゲームです。もちろん、スターターキットなのでフルソースコード、フルコンテント付です。 また、新しいサンプルプログラムとして以下のものが追加されました。 Bloom ポストプロセスの代表的手法の一つである、眩しい光などが滲む、ブルームのサンプルです。 プリミティブ描画 Spacewarで使われていた、VectorShapeクラスを元にしたPrimitiveBatchを使ったサンプルです。このクラスを使うことで簡単に点、線分、三角形などを画面に描画することができます。 Game State Management ゲームを作る上で必ずといって必要だけど、作るのが面倒なメニュー画面。このサンプルでは、複数のメニュー画面の切り替え簡単にするための仕組みを提供しています。 3D Audio GSE 1.0 RefreshでサポートされたXACT 3Dの使い方のサンプルです。 2Dパーティクル SpriteBatchを使った2Dベースのパーティクルシステムのサンプルです。 シェーダーシリーズ 1:頂点ライティング シェーダーの基本である、頂点ライティングのサンプルです。 また、ユーティリティとして以下のものが追加されました。 Bitmap Font Marker Utility WindowsのTrueTypeフォントから、.bmpファイルを生成するツールです。ここで生成された画像をFontTextureProcessorを使って、SpriteFontとして使えます。変換された画像を加工することで、影付の文字にしたり、文字列の中にコントローラーのボタンイメージを表示したりといった事に使うことができます。 Xbox360 コントローラーグラフィクス ゲームの操作方法を説明したりするときに使えるXbox360のゲームコントローラーのイメージファイルがあります。   その他にもアーティクルや、チュートリアルビデオにも有用な情報が追加されているのですが、全て英語なので読みづらいと思います。チュートリアルビデオに追加されたXACTツールを使っての、サウンドエフェクトの音量やピッチを変更する方法や、3Dオーディオの使い方などは映像を見るだけでも、なんとなく判るかも?


GSE 1.0 Refresh API その詳細

GSE 1.0 Refreshは1.0とバイナリ互換、つまり1.0でコンパイルしたものが、そのまま1.0 Refreshで動作するようになっているので、1.0のAPIはそのままで、新しいAPIが追加されています。 ここにRefreshで追加されてAPIのリストがあります。今まで概要は説明してきましたが、詳細は省いていたので、以下に追加されたAPIの詳細を書きます。   Math関連 BoundingBoxとBoundingFrustumのGetCornersメソッドを追加。Cornersプロパティと違って予め確保した配列を指定できるので、GC発生率を抑えることができます。 Curveクラスにタンジェントを計算するComputeTangentとComputeTangentsメソッドを追加。現在のCurveKeyの状態でCurveTangentで指定したタンジェントを計算します。例えば、CurveTangent.Smoothを指定することで、滑らかに繋がった曲線になるようにタンジェントを計算します。 MatrixとQuaternionにCreateFromYawPitchRollメソッドを追加。ヨー、ピッチ、ロールの角度を指定することで、回転行列やクォータニオンを生成します。 Matrix.CreateReflection。指定したPlaneの位置でオブジェクトを鏡で反射させた場所に移動させる行列を生成します。水面や鏡の反射されたものの描画に使えます。 Matrix.CreateShadow。オブジェクトを指定したPlaneとライト方向によって、射影行列を生成します。平面への投射しかできませんが、簡単な影の描画に使えます。 Matrix.Decompose。行列をスケール、回転、移動の三つの要素を取り出します。指定する行列はスケール、回転、そして移動の順で組み合わされたいう前提があります。 Matrix.Transformメソッド。指定した行列を、指定されたクォータニオンで回転させます。 Vector2、Vector3、Vector4のTransform、TransformNormalメソッドで配列が指定できるようになった。 Vector2、Vector3、Vector4のTransform、TransformNormalメソッドでQuaternionが指定できるようになった。 RayとPlaneの交差判定、Ray.Intersectsメソッド追加。線の始点と面の距離を返します。 RectangleとPoint、Rectangle同士の交差、包括判定、Contains、Intersectsメソッドの追加。 グラフィクス 文字描画の為のSpriteFontクラスの追加。文字列を描画したときの領域を計算するMeasureStringメソッドなどがあります。実際の描画はSpriteBatch.DrawStringを使います。 SpriteBatch.BeginでMatrixを指定できるようになった。画面分割などのゲームを作るとき等、Drawメソッドを呼ぶときに自前で移動させたり、スケールさせたりする計算をする手間が省けます。 BasicEffect.PreferPerPixelLightingプロパティの追加。このプロパティにtrueにすることで、ピクセル単位のライティングを使用するようにします。ピクセル単位のライティングにはシェーダーモデル2.0以上のビデオカードが必要ですが、BasicEffectはそれを自動判別するので気軽に使えます。 GraphicsDeviceで、Vector2、Vector3、Vector4、Quaternion、そしてMatrixといった構造体をピクセル/頂点シェーダーの定数レジスタに直接設定できるようになりました。 オーディオ XACT 3Dオーディオサポートの為に、AudioEmitter、AudioListenerといったクラスが追加されています。3Dオーディオは5.1chスピーカーで、後ろの方から音が聞こえてきたりするのはもちろん、救急車が目の前を走り去るときに起こるドップラー効果もサポートしています。ここにサンプルコードがあります(ねこの泣き声のドップラー効果つき)。 コンテント・パイプライン SpriteFontをサポートするためのFontDescriptionやFontDescriptionProcessorの追加。 任意の画像、例えばコントローラーのボタンイメージをSpriteFontとして使う為のFontTextureProcessorの追加。 3DテクスチャをサポートするためのTexture3DContentの追加。 外部のコンテントを参照するときに使える、ExternalReference<T>クラスの追加。 コンテントクリーンビルドのためのMSBuild用のタスク、CleanContentの追加。   この殆どの機能は、フィードバックを元に追加されています。特にMath関連の追加機能は全てフィードバックを元にしたものです。逆に言えば、フィードバックさえすれば、その機能が次のリリースに反映される可能性が非常に高いということです。日本語の報告もMicrosoft Connectにできるようになったので、沢山のフィードバックをお待ちしております。


Game Studio Express 1.0 Refresh

と、言うわけで Microsoft XNA Game Studio Express 1.0 Refreshがリーリスされました。主な新機能は Windows Vistaのサポート 開発者同士でのゲームバイナリ交換のサポート ビットマップベースの文字描画のサポート XACT 3Dオーディオのサポート Xbox 360上でのゲーム独自のサムネイル画像が使えるようになった その他の細かい機能追加 バグフィックス   デベロッパー同士でのゲームバイナリの交換は、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をインポートするというのが丁度良さそうなので、次回はそれを作ってみたいと思います。

4

Content Pipeline その2 その流れ

コンテントの流れ 前回は、コンテントマネージメントに関する問題の複雑さについて書きました。今回から、その問題を解決する為に設計された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から当たり判定データに変換したりするプロセッサを作ったりということができます。 最大の利点はインポーターやプロセッサはモジュール化しやすいので、作ったものを簡単に皆に使ってもらえる、使えるということではないでしょうか? 次からは、実際にインポーターや、プロセッサの作り方の紹介をしていきます。

2

Content Pipeline その1 その問題点

ゲームにはコンテントが必要 ゲーム製作で欠かせない要素として、プログラミングの他にコンテント作成があります。コンテントとは、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の目標であるゲーム開発者がゲーム開発に集中できる環境の提供を実現するために設計されたのがコンテント・パイプラインです。 次回からは、数回に渡ってコンテント・パイプラインの仕組みを紹介していきます。