Twitter @HigenekoTwitter #XNA
昨日、一昨日と二日間に渡ってMicrosoftキャンバス内で開催されたPDC10の中で行われた多数のセッションはストリーミング配信され、記録された動画も公開されています。そのセッションの中には二つのXNA関連のセッションがありました。
「Things You Need to Know Before Building XNA Games for Windows Phone 7(Windows Phone 7でXNAゲームを作る前に知っておきたいこと)」 http://player.microsoftpdc.com/Session/b8100382-1fdf-482e-b4ec-2b1f0315987f
「Real-World Analysis and Optimization of XNA Framework Games on Windows Phone 7(Windows Phone 7のXNAゲームにおける分析と最適化の実践)」 http://player.microsoftpdc.com/Session/6a4f4c01-5984-4b33-9e27-e725791980b1
オリジナル音声は英語ですが、日本語同時通訳のオーディトラックを選択できるようになっています。プレイヤーの右下にあるAudioボタンを押すとリストが以下のように表示されるのでJapaneseを選択することで日本語音声で視聴することができます。
「Things You Need to Know Before Building XNA Games for Windows Phone 7(Windows Phone 7でXNAゲームを作る前に知っておきたいこと)」のセッションの中ではShawn Heargreavesがゲーム制作の過程をIdea(発想)、Implement(実装)、Optimize(最適化)、Polish(仕上げ)、そしてSell(セールス)の５つに分け、そのうちのOptimize、Polish、そしてSellについて話しています。
Optimize(最適化)の中ではゲームの中で大半を占めるコンテントの最適化をすることで、ゲームが始まるまでの時間短縮、コンテント自体の読み込みの高速化などに触れています。Polish(仕上げ)の中ではWindows Phone 7向けのゲームを快適にプレイする為の手法を紹介しています。
このセッションの中ではApp Hubサイトにあるサンプルコードであるゲーム状態の管理(Windows Phone向けのサンプルは英語版のみ)と、複数の画像ファイルを一つにまとめることで読み込みや描画の高速化(テクスチャの切り替えが少なくなるため)に役立つスプライトシート(4.0用プロジェクトは英語版のみ)を紹介しています。
「Real-World Analysis and Optimization of XNA Framework Games on Windows Phone 7(Windows Phone 7のXNAゲームにおける分析と最適化の実践)」のセッションではガーベージコレクション、低フレームレートの代表的な問題の分析方法と最適化方法が紹介されています。
Windows Phone 7のゲームは.Net Compact Framework 3.7上で動作しているので、Xbox 360と同じようにガーベージコレクションには気をつける必要があります。殆どの場合は不必要なメモリ確保をしてしまうのが問題の原因となっています。その不必要なメモリ確保が起きている場所を特定するのにXbox 360の場合はRemote Performance Monitorがありますが、Windows Phone 7では対応していないのと、どのコードが原因なのかまでは突き止めることはできませんでした。
そこで、このセッションではVS2010のPremium/Ultimate版についている分析ツールを使うことによってどのコードが不必要なメモリ確保をしているのかを素早く発見する手法を紹介しています。
後半はフレームレート低下の原因の発見方法を最適化の手法を紹介しています。この内容はこのサイトで紹介した手法と殆ど同じものとなっています。
CPUバウンドとGPUバウンド コード探偵 ファイル01「パフォーマンス殺害事件」 コード探偵 ファイル02「FPSで犯人割り出し」 コード探偵 ファイル03「タイムルーラーで現場測定」 コード探偵 ファイル04「CPUは正直者」 コード探偵 ファイル05「無口なGPU」 コード探偵 ファイル06「暗闇にさす光」
これらのセッションはWindows Phone 7向けとなっていますが、同じ.Net Compact Framework 3.7を使っているXobx 360には同じ手法がそのまま使えますし、Windowsでもコンテント読み込みの最適化などの手法はそのまま当てはまるので、それらのプラットフォーム向けのゲーム制作をしている人にとっても有意義な情報です。
日本語の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作業はお休みとなってしまいました。
仕事を終わらせたので、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でこのカメラの切り替えの他にも簡易パーティクルシステムで使いました。
ワープシーンのエフェクトはLightWaveで上図のモデルを作ってテクスチャを貼り、UV座標をスクロールさせるシェーダを適用して作ることにしました。これぐらいのモデルだったらプログラムでもできますが、すぐにモデルを作ることができるのと、実際のゲームに近い環境で見た目の修正をリアルタイムできるツール上の方が微調整が効くのでモデリングする方法を選びました。
最初に試したものは下図のようなもので、ちょっと大人しい感じのワープシーンでした。
どうせワープしてるシーンでは他のモデルも出てこないんだから、半透明処理のモデルをもっと重ねてみようということで、元のモデルをコピーして半透明四枚重ねにした結果は下図のようになりました。
ここでも最初に作ったマテリアルバッチの効果がありました。別々のUV座標スクロールさせたいモデルにLightWave上で別々のマテリアルを割り当てておくことでプログラムの方で簡単に処理することができました。
このワープシーンには隕石がでてくるので、そのモデリングをしました。テクスチャはハイキングに行ったときに撮っておいた岩の写真を以前紹介した方法で加工して使いました。
ワープシーンエフェクトで既に前に進んでいる状態を表現しているので、ここではカメラは固定位置で隕石がカメラの前を通るパスを作るだけで終わりです。
このシーンでは沢山の隕石が出てきますが、一つ一つの隕石が別々に動く必要はないのでモデラー上で隕石一つをコピーして二つにし一方を適当に回転、 出来た二つの隕石をコピーし…というのを６回繰り返して64個の隕石群をひとつのモデルとしてシーンエディターで以下のように配置し、ゆっくりとした移動と回転をさせるとそれっぽいシーンができあがります。
後はDeath Ball(宇宙機雷)を適当に配置し、カメラパスを作って完成です。
このシーンは戦艦が二隻出てきて、その至近距離をすれ違うように飛行するという経路なんで簡単そうなシーンだと思っていました。ですが、オリジナルの動画を見ながら作ってみると二番目の戦艦に接近したときの背景に見える星と戦艦の位置関係を正しくすると、一隻目の戦艦に近づくときに二隻目の戦艦が視界に入ってしまうという問題がありました。
そこで、一隻目の戦艦に近づくにつれ二隻目の戦艦が所定位置に見えないところで定位置にスタンバってくれるようにアニメーションさせるようにしました。
さて、空母シーンを作るわけですが、既に午前４時を過ぎているので眠い目をこすりながら作ってみるもののカメラパスがかなり怪しい挙動になってしまいました。修正したいところですが、こう頭が回らなくては修正作業もままならないので今日は寝ることにしました。
そんな訳で、今日一日は各シーンの生成に費やしたのでコーディングはお休みの一日でした。
Game Building発表まであと２日……
つづく
これからXNA Game Studio Connect正式リリースするまでの流れを時系列に沿って紹介します。
まとめると、
情報元: http://blogs.msdn.com/b/xna/archive/2010/10/12/xna-game-studio-4-0-submissions-for-xbox-live-indie-games.aspx
お待たせしました。数日間のメンテナンス期間を経て、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中はゲームを作ることが優先されますが、優先度の高いバグや他のチームからの質問などには対応しないといけません。そんな訳で、今日は出社した途端に優先度の高いバグの検証作業などが入り、Game Buildingの作業は一旦中止になってしまいました。
それではいよいよコーディング開始です。まずは、ゲームの状態の管理サンプルをダウンロードして、プロジェクト名と、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という名前のクラスを作ることになってしまうので、名前衝突が起きてしまうのを避けるためです。
この段階では特に名前にこだわらずにゲームにありそうな名前を適当に付けていくだけです。そんな感じで作業開始から２０分足らずの段階で下図のようなソリューションになります。
なぜ、この段階でカラのフォルダーだけ作るのかというと、作業の全体量を早めのうちに把握できるからです。あくまでゲームを完成させるのが目的なので、一部分だけ気合を入れすぎて作ってしまうと、他の部分とのバランスが取れなくなったりして、スケジュールが差し迫った時には他の部分を作りこむ余裕が無くなってしまった、なんていうことが良くあります。また、作業を進めていく途中でも「ここまでやった」という達成感があり、モチベーション維持にも役立ちます。
雛形ができたので実際にプログラムを組んでいきます。LightWaveのインポーターを作った時にテスト用に描画プログラムも書いたのですが、なにぶんテスト用だったので下図の左側のシーンツリーを素直に描画するだけのものでした。そこで、今回は簡単なマテリアルバッチ変換をして描画するように変更しました(マテリアルバッチの効果についてはGamefest Japan 2008デモプログラムを参考)。
「最適化は必要にならない限りしない」という言葉がありますし、私も同じ事を言ってるので、「おいおい、言ってることとやってることが違うじゃないか」と突っ込みが入りそうですが、実は今回マテリアルバッチを最初に組んだのには最適化以外の理由があります。
マテリアルバッチは描画高速化に有効な手立てのひとつですが、他にもシーンツリーがノード毎の座標空間を渡り歩いて「このノードのモデルを描画」という風に描画するのに対して、マテリアル毎に渡り歩いて「このマテリアルを使っているノードを描画」という風に描画の指定の仕方が違うという特徴があります。
実際のゲームではマテリアルをアニメーションさせたりすることが多いので、そういうときにもマテリアルバッチを使っていると処理がしやすくなります。
今回はまさにそれに該当するケースで、敵のエンジン(と思われる)部分の色をアニメーションさせたかったからです。例えば下図の場合では白い部分がアニメーションさせたい部分です。マテリアルバッチにしておけば、こまエンジン部分の色を一箇所で変えるだけで、このマテリアルを使っている全てのモデルに反映させることができます。
また、この部分を別のレンダーターゲットに描画し、ぼかした後に元のシーンと重ねることで下図のようにまぶしい光の表現もできるなぁ、と、この時は考えていました。
マテリアルバッチ処理のコードを書いた後はLightWaveから出力したシーンをアニメーションさせる部分をプログラム。今回のゲームは最初から最後までプレイすると６分程掛かります。これをひとつのシーンファイルにまとめてしまうと、敵の出現タイミングを合わせたりするのに時間が掛かるので、複数のシーンファイルに分けておいて連続で再生するようにしました。コード的には以下のように単純なものですが、このテーブルを変更することでテストしたいシーンからすぐに始められるので時間の節約になります。
GameScene[] scenes = { new StartScene("game-scene01"), // スタート new GameScene("game-scene02"), // ロウンチ new WarpScene("game-scene03"), // ワープ new AsteroidBeltScene("game-scene04"), // アステロイドベルト new BattleShipScene("game-scene05"), // 戦艦 new MotherShipScene("game-scene06"), // 空母 new PlanetScene("game-scene07"), // 惑星 };
これらの「GameScene」クラスを管理するGameScenePlayerクラスがあり、このクラスで現在再生中のゲームシーンの管理と、それぞれのシーンの連続再生をするようになっています。また、GameSceneは再生中にGameComponenetと同じようにUpdateとDrawが呼び出されるのでシーン毎に敵パターンなどを管理できるようになっています。
とりあえず、シーンの管理周りができたのでLightWaveでこの二日間でモデリングした3Dモデルを配置し、簡単なカメラの移動アニメーションを作り、実際にゲームに読み込んでテストしました。
さて、テストシーンでは殆どのモデルが正常に表示され、カメラのアニメーションも問題なく再生されました。ですが、ひとつDeath Ball(上図の左側にあるピンク色の四角形のモデル)のマテリアルが逆になって表示されているという問題がありました。
マテリアルが逆になっている問題ですが、丁度マテリアルバッチのプログラムを追加したので、その線が濃厚なのですがデバッグしてみると、マテリアル情報が元から逆になっていることが判明したのでインポーターのデバッグを開始しました。
コンテント・パイプラインのデバッグはここで紹介した方法のうち、デバッガをアタッチする方法を使っています。Visual Studio 2010を二つ起動させ、二つ目のVisual Studio 2010からゲームのプロジェクトを開いているVisual Studio 2010にアタッチします。
問題の起きるモデルと起きないモデルの比較をしながら、LWOファイルインポーターをデバッグしはじめて１時間半、LWOファイルのマテリアルの参照インデックスはマテリアルの宣言順ではなく、TAGSチャンクと呼ばれるデータの中で文字列が宣言されている順番だという仕様書読み間違いが原因でした。
インポーターのバグをとったついでに、LightWaveのシーンファイルであるLWSファイルを処理するプロセッサに新しい機能を追加することにしました。
LWSファイルのプロセッサはスキニングモデルサンプルと同様にコンテントビルド時にアニメーションデータをサンプリングするようになっていて、LightWaveで指定したフレームレートでサンプルするようになっています。
規定値では30FPSなので、この値をプロセッサパラメーターで設定できるようにし、60FPSでサンプリングするようにしました。
これで滑らかなアニメーションが再生されるようになりました。
LightWaveで作ったデータをゲーム内で表示、動作させる部分が完成したので、実際にゲームのシーンを作る準備が整いました。実際にシーンを作っていく前に、モデリングする時にサイズを気にせずにして作ったモデルのサイズ調整をします。
オリジナルのゲームの設定では戦艦のサイズが500m、母艦に至っては2Kmという大きさになっています。このままの数字でも問題ないのですが、これだけ大きなスケールには馴染みがないので実感がなく、シーンを作っている時に手探りになってしまうことがあります。
そこで、今回は設定の1/100スケールにします。つまり、500mの大きさの戦艦は5mになり、18mの設定の敵小型戦闘機は18cmの大きさになるわけです。このサイズになると、部屋の中に5mの大きさの戦艦があって、自分の手には18cmの大きさの模型を手に持ち、童心に返って「ブーン」なんて言いながら飛行経路を考えるなんてことが容易にできるようになります。
FPSなどの場合は現実にあるサイズをそのまま使ったりしますが、今回のようなSFものの場合はゲームのスケールを馴染みのある大きさに縮尺することでゲームプレイ部分をいつでも容易に考えることができます。
Game Building発表まで、あと３日……
月曜の朝は週末に溜まったメールに目を通すので、これに１時間程の時間を費やしてから作業開始です。
まずは曲面のモデリングですが、NURBSとか使った曲面モデリングはMayaでやったことがあるのですが、LightWaveではやったことがなかったので例によって例のごとくトレーニングビデオを観て勉強しました。 Introduction to the Bend Tool(ベンドツールの紹介) Adding thickness to single-sided geometry(板ポリゴンに厚みをつける方法)
今回はポリゴンで作った板をベンドツールを使って曲げることにしました。
外観が大体できたのですが、このシーンは巨大空母の内部に入っていくというシーンなので中に何もないと非常に寂しいので内部のモデリングすることにしました。
ここら辺の資料は殆どないので何度もビデオを観ながら、こんな感じかな？という感じに手探りでモデリングしたので時間が掛かりました。
プログラマーの葛藤、その1: ここへ来てマテリアル数が増えてきたので、ひとつひとつマテリアルを追加する度に「ああ、DrawIndexedPrimitiveの呼び出しがまた増える…」と悩むようになりました。テクスチャにして一つのマテリアルでごまかすという手もありますが、テクスチャを貼る、特にUV座標の編集は非常に時間が掛かるのでマテリアル数を追加することを選びました。「まぁ、実際のゲームではもっとマテリアル数があったりするから、これくらいでいいか」というようにプログラマー脳を眠らせながらモデリングしていました。
とりあえず、中身もそれっぽいものがモデリングできました。もちろん、時間を掛ければもっと細かい部分を追加できますが、今日中にモデリングは終わらせておきたかったので、ここで一旦終了して家に帰りました。
帰宅して、夕食を摂り、少し休んだ後にまたモデリング開始です。次のモデルは非常に形状が複雑な上に参考になる資料が少ないという状態だったのでモデリングするのが大変でした。
何度も何度もビデオを観て、複雑だと思ってた形状も八角形の形で、二種類のパーツを回転コピーさせるとできるということがわかってから黙々とそのパーツ郡をモデリングしていきました。
モデリング開始してから5時間以上経って、ようやくそれらしい形になりました。本当は内部のモデリングをしないといけないのですが、朝6時前で気力がないのと、これ以上モデリングに時間を費やしたら間に合わなくなりそうだったので、ここで切り上げることにしました。
これでGame Building二日目の作業を終えました。
明日からはこの二日間で作ったモデルを実際にゲームの中に組み込んでいくプログラミング作業を開始します。
つづく……
さて、今回からは実際にGame Buildingでしたことをレポートしていきます。時間が妙に正確なのはTwitterでつぶやいた時刻がログに残っているからです。
注:今回の記事で参照しているトレーニングビデオのリンクはftpなので、クリックするだけでは見ることができないことがあります。右クリックメニューから対象を保存するを選んでダウンロードしてから観てください。
先週は仕事が入り、週末こそはGame Buildingの作業を始めようと思ってた矢先にいきなり歯が痛み出し、あまりの痛さに土曜日は一日中寝てました。それもあってこんな時間に目が覚めました。まだ歯は痛みますが、我慢できない程ではないのでモデリング作業開始です。
まずは作るモデルの参考にするためにこのビデオを観ました。LightWaveでまじめにモデリングするのはこれが初めてのことなので練習も兼ねて簡単なモデルから作っていきます。ちなみにこのBGMが大好きなんで、作業中はずっと流しっぱなしでした。
９月19日(日) 02:17AM Death Ball完成
まずは最初のモデルであるDeath Ball、簡単そうに見えますが操作になれるまで時間が掛かり、１時間以上掛かりました。この間にみたトレーニングビデオは以下の三つです。赤い部分は光らせたいので別のマテリアルで作りました。
Introduction to Action Center Control Introcution to the Bevel Tool(べベルツールの紹介) Introduction to Magic Bevel(マジックベベルの紹介)
９月19日(日) 03:26AM Faker完成
LightWaveの基本的な使い方が判らないのでNewTekのサイトからマニュアルをダウンロードしました。このモデルも１時間くらい掛かりました。
頂点、辺、面の選択、移動は判ったのですが、選択を全て外す簡単な方法が判らなかったので、ネットで検索して答えを発見。何も使っていないxキーをショートカットキーにして作業効率が大分上がりました。
９月19日(日) 05:08AM Faker完成
形状が複雑で、ビデオを見ても良く判らない場所があったりしたので試行錯誤しながら作業したので１時間半掛かりました。
９月19日(日) 05:58AM Talken完成
所要時間50分。モデリングに少し慣れてきました。
９月19日(日) 07:04AM Scutter完成
こういった形状をボックスプリミティブから作るというのを覚えました。所要時間はやはり１時間。６時間程連続で作業したので疲れたのと眠いのでお昼前まで寝ることにしました。
９月19日(日) 01:00PM トレーニングビデオ鑑賞
お昼を食べながら、トレーニングビデオを鑑賞。Booleans vs Speed Booleans(ブーリアンとクイックブーリアンの違い)を観てブーリアンを勉強しました。
９月19日(日) 02:18PM Hover 完成
早速、ブーリアンツールを使って足の部分と胴体を繋げることをしてみました。お陰で30分でできました。
９月19日(日) 03:37PM Blue Fly完成
約１時間で完成、ここでもブーリアン使いました。このあたりから平面問題が気になり始めました。ポリゴンで平面を作った後に頂点を移動させると、平面じゃなくなってしまい、描画が正しくできなくなるという問題です。三角形化すれば表示はされますが、デザイン的に平面にしたいことがあるので、良い方法が無いかを考え始めました。
９月19日(日) 04:45PM Large Tower Cannon完成
所要時間40分。このモデリングではここでも平面問題に悩まされましたが、良い解決策が思いつかないのでそのまま放置することにしました。
９月19日(日) 05:05PM Small Tower Cannon完成
これは簡単、と気を抜いたら間違ったモデルでファイルを上書きしてしまうという凡ミスをして、やり直しも含めると15分掛かりました。こういったモデリングをする時にはモデリング時のファイルと、ゲームで使うファイルは分けるのが普通です。これは実際の開発現場でもやっていることですが、モデリング時にあると便利なデータはゲーム内では要らないし、三角形化してある必要なゲーム用のデータではモデリングがしづらいという問題があるからです。
ただ、これだとデザイナーさんが扱うファイルが増えてしまうので、今回のようにファイル上書きミスとか、デザイン用ファイルは更新したけどゲーム用ファイルを更新し忘れたなんてことが発生したりします。
プログラマーの場合、バージョンコントロールなどを使ったりするのですが、デザイナー向けツールでもそういったバージョンコントロールが標準で備わっていて欲しいですね。
９月19日(日) 06:00PM Violet Bee完成
所要時間30分。これは見た瞬間にボックスの面を押し出し(Extrude)処理を続ければできそう、と思って実行してみたら、問題なくできました。
９月19日(日) 11:11PM Delta Nose完成
ここでもブーリアンを使って窪んでいるところを形作りました。所要時間は三時間半。時間は掛かりましたが、難易度的には高いとは感じませんでした。これくらいの大きさのモデリングになると、各パーツを個々にモデリングして組み立てるという感じになるようです。逆に小物の方が形状に気をつけないといけないので難しいと感じました。
この段階までくるとモデリングが楽しくなってきて、いくらでも細かい部分を追加できるのですが、時間の制約があるのでとりあえずという形で止める事にしました。プログラムの場合はプログラムが正常に動いた時点で作業完了という目処が立つのですが、モデリングの場合はいつまでも細かい部分をつけていけそうなのでデザイナーさんがいつまでも修正を加えていくという気分がなんとなく判ったような気がしました。
時間制限があるのでいらない作業をして時間を無駄にしないよう、作業の切り上げ時を判断することが大事だということを改めて認識しました。そんな作業短縮化の一つとして、このモデルの下の部分はゲーム中には見えないので、見えない部分のモデリングはしていません。
９月19日(月) 01:14AM Hammer Head完成
所要時間２時間。これは前のモデルと形状が似ていたので前より短い時間でモデリングすることができました。
そんな訳で、一日で１２個のモデルを作ることができました。これが多いか少ないかは判断しかねますが、最初の方ではツールの使い方も良くわかっていない状態から考えれば、ここまで出来ればまぁまぁと言ったところでしょうか？
今日一日だけで何度も24時間トレーニングビデオ(英語)のお世話になっているのが判るかと思います。このトレーニングビデオの良い所は、機能ひとつひとつの紹介の中で基本的な使い方はもちろん、どんな時に使うのかということも紹介してあるので非常に役に立ちました。
前回の投稿で述べたように、ツールに関する情報の多さがそのまま開発効率向上に繋がっているというのが実感できた一日でした。
また、ゲームに必要のないところはモデリングしないで時間を節約するなど、単にモデリングをするだけよりもゲーム内容をしっかりと把握していれば、貴重な時間を費やすことも減ってくるというのも教訓のひとつですね。
Game Building発表まで、あと６日……
続く
今回の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”で検索すると以下のようになっています。
今回LightWaveを使うにあたって日本語資料がどれくらいあるか調べてみたのですが、チュートリアルやトレーニングビデオはあれど有償のものが殆どでした。
対して英語資料だと24時間トレーニングビデオ(英語)なんてものが無償で提供されていて、このビデオには何度も助けられました。
digital-tutorsというサイトではさまざまDCCツールのトレーニングビデオ(XNAもある)があるので、こちらもフリーのトレーニングビデオを一度見ることをお勧めします。
プログラマー視点からみると、どのDCCツールが自分のゲームに組み込みやすいかというのも基準になりますが、最近はプラグインなども豊富に提供されているので、扱いやすいファイルフォーマットに出力することでツール間の差を気にすることも少なくなってきたと思います。
結局、ゲーム全体で見ると、より良いコンテントをどれだけ早く作れるが重要になってくるので、自分の使いやすいツールを使いましょうということになりますね。