PowerShellと大規模ゲーム開発

今回の投稿からブログのタイトルが「ひにけにXNA」改め「ひにけにGD(Game Development)」となりました。これからはXNAに限らず、ゲーム開発全般についての記事を書いていこうと思っています。 最初の投稿はPowerShell Advent Calendar 2012への記事になります。   大規模ゲーム開発の見えづらい問題点 個人的にPowerShellが大好きで、Advent Calendar 2012投稿へのお誘いを受けたのは嬉しいことなんですが、まだまだ周りの人達から教えてもらうことの方が多く、既に知られている記事になってしまいそうだなぁということで、今回は100人を超える大規模ゲーム開発現場でPowerShellがどのように使われているのか紹介します。   現在、私が携わっているゲーム開発ではシアトルを本拠地として、世界の数ヶ所に開発拠点があり、約150人がゲーム開発に関わっています。つまり、実質1日24時間体制でゲーム開発が行われています。1日24時間といっても土日は休みになるので年中無休ではありません(少なくとも現状ではw) これだけの大人数での開発を支える為に120台程のサーバーがあり、その役割として、100近いVisual Studioのプロジェクをはじめとしたソースコードのバージョン管理ソフト用サーバーや、数百GBに達するコンテント処理をして最終的なメディアに変換するためのビルドサーバー等があります。 大規模プロジェクトでは、ゲーム開発に直接関わる作業以外の見えずらいコストが問題になってきます。 数百台あるPCのプログラマーやアーティスト、そしてサーバーの初期設定や更新コスト ツールやスクリプトの学習コスト 開発環境を整える 大規模ゲーム開発で、チームメンバー数の増減はプロジェクトの最中でも頻繁に起こります。それに加えて開発環境に必要なものも多くあり、プログラマーにはVisual Studio、TFS、.Net Framework、Xbox 360 SDK、各ミドルウェアSDK、アーティストには3D Studio Max、Photoshop、内製のツール群、そしてバグ追跡用ツールなどのプログラマーとアーティストの両方に必要なツールなどを新しいチームメンバのPC初期設定、そして常に最新の状態にしておく必要があります。 その為に”setup.exe”という名前のシンプルなGUIベースのツールがあり、ずらーっと並んだチェックボックスやコンボボックスからインストールする物や設定する項目を選択できるようになっています。選択項目は沢山ありますが、基本的にはプログラマーかアーティストかを選択して「Go」ボタンを押すだけで済むようになっています。 「Go」ボタンを押すとPowerShellが起動され、選択した項目を自動的にインストールまたは設定するスクリプトが実行されるようになっています。私がチームに入った当日、朝に「Go」ボタンを押し、待っている間に必要なドキュメントを読み、ランチから帰ってきた時にはゲーム開発の準備が整っていました。この理由から開発用PCにはWindows Serverを使用しています。 このツールは開発PCの初期設定の他にも自動更新等にも使用されています。例えばレジストリキーを変更する必要があった時、PowerShellスクリプトに数行の変更を加えるだけで全ての開発PCに同じ変更を適用することができました。同様のPowerShellスクリプトは100台以上あるビルドサーバーの設定を変更する時にも使用されています。   プログラマーの場合、開発用のPowerShellウインドウが用意されていて、開発に有用なモジュール、スクリプト、エリアスなどを使うことができるようになっています。 このPowerShellウインドウから、”vs”エリアスでカスタム環境設定を適用したVisual Studioを起動したり、”Set-DebugConfigs” スクリプトでデバッグ用パラメーターを設定したり、”Prop-Build” スクリプトでXbox 360上でゲームを実行するのにテスト設定ファイルを含む必要なコンテントファイルや実行ファイルをXbox 360開発機へと転送したりするといった毎日の作業に役立つスクリプトなどを使用することができます。 学習コストの削減 PowerShellスクリプトの素晴らしい点は、スクリプトのパラメーターを扱う機能やUsageを表示する機能などが標準で提供されていることです。大規模なプロジェクトでは、その全てを詳細まで把握できる人は存在せず、開発期間中に今まで一度も触ったことのないツールやスクリプトを使う必要に迫られるケースもあります。そういう時、使い方を学ぶ必要がありますが、その時間は極力少なく、もしくは使い慣れていないツールを学ぶ時間を取ることができないことも少なくはありません。 PowerShell導入以前は小さなツールやスクリプトは複数の方法で作られていました。メイン処理の行数よりもコマンドラインオプションを処理する行数が多くなってしまうDOSのバッチファイル、コンパイルする必要のあるC#で書かれたプログラム、更に今ではすっかり読める人が少なくなってしまったPerlスクリプトまでありました。 複数の方法で作られた多数の小さなツールやスクリプトは使うのもメンテナンスするのも困難です。あるツールは「/」をオプション指定の接頭文字に使い、他のツールは「-」を使う。また、あるツールは接頭文字を指定する必要がないものもあります。複数のファイルの指定の仕方は?Usage表示の仕方やそのフォーマットは?それぞれの差異は小さくてもその量が多いと把握するのは難しくなり、個々の小さなツールを使うのに時間が掛かってしまいます。1人がそれぞれのツールを使うのに掛かる時間自体は多くなくても、全体で見ると無視できない量のコストとなってしまいます。 これがPowerShellだとParameterアトリビュートによる各パラメーターの検証、説明の記述ができるので「help スクリプト名」という共通のコマンドで全スクリプトの使用方法を即座に把握でき、タブキーによる自動補完機能を前提としてパラメーター名は多少冗長になっても理解しやすさを重視しています。これらの機能による学習コストや些細なミスを未然に防ぐことによる生産性向上は決して少なくはありません モダンシェル その他にも、PowerShellには単純な違いに思えるけど非常に有益な機能の一つに、テキストの代わりにオブジェクトベースのパイプ処理になっていることです。 多くの小さなツールがある状況で毎日の作業効率を上げる為に、それらのツールを組み合わせたツールやスクリプトを作るのは自然なことです。例えば「指定したXbox 360開発機に幾つかのファイルを配置したいけど、それらはユーザー毎の設定ファイルによってコントロールしたい」という要求があった場合、既にある「指定したファイルをXbox 360開発機へ配置するスクリプト」と「ユーザー設定を表示するスクリプト」、そして配置したいファイルリストを組み合わせます。ポイントとして「ユーザー設定を表示するスクリプト」がテキストを返す場合、そのテキストの受け取り側のスクリプトで受け取ったテキストの中から欲しい情報を抽出処理する必要があります。対照的にPowerShellはオブジェクトを返すので、受け取り側で単に「$_.プロパティ名」と指定するだけで済みます。つまり、他のスクリプトへの依存関係を少なくすることができるということです。 これらのスクリプトを組み合わせる時に非常に有用なのがデバッグ機能です。初めて使うスクリプトでもデバッガを使ってその流れを追うことで短時間で理解することができ、複雑なスクリプトでもその問題点を見つけ出すのに他のスクリプトでは定番になっている「Printfデバッグ」に比べて遥かに短時間で問題点を洗い出すことができます。   最後に、最も重要なPowerShellの機能として.Net Frameworkとの連携があります。今携わっているプロジェクトではWPFで作られたゲームエディタを初めとし、.Netベースのツールが数多くあり、その多くの機能はエディタ以外にもコンテントビルド中に使われます。 例えばテクスチャコンパイラーと呼ばれるツールがありますが、このツールはC++/CLIで作られていて、ゲームエンジンの機能を流用すると同時に.Netアセンブリとして使いやすいインターフェースを提供しています。このアセンブリはWPFツールから参照され、エディター上でコンパイルされたテクスチャの表示やサムネイルの生成機能などを提供し、MSBuildのプロジェクトから参照され、ビルドサーバー上でテクスャをコンパイルする為の機能を提供、そしてもろちんPowerShellスクリプトからも参照され、コンパイルされたテクスャ情報のデータマイニング、ゲーム中UIで使われるテクスチャーを別途処理するのに使われています。 PowerShellを使おう…

0

続・真・簡単(かもしれない)日本語表示

問題報告をツイッターでつぶやくと…… 以前紹介したWPFフォントプロセッサーを使ってくれている人からツイッターの方で不具合報告がありました。 不具合報告は太いアウトライン描画をすると下図のような状態になるというものでした。 これはWPFのアウトライン描画時の使用するペンに線を繋げる時の方法を指定するPenLineJointというプロパティがあり、それがMiterになっていることが原因でした。これをBevel、もしくはRoundにすると問題は解決します。 また、アウトラインを描画するとフォントの上にラインを描画するので、小さなサイズのフォントでは1、2ピクセルの太さのアウトライン描画をすると下図のようにアウトラインが文字に覆いかぶさった状態になってしまいます。 今回、不具合を報告してくれた方がしていた方法として、アウトライン描画をした後にもう一度アウトライン無しで文字を描画することで、小さい文字でも綺麗に見えるようにしていました。同じ方法はAdobe After Effectのテキスト描画の時にアウトラインを先に描画するのか、後に描画するかを指定できるようになっています。     WPFフォントプロセッサーが更新される この二つの機能は便利なので早速WPFフォントプロセッサーに取り入れることにしました。今回追加したのは以下の二つのプロセッサーパラメーターです。 アウトライン形状 アウトライン描画方法 アウトライン形状には、Miter(鋭角)、Bevel(ベベル)、そしてRound(円形)のいずれかを設定できるようになっています。それぞの違いは下図の、特に「W」の文字で違いが分かると思います。 そして、アウトライン描画方法には以下の3つの方法を指定することができます。 StrokeOverFill 文字本体描画の後にアウトラインを描画する FillOverStroke アウトラインを描画した後に文字本体描画する StrokeOnly アウトラインのみを描画する   WPFフォントプロセッサー サンプル いつものように、今回もサンプルプログラムとWPFフォントプロセッサーのソースコードを公開します。 サンプルプログラムはWindows, Xbox 360,そしてWindows Phone 7 (7.1)のプロジェクトが用意されています。このサンプルプログラムでは複数のフォントを使った文字描画をしています。Xbox 360コントローラーのスティック、キーボードの上下キー、マウスのホイールスクロール、そしてタッチとフリック操作で文字をスクロールさせることができます。 サンプルは以下のURLからダウンロードできます。 http://higeneko.net/hinikeni/sample/xna40/WpfFont20120604.zip XNA 4.0で用のWpfFontPiepline.dllは以下のURLからダウンロードできます。 http://higeneko.net/hinikeni/sample/xna40/WpfFontPipeline20120604.zip

5

ネットワークゲームに関する記事まとめ

ツイッターの方でネットワークゲームに関する話題が上がったので、以前投稿したネットワークゲームに関する物をまとめてみました。これらの記事はXNA向けに書かれた物ですが、基本的な考え方やテクニックはどのプラットフォームでも同じなので参考になれば幸いです。 ネットワーク その1 レイテンシ ネットワーク その2 パケットロス ネットワーク その3 帯域 ネットワーク その4 帯域 ボイスチャットについて ネットワーク その5 圧縮 ネットワーク その6 量子化で圧縮 ネットワーク その7 ビットフィールドで圧縮 ネットワーク その8 算術符号化圧縮 ネットワーク その9 究極の圧縮方法 ネットワーク その10 オブジェクト所有権 また、AppHubの方にあるネットワーク関連のサンプルへのリンクもまとめてみました。 ネットワーク予測 ネットワーク アーキテクチャー: クライアント/サーバー ネットワーク ゲームの状態管理 ネットワーク アーキテクチャー: ピア ツー ピア 招待 ネットワーク ロビーおよびチャット用アイコン Net Rumble (英語版) HTTP マルチプレイヤー: Tic Tac Toe…

0

乗算済みアルファとは? その2: コンポジション

前回の投稿からものすごーく間があきましたが、乗算済みアルファの話がTwitterの方で盛り上がったので、思い出したように続きを書いてみます。 前回は今まで多く使われてきた補間アルファの問題とそれを解決するための乗算アルファの紹介をしました。今回は乗算済みアルファの真骨頂である半透明を使ったコンポジションを紹介します。 コンポジションの使い道 レースゲームでは、ゲーム内で複数の車を購入でき、さらに購入した車の各パーツを変更することができるという機能は一般的なものです。中には自分で描いた絵を車に張るなんて言うこともできるものもあります。こういったレースゲームでは、購入した車の一覧はガレージメニュー内でサムネイル表示され、車を選択すると3Dモデルが読み込まれ、自分がチューンナップした車のモデルを見ることができます。 では、このサムネイル画面はどうやって表示するのでしょうか? こういった3Dモデルをカスタマイズできるゲームでは、あらかじめサムネイル画像を用意するということはできません。なぜなら、その組み合わせは膨大な数になってしまうのと、ユーザーが描いた絵までは用意することはできないからです。そこで良く用いられるのが、3Dモデルを変更した時にセーブデータ領域などに3Dモデルをレンダリングした結果をサムネイル画像として保存し、それをメニュー画面で使用するという手法です。 単に矩形型のサムネイルを用意するだけだったら問題は無いのですが、このサムネイル画像をビルボードとして使い、メニュー画面の背景の上に重ね合わせて描画したい場合、例えば車のボディ部分のような不透明部分は不透明に、車のウィンドウ部分のような半透明部分はメニュー画面が透けて見えたりするといった重ね合わせ処理をコンポジション(Composition、日本語で「合成」)と呼びます。 コンポジションの基本 コンポジョン処理をする場合の基本として、描画するオブジェクトA,B,Cがあった場合、以下の式が成り立たないといけません。 A + B + C = (A + B) + C = A + (B + C) この式のA+B+Cという部分はオブジェクトA,B,Cの順に描画するという意味で、(A+B)+CはAとBをまとめて描画した結果を描画した後にCを描画、A+(B+C)はAを描画した後にBとCをまとめて描画した結果を描画するという意味になります。言い換えると()で囲まれたオブジェクトは別のレンダーターゲットに描画し、そのレンダーターゲットの描画結果を他のオブジェクトの描画と合成(コンポジット)できるということです。もしくは前述のレースゲームの中のサムネイル画像がカッコ内の部分に相当します。 結論から言うと、上記の式は補間アルファでは成り立たず、乗算済みアルファでは成り立ちます。つまり、補間アルファではできなかったコンポジションが乗算済みアルファではできるということです。 実際に上の式に補間アルファと乗算済みアルファのブレンディング計算式を当てはめると証明できるのですが、長くなるし、読んでもつまらないし、本題から外れるので、ここでは割愛します。 コンポジション比較 では、実際に乗算済みアルファと補間アルファでコンポジションした場合の結果を見比べてみましょう。まずは、レンダーターゲットを使わずに背景を描画した後に赤い不透明の四角形、半透明の緑色の四角の順に描画してみましょう。 乗算済みアルファ、補間アルファ、どちらも同じ結果になっていますね。 では、次に赤と緑の四角形をレンダーターゲットへ描画し、その結果をテクスチャとして使って背景を描画した後に描画してみましょう。 補間アルファを使った方は緑の半透明部分がより薄くなっており、不透明であるはずの赤い部分も半透明になってしまっています。対照的に乗算済みアルファの方は全く同じ描画結果となっています。つまり、補間アルファではコンポジッションが上手くいかなかったのが、乗算済みアルファではコンポジションができるということです。   XNA 4.0でコンポジション処理 では、実際にXNA 4.0でコンポジション処理をする時にどんなコードを書くのか見ていきましょう。 まずは、コンポジション用のレンダーターゲットの生成と、そこへ描画するコードです。通常のレンダーターゲットを使った描画と殆ど同じものですが、ここではColor.Transparentでクリアするのがポイントとなっています。このTransparent(透明色)はRGBA値が(0,0,0,0)になっています。 // コンポジション用のレンダーターゲットの生成 RenderTarget2D layer = new RenderTarget2D(GraphicsDevice, 1280, 720); // **** コンポジション用のレンダーターゲットへの描画 **** // レンダーターゲットをグラフィクスデバイスへ設定する…

0

続・簡単(かもしれない)日本語表示

以前、カスタム・コンテント・プロセッサーを使って日本語表示する方法を紹介しました。 XBLIGやWindows Phone 7に配信することを考えてゲームを作る場合、カスタム・コンテント・プロセッサーを作ることが殆どなので、この方法でも問題無いのですが、初めてXNAをさわり始めた人や、ちょっとしたサンプルを作るときに 「ようこそ、XNAの世界へ♪」 と、いった一文を表示するだけのプログラムなのに、カスタム・コンテント・プロセッサーを使うのは初心者には難易度が高いし、プロジェクトが複雑になってしまいます。 そこで今回はカスタム・コンテント・プロセッサーを使わずに日本語表示をする方法を紹介します。 CharacterRegionsを手動で変更する XNAで文字を表示する場合、プロジェクトにSpritefontファイルを追加しますが、このSpritefontファイルには使用するフォントの種類やサイズ、そしてテクスチャへ変換する文字を指定できるようになっています。この文字の指定はファイルの最後の方にあるCharacterRegionsエレメントで行います。Spritefontを追加した場合、あらかじめ英数字のコードが指定されています。 <CharacterRegions> <CharacterRegion> <Start>&#32;</Start> <End>&#126;</End> </CharacterRegion> </CharacterRegions> この中のStartとEndエレメントに使用する文字の開始と終了文字コードをユニコードで指定されています。 CharacterRegions内にはCharacterRegionエレメントを複数宣言できるので、ひらがなを表示したい場合、ひらがなのユニコードはこうなっているので、以下の様なCharacterRegionを追加します。「&#x番号;」と言うのはXMLファイル内で16進数を指定する方法です。 <!– ひらがな –> <CharacterRegion> <Start>&#x3041;</Start> <End>&#x3096;</End> </CharacterRegion> カタカナや全角英数字なども同様にして追加することができます。以下はそれぞれのユニコード表PDFへのリンクです。 ひらがな: http://www.unicode.org/charts/PDF/U3040.pdf カタカナ: http://www.unicode.org/charts/PDF/U30A0.pdf 全角英数: http://unicode.org/charts/PDF/UFF00.pdf 全角記号(全角スペースや句読点など): http://www.unicode.org/charts/PDF/U3000.pdf この方法でひらがなやカタカナといった、あらかじめ文字コード領域がハッキリしているものを追加することができます。 では、漢字の場合はどうでしょう?ユニコードではCJK、つまり中国語、日本語、そして韓国語の文字が混合して定義されているので、ひらがなと同じように指定することはできないし、コード表から一文字毎にコードを探し出すのは現実的ではありません。 実はSpritefontファイルには直接文字を指定することができます。例えば「日本語」という文字を表示したい場合、以下のようにして表示したい文字を追加することができます。 <CharacterRegions> <CharacterRegion><Start>日</Start><End>日</End></CharacterRegion> <CharacterRegion><Start>本</Start><End>本</End></CharacterRegion> <CharacterRegion><Start>語</Start><End>語</End></CharacterRegion> </CharacterRegions> この方法を使うことによって、カスタム・プロセッサーを書かずに日本語を表示することができます。   やっぱり面倒 確かに、上記の方法でも文字数が少なければ手動で良いのですが、やはり一文字づつコードを指定するのは面倒です。 そこで、今回は入力した文字列から使用している文字を抜き出してCharacterRegions宣言部分を生成するツール、ChracterRegionジェネレーターを作ってみました。 実行ファイル: http://higeneko.net/hinikeni/tool/CharacterRegionGenerator-bin.zip ソースファイル: http://higeneko.net/hinikeni/tool/CharacterRegionGenerator-src.zip このツールはWPF 4.0を使って作られています。XNA Game Studio 4.0をインストール時に.Net…

1

メタセコイアとKeynoteとXNAとMkxエクスポーター

前回はメタセコイアのモデルファイルであるMQOファイルを直接読み込むことのできるインポーターを含んだメタセコイア・パイプラインを紹介しました。 モデルが読み込めたら、次はアニメーションデータを使いたくなります。メタセコイア自体にはアニメーション機能は付いていないのですが、プラグインによってアニメーションを付けてしまおうというのがKeynoteです。Keynoteを使っている時にモデルデータをセーブすると、.mqoファイルと一緒に.mqxというプラグイン用のファイルが出力されます。 理想的には、この.mqxファイルにあるアニメーションデータをメタセコイア・パイプラインで直接読み込めると良いのですが、以下の問題がありました。 Keynoteが出力する.mqxにはアニメーションのキーフレーム情報しか出力されない ボーン情報が.mqxに含まれていない。 メッシュのボーンウェイト情報が.mqxに含まれていない これらの情報はKeynote内でモデルデータから生成されているのですが、その生成方法が判らないとインポートすることができません。同じ理由でMqoファイルインポーターでも一般に良く知られているCatmull-Clark曲面は実装できましたが、曲面タイプ1と2は実際にメタセコイアがどのような計算をしているのかが判らないと実装できないので、これらの曲面タイプはサポートされていません。 さて、これは困ったなぁと、数日間試行錯誤することとなりました。幸い、Keynoteには他のプラグインからKeynoteで生成した情報にアクセス出るAPIが提供されていたので、それを使うためにメタセコイア用のプラグインを作り、そこからメタセコイア・パイプラインで読めるファイル形式の形にして出力する方法が使えると言うことが判りました。 ただ、独自ファイルフォーマットを作るには時間が掛かるし、アニメーションデータを読むだけの為にわざわざ新しいファイルフォーマットを作るのには抵抗がありました。そこで、メタセコイア・パイプライン内にはMqoファイルから読み込んだ情報を一旦DOM(データ・オブジェクト・モデル)形式として保持するようになっているので、このDOM自体をXNAコンテント・パイプラインのIntermediateSerializerを使ってデシリアライズする方法をとることにしました。こうすることでMqoファイルを読むときもDOM形式でデシリアライズするときも全く同じ処理をすることができるので作業量が減り、メンテナンス性が上がり、バグの可能性も大幅に減らすことができるようになります。 と、いう経緯でできたのがMkxファイルフォーマットです。MkxはMetasequoia,Keynote,XNAの略でデータの流れを表しています。実際にはXMLファイル形式となっています。   メタセコイア用プラグイン、Mkxエクスポーター 前置きが長くなりましたが、今回はMkxエクスポーターを紹介します。以下のURLからダウンロードできるようになっています。ファイルの使い方に関する情報は付属しているReadme.txtファイルを参照してください。 プラグインのインストール方法はメタセコイアのマニュアルを参照してください。このプラグインはWindows XP SP2以降のOS標準の機能しか使っていないので、プラグインを使用する際はXNA Frameworkランタイムを始め、VC++用のランタイムなどは必要ありません。 Mkxエクスポーター本体(MkxExporter.dll) http://higeneko.net/hinikeni/sample/xna40/MkxExporter-1.0.101222.0-bin.zip Mkxエクスポーターのソースコード(Visual Studio 2010用プロジェクト) http://higeneko.net/hinikeni/sample/xna40/MkxExporter-1.0.101222.0-src.zip これらは私個人で仕事時間外に作ったものなので、Microsoft社やXNAチームは一切関与してません。ですから、バグあってもConnectとかに連絡しても相手にしてくれないでしょう。バク報告や要望などがあればAppHub内のフォーラム(XNA開発者によるコミュニティフォーラムです)かsupport@higeneko.comへメールしてください。   Mkxエクスポーターの機能 Mkxエクスポーターには以下の機能があります。 日本語完全対応 Keynoteで作成したボーン情報、スキニング情報、複数アニメーション出力 Keynoteを使っている時におきる問題の検出と対処方法の表示 オブジェクト出力モード Catmull-Clark曲面やミラーリング使用時のボーンウェイト生成(インポート時) Keynoteで作成した情報を出力するにはKeynoteをアクティブの状態、つまり「ボーン」コマンドボタンが押された状態で「ファイル/上書き保存」を選び、ファイル種類を「MKXファイル(*.mkx)」を選んで保存することでできます。 Keynoteによる名前変更が原因で名前衝突が起きる場合、Mkxエクスポーターは名前衝突が起きない名前へと変更します。この処理が発生した場合、エクスポート終了後に下図のようなメッセージが表示され、どの名前を変更したのかが表示判るので容易に修正できるようになっています。 また、設定ミスによってできてしまう、どのボーンにも属さない頂点を見つけたときには、XNA側で正しくインポート出来るように孤立した頂点用のボーンを自動生成するようになっています。この場合もエクスポート終了後に下図のようなメッセージが表示され、どのオブジェクトに孤立した頂点があるのかが表示されるので容易に修正できるようになっています。 オブジェクト出力機能は私がデバッグ時に使用していた物で、Keynoteを非アクティブ、もしくはインストールされていない状態でMkxファイルを出力すると、このモードでファイルが出力されます。この時に出力されるのはMqoファイル形式で出力されるものと同じ物が出力されます。メタセコイア・パイプラインにはMqoファイルを直接読み込む機能があるので、必要性は殆どありません。強いて言うならMqoファイルで出力するより15~50%程ファイルサイズが小さくなることくらいです。   Mkxファイルの使い方 Mkxファイルをゲームプロジェクトへ追加する方法は前回紹介したMqoファイルのインポート方法と同じように MetasequoiaPipeline.dllをコンテントプロジェクトの参照設定で追加する インポートしたいMkxファイルを追加する だけです、この時、自動的にMkx形式メタセコイア モデルインポーター(MkxImporter)が設定されます。   アニメーションサンプル(SkinningSample) 前回紹介したサンプルの中にはMkxファイルをインポートしてアニメーションさせるサンプルが同梱されています。このプロジェクトを実行すると、下図のようにeynoteに付属しているサンプルのキャラクターアニメーションを見ることができます。 このプロジェクトはAppHubにあるSkinned Modelサンプル(英語版)のコメントを日本語に訳し、以下の2つの変更を加えたものです。 SkinnedModelProcessorをModelProcessorではなくMqModelProcessorから派生させた 実行時、テクスチャが指定されていないSkinnedEffectに白いテクスチャを設定 SkinnedEffectはテクスチャなしの状態だと実行時にエラーとなるので、それを回避する為に1x1の白いテクスチャを生成して設定するようにしました。 以上のように既存のサンプルからの変更点は皆無に等しいので、簡単にMkxファイルフォーマットへと移行することが判ると思います。   まとめ 今回のメタセコイア特集連載(第一弾?)の最後に、この場を借りてメタセコイアの作者である水野様、サンプルで使用したモデル制作者であるKT爺様、そしてKeynoteの作者でありエクスポーター制作時には私の不躾な質問に快く答えてくださったmqdl様に感謝の意を表します。…

11

メタセコイアのモデルファイルを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ファイルをインポートする場合、プロパティのアセット名を英数字にするだけで元のファイル名はそのままでインポートすることができる、つまりコンテント生成時にはなにも気にせずに日本語を使うことができるということです。…

0

メタセコイアで作ったモデルをXNAで使う

メタセコイアで作ったモデルをXNAで使う時の注意事項 それでは実際にメタセコイアで作られたモデルをXNAで使用する場合の注意点を紹介していきます。メタセコイアで生成したモデルをXNAで使う場合、現状では3種類の方法があります。 標準のXファイル形式出力機能を使う FBXエクスポーターを使用してFBX形式で出力する(要シェアウェア版) Keynoteに付属しているアニメーション付きXファイル出力を使う(要シェアウェア版)   1はメタセコイアに付属しているXファイル出力機能を使う方法ですが、これには以下の注意点があります。 マテリアルやオブジェクト名は出力されない テクスチャ名に日本語は使えない(文字化けするケースがある) 透明テクスチャ情報は欠落する メタセコイアが出力するのはテキスト形式なのでファイルサイズが大きくなり、メモリ不足でインポートできなくなることもある ファイルサイズが大きくなるという問題ですが私がテストしたケースでは7MBのMQOファイルが165MBのXファイルになるケースがありました。   続いて2のFBXエクスポーターを使う場合の注意点です。 日本語を使わないこと(FBX SDKが多言語サポートしていない) ミラーリングや曲面を使っている場合はエクスポート前にフリーズする必要がある Keynoteと併用する場合はその注意点に留意する必要がある 日本語を使わないことにさえ注意しておけば最も安定している方法なのですが、マテリアル情報変換が正しく行われず、モデルの見た目が変わるケースが見受けられました。 透明テクスチャ情報はマテリアルのTextures[“Transparency”]の中に格納されます。   最後にKeynoteに付属しているXファイル出力機能(Direct X with Animation)を使う場合の注意点です。ここではXファイルフォーマットに関する注意点とKeynoteの注意点の二つに分かれます。まずはXファイルフォーマットに関する注意点としては マテリアルやオブジェクト名はインポートされない テクスチャ名に日本語は使えない(文字化けするケースがある) 透明テクスチャ情報は欠落する ミラーリングや曲面を使っている場合はエクスポート前にフリーズする必要がある Xファイル内ではオブジェクト用のボーンとスケルトン用のボーンを区別できない。 最後の注意点ですが、XNAはインポート時にボーンウェイトが設定されているメッシュから参照されているボーンをスケルトン用のボーンとして扱います。この予測は多くの場合は正解なのですが、スケルトン階層のなかにどのメッシュからも参照されていないボーンがある場合に、そのボーンはスケルトンに属するボーンと認識されずにビルドエラーの原因となります。 Keynoteを使う際特有の注意点としては以下の二つがあります。 オブジェクト名に「:」「-」「|」といった文字がある場合、Keynoteによって名前が変更され、名前衝突の原因となる どのボーンにも属さない頂点を生成することができ、ビルドエラーの原因となる Keynoteはオブジェクト名にスケルトンに関する情報を格納します。ですから、この命名規約に従わないオブジェクト名を使うとKeynoteによって名前が変更され、場合によっては同じ名前のオブジェクトが複数存在することになってしまい、コンテントビルド時の「ノードに複数の BoneContent の子があります。どれをスケルトンのルートにするか決定できません。」というエラーメッセージの原因となります。 また、Keynoteはどのボーンにも属さない頂点を生成することができ、これは実行時に正しく表示されない原因となります。運良くというか運悪く、この孤立した頂点と通常の頂点が同じポリゴン内に混在していた状態だとコンテントビルド時に「頂点のボーンの重みを正規化しているときにエラーが発生しました。BoneWeightCollection に重みの値が含まれていません。」という謎のエラーメッセージとして表示されます。 この問題の頂点はKeynoteをアクティブにした状態でモデル全体を移動させて発見することができます。どのボーンにも属さない頂点は移動しないので、モデル全体を動かすと下図のように引き延ばされることになります。この移動しない頂点が孤立した頂点だということが判ります。問題の頂点が判れば、ボーンの影響範囲を調整することで修正することができます。   ゲーム制作ではどんな情報が必要なのか? これまでの注意点をまとめる前に、ゲーム内での3Dモデルデータの使われ方について考えてみましょう。この用途には以下のものがあります。 キャラクターや背景などのゲーム中に描画されるもの 当たり判定メッシュ ゲーム内オブジェクト配置情報 トリガー 恐らくゲーム用の3Dモデルというと真っ先に思い浮かべるのは1なのは間違いないと思います。ですが、ゲーム制作では実際にゲーム中に描画する以外にも、3Dモデルデータ必要になる場面が多数あります。その主なものが2~3になります。まずは下図を見てください。メタセコイアで3分程で作ったものなのでモデリングのクオリティは気にしないでください(汗)。ゲーム内で実際に描画するのは地面とビルですが、それ以外にも赤い三角錐モデルはプレーヤーのスタート地点、黄色い点は敵の出現ポイント、そして赤い半透明の箱はプレイヤーが触れると次のマップへ移動するトリガーを表しています。 このように図で表すと色んな事が視覚的に判りやすくなります。例えば、このマップでは、プレーヤーのスタート地点は手前で3つの出口があり、敵の数は後になる程多くなり、中にはビルの屋上に出現する敵もいるということが判ります。さて、このゲームデザインをどうやって実装しますか?これらの情報をソースコードに一つ一つ数値として書いていきますか?それともレベルエディターを作りますか?個人や小規模な人数でゲーム制作という視点で考えると、どちらも時間と労力が必要になるのであまり現実的ではありません。ではどうしたらいいでしょうか? 最も簡単な手段はモデルデータにこれらのゲーム特有の情報を追加してファイルにセーブ、後はコンテントパイプラインでモデルデータ処理と同時にゲーム特有の情報を抽出することです。例えば、「敵出現位置」と名付けたマテリアルを使ったオブジェクト位置を敵の出現位置、「出口」と名付けたモデルはそのメッシュデータを判定範囲としたトリガーとして変換することで実現することができます。この方法であればメタセコイアをレベルエディターとして流用することができるので、視覚的にマップデザインすることができ、時間と労力も節約できるのでゲーム本来の部分の作業に集中することができます。 このマップを3分間程度で作ることができたことを考えるとその効率の良さが判ると思います。もちろん、面白いゲームを作るにはもっと時間を費やして優れたレベルデザインに仕上げる必要があります。ですが、ここで重要なのは、短時間でゲーム自体の面白みを出す部分に集中できる作業環境を作り出すことができるかということです。   まとめ 以上の事から、ゲームで使うことを考えると、名前や透明テクスチャ情報が欠落してしまうXファイルを使うのは避けた方が良いでしょう。となると、残ったFBXエクスポーターを使用することになると思います。この場合、以下の注意点に留意する必要があります。 日本語を使わないこと(FBX…

2

メタセコイアはじめました

Game Building日誌の「3Dモデリングツール選び」の時にコメントで「メタセコイアを取り上げて欲しい」というコメントが寄せられました。実はXNA 1.0の時にメタセコイアはLE版を試してみて、シェアウェア版を購入しようとしたのですが、購入するには日本の銀行に振り込まないといけないということでそのままになっていました。今回、改めて見てみるとPayPalでの支払いにも対応していたので購入したのが2ヶ月程前でした。 そこで、今回から数回にわたってメタセコイアを使って作ったモデルをXNA上で使うための情報を紹介していきたいと思います。 3Dモデルデータ変換の問題点 XNAは標準でXファイルとFBXファイルから3Dモデルを読み込む事ができます。メタセコイアのモデルファイルフォーマットはMQOファイルに格納されるので、メタセコイアで作ったモデルをXNA上で使用するにはXファイルかFBXファイルへ変換する必要があります。 結論から言うと、メタセコイアに限らず、どの3Dモデリングツールでもツール向けのファイルフォーマット以外へ変換する時には幾つかの問題点があります。それらの問題点は以下の4つに分類されます。 日本語問題 ファイルフォーマット変換による情報欠落問題 アプリケーション未対応データ問題 問題箇所を特定するのが難しい 1の日本語問題はネイティブ、特にC/C++で作られている多くのアプリケーションは多言語をサポートしていないという問題に起因します。特に古くからある3Dモデルファイルフォーマットは多言語サポートしていないものが多く、サポートしていても環境依存なマルチバイト文字(SJISなど)のみであったりと、言語の違うOSでは使えないことが多くあります。例えばFBXファイルは多言語サポートしていないので日本語文字を使うことはできません。使えても文字化けするケースがあります。 メタセコイアは日本製ツールでUIも全て日本語なので、自然とオブジェクト名やマテリアル名に日本語を使うことが多くなりますが、そのままでは他の3Dモデルフォーマットへ変換するときに問題となってきます。   2の情報欠落問題はファイルフォーマット変換時には必ずといって起きる問題です。3Dモデルファイルフォーマットにはそれぞれに設計意図があるので、その設計意図が異なるファイルフォーマットへ変換する時にはどうしても変換しきれない情報があります。例えばゲーム系のファイルフォーマットはポリゴンデータを使うことが前提とされているので、3Dモデリングツールでサポートされている曲面データは無視するものが多いのが現状です。   3のアプリケーション未対応データ問題ですが、モデルデータを読み込む側で未対応のモデルデータを使おうとしたときに起きる問題です。XNAの場合、あくまで最近のGPU上で効率的に動作するゲームを作ることを目的としているので、そういった知識が無い状態でモデルデータを作ってしまうと、非効率であり、時にはゲームが実行できない、強制終了してしまうということになってしまいます。よくある問題としてはXNA 4.0のReachプロファイルで3Dモデルに使うテクスチャサイズは2のn乗である必要がありますが、このことを知らないで100x200といったテクスチャを使用するとコンテントビルド時にエラーとなります。   4の問題箇所を特定するのが難しいというのは下図のデータの流れをみると判りやすくなります。例えば、あなたがあるモデルをXNAで表示させたいと思い、メタセコイア標準のXファイル出力機能を使ったとします。これで問題無くXNA上で表示されれば良いのですが、問題はうまく表示されなかった時です。この時、何が原因だったのかを究明するにはどうしたら良いでしょう? 問題になりそうな箇所はいくらでもあります。Xファイル変換にバグがあるのか、Xファイル変換が対応していないデータを作ったのか、Xファイルインポート時の問題なのか、はたまたXNAが対応していないデータだったのか、もしかしたら、単純にモデルデータが悪かったのかもしれません。これらの問題点を探していて原因を見つけたら、単にファイルのコピーし間違いだったなんてことも良くあります。要するにコンテント生成するポイントから実際にコンテントを使うまでの道のりが長ければ長いほど開発効率が下がってしまうことになります。   このように、3Dモデリングツールを使う場合、そのツールの標準フォーマット以外のフォーマットを扱う場合にはいろいろな問題点に注意しないといけません。   つづく……

0

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