Twitter @HigenekoTwitter #XNA
今回からGame Buildingで作ったゲームの製作過程を紹介していこうと思います。今まではどちらかというとプログラマー視点から記事を書くことが多かったのですが、今回のGame BuildingではXNA Game Studioをより良いものにする為に実際にインディーズ・ゲーム開発者側の視点に立ってゲーム製作をしてみようということを念頭に置いて製作しました。
また、Game Buildingでは限られた時間内で製作するという制限があります。Game Building期間中でも、他に作業が入ったりすることがあるので、いかにして短い間内で遊べるゲームを完成させることができるかがカギとなってきます。今回のGame Buildingは全体で二週間あったのですが、私が実際に作業できたのは9月19日(日)～9月24日(金)の午後四時まで、日付の上では６日間でしたが、途中で仕事が入ったので実質５日間の作業期間となりました。
この短期間内では新しいゲームプレイを企画して試したりする時間がないので、既存のゲームを作ることにしました。元となったゲームはギャラクシアン3と呼ばれる１６年前のゲームです。当時は二つのLDプレイヤーを使ってあらかじめ用意されたビデオ画像の上に3Dポリゴンで表示された敵を撃つというゲームでした。今だったらリアルタイムでできそうだし、背景自体とのインタラクションは少ないし、移動する敵を撃つだけというシンプルなゲーム内容なのでプログラム技術的には問題なさそうということで、今回はこのゲームを再現することにしました。
私はこのゲームが大好きで、アーケードに通いまくって６人プレーのところを一人でクリアできるよう頑張ったり、ゲーム内容を収録したLDとか、サントラとか、設定資料集まで買ったりしていました。PS1版があるのですが、動画のフレームレートが低く(たぶん15FPS程度？)、あんまり快適とは言えないものでした。
個人的にはネットワーク対応にして大人数でプレイできれば面白そうなのに、とは思うのですがそういった話もとんと聞かないので、ないのなら自分で作ってしまおうということで、今回のGame Buildingで作ることにしました。
今回は作業を始める段階で自作しておいたコンテント・パイプラインのライブラリがあったのが大幅な作業短縮に繋がりました。このライブラリは3DモデリングツールのLightWaveのモデルファイルフォーマットであるLWOファイルと、シーンファイルフォーマットであるLWSファイルのインポーターとプロセッサがあります。ですから、プロジェクト上に直接LWOファイルとLWSファイルを追加するだけで簡単にコンテントを追加することができるようになっています。
また��テスト用に作っておいたシーンファイル再生ライブラリがあるのでそれを流用することにします。LightWave用のパイプライン・ライブラリにはLightWaveで作ったアニメーションをCurveクラスのデータに変換するようになっていますが、大量のCurveクラスを使うのは処理速度的に厳しそうだったので、スキニングモデルサンプルにあるAnimationPlayerを元にしてあらかじめキーフレームデータへと変換するようになっています。
コンテントとして流用したのは最初の出撃シーンで、これは友人がモデリングしてもらったものを使わせてもらいました。
次回からは、時系列毎にGame Buildingの５日間にあった出来事を書いていきます。
NickがGame Buildingで作ったゲームの紹介と、XNA Game Studio 4.0を使っての製作過程の紹介を複数回に渡って紹介しています。
My AppWeek 2010
The delights of DualTextureEffect 4.0で追加されたDualTextureEffectを使ってライトマップを実現しています。ライトマップ自体は3D World Studioを使って生成しています。
Batch your polygons 3D World Studioから出力されたモデルをそのまま使うと実行時のDraw呼び出しの回数が増え、４画面分割の場合には716回の呼び出しになってしまうという問題がありました。Nickはランタイム時にビューカリングするのではなく、複数のモデルをまとめるカスタム・プロセッサを作ることで描画関数呼び出しの回数を716回から20回にまで減らすことでパフォーマンスが劇的に向上しました。
ここでのポイントは実装に時間の掛かるポータルカリングなどの実行時の最適化をせずにコンテント自体を最適化することで少ない労力で効果的に最適化したということでしょう。
Don’t reinvent those wheels 限られた時間の中でゲームを作るというGame Guildingはいかにして効果的にゲームを作ることができるかという事が課題になります。
そこでNickは、EasyConfig、BoxCollider、パーティクルサンプルなどの既存のコードを組み合わせることで製作時間の短縮を実現しています。パーティクルサンプルはグレネードの表現に使ったそうです。
Nickはゲームを完成させたいのであれば、世の中に流用できるものが無いかを探すのにほんの少し時間を掛けることで開発速度のアップにつながるとしています。
Don’t build more than what you need Nickは、最初のうちは空き時間を使って作っていた3Dゲームエンジンを完成させ、自分のゲームに使おうと思いましたが作っているうちに開発速度が思ってたよりも遅いということに気づきました。
そこでNickは途中で自作の3Dゲームエンジンを捨てて、Game Buildingに必要な部分だけを作るようにしたことで殆ど時間を費やすこともなくエンジンを使っていたところまで組みなおし、その後も理想的な開発速度を保ちながら開発を続けることができました。
ここでの教訓として、3Dゲームエンジンを自作するのは技術的に楽しいものですが、作りたいゲームが定まらない状態だと、不必要な機能を盛り込んだりして終わりが見えず、時間が掛かりすぎて最終的にモチベーションが続かずに放置するなんてことを経験した人は少なからず居ることと思います。
逆に自分が作りたいゲームをしっかりと把握していると迷うことなく短い時間でゲームを完成させることができます。大事なのは「ゲームを作りたい」よりも「ゲームを完成させる」という目的意識を持つことです。
と、まじめな話になってしまったので、ここでちょっと一息。
昨日の投稿で紹介し忘れたゲームがひとつありました。作成したCooperは、グラフィクスよりもオーディオ部分に気合を入れて作っていたので残念ながらゲームシーンのスクリーンショットはありませんが、そのタイトルは
Beers of War (ビアーズ オブ ウォー)
です。私はこのタイトル画面を見た瞬間にあのテーマ曲が頭の中で再生されました(笑)
内容は、缶ビールと瓶ビールの壮絶な戦いを描いたゲームだそうです。プレイヤーが操るのは缶ビール側で、南部訛りの英語で喋るカウボーイタイプなキャラクター(でも缶)のBud(バド)、筋肉ムキムキタイプ(でもやっぱり缶)のColt(コルト)、45才。某ゲームに出てくるマーカスタイプ(だから缶だって)のFlask(フラスク)、そしてオーストラリア訛りのFosters(フォスタース)の４人のキャラクターを操ることができる予定だったようです。
ゲームは一般的なFPSなのですが、ビール瓶の敵を倒すたびに
「バド、なんでお前はワインクーラー臭ぇんだ？」
「今日はリサイクル業者が大忙しだな」
「なんで、この町はこんなに見てくれが悪いんだ？」「ライトマップが無いからであります、サー」
という、ユニークな台詞が大うけでした。
是非、このまま続けて作って欲しいですね。
XNA Game Studio 4.0がリリースされ(Xbox 360のランタイムの完成版はもう少し待ってね)、XNAチーム内では恒例のGame Building(AppWeek)がありました。3.1の時のAppWeekのゲーム紹介はここ。
いつもならGame Buildingの期間は一週間程度なのですが、今回は二週間という長い期間があり、皆いろんなゲームを作っていました。残念ながら、私は他にしなければいけない作業が入ったので実質5日間のGame Buildingとなりました。
いつもはプログラム部分に大半の時間を掛けるのですが、以前作っておいたコンテント・パイプラインのインポーターやプロセッサを流用したので、今回はコンテント製作とプログラムが半々といった感じになりました。
このゲームは１６年程前にあったゲームで、当時はLD(レーザーディスク)で再生された背景の上に敵が3Dポリゴン表示されているというものでした。今だったら全部リアルタイムで描画できそうだし、ネットワーク対応にしたら面白いかも？という思いつきで作ってみました。分類的には今では少なくなったレイルシューターなので、まずは習作という意味でオリジナルシーンをどこまで再現できるか試してみました。残念ながら、ゲームの最後のシーンまでは時間ができなくて再現できませんでしたが、当時の雰囲気をある程度までは再現できていると思います。
上の動画はYouTube版ですが、ニコニコ動画版の方に60FPSでキャプチャーしたものをおいておきました。
こちらはShawnが作ったソフトウェアシンセサイザーです。4.0からサポートされたダイナミックオーディオ機能を使い、WinFormサンプルをベースにして各モジュールをつなげ合わせることで複雑な音を生成することができます。リズム機能もあり、この図はドラムセットをビートに合わせて再生しているものです。
続いてNickが作ったのはFPSゲームです。グラフィクスはDualTextureEffectを使ってライトマップを実現しています。DualTextureEffectはWindows Phoneでも動作するので同じものがWindows Phoneでも遊べるようになっています。
Rezaの作品はDeferredレンダリングを使ったもので、沢山の点光源が移動する様は幻想的でもありますが、ゲーム内容の方はアバターを操り、手にしたバットで光を叩きまくるという幻想的とは言えないものでした(汗)
こちらはXiaoyueの作ったゲームで、プレイヤーである玉を操作して囲った領域を消して敵を倒すというゲーム(名前が思い出せない)なのですが、このゲームではプレイヤーが弾を撃って敵を倒すこともできます。ちなみに画面に映っているいるのはボスのバナナ(3Dで描画されている)です。
続いてAaron、Brett、Mike、そしてMarcの４人で作ったCEOZ(Crunchy Employee Offering for Zombies)というゲームです。迫り来るゾンビを倒すというゲームの中に中間管理職として社員を殺さずに効率的にゾンビを撃退することができるかが試されるシミュレーションゲームということらしいです。
こちらはEricの作ったShape Shooter、コントローラーのボタンの色と敵の色との組み合わせによって時間内に得点を競うゲームで、最大4人まで同時プレイができます。見た目はシンプルですが、小魚の群れのように移動する敵の動きが特徴的でした。
Shannonが作ったのはコンテントを作るのがアレだから、コンテントを作ることを断念して作ったというゲームです。こちらもスクリーショットを見るとシンプルですが、有機的に移動する四角に敵の動きが面白かったです。
そして、今回のGame Buildingで最もウケたのがJaceの作ったゲームでした。Game Buildingではチーム内で受けを狙う為に作る人も居るのですが、内輪向けということでピア・レビュー絶対通らないとか、ブログで紹介すらできないよっていうものまであります。ちなみに、JaceはGame Building発表の前日に私のところへ「アバターの腕だけ表示させたいんだけど、どうしたら良いかな？」と、相談しに来ました。なんで腕だけを表示させたいのか首をかしげながらも、いくつかの質問に答えたのですが、その結果がこんなゲームになるとは思いませんでした。
ゲーム内容は至って単純で、４人プレーでAボタンをいかに早く連打するかを競うといものです。
一番最初にゲージを満タンにした人の勝利となります。
これで終わりかな？と思っているとおもむろにカウントダウンが始まり、負けたアバターが不思議そうにあたりをキョロキョロと見回します。
ここから先は説明する必要はないでしょう。スクリーンショットを見てください。
さて、これを見た人の中には「やってみたい」と思う人がいるかも知れませんが、念のために言っておきますが禁止されているアバターの取り扱いの中では
出血や流血、手足または頭部の切断、身体への損傷、身体に致命的な欠損を生じるような暴力行為
と明言されているので、同じようなゲームを作った場合は投稿直後にピアレビューが蹴られるので注意しましょう(汗)。
デバッグコマンドはゲーム開発する上では欠かせないツールの一つですがXbox 360上で使用するにはUSBキーボードが必要になります。私の場合は新し物好きで定期的にキーボードを買い換えるので家の中には使っていないキーボードが幾つかあり、いならくなったキーボードを使っていました。
ですが、最近になって１１年物のTVが写らなくなってしまい、ようやっとHDTVというものを購入しました。新しいTVの画面上で自分の作ったゲームが動いているのを見るのは楽しいので、リビングルームでソファに座りながらプログラムするという機会が増えました。
そこで、新たに起きた問題が発生しました。その問題を図式化したのが以下の図です。
ソファーに座っていると、ねこさん達が私の膝の上に乗ってきます。これから寒くなってくる時期には暖かいねこが膝の上に乗ってくるというのはありがたいものです。ですが、デバッグコマンドを使おうとするときに問題が発生します。デバッグコマンドを使用するときにはXbox 360に接続されたキーボードがあるところまで移動しないといけません。その為には膝の上のねこをどける必要があるのですが、せっかく寄ってきたねこさんを無下にする訳にもいきません。
USB延長ケーブルで手元にキーボードを持ってくるという方法もありますが、コントローラーも無線、Xbox 360へのゲームの転送もWiFi使っているので無線という環境なので、延長ケーブルを使うというのはスマートではありません。
そこで新たに追加したデバッグコマンドがremoteコマンドです。remoteコマンドはWindowsとXbox 360上で同じゲームを実行している時にNetworkSession機能を使い、Windows上で動作しているゲームで入力したコマンドをXbox 360で実行するというものです。
下図はWindows上でremoteコマンドを実行した状態のものです。
リモートコマンドの実行が成功するとデバッグコマンドがリモートコマンドモードへと移行し、今まではCMD>と表示されていたものが[Client]と表示されます。この状態で入力されたコマンドはXbox 360側へと送られ実行され、実行された結果はWindows側へと送られます。リモートコマンド状態から抜け出すにはquitコマンドを使用します。
ゲームへの追加以下のようにコンポーネントを追加するだけです。Windwos Phoneには対応していないので、#ifdefで括っておくと良いでしょう。
#if WINDOWS || XBOX // リモートデバッグコマンド「remote」の追加 Components.Add(new RemoteDebugCommand(this)); #endif
#if WINDOWS || XBOX
// リモートデバッグコマンド「remote」の追加
Components.Add(new RemoteDebugCommand(this));
#endif
NetworkSessionを使っているのでGamerServicesを初期化する必要があるのですが、remoteコマンドはGamerServicesを使っていない場合は自動で初期化するので、GamerServicesを使っていないゲームでも特別なコードを書く必要がなく使えます。また、既にNetworkSessionを使っている場合にはゲーム側で作ったNetworkSessionをRemoteDebugCommand.NetworkSessionへ設定し、文字列データを受け取った場合にRemoteDebugCommand.ProcessRecievedPacketメソッドを呼び出すようにすることで共存できるようになっています。
ただし、最低でもローカルプロファイルがサインインしている必要があります。
ここで見逃しがちなのが、ローカルプロファイルの作るにはプロファイルの生成を選択した後の画面で下の方にスクロールさせた場所にあるリンクをクリックする必要があるということです。
実のことを言うと、remoteコマンドはデバッグサンプルの3.1版を公開したときに既にあった機能でしたが、いままで説明するのをすっかり忘れていました(汗)。そんな訳で、このリモートコマンド機能は前日に公開した4.0版のデバッグサンプルに既に含まれており、リモートコマンドも登録してあるので、そのまま使えるようになっています。
これで私は膝の上に乗っているねこさんを降ろすことなくデバッグコマンドが使えるようになりました。
と、いうのは半分冗談で、実はリモートコマンドにはもう一つの重要な役割があります。
つづく
XNA Game Studio 4.0ではReach(リーチ)とHiDef(ハイデフ)の二つのプロファイルがあり、細かなCapsビットを調べる必要が無くなりました。Reachプロファイルはその名のとおり、多くのプラットフォームで動作するプロファイルとなっています。このプロファイル向けに作られたゲームはXbox 360上ではもちろん、多くのWindows PC上で動作し、更にはWindows Phone 7シリーズのデバイスでも動作します。
対してHiDefプロファイルはXbox 360とミドル～ハイエンドGPUを搭載したWindows PC向けのプロファイルです。
他には
Reach
HiDef
HiDefプロファイルに必要なGPUとしてDirectX 10対応のGPUとなっていますが、XNA Game Studio 4.0はDirectX 10で動作している訳ではなく、DirectX 9上に実装されています。ですから、厳密に言えばHiDefプロファイルはDirectX 9対応GPUで上記の条件を満たしていれば動作します。また、DirectX 9で実装されているのでWindows 7、Windows Vistaに加えてWindows XP上でも動作するようになっています。
では、なぜDirectX 10対応GPUと記述してあるかというと、HiDefプロファイルにはXbox 360相当のGPU能力、つまりDirectX 9GPUではオプションとなっている機能が求められるからです。例えば浮動小数点フォーマットのMRTや頂点バッファのサポートはDirectX 9GPUではオプション扱いとなっています。
さて、ここで問題ですが「XNAで作ったHiDefゲームを遊ぶのに必要なものはなに？」と聞かれた時になんと答えるべきでしょうか？もし答える相手が技術に詳しい人であれば「DirectX 9対応GPUで、シェーダーモデル3.0、浮動小数点のMRTに対応していて…」と答えても問題ありませんが、相手が技術的なことに詳しくない場合には混乱させてしまうだけです。
ですから、DirectX 9GPUではオプションとなっている機能が必須となっているDirectX 10GPUが使える環境であればHiDefプロファイルは問題なく動作するので、「HiDefゲームはXbox 360かDirecX 10GPUの搭載しているPCで動作する」と答えるのが現実的です。
レンダーターゲットで対応するフォーマットは全てのプラットフォームで統一されているわけではありません。これはレンダーターゲットに使用可能、不可能なフォーマットの組み合わせが大量にあるためです。その代わりに、4.0ではGraphicsAdapter.QueryTargetFormatとGraphicsAdapter.QueryBackBufferFormatメソッドが追加されました。このメソッドは使いたいカラーフォーマットと深度バッファフォーマットを指定すると、使えるフォーマットの中からもっとも近いフォーマットを返します。
このメソッドはバックバッファやRenderTarget2Dなど作るときに自動的に呼び出されるので、どのフォーマットがサポートされているかを気にすることが無くなりました。例えば、Windows PhoneでサポートされているBgra5551フォーマットは16ビットレンダーターゲットの使えないXbox 360では自動的にColorフォーマットが適用されるようになっています。
XNA Game Studio 4.0ではColor型のバイトオーダーが以前のBGRAからRGBAへと変わりました。殆どの場合はこの変化には気づきません。なぜなら、単にColor型のバイトオーダーを変更しただけではなく、テクスチャや頂点宣言生成部分のコードも更新したからです。例外として、Color[]としてではなく、Byte[]として自前でバイト単位にデータを扱っているコードはBとRのバイトをスワップするように書き換える必要があります。
XNA Game Studio 4.0では以下の頂点フォーマットはサポートされなくなりました。
また、以下のテクスチャフォーマットはサポートされなくなりました。
サポートされなくなったフォーマットのいくつかは殆どのハードウェアでサポートしていない、もしくは全くサポートされていないフォーマットで、それ以外は同じ機能だがビットフォーマットが違うなどの冗長な部分を簡略化しました。例えばRGBとBGRの二つのフォーマットは同じ機能なので両方のフォーマットを持つ必要はありません。
元ネタ
http://blogs.msdn.com/b/shawnhar/archive/2010/03/12/reach-vs-hidef.aspxにリリース版の情報を加味しました。
例えばXNA Game Studio 3.1で以下のコードがあったとします。
// ゲームシーンの描画GraphicsDevice.RenderState.DepthBufferEnable = true;DrawGameScene();// ブルーム部分の描画DrawBloom(); // DrawBloom内で使っているシェーダー内で深度バッファを無効にしているので// 再び有効にするGraphicsDevice.RenderState.DepthBufferEnable = true;
このコードXNA Game Studio 4.0用に書き換えると、以下のようになると思います。
// ゲームシーンの描画 GraphicsDevice.DepthStencilState = DepthStencilState.Default; DrawGameScene();// ブルーム部分の描画 DrawBloom();// DrawBloom内で使っているシェーダー内で深度バッファを無効にしているので// 再び有効にする GraphicsDevice.DepthStencilState = DepthStencilState.Default;
このプログラムを実行すると、何故かゲームシーンの描画が深度バッファが無効になっているように見えてしまいます。
何故でしょうか？
XNA Game Studio 4.0以前は、レンダーステートのプロパティへ設定した値は以前と同じ値であっても直接デバイスへ設定するようになっていました。ですから、3.1で以下のコードを書いた場合、デバイスに同じ値を5回設定することになります。
GraphicsDevice.RenderState.DepthBufferEnable = true; // デバイスへ設定される GraphicsDevice.RenderState.DepthBufferEnable = true; // デバイスへ設定される GraphicsDevice.DrawPrimitives(); // 描画 GraphicsDevice.RenderState.DepthBufferEnable = true; // デバイスへ設定される GraphicsDevice.RenderState.DepthBufferEnable = true; // デバイスへ設定される GraphicsDevice.RenderState.DepthBufferEnable = true; // デバイスへ設定される GraphicsDevice.DrawPrimitives(); // 描画
4.0ではステートオブジェクトが導入され、複数のレンダーステートを一気に変更することが出来るようになりました。ですが、4.0以前と同じ振る舞いにすると内部でのレンダーステートの設定が極端に多くなってしまい、パフォーマンスへの影響が大きくなってしまいます。例えば、BlendStateオブジェクトの中には12個のレンダーステートがあるので、BlendStateの設定を5回繰り返すと内部では60回ものレンダーステート変更が起きてしまいます。
そこで4.0では以下のルールによって実際にデバイスへの設定が行われます。
ですから、以下のコードを実行した場合、実際にデバイスへ設定されるのは１回になります。
GraphicsDevice.DepthStencilState = BlendStae.Opaque; // 内部キャッシュへ設定される GraphicsDevice.DepthStencilState = BlendStae.Opaque; // 内部キャッシュへ設定される GraphicsDevice.DrawPrimitives(); // 描画(デバイスへ設定される) GraphicsDevice.DepthStencilState = BlendStae.Opaque; // 内部キャッシュへ設定される GraphicsDevice.DepthStencilState = BlendStae.Opaque; // 内部キャッシュへ設定される GraphicsDevice.DepthStencilState = BlendStae.Opaque; // 内部キャッシュへ設定される GraphicsDevice.DrawPrimitives(); // 描画(デバイスへは設定されない)
この仕組みがあるので、デバイスに対してのステート設定の数を最小限に抑えることができ、パフォーマンス向上につながります。
ですが、この仕組みの副作用として出てきたのが、エ���ェクトファイル内でレンダーステート変更する記述をすると、その変更はステートオブジェクトとして反映されないという問題です。これはXNAフレームワーク内のステート管理と、Effect内のステート管理する部分が別々にあることが原因になっています。
ですから、冒頭のコードの場合、
と、なってしまいます。
この問題を解決するには二つの方法が考えられます。
判りやすさ、扱いのし易さから考えると1を奨励します。2はエフェクト内でどのステートを変更しているのかしっかりと把握する必要があり、ミスも多くなるので注意する必要があります。
09/18/2010追記、AMD/ATI RADEON系のビデオカードでGameFest Japen 2008デモ内のインスタンス描画部分が表示されないという不具合がありました。修正したものに差し替えておきました。これ以前にダウンロードした人はダウンロードし直すか、DemoContent/GameModel/InstancedModel.fx内の最後の方にあるテクニック宣言部分をvs_3_0、ps_3_0のようにシェーダーモデル3.0を使うようにしてください。
今まで紹介してきたサンプルコードをXNA 4.0用に更新しました。GameFest Japan 2008以外のサンプルは大体５～10分程度で更新することができました。GameFest Japan 2008のデモコードは8,000行とそれなりの量があったので、更新には2時間程掛かりました。
実際の更新内容としては殆どが簡素化されたAPIに合わせて要らないコードを削っていくという作業でした。中にはソースファイル丸ごと要らなくなったというケースもありました。また、修正するべき箇所はコンパイラーがエラーとして教えてくれるので、コンパイルエラー箇所を修正するだけでそのまま動くというのが大半でした。
もちろん、なかには知らないと嵌ってしまう箇所もありますが、その紹介は追々しますので、今回は更新したプロジェクトの公開と、主な変更点を紹介します。
簡単(かもしれない)日本語表示
http://higeneko.net/hinikeni/sample/xna40/SimpleMessage.zip
デバッグサンプル
http://higeneko.net/hinikeni/sample/xna40/DebugSample.zip
クォータニオンでスキンアニメーション
http://higeneko.net/hinikeni/sample/xna40/QuatSkinningSample.zip
頂点テクスチャでスキンアニメーション
http://higeneko.net/hinikeni/sample/xna40/TexSkinningSample.zip
vFetchでスキンアニメーション
http://higeneko.net/hinikeni/sample/xna40/vFetchSkinningSample.zip
Gamefest Japan 2008 デモプログラム
http://higeneko.net/hinikeni/sample/xna40/GamefestJapan2008Demo.zip
XNA Game Studio 4.0にはReachとHiDefの二つのプロファイルがあります。それぞれのプロファイルの詳細は後で説明しますが、HiDef設定にした場合、少なくともシェーダーモデルが3.0に対応しているGPUが必要になります。
シェーダーモデル3.0に対応していない環境で実行させると下図のようなエラーメッセージが表示されます。
この場合、プロファイルの設定をReach(要シェーダーモデル2.0)にすることで解決することができます。プロファイルの切り替えはプロジェクトプロパティ画面のXNA Game Studioタブ画面で設定します。Windowsプロジェクトの規定値はHiDefになっていることに注意してください。
この設定はコンテント・パイプラインなどの動作にも影響してきます。例えばReachプロファイルに設定しているときにシェーダー内でシェーダーモデル3.0を使っている場合、コンパイル時にエラーとなります。
XNA Game Studio 4.0がリリースされました。前述のとおり、XNA Game Studio 4.0はWindows Phone Developer Toolsに含まれる形でリリースされました。
Windows Phone Developer Toolsのダウンロード リリースノート
Windows Phone Developer Toolsには以下のものが含まれます。
前述のようにWindows Phone Developer ToolsはWindows XPに対応していません。Windows XPユーザーの方は以下のスタンドアロン版のXNA Game Studio 4.0をインストールする必要があります。スタンドアロン版で開発できるのはWindowsとXbox 360のみとなっていて、Windows Phoneのアプリケーションは開発することができません。
XNA Game Studio 4.0スタンドアロン版をダウンロードする
2006年11月のXNA Game Studio Expressのリリース以来、XNA Game Studioは大体一年毎にリリースしてきました。さて、XNA Game Studio 3.1がリリースしたのが去年の６月ですから、既に１年と３ヵ月が過ぎました。では、XNA Game Studio 4.0のリリースはいつなのでしょうか？
この質問の答えは答える相手によって変わってきます。
ゲーム開発者への答え: 来週の9月16日(北米時間)の時点でリリースされるXNA Game Studio 4.0を使ってWindows Phone 7、Windows、そしてXbox 360の全てのプラットフォーム向けのゲーム開発を開始することができます。 ゲームで遊びたい人達への答え: XNA Game Studio 4.0で作られたゲームが遊べるようになるのは年内
ゲーム開発者への答え: 来週の9月16日(北米時間)の時点でリリースされるXNA Game Studio 4.0を使ってWindows Phone 7、Windows、そしてXbox 360の全てのプラットフォーム向けのゲーム開発を開始することができます。
ゲームで遊びたい人達への答え: XNA Game Studio 4.0で作られたゲームが遊べるようになるのは年内
正式には９月１６日にリリースされるのはWindows Phone 7向けの開発ツールであるWindows Phone Developer Toolsであり、その中にはXNA Game Studio 4.0も含まれています。
この時点で開発環境としてのXNA Game Studio 4.0は完成、リリースとなり、Windows Phone 7はもちろんのこと、WindowsとXbox 360用のプロジェクトを作成することができます。
また、同日にはXbox 360上でゲームを配置、デバッグさせる為に必要な開発者向けのXNA Game Studio Connect Toolのベータ版がリリースされる予定です。このツールを含め、Xbox LIVE インディーズゲームとして投稿するといったXbox 360向けの機能は年内リリース予定です。