Dream Build Play 2011開催

今年もDream Build Play 2011が開催されます。 http://www.dreambuildplay.com/ 賞金総額75,000ドル、優勝者には賞金の他にXbox LIVEアーケードタイトルとして発売する権利も与えられます。 大会への登録期限は5月17日までで、すでに受付は開始されています。そして、作品の受け付けは5月17日~6月14日までとなっています。この日付はいずれも米国中部標準時(GMT-06:00)なので日本時間(GMT+08:00)との時差があることに注意してください。その後、応募された作品の中からトップ20までの作品が8月までに発表され、8月末に受賞者が発表される予定です。 毎年、世界中からの参加者があり、去年の受賞者には日本人の作品が2位になったので、今年も日本から受賞者がでることを期待しています。 登録する作品はXNA Game Studio 4.0で作られたXbox 360用のゲームである必要があります。 作品登録は6月14日までとなっていますが、その前の5月17日までの参加登録をするのを忘れないようにしてください。 まずは、このページの「Register Now」を押して登録しましょう。


XNA 3.1から4.0への更新

英文ですが、XNA 3.0からXNA 4.0への更新についてのまとまった情報があるので紹介します。 http://www.nelxon.com/blog/xna-3-1-to-xna-4-0-cheatsheet/


メタセコイアのモデルファイルをXNAで直接読み込む「メタセコイア・パイプライン」

メタセコイア 4.2が出力するMQOファイル読み込みに対応した「メタセコイア・パイプライン Ver. 1.3」を公開しました メタセコイア 4.0が出力するMQOファイル読み込みに対応した「メタセコイア・パイプライン Ver. 1.2」を公開しました メタセコイア 3.0が出力するMQOファイル読み込みに対応した「メタセコイア・パイプライン Ver. 1.1」を公開しました   前回は「問題箇所を特定するのが難しい」という問題を解決する為にメタセコイアファイルとXNAデータの間に入る変換プロセスはなにか?というところで終わりました。 プロのゲーム開発でもこの「問題箇所を特定するのが難しい」というのは非常に大きな問題です。なぜならこの問題を解決するのに時間が掛かるのはもちろん、いつ問題が発生するのか判らないという、スケジュールへの悪影響があるからです。ですから、ゲーム制作の中で重要な3Dモデルデータの場合、使用するモデリングツール専用のプラグインや変換ライブラリを作ることが多くなります。他社で提供されたものを使う場合でも、慎重に検証するのはもちろん、そのソースコードとコンパイル環境があるかが採用する際の重要な決め手となります。 XNAでは、この「モデリングツール専用の変換ライブラリ」に相当するのがインポーターです。 もちろん、インポーターを作るのにも時間が掛かりますが、一旦完成させると開発効率が飛躍的に向上します。私がGame Buildingの時に5日間でゲームっぼい物を作ることができたのも、自作したLightwaveインポーターによるところが大きいです。 そこで、今回はメタセコイアファイルを直接読み込むことのできるインポーターを含んだコンテント・パイプライン用アセンブリ、メタセコイア・パイプラインを紹介していきます。 今回紹介するメタセコイア・パイプラインは以下のURLからダウンロードできるようになっています。XNA Game Studio 4.0向けに書かれています。ファイルの使い方に関する情報は付属しているReadme.txtファイルを参照してください。 メタセコイア・パイプラインを使ったサンプル(アセンブリファイルも含む) http://higeneko.net/hinikeni/sample/xna40/MetasequoiaPipeline-1.0.101222.0-sample.zip メタセコイア・パイプライン: コンテント・パイプライン用アセンブリファイル http://higeneko.net/hinikeni/sample/xna40/MetasequoiaPipeline-1.0.101222.0-bin.zip メタセコイア・パイプライン: ソースコードとプロジェクト http://higeneko.net/hinikeni/sample/xna40/MetasequoiaPipeline-1.0.101222.0-src.zip これらは私個人で仕事時間外に作ったものなので、Microsoft社やXNAチームは一切関与してません。ですから、バグあってもConnectとかに連絡しても相手にしてくれないでしょう。バク報告や要望などがあればAppHub内のフォーラム(XNA開発者によるコミュニティフォーラムです)かsupport@higeneko.comへメールしてください。   メタセコイア・パイプライン(MetasequoiaPipeline.dll) このパイプライン・アセンブリには以下のインポーターとプロセッサーが含まれています。 メタセコイア モデルインポーター(MqImporter) MKX形式メタセコイア モデルインポーター(MkxImporter) メタセコイア モデルプロセッサー(MqModelProcessor) メタセコイア モデルインポーター(MqImporter)では以下のメタセコイアファイル内情報をインポートします。 日本語を含んだオブジェクト名、マテリアル名、そしてテクスチャファイル名 オブジェクト(階層構造、可視、スムージング等) マテリアル情報(模様、透明、凸凹テクスチャ情報を含む) メッシュデータ(頂点、UV座標、頂点カラー) Catmull-Clark曲面(インポート時にポリゴン面へ変換される) ミラーリング(分割、接続、接続距離制限、ローカル座標) 回転体 メッシュ分割機能(16Bitインデックスバッファに収まるようにする) このインポーターはMQOファイルに書かれている文字列をSJISとして処理するので、オブジェクト名、マテリアル名、そしてテクスチャ名全てに日本語文字列を使うことができます。Windows、Windows Phone 7では日本語ファイル名をサポートしているのでMQOファイルやテクスチャファイル名に日本語があっても問題ありません。Xbox 360は日本語ファイル名をサポートしていませんが、テクスチャファイル名はコンテント・パイプライン内ではモデルから参照されているテクスチャファイル名を英数字へ変換するので問題ありません。日本語ファイル名のMQOファイルをインポートする場合、プロパティのアセット名を英数字にするだけで元のファイル名はそのままでインポートすることができる、つまりコンテント生成時にはなにも気にせずに日本語を使うことができるということです。…


Game Building日詩 その8「最終日、発表会5分前に……」

9月24日(金曜日) 09:30AM 発表当日開始 久々に徹夜したので眠気覚ましにシャワー浴びて出社。早速、同僚を三人呼んで一人ではできなかった4人同時プレイのテストプレイをしました。プレイ終了後、同僚からは「どの照準が自分のか判らない」「スコアが変化しないね」「パンツァードラグーンの用にボタン連打で通常弾で、溜めるとホーミングレーザーの方が良いかも」といった意見を聞く事ができました。 9月24日(金曜日) 11:30AM スコアリングシステムの追加 早速、プレイヤー毎に照準の色を変える処理を追加し、敵を倒したときの点数加算処理を追加、ついでに敵編隊を全部撃破を連続でした時にコンボ数が増えていく簡単なボーナススコアシステムを追加しました。 9月24日(金曜日) 03:55PM 発表5分前、トリガーシステムの追加 スコアリングシステムを追加した段階で「こんなもんで良いかなぁ?」と気が抜けたのと、徹夜の反動で非常に眠くなりました。新しいことを考える余裕が無くなり、テストプレイをしては細かい修正をするというのを繰り返していたら、いつの間にか午後2時すぎ。発表まで後2時間を切ったので、この段階で思い切った機能追加はとても危険です。 と、普通の状態だったら、これ以上の変更は加えなかったのでしょうけど、ふと「爆発欲しいな~」と思い立ち、しかもインポーターに変更を加える必要があるトリガーシステム(ゲーム内で任意のイベントを発生させる時等につかう仕組みのこと)を追加し始めました。 追加したトリガーシステムの仕組み自体は単純で、Lightwave内でNullオブジェクト(モデルデータの無いノードのこと)を追加し、その名前を「trigger-」で始まるようにし、アニメーションデータにX軸のスケール値が0から1に変わったフレームをトリガー発生の時間とし、その時間が来るとアニメーションプレイヤーのイベントオブジェクトを「このノードでイベントが発生」と呼び出すようになっています。 普段だったら、識別子とパラメーターの混同した命名規約や、アニメーションを特定の状態にするといった判りづらい仕組みは後で混乱の元になるので追加しません。変わりにゲーム専用のレベルエディタ上でちゃんとしたトリガーとした仕組みを提供するべきと判断したことでしょう。 ですが、徹夜明けのボーっとした頭ではそこまで考えが及ばずに、これまたボーっとしながら黙々とコーディングし、Lightwave上で必要なデータを生成、ゲームプレイを繰り返しながら爆発の大きさなどを調整し終わったのは実に発表の5分前でした……。 結果的に爆発エフェクトを追加することができたのは良かったのですが、今思い起こすとかなりきわどかったことをしたなぁと思います。 9月24日(金曜日) 04:00PM Game Building 2010 発表会 そして遂にGame Building 2010の発表の時となりました。前回はYouTube版の動画を貼ったので、今回はニコニコ動画の方を貼っておきます。 【ニコニコ動画】XNA 4.0で作ってみた まとめ と、言うわけで8回に渡ってXNAチーム内で行われたGame Building 2010向けに作ったゲーム製作の過程を紹介してきました。Game Buildingの目的としてはゲームを楽しく作ろうという他に、このようにして自分達で作ったフレームワークを使って実際にゲームを作ることでフレームワーク設計時には見えなかった問題や改善点を洗い出し、より良いフレームワークを作ろうという目的があります。 私は今まではフレームワークの新機能のテストを兼ねたゲームを作ってきましたが、今回はゲーム製作におけるコンテント製作の難しさの実態を把握するためにコンテント部分の製作に多くの時間を割くようにしました。改めて実感したのはコンテント製作自体、特にモデリングは楽しい作業だったのですが、作ったコンテントを実際にゲームの中で使えるようにするにはまだまだ時間と労力をかけないといけないということでした。 今回学んだことを将来のXNA フレームワーク開発に役立ていきたいと思います。 今までの投稿へのリンク Game Building日詩 その1「はじめに」 Game Building日詩 その2「3Dモデリングツール選び」 Game Building日詩 その3「1日目、モデリング日和」 Game Building日詩 その4「2日目、モデリング終了?」 Game Building日詩 その5「3日目、プログラム開始」 Game Building日詩 その6「4日目、ゲームシーン製作中」…

3

Game Building日誌 その7「5日目、ゲームらしくする」

9月23日(木) 12:00PM 疲れ気味 日曜からずっと寝不足なので疲れ気味ですが、Game Buildingも残すところ今日一日、厳密に言えば明日の午後四時までに完成させれば良いのですが、直前でバグが入ってしまって発表中に止まってしまうのは避けたいので、やはり今日中に仕上げるよう頑張ります。 9月23日(木) 02:03PM キューブマップの背景追加 さて、今まで背景にはなにも無かったので、この段階でキューブマップテクスチャを使った背景を追加します。キューブマップテクスチャの作り方の一つとしてはカスタムモデルエフェクトサンプル(4.0版は英語版のみ)についているCubemapProcessor.csを使うことで一枚の背景テクスチャからキューブマップテクスチャをコンテントパイプライン内でコンパイル時に生成することができます。 この方法は反射マッピングなどの見た目の整合性が多少とれていなくても気づかないような用途では問題ないのですが、背景テクスチャとして使う場合には、上下のテクスチャ部分が歪んでいるのが判りやすくなってしまうという問題があります。 そこで、今回はLightwaveを使ってキューブマップテクスチャを作るのに必要な6枚のテクスチャを生成します。やり方は簡単でアスペクト比が1:1になるカメラを作り、6フレームのアニメーションを作ってイメージファイルへ書き出します。   今回の舞台は宇宙なので、星雲とかをパーティクル使って出来たら良いとは思いましたが、時間が無いのでLightwaveのバックドロップ機能を使います。この機能を使うと背景にフラクタルなどを使ったテクスチャを張ることができるので、複数のテクスチャを設定すると簡単に宇宙っぽい背景をつくることができます。 こうして出来た6枚のテクスチャからDirectX SDKに付属するテクスチャツールなどを使ってDDSファイルを生成します。 9月23日(木) 08:52PM 惑星上、キャノンシード突入直前まで完成 さて、キューブマップの背景を追加し終えたのが午後3時頃。この時点で手来ているのはいままで作ってきたシーンを再生するだけでゲームプレイ的なものは全くありませんでした。残り時間が25時間となったので、本来であればゲームプレイ部分を作るべきですが、せっかく半日かけてモデリングしたキャノンシードは見せたいという欲求が勝って最悪ゲームプレイができなくても良いというリスクを承知で最後のシーンを追加することにしました。 最後のシーンは惑星上なので、地上部分のモデリングをしました。カメラから見える部分だけをモデリングしていきます。   岩山は分割数を多くした立方体にfractalizeという機能を使えば、一つ一つの頂点を修正するより手軽にそれっぽいモデルを作ることができます。ただし、やり過ぎると表裏が反対になってしまうこともあるので注意が必要でした。左下の図をみるとポリゴンが重なり合っているのが判ると思います。修正したいところですが、この岩山がゲーム内で表示されるのは一瞬なので気づく人は居ないだろうということで、こままにしておくことで時間節約。 そして、メインディッシュであるキャノンシードと、その前の地上砲台を設置し、カメラパスを作って完成。   9月24日(金) 04:25AM 敵の飛行パス完成 帰宅して夕食をとって午後10時、ここでようやっとゲームプレイ部分を作り始めることになります。敵の移動パターンもLightwave上で作っていきます。敵の飛行経路はワールド座標ではなく、ビュー空間で指定します。つまり、カメラをどんなに激しく動かしても、その動きが敵の飛行経路に影響を与えることはありません。と、書くと変に思えますが、実際に出来たものを見てみると特に大きな問題はないことが判ります。 ビュー空間で飛行経路を作るのにはいくつかの理由があります。第一にツール上で再生したときに実際にゲーム上で動かしているときと同じように見えるのでデザインや調整がしやすいのが一つ。次にカメラの移動に左右されないので使い回しが効くと言った利点があります。もちろん、カメラの移動経路とあまりにもかけ離れたものを作ると見た目が破綻してしまう事に注意する必要があります。また、建物の間を縫って飛ぶような経路を作りたい場合にはビュー空間ではなくワールド空間で作った方が良い場合もあります。 大事なのは短い時間で敵の飛行経路を繰り返し調整が簡単にできることがゲームのクオリティアップへつながるということです。 と、言うわけで幾つかの飛行パターンを作った後はゲーム上で再生するコードを書きます。これもシーンを再生させるコードの再利用で、再生中に撃破されるように変更を加えるだけで済みます。 9月24日(金) 07:42AM ゲームプレイ基礎部分が完成 さて、敵の動きができたので、次は実際に撃ってみたくなります。オリジナルのゲームではゲーム画面上にある照準を移動させてボタンを押すとレーザーがでるというものでした。ですから、堅い敵が出てきたりしたときにはボタンを連打する必要がありました。今時ボタン連打もアレだし、ネットワークプレイに対応したときに大変そうだということで、ホーミングレーザー形式を試してみることにしました。 ホーミングレーザーは今まで何度か作ったことがあるし、XNA上でもWindows Phone 7のマルチタッチのテストする時にタッチした場所に沿って線を描くプログラムがあったので、そのコードを流用して3D用に修正を加えて使いました。 レーザーを撃って、敵が消えるまでできたので、次は爆発エフェクトです。ここまで来たら爆発エフェクトも作りましょう(徹夜でハイになってる)ということで、Lightwaveのパーティクル機能を使って爆発するシーンを作ります。ここでは100個のパーティクルをHyperVoxelsと呼ばれるボリュメトリックレンダリング機能を使ってそれっぽいものを作っていきます。 で、複数のフレームをレンダリングしたものを下図のようにまとめたスプライトシート(4.0用プロジェクトは英語版のみ)を作りました。 そして、パーティクルサンプル(4.0用プロジェクトは英語版のみ)を流用したものを使ってゲームの中に組み込みます。 これで、移動する敵、レーザー発射、撃墜、爆発エフェクトとゲームプレイの基本部分ができました。下のスクリーンショットを見てもだいぶゲームらしくなったのが判ると思います。   この段階で周りはすっかり明るくなってしまいました。 Game Buildingの発表会まであと8時間18分…… つづく


XNA Game Studio 4.0 Language Pack(日本語)がリリースされました

日本語のXNA Game Studio 4.0Language Packがリリースされました。これでVisual Studioのメニューやプロジェクトテンプレートが日本語化されるのはもとより、日本語のヘルプドキュメントも付いているので英語を読むのが苦手という人でも安心してXNA 4.0を使えるようになりました。 注意点としてはLanguage Packとしての提供になるので一旦英語版をインストールした後にLanguage Packをインストールする必要があります。英語版のインストール方法については以前の記事が参考になると思います。また、英語版を既にインストールしている場合はLanguage Packをインストールするだけで日本語化されます。 Windows Phone Developer Toolsのダウンロード (Windows Phone開発キットに含まれている) XNA Game Studio 4.0スタンドアロン版をダウンロードする (Xbox 360/Windowsのみ開発できる) XNA Game Studio 4.0 Language Pack (日本語) のダウンロード 詳細は以下のニュースリリースを見てください。 http://create.msdn.com/ja-JP/home/news/xnags40jpnlangprel


Game Building日誌 その6「4日目、ゲームシーン製作中」

9月22日(水) 10:30AM またまた仕事発生、5時間のロス そんな訳で、またまたやらなければいけない仕事が発生、午前中はGame Building作業はお休みとなってしまいました。 9月22日(水) 03:20PM 作業再開、60FPSの弊害 仕事を終わらせたので、Game Building作業再開。まずはロウンチシーンから作ります。といっても、ここは友人が作ってくれたシーンを再生するだけなので簡単に済むはずです。 と、思ってたりすると必ず発生するのが問題。このシーンを再生してみると、シーンのところどころでモデルがカクッとなったり、一瞬消えたりすることがありました。LightWave上で再生させると問題ないのですがゲーム内で再生するとこの問題が発生します。 実はこのシーン、戦闘機モデルはひとつではなく、複数あり、そのモデルを切り替えながらアニメーション再生をしています。そして今回の問題の原因はその切り替え方法にありました。例えばモデルAからモデルBに10フレーム目で切り替えたいときにはモデルAのスケールを0~9フレーム目まで1に設定し、10フレーム以降は0に設定します。そしてモデルBの方は逆に0~9フレームまで0、それ以降を1という風に設定するといった感じです。 この1フレームの間にスケール値を極端に変更するというのが原因でした。下図はスケール値が0から1に変更している部分を拡大したものです。この二つのキーフレームの間隔は1フレームなので30FPSで再生しているときには問題がありませんが、60FPSで再生すると間のフレームを補間してスケール値が0.5になってしまうので表示がおかしくなってしまいます。 ですから、キーフレームの補間方法をステップに変更することで修正することができます。また、問題を人の目で見てから修正するのでは無駄な時間が掛かってしまうので、プロセッサ内で1フレームで値が変わっていて、補間方法がステップになっていない場合は警告メッセージを表示するといったことをした方が良いでしょう。 と、言うのが正しい方法なのですが、今回は他の人が作ったシーンを把握して問題のキーフレームを探し出して修正という作業をしないといけないので面倒もとい時間が掛かりそうだなぁと考えたので別の方法を考えることにしました。今回の問題は 「見せたいシーンの中に見せたくない問題が発生」 だったので、見せたくないというのを基点に逆の発想にして 「見せたくない問題が発生するんだったら、問題が発生している場所を見せなければ良い」 と、考えました。幸い、友人からもらったシーンでは母艦内部しか出てこないので、せっかくのカッコいい母艦も表示させたいなぁと思っていました。そこで、母艦内部のシーンと母艦を外から見たシーンのカメラを問題が起きるタイミングで切り替えるようにすることにしました。こうしておけば、見せたい母艦も見せることができ、見せたくない問題部分を隠すこともできる、そして時間の節約にもなると、一石三鳥です。 そんな訳で、母艦外部のカメラパスを設定し、 カメラパスの切り替えタイミングはカーブエディターを使って作りました。 カーブエディターが出力するXMLファイルはそのままプロジェクトに追加でき、読み込みもCurveオブジェクトとして読み込むことができるので、今回のGame Buildingでこのカメラの切り替えの他にも簡易パーティクルシステムで使いました。 9月22日(水) 08:07PM ワープシーンエフェクト完成 ワープシーンのエフェクトはLightWaveで上図のモデルを作ってテクスチャを貼り、UV座標をスクロールさせるシェーダを適用して作ることにしました。これぐらいのモデルだったらプログラムでもできますが、すぐにモデルを作ることができるのと、実際のゲームに近い環境で見た目の修正をリアルタイムできるツール上の方が微調整が効くのでモデリングする方法を選びました。 最初に試したものは下図のようなもので、ちょっと大人しい感じのワープシーンでした。 どうせワープしてるシーンでは他のモデルも出てこないんだから、半透明処理のモデルをもっと重ねてみようということで、元のモデルをコピーして半透明四枚重ねにした結果は下図のようになりました。 ここでも最初に作ったマテリアルバッチの効果がありました。別々のUV座標スクロールさせたいモデルにLightWave上で別々のマテリアルを割り当てておくことでプログラムの方で簡単に処理することができました。 9月22日(水) 10:00PM ワープシーン完成 このワープシーンには隕石がでてくるので、そのモデリングをしました。テクスチャはハイキングに行ったときに撮っておいた岩の写真を以前紹介した方法で加工して使いました。 ワープシーンエフェクトで既に前に進んでいる状態を表現しているので、ここではカメラは固定位置で隕石がカメラの前を通るパスを作るだけで終わりです。 9月23日(木) 12:00AM アステロイドベルトシーン完成 このシーンでは沢山の隕石が出てきますが、一つ一つの隕石が別々に動く必要はないのでモデラー上で隕石一つをコピーして二つにし一方を適当に回転、 出来た二つの隕石をコピーし…というのを6回繰り返して64個の隕石群をひとつのモデルとしてシーンエディターで以下のように配置し、ゆっくりとした移動と回転をさせるとそれっぽいシーンができあがります。 後はDeath Ball(宇宙機雷)を適当に配置し、カメラパスを作って完成です。 9月23日(木) 03:00AM 戦艦シーン完成 このシーンは戦艦が二隻出てきて、その至近距離をすれ違うように飛行するという経路なんで簡単そうなシーンだと思っていました。ですが、オリジナルの動画を見ながら作ってみると二番目の戦艦に接近したときの背景に見える星と戦艦の位置関係を正しくすると、一隻目の戦艦に近づくときに二隻目の戦艦が視界に入ってしまうという問題がありました。 そこで、一隻目の戦艦に近づくにつれ二隻目の戦艦が所定位置に見えないところで定位置にスタンバってくれるようにアニメーションさせるようにしました。 9月23日(木) 04:00AM 空母シーン完成? さて、空母シーンを作るわけですが、既に午前4時を過ぎているので眠い目をこすりながら作ってみるもののカメラパスがかなり怪しい挙動になってしまいました。修正したいところですが、こう頭が回らなくては修正作業もままならないので今日は寝ることにしました。   そんな訳で、今日一日は各シーンの生成に費やしたのでコーディングはお休みの一日でした。 Game Building発表まであと2日………


XNA Game Studio 4.0 Connectのリリース予定とインディーズゲーム

これからXNA Game Studio Connect正式リリースするまでの流れを時系列に沿って紹介します。 現在、インディーズゲームとしてピアレビューへ提出するゲームはXNA Game Studio 3.1で作られたものに限られます。 今秋、XNA Game Studio Connect正式リリースされ、その日からXNA Game Studio 4.0で作られたゲームをピアレビューへ提出することができるようになります。 XNA Game Studio Connectリリース日から90日の間、XNA Game Studio 3.1で作られたゲームもピアレビューに提出することでがきます。 XNA Game Studio Connectリリース日から90日後、ピアレビューに提出できるのは4.0で作られたゲームのみとなり、3.1で作られたゲームはピアレビューに提出できなくなります。 まとめると、 近日中にゲームが完成、ピアレビューに提出できるのであれば3.1で作る 今からゲームを作り始めるのであれば4.0にアップグレードする XNA Game Studio Connectの正式リリース日の発表はXNA Game Studioチームのブログ、App Hubサイトに掲載されます(このブログでも情報が来次第に紹介します) 情報元: http://blogs.msdn.com/b/xna/archive/2010/10/12/xna-game-studio-4-0-submissions-for-xbox-live-indie-games.aspx


APP HUBへようこそ!!

Xbox 360とWindows Phoneのアプリを発信できる お待たせしました。数日間のメンテナンス期間を経て、Creators Club OnlineサイトがAPP HUB(アップ・ハブ)として生まれ変わりました。これを機にURLアドレスも新しくなりました。 APP HUB 英語版 http://create.msdn.com/ APP HUB 日本語版 http://create.msdn.com/ja-JP APP HUBサイトでは従来どおり、XNA Game Studioに関する情報やサンプルがあり、プレミアム会員の場合はインディーズゲームの発信ができるのに加えて新たにWindows Phone用のゲームが発信できるようになりました。 Windows Phoneでの開発に興味がある人はラーニング ロードマップのページが参考になると思います。 また、日本語版からのリンクからはまだ見ることができないXNA Game Studio 4.0の新機能に関するサンプルも英語版のEducation Catalogから見ることができます。例えばエコーサンプルなどはダイナミックサウンド機能を使い始める上で参考になるでしょう。


Game building日誌 その5「3日目、プログラム開始」

  9月21日(火) 10:00AM 仕事発生、6時間のロス Game Building中はゲームを作ることが優先されますが、優先度の高いバグや他のチームからの質問などには対応しないといけません。そんな訳で、今日は出社した途端に優先度の高いバグの検証作業などが入り、Game Buildingの作業は一旦中止になってしまいました。 9月21日(火) 03:53PM 作業再開、ゲームステート管理サンプルを雛形に それではいよいよコーディング開始です。まずは、ゲームの状態の管理サンプルをダウンロードして、プロジェクト名と、GUIDを変更します。GUIDを変更するのはXbox 360に配置するときに、このGUIDが他のプロジェクトと見分けるIDとなるので、同じGUIDのプロジェクトを配置すると上書きしてしまうという問題を避けるためです。 ゲームステート管理サンプルはおそらくクリエーターズクラブオンラインサイトの中では最も使われているサンプルでしょう。今回のGame Buildingでも殆どのゲームがこのサンプルを雛形にしてメニュースクリーンを作っていました。 注: 4.0版のサンプルは既に出ているのですが、サイトのバグでフレームワークの表示部分が2.0のままになっていることに注意してください。サンプル名+_4_0.zipとなっているものは4.0版です。 今回はSci-Fiものということで、それっぽいフォントに差し替えました。 それ以外にもデバッグサンプルのコードや、自作しておいたLightWaveのインポーター、プロセッサをプロジェクトへ追加しました。 私がゲームを作るときに必ずあるのがDrawContextとGlobalというクラスです。DrawContenxtはその名のとおり、描画するのに必要な情報をまとめて持っておくクラスで、View、Projectionを設定するメソッドがあり、設定した場合に鏡面光を計算するのに視線ベクトルや、BoundingFrustumなどを生成するようになっています。描画メソッドにはこのクラスのインスタンスを渡して描画するようになっています。 また、Globalクラスはゲームの中で一度生成したら破棄しないものを入れておくためのクラスです。例えばゲーム全体に共通するグラフィクス関連のリソースなどを入れています。また、このクラスはstaticではなくSingletonパターンを使っていて、Global.Current.XXXXの様にメンバにアクセスします。staticクラスじゃない理由としては、インスタンスを作る時期を明示的にコントロールできる、拡張メソッドを追加できる(拡張メソッドはインスタンスメソッドのみに使える)、後でインスタンスクラスにしたい時に移行が楽になる、といった感じです。 また、この段階で将来的に作るであろうソースコードの種類を分類してフォルダーとして作っておきます(中身はカラ)。私は習慣的にこのフォルダの名前をGameXXXXといった名前にします。これはEnemyというフォルダ名を作ってしまうと、その中に更にEnemey.csという名前のクラスを作ることになってしまうので、名前衝突が起きてしまうのを避けるためです。 この段階では特に名前にこだわらずにゲームにありそうな名前を適当に付けていくだけです。そんな感じで作業開始から20分足らずの段階で下図のようなソリューションになります。 なぜ、この段階でカラのフォルダーだけ作るのかというと、作業の全体量を早めのうちに把握できるからです。あくまでゲームを完成させるのが目的なので、一部分だけ気合を入れすぎて作ってしまうと、他の部分とのバランスが取れなくなったりして、スケジュールが差し迫った時には他の部分を作りこむ余裕が無くなってしまった、なんていうことが良くあります。また、作業を進めていく途中でも「ここまでやった」という達成感があり、モチベーション維持にも役立ちます。 9月21日(火) 04:10PM マテリアルバッチング 雛形ができたので実際にプログラムを組んでいきます。LightWaveのインポーターを作った時にテスト用に描画プログラムも書いたのですが、なにぶんテスト用だったので下図の左側のシーンツリーを素直に描画するだけのものでした。そこで、今回は簡単なマテリアルバッチ変換をして描画するように変更しました(マテリアルバッチの効果についてはGamefest Japan 2008デモプログラムを参考)。 「最適化は必要にならない限りしない」という言葉がありますし、私も同じ事を言ってるので、「おいおい、言ってることとやってることが違うじゃないか」と突っ込みが入りそうですが、実は今回マテリアルバッチを最初に組んだのには最適化以外の理由があります。 マテリアルバッチは描画高速化に有効な手立てのひとつですが、他にもシーンツリーがノード毎の座標空間を渡り歩いて「このノードのモデルを描画」という風に描画するのに対して、マテリアル毎に渡り歩いて「このマテリアルを使っているノードを描画」という風に描画の指定の仕方が違うという特徴があります。 実際のゲームではマテリアルをアニメーションさせたりすることが多いので、そういうときにもマテリアルバッチを使っていると処理がしやすくなります。 今回はまさにそれに該当するケースで、敵のエンジン(と思われる)部分の色をアニメーションさせたかったからです。例えば下図の場合では白い部分がアニメーションさせたい部分です。マテリアルバッチにしておけば、こまエンジン部分の色を一箇所で変えるだけで、このマテリアルを使っている全てのモデルに反映させることができます。 また、この部分を別のレンダーターゲットに描画し、ぼかした後に元のシーンと重ねることで下図のようにまぶしい光の表現もできるなぁ、と、この時は考えていました。 9月21日(火) 07:42PM テストシーン再生 マテリアルバッチ処理のコードを書いた後はLightWaveから出力したシーンをアニメーションさせる部分をプログラム。今回のゲームは最初から最後までプレイすると6分程掛かります。これをひとつのシーンファイルにまとめてしまうと、敵の出現タイミングを合わせたりするのに時間が掛かるので、複数のシーンファイルに分けておいて連続で再生するようにしました。コード的には以下のように単純なものですが、このテーブルを変更することでテストしたいシーンからすぐに始められるので時間の節約になります。 GameScene[] scenes = { new StartScene(“game-scene01”), // スタート new GameScene(“game-scene02”), // ロウンチ new WarpScene(“game-scene03”), // ワープ new…