メタセコイア・パイプライン Ver. 1.3

メタセコイア 4.2がリリース メタセコイア 4.2がリリースされました。4.2では作業中のサムネイル画像をMQOファイルにThumbnailチャンクとして保存できるようになりました。 そこで、この変更に対応したメタセコイア・パイプライン、バージョン1.3を公開します。 メタセコイア・パイプラインを使ったサンプル(アセンブリファイルも含む) http://higeneko.net/hinikeni/sample/xna40/MetasequoiaPipeline-1.3.140718.0-sample.zip メタセコイア・パイプライン: コンテント・パイプライン用アセンブリファイル http://higeneko.net/hinikeni/sample/xna40/MetasequoiaPipeline-1.3.140718.0-bin.zip メタセコイア・パイプライン: ソースコードとプロジェクト http://higeneko.net/hinikeni/sample/xna40/MetasequoiaPipeline-1.3.140718.0-src.zip 例によって例のごとく、不具合を見つけたら、お手数ですがご連絡ください。

0

メタセコイア・パイプライン Ver. 1.2

メタセコイア 4.2が出力するMQOファイル読み込みに対応した「メタセコイア・パイプライン Ver. 1.3」を公開しました メタセコイア 4.0がリリース メタセコイア 4.0がリリースされました。4.0でセーブされたMQOファイルではバージョン番号が1.1になり、tripatchチャンクが追加されていることを確認しました。 そこで、この変更に対応したメタセコイア・パイプライン、バージョン1.2を公開します。 メタセコイア・パイプラインを使ったサンプル(アセンブリファイルも含む) http://higeneko.net/hinikeni/sample/xna40/MetasequoiaPipeline-1.2.131030.0-sample.zip メタセコイア・パイプライン: コンテント・パイプライン用アセンブリファイル http://higeneko.net/hinikeni/sample/xna40/MetasequoiaPipeline-1.2.131030.0-bin.zip メタセコイア・パイプライン: ソースコードとプロジェクト http://higeneko.net/hinikeni/sample/xna40/MetasequoiaPipeline-1.2.131030.0-src.zip 例によって例のごとく、不具合を見つけたら、お手数ですがご連絡ください。

5

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

XNA Game Studio 4.0 Refreshに更新しよう

XNA Game Studio 4.0 Refreshに更新しよう 去年の10月にXNA Game Studio 4.0 Refreshが公開されました。これは、Windows Phone SDK 7.1の中に含まれる形でリリースされ、内容もWindows Phone 7.1の新機能追加が主だったので私もツイッターの方でつぶやく程度で済ませてました。 ですが、Windows Phone向けの新機能以外にもVisual Basic対応やバグフィクスが含まれているので、WindowsやXbox 360で開発している人でも更新する価値は十分にあると思うのでここでも紹介します。 まず、新機能としてVisual Basicに正式に対応したこと、これはWindows Phoneはもちろん、Xbox 360やWindowsでもXNA Game StudioをVisual Basicを使って開発できるようになりました。 そして、バグフィクスの中で比較的重要だと思われるのが「固定更新時、速いPCやフレーム内の処理量が少ない時に更新時間計算の誤差が大きくなり、見かけのフレームレートが下がってしまう」という問題が修正されていることです。 また、Refreshという名前の通り、既存APIからの変更は無くバイナリ互換となっているので3.1から4.0へ更新の時とは違って既存のプロジェクトやコードはそのままコンパイル、実行することができるので現在4.0で開発中の人でも安心して更新することができます。   XNA Game Studio 4.0 Refreshへ更新する 幾つかのケースがあると思うので、それぞれのケースでXNA Game Studio 4.0 Refreshをインストールする方法を紹介します。   Windows Phone SDK 7.1をインストールしている なにもする必要はありません。前述のようにXNA Game Studio 4.0 RefreshはWindows Phone SDK 7.1に含まれています。 Windows Phone Developer…

0

動的テクスチャとその注意点

パーティクルシステムなどで動的に頂点データを変更する場合、GPUとCPUが競合しないように、DynamicVertexBuffer(動的頂点バッファ)、そしてNoOverwriteとDiscardオプションを使う方法を以前紹介しました。 では、テクスチャを動的頂点バッファのように扱うにはどうしたら良いでしょうか?そもそもDynamicTexture2Dというクラスもないし、Texture2D.SetDataにSetDataOptionsを受け取るメソッドもない……。 その答えは XNA Game Studio 4.0でのTexture.SetDataメソッドはSetDataOptions.Discardを指定した時と同じ振る舞いをする(但し注意点あり) となります。 振る舞い的にはTexture2D/Texture3D/TextureCube、それぞれDiscardオプションを指定した時と同じように、指定したテクスチャがGPUで使われていた場合、内部で自動的に同じサイズ、フォーマットのテクスチャを生成し、その新しいテクスチャへデータを書き込むようになっています。 但し、この時にSetDataに渡されるパラメーターがテクスチャの一部分を書き換える設定になっていると、以前のテクスチャからデータを新しいテクスチャへコピーするようになっています。コピーだけならそれ程時間が掛からないのですが、このコピーする際に以前のテクスチャをGPUが使い終わるまで待ってからコピーするようになっているので、結局はDiscardオプションをつけていない時と同じ状態になってしまいます。 私のところでテストしたところ、256x256のテクスチャの一部分を書き換えた時、以下のような結果になりました。 方法 SetDataに掛かった時間 同じテクスチャでSetData 6.8ミリ秒 テクスチャを切り替えてSetData 0.3ミリ秒   まとめると、 テクスチャ全体を書き換える場合は、パフォーマンス問題は発生しない テクスチャの一部分を書き換える場合、複数のテクスチャを切り替えながら書き込むようにしないと遅くなる となります。 テクスチャを切り替えながらSetDataを呼ぶ方法としては「頂点テクスチャでスキンアニメーション」の記事のサンプルコード内にあるFlipTexture2D.csが参考になるでしょう。

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

メタセコイア・パイプライン Ver. 1.1

メタセコイア 4.2が出力するMQOファイル読み込みに対応した「メタセコイア・パイプライン Ver. 1.3」を公開しました メタセコイア 4.0が出力するMQOファイル読み込みに対応した「メタセコイア・パイプライン Ver. 1.2」を公開しました メタセコイア 3.0がリリース メタセコイア 3.0がリリースされたので、早速ダウンロードして軽く以前紹介したメタセコイアサンプルプログラムの動作テストをしてみました。 Mkxエクスポーターはそのまま使えるのを確認しましたが、MQOファイルを直接読み込むメタセコイア・パイプラインはそのままでは3.0から出力したMQOファイルを読み込めませんでした。これは、2.2の時には無かったチャンクが3.0で出力したMQOファイルに存在するのが原因でした そこで、3.0で出力したMQOファイルも読み込めるように修正したバージョン1.1を公開します。 メタセコイア・パイプラインを使ったサンプル(アセンブリファイルも含む) http://higeneko.net/hinikeni/sample/xna40/MetasequoiaPipeline-1.1.120430.0-sample.zip メタセコイア・パイプライン: コンテント・パイプライン用アセンブリファイル http://higeneko.net/hinikeni/sample/xna40/MetasequoiaPipeline-1.1.120430.0-bin.zip メタセコイア・パイプライン: ソースコードとプロジェクト http://higeneko.net/hinikeni/sample/xna40/MetasequoiaPipeline-1.1.120430.0-src.zip   メタセコイア 3.0の新機能として彫刻機能があります。下図は球体に1分くらいで適当に彫刻したモデルをメタセコイア・パイプライン Ver. 1.1を使ってXNAで表示したものです。こういった複雑な形状のモデルが直ぐに作ることができ、そのままXNA上で表示できるというのはゲーム制作に大いに役立つことでしょう。   まだメタセコイア3.0はリリースされたばかりなので、これ以外にもパイプラインに不具合があるかもしれないので、もし見つけたら気軽に連絡ください。

0

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

2012年6月4日追記 新しい機能を追加したものを投稿しました  いままで、ひにけにXNAではXNAで日本語表示する為の投稿を複数回してきました。 続・簡単(かもしれない)日本語表示: ツールによる日本語文字の追加 簡単(かもしれない)日本語表示: プロセッサー・パラメーターを使った日本語文字の追加 Content Pipeline その3 そのカスタマイズ: XNA 1.0時代のコンテント・パイプラインのカスタマイズの例として紹介 こうやって見返すと、今までの投稿ではいかにして簡単に日本語文字を追加するのかということを紹介してきました。 XNA標準のフォントプロセッサーでは、これ以外にも以下の基本的な問題があります。 OpenTypeフォントが使えない 大量の文字を処理させると時間が掛かる これらの問題を解決するには新しいフォントプロセッサーを作ることですが、独自のフォントプロセッサーを作ってしまうと、それに伴って独自の表示プログラムも用意しないといけません。XNAで用意されているSpriteFont描画に慣れている人達が多く居るなかで、似たような、だけどちょっとだけ違う文字表示APIを作るというのには抵抗がありました。 ですが、XNBファイルフォーマットが公開され、Silverlight 5のToolkitの中ではXNA 4.0のコンテント・パイプラインをそのまま使用し、Windows用のXNBファイルから直接3Dモデルなどを読み込んで、Silverlight 5で表示することができると知ったときに思いついたのが「同じデータを出力してSpriteFontになりすまことができれば、実行時にXNAの文字描画APIをそのまま使うことができるかも?」というアイディアが浮かんだので試してみたら、思ったよりも良い物ができたので公開することにしました。 WPF フォントプロセッサー 今回紹介するのはWPFを使用したWPFフォントプロセッサーです。WPFを知らない人の為に補足しておくと、WPFはWindows Presentation Foundationの略で今までのGDI/GDI+を使ったUIフレームワークとは違い、GPUアクセラレーションを利用した新しいUIフレームワークです。SilverlightはWPFのサブセットでWindows Phone 7でも使われいて、Windowsの後継OSであるWindows 8の新しいアプリケーションモデルの1つであるXAMLアプリケーションはこのWPFが元となっています。 WPFフォントプロセッサーはその名の通り、WPFの文字描画を使用したフォントプロセッサーです。特徴としては以下の3つがあります。 OpenTypeフォント対応 処理速度の高速化 JIS漢字追加機能 文字装飾 WPFは今までのようにTrueType、そしてOpenTypeフォントに対応しています。OpenTypeフォントはOpenの名が示すとおりOSに依存しないフォントフォーマットで、現在広く普及しているフォントフォーマットです。OpenTypeフォント対応によって、これらの多くのフォントをXNAで作られたゲームでも簡単に使えるようになりました。 そして、処理速度の高速化ですが、XNA標準のフォントプロセッサーは生成したテクスチャをできるだけコンパクトにまとめる為のアルゴリズムを採用しています。ですが、文字数の増加に対して指数関数的に処理時間が掛かってしまうという問題があります。ゲーム内で使われる文字だけを抽出して生成する場合は1,500文字程度で収まるので大きな問題とはならないのですが、常用漢字やJIS漢字といった2千文字を超えてくると極端に時間が掛かるようになり、場合によっては20分近く掛かってしまうということがありました。 そこで、WPFフォントプロセッサーでは漢字などの大量の文字を処理するのに適したアルゴリズムを採用して処理速度の高速化をしています。以下は私のPCで測定した結果です。 文字数 XNAフォント プロセッサー WPFフォント プロセッサー 速度差 常用漢字を含む2,331字 3分20秒 0.6秒 333倍 JIS第1水準漢字を含む3,438字 10分28秒 0.82秒 765倍 JIS第2水準漢字を含む6,974字 N/A 1.63秒…

0

Xbox LIVE インディーズゲームの上限数変更

あけましておめでとうございます!おかげさまで昨年はXbox Liveインディーズゲームの作品登録数が全世界で2,200本を超えました。 2012年も沢山の面白いゲームを登録していただけるように、皆様から要望の多かったゲームサイズや登録数の制限数を上げることとなりました。 CCGAMEファイルが最大500MBに ゲームのサイズ上限はCCGAMEファイル(圧縮ファイル)のサイズによって決まりますが、この上限が以下のようになりました。 値段 旧 新 240, 400MSP 150MB 500MB 80MPS 50MB 150MB 登録できるタイトル数は20タイトルに また、登録できるゲームの数が以前は10タイトルまででしたが、この上限が20タイトルまでとなりました。 今年も沢山の面白いゲームを是非Xbox LIVE インディーズゲームへと是非登録してください!   公式発表(英文) http://blogs.msdn.com/b/xna/archive/2012/01/04/happy-new-year-xbox-live-indie-games.aspx

0