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分…… つづく

0

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日………

0

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…

0

Game building日誌 その4「2日目、モデリング終了?」

  9月20日(月) 11:20AM モデリング開始 月曜の朝は週末に溜まったメールに目を通すので、これに1時間程の時間を費やしてから作業開始です。 まずは曲面のモデリングですが、NURBSとか使った曲面モデリングはMayaでやったことがあるのですが、LightWaveではやったことがなかったので例によって例のごとくトレーニングビデオを観て勉強しました。 Introduction to the Bend Tool(ベンドツールの紹介) Adding thickness to single-sided geometry(板ポリゴンに厚みをつける方法) 今回はポリゴンで作った板をベンドツールを使って曲げることにしました。 9月20日(月) 04:00PM Doldvaの外観が完成 外観が大体できたのですが、このシーンは巨大空母の内部に入っていくというシーンなので中に何もないと非常に寂しいので内部のモデリングすることにしました。 ここら辺の資料は殆どないので何度もビデオを観ながら、こんな感じかな?という感じに手探りでモデリングしたので時間が掛かりました。 プログラマーの葛藤、その1: ここへ来てマテリアル数が増えてきたので、ひとつひとつマテリアルを追加する度に「ああ、DrawIndexedPrimitiveの呼び出しがまた増える…」と悩むようになりました。テクスチャにして一つのマテリアルでごまかすという手もありますが、テクスチャを貼る、特にUV座標の編集は非常に時間が掛かるのでマテリアル数を追加することを選びました。「まぁ、実際のゲームではもっとマテリアル数があったりするから、これくらいでいいか」というようにプログラマー脳を眠らせながらモデリングしていました。 9月20日(月) 07:22PM Doldva完成 とりあえず、中身もそれっぽいものがモデリングできました。もちろん、時間を掛ければもっと細かい部分を追加できますが、今日中にモデリングは終わらせておきたかったので、ここで一旦終了して家に帰りました。 9月20日(月) 11:11PM モデリング夜の部開始 帰宅して、夕食を摂り、少し休んだ後にまたモデリング開始です。次のモデルは非常に形状が複雑な上に参考になる資料が少ないという状態だったのでモデリングするのが大変でした。 何度も何度もビデオを観て、複雑だと思ってた形状も八角形の形で、二種類のパーツを回転コピーさせるとできるということがわかってから黙々とそのパーツ郡をモデリングしていきました。 9月21日(火) 05:41AM Cannon Seed完成?   モデリング開始してから5時間以上経って、ようやくそれらしい形になりました。本当は内部のモデリングをしないといけないのですが、朝6時前で気力がないのと、これ以上モデリングに時間を費やしたら間に合わなくなりそうだったので、ここで切り上げることにしました。 これでGame Building二日目の作業を終えました。 明日からはこの二日間で作ったモデルを実際にゲームの中に組み込んでいくプログラミング作業を開始します。 つづく……

0

Game building日誌 その3「1日目、モデリング日和」

さて、今回からは実際にGame Buildingでしたことをレポートしていきます。時間が妙に正確なのはTwitterでつぶやいた時刻がログに残っているからです。 注:今回の記事で参照しているトレーニングビデオのリンクはftpなので、クリックするだけでは見ることができないことがあります。右クリックメニューから対象を保存するを選んでダウンロードしてから観てください。 9月19日(日) 01:00AM 作業開始 先週は仕事が入り、週末こそはGame Buildingの作業を始めようと思ってた矢先にいきなり歯が痛み出し、あまりの痛さに土曜日は一日中寝てました。それもあってこんな時間に目が覚めました。まだ歯は痛みますが、我慢できない程ではないのでモデリング作業開始です。 まずは作るモデルの参考にするためにこのビデオを観ました。LightWaveでまじめにモデリングするのはこれが初めてのことなので練習も兼ねて簡単なモデルから作っていきます。ちなみにこのBGMが大好きなんで、作業中はずっと流しっぱなしでした。 9月19日(日) 02:17AM Death Ball完成 まずは最初のモデルであるDeath Ball、簡単そうに見えますが操作になれるまで時間が掛かり、1時間以上掛かりました。この間にみたトレーニングビデオは以下の三つです。赤い部分は光らせたいので別のマテリアルで作りました。 Introduction to Action Center Control Introcution to the Bevel Tool(べベルツールの紹介) Introduction to Magic Bevel(マジックベベルの紹介) 9月19日(日) 03:26AM Faker完成   LightWaveの基本的な使い方が判らないのでNewTekのサイトからマニュアルをダウンロードしました。このモデルも1時間くらい掛かりました。 頂点、辺、面の選択、移動は判ったのですが、選択を全て外す簡単な方法が判らなかったので、ネットで検索して答えを発見。何も使っていないxキーをショートカットキーにして作業効率が大分上がりました。 9月19日(日) 05:08AM Faker完成 形状が複雑で、ビデオを見ても良く判らない場所があったりしたので試行錯誤しながら作業したので1時間半掛かりました。 9月19日(日) 05:58AM Talken完成   所要時間50分。モデリングに少し慣れてきました。 9月19日(日) 07:04AM Scutter完成 こういった形状をボックスプリミティブから作るというのを覚えました。所要時間はやはり1時間。6時間程連続で作業したので疲れたのと眠いのでお昼前まで寝ることにしました。 9月19日(日) 01:00PM トレーニングビデオ鑑賞 お昼を食べながら、トレーニングビデオを鑑賞。Booleans vs Speed Booleans(ブーリアンとクイックブーリアンの違い)を観てブーリアンを勉強しました。…

0

Game Building日誌 その2 「3Dモデリングツール選び」

3Dモデリングツール選び 今回のGame Buildingではゲームに出てくる3Dモデルをモデリングすることからはじめました。私が今回3Dモデリングツールに選んだのはLightWave 3Dでした。北米のゲーム開発現場で使われている3Dモデリングツールというと、Maya、3Ds Maxが主流となっていますが、個人で気軽に購入するというには値が張ります(MayaもAutodeskになってから実質値上げしてしまった)。それらのツールに比べると安価に入手できるLightWaveが個人や小規模のスタジオ(TVドラマの特殊効果スタジオも含む)ではLightWaveが使われていたりすることも多いようです。例えばBattlestar Galacticaシリーズの特殊効果はLightWaveで作られています。 世の中にはいろいろなモデリングツールがあるので、どれを選ぶかは人それぞれですし、選ぶ基準も値段、使いやすさ、ユーザーの多さといろいろありますが、私がツールを選ぶ基準を一言で表すと「情報量の多さ」です。 3Dモデリングツールは非常に複雑で、初めてツールを起動したときには誰もが困惑します。ここで、なんらかの足ががりがないと使いこなす前に挫折してしまうことでしょう。まずはツールのコンセプトを学ぶためのチュートリアル、ドキュメントでもいいのですがGUIツールという性質上、ビデオチュートリアルがあるのが好ましいです。また、使い方がよく解らなかったり、「こんなモデルを作るにはどうしたらいいのか?」という疑問があったときにネットで検索して即座に答えを得られるというのはとても大事なことです。 今回のGame Buildingで3Dモデリングをしているときにも、LightWaveに関する情報量の多さに助けられた場面が何度もありました。 また、プログラムと違ってチュートリアルビデオであれば、英語があまり理解できなくてもGUIの操作部分を見てればなんとなく解かるということも多いので、大量にある英語資料に目を通すことをお勧めします。例えば、それぞれのツール名+”3D”で検索すると以下のようになっています。 ツール Bingでの検索ヒット数 Maya 890万 LightWave 500万 3Ds Max 280万 Blender 198万 XSI Softimage 148万 六角大王 32万 メタセコイア 14万 今回LightWaveを使うにあたって日本語資料がどれくらいあるか調べてみたのですが、チュートリアルやトレーニングビデオはあれど有償のものが殆どでした。 対して英語資料だと24時間トレーニングビデオ(英語)なんてものが無償で提供されていて、このビデオには何度も助けられました。 digital-tutorsというサイトではさまざまDCCツールのトレーニングビデオ(XNAもある)があるので、こちらもフリーのトレーニングビデオを一度見ることをお勧めします。 プログラマー視点からみると、どのDCCツールが自分のゲームに組み込みやすいかというのも基準になりますが、最近はプラグインなども豊富に提供されているので、扱いやすいファイルフォーマットに出力することでツール間の差を気にすることも少なくなってきたと思います。 結局、ゲーム全体で見ると、より良いコンテントをどれだけ早く作れるが重要になってくるので、自分の使いやすいツールを使いましょうということになりますね。   つづく

2

Game Building日誌 その1「はじめに」

はじめに 今回からGame Buildingで作ったゲームの製作過程を紹介していこうと思います。今まではどちらかというとプログラマー視点から記事を書くことが多かったのですが、今回のGame BuildingではXNA Game Studioをより良いものにする為に実際にインディーズ・ゲーム開発者側の視点に立ってゲーム製作をしてみようということを念頭に置いて製作しました。 また、Game Buildingでは限られた時間内で製作するという制限があります。Game Building期間中でも、他に作業が入ったりすることがあるので、いかにして短い間内で遊べるゲームを完成させることができるかがカギとなってきます。今回のGame Buildingは全体で二週間あったのですが、私が実際に作業できたのは9月19日(日)~9月24日(金)の午後四時まで、日付の上では6日間でしたが、途中で仕事が入ったので実質5日間の作業期間となりました。 なにつくる? この短期間内では新しいゲームプレイを企画して試したりする時間がないので、既存のゲームを作ることにしました。元となったゲームはギャラクシアン3と呼ばれる16年前のゲームです。当時は二つのLDプレイヤーを使ってあらかじめ用意されたビデオ画像の上に3Dポリゴンで表示された敵を撃つというゲームでした。今だったらリアルタイムでできそうだし、背景自体とのインタラクションは少ないし、移動する敵を撃つだけというシンプルなゲーム内容なのでプログラム技術的には問題なさそうということで、今回はこのゲームを再現することにしました。 私はこのゲームが大好きで、アーケードに通いまくって6人プレーのところを一人でクリアできるよう頑張ったり、ゲーム内容を収録したLDとか、サントラとか、設定資料集まで買ったりしていました。PS1版があるのですが、動画のフレームレートが低く(たぶん15FPS程度?)、あんまり快適とは言えないものでした。 個人的にはネットワーク対応にして大人数でプレイできれば面白そうなのに、とは思うのですがそういった話もとんと聞かないので、ないのなら自分で作ってしまおうということで、今回のGame Buildingで作ることにしました。 作業をはじめるまえに 今回は作業を始める段階で自作しておいたコンテント・パイプラインのライブラリがあったのが大幅な作業短縮に繋がりました。このライブラリは3DモデリングツールのLightWaveのモデルファイルフォーマットであるLWOファイルと、シーンファイルフォーマットであるLWSファイルのインポーターとプロセッサがあります。ですから、プロジェクト上に直接LWOファイルとLWSファイルを追加するだけで簡単にコンテントを追加することができるようになっています。 また、テスト用に作っておいたシーンファイル再生ライブラリがあるのでそれを流用することにします。LightWave用のパイプライン・ライブラリにはLightWaveで作ったアニメーションをCurveクラスのデータに変換するようになっていますが、大量のCurveクラスを使うのは処理速度的に厳しそうだったので、スキニングモデルサンプルにあるAnimationPlayerを元にしてあらかじめキーフレームデータへと変換するようになっています。 コンテントとして流用したのは最初の出撃シーンで、これは友人がモデリングしてもらったものを使わせてもらいました。   次回からは、時系列毎にGame Buildingの5日間にあった出来事を書いていきます。

0

Game Building 2010 その2

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呼び出しの回数が増え、4画面分割の場合には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ゲームエンジンを自作するのは技術的に楽しいものですが、作りたいゲームが定まらない状態だと、不必要な機能を盛り込んだりして終わりが見えず、時間が掛かりすぎて最終的にモチベーションが続かずに放置するなんてことを経験した人は少なからず居ることと思います。 逆に自分が作りたいゲームをしっかりと把握していると迷うことなく短い時間でゲームを完成させることができます。大事なのは「ゲームを作りたい」よりも「ゲームを完成させる」という目的意識を持つことです。   Beers of War と、まじめな話になってしまったので、ここでちょっと一息。 昨日の投稿で紹介し忘れたゲームがひとつありました。作成したCooperは、グラフィクスよりもオーディオ部分に気合を入れて作っていたので残念ながらゲームシーンのスクリーンショットはありませんが、そのタイトルは  Beers of War (ビアーズ オブ ウォー) です。私はこのタイトル画面を見た瞬間にあのテーマ曲が頭の中で再生されました(笑)…

0

Game Building 2010

XNA Game Studio 4.0がリリースされ(Xbox 360のランタイムの完成版はもう少し待ってね)、XNAチーム内では恒例のGame Building(AppWeek)がありました。3.1の時のAppWeekのゲーム紹介はここ。 いつもならGame Buildingの期間は一週間程度なのですが、今回は二週間という長い期間があり、皆いろんなゲームを作っていました。残念ながら、私は他にしなければいけない作業が入ったので実質5日間のGame Buildingとなりました。 いつもはプログラム部分に大半の時間を掛けるのですが、以前作っておいたコンテント・パイプラインのインポーターやプロセッサを流用したので、今回はコンテント製作とプログラムが半々といった感じになりました。 このゲームは16年程前にあったゲームで、当時はLD(レーザーディスク)で再生された背景の上に敵が3Dポリゴン表示されているというものでした。今だったら全部リアルタイムで描画できそうだし、ネットワーク対応にしたら面白いかも?という思いつきで作ってみました。分類的には今では少なくなったレイルシューターなので、まずは習作という意味でオリジナルシーンをどこまで再現できるか試してみました。残念ながら、ゲームの最後のシーンまでは時間ができなくて再現できませんでしたが、当時の雰囲気をある程度までは再現できていると思います。 上の動画はYouTube版ですが、ニコニコ動画版の方に60FPSでキャプチャーしたものをおいておきました。   こちらはShawnが作ったソフトウェアシンセサイザーです。4.0からサポートされたダイナミックオーディオ機能を使い、WinFormサンプルをベースにして各モジュールをつなげ合わせることで複雑な音を生成することができます。リズム機能もあり、この図はドラムセットをビートに合わせて再生しているものです。 続いてNickが作ったのはFPSゲームです。グラフィクスはDualTextureEffectを使ってライトマップを実現しています。DualTextureEffectはWindows Phoneでも動作するので同じものがWindows Phoneでも遊べるようになっています。 Rezaの作品はDeferredレンダリングを使ったもので、沢山の点光源が移動する様は幻想的でもありますが、ゲーム内容の方はアバターを操り、手にしたバットで光を叩きまくるという幻想的とは言えないものでした(汗)   こちらはXiaoyueの作ったゲームで、プレイヤーである玉を操作して囲った領域を消して敵を倒すというゲーム(名前が思い出せない)なのですが、このゲームではプレイヤーが弾を撃って敵を倒すこともできます。ちなみに画面に映っているいるのはボスのバナナ(3Dで描画されている)です。 続いてAaron、Brett、Mike、そしてMarcの4人で作ったCEOZ(Crunchy Employee Offering for Zombies)というゲームです。迫り来るゾンビを倒すというゲームの中に中間管理職として社員を殺さずに効率的にゾンビを撃退することができるかが試されるシミュレーションゲームということらしいです。 こちらはEricの作ったShape Shooter、コントローラーのボタンの色と敵の色との組み合わせによって時間内に得点を競うゲームで、最大4人まで同時プレイができます。見た目はシンプルですが、小魚の群れのように移動する敵の動きが特徴的でした。 Shannonが作ったのはコンテントを作るのがアレだから、コンテントを作ることを断念して作ったというゲームです。こちらもスクリーショットを見るとシンプルですが、有機的に移動する四角に敵の動きが面白かったです。   そして、今回のGame Buildingで最もウケたのがJaceの作ったゲームでした。Game Buildingではチーム内で受けを狙う為に作る人も居るのですが、内輪向けということでピア・レビュー絶対通らないとか、ブログで紹介すらできないよっていうものまであります。ちなみに、JaceはGame Building発表の前日に私のところへ「アバターの腕だけ表示させたいんだけど、どうしたら良いかな?」と、相談しに来ました。なんで腕だけを表示させたいのか首をかしげながらも、いくつかの質問に答えたのですが、その結果がこんなゲームになるとは思いませんでした。 ゲーム内容は至って単純で、4人プレーでAボタンをいかに早く連打するかを競うといものです。 一番最初にゲージを満タンにした人の勝利となります。   これで終わりかな?と思っているとおもむろにカウントダウンが始まり、負けたアバターが不思議そうにあたりをキョロキョロと見回します。 ここから先は説明する必要はないでしょう。スクリーンショットを見てください。     さて、これを見た人の中には「やってみたい」と思う人がいるかも知れませんが、念のために言っておきますが禁止されているアバターの取り扱いの中では 出血や流血、手足または頭部の切断、身体への損傷、身体に致命的な欠損を生じるような暴力行為 と明言されているので、同じようなゲームを作った場合は投稿直後にピアレビューが蹴られるので注意しましょう(汗)。

0