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表示の仕方やそのフォーマットは？それぞれの差異は小さくてもその量が多いと把握するのは難しくなり、個々の小さなツールを使うのに時間が掛かってしまいます。１人がそれぞれのツールを使うのに掛かる時間自体は多くなくても、全体で見ると無視できない量のコストとなってしまいます。
これがPowerShellだとParameterアトリビュートによる各パラメーターの検証、説明の記述ができるので「help スクリプト名」という共通のコマンドで全スクリプトの使用方法を即座に把握でき、タブキーによる自動補完機能を前提としてパラメーター名は多少冗長になっても理解しやすさを重視しています。これらの機能による学習コストや些細なミスを未然に防ぐことによる生産性向上は決して少なくはありません
モダンシェル
その他にも、PowerShellには単純な違いに思えるけど非常に有益な機能の一つに、テキストの代わりにオブジェクトベースのパイプ処理になっていることです。
多くの小さなツールがある状況で毎日の作業効率を上げる為に、それらのツールを組み合わせたツールやスクリプトを作るのは自然なことです。例えば「指定したXbox 360開発機に幾つかのファイルを配置したいけど、それらはユーザー毎の設定ファイルによってコントロールしたい」という要求があった場合、既にある「指定したファイルをXbox 360開発機へ配置するスクリプト」と「ユーザー設定を表示するスクリプト」、そして配置したいファイルリストを組み合わせます。ポイントとして「ユーザー設定を表示するスクリプト」がテキストを返す場合、そのテキストの受け取り側のスクリプトで受け取ったテキストの中から欲しい情報を抽出処理する必要があります。対照的にPowerShellはオブジェクトを返すので、受け取り側で単に「$_.プロパティ名」と指定するだけで済みます。つまり、他のスクリプトへの依存関係を少なくすることができるということです。
これらのスクリプトを組み合わせる時に非常に有用なのがデバッグ機能です。初めて使うスクリプトでもデバッガを使ってその流れを追うことで短時間で理解することができ、複雑なスクリプトでもその問題点を見つけ出すのに他のスクリプトでは定番になっている「Printfデバッグ」に比べて遥かに短時間で問題点を洗い出すことができます。
最後に、最も重要なPowerShellの機能として.Net Frameworkとの連携があります。今携わっているプロジェクトではWPFで作られたゲームエディタを初めとし、.Netベースのツールが数多くあり、その多くの機能はエディタ以外にもコンテントビルド中に使われます。
例えばテクスチャコンパイラーと呼ばれるツールがありますが、このツールはC++/CLIで作られていて、ゲームエンジンの機能を流用すると同時に.Netアセンブリとして使いやすいインターフェースを提供しています。このアセンブリはWPFツールから参照され、エディター上でコンパイルされたテクスチャの表示やサムネイルの生成機能などを提供し、MSBuildのプロジェクトから参照され、ビルドサーバー上でテクスャをコンパイルする為の機能を提供、そしてもろちんPowerShellスクリプトからも参照され、コンパイルされたテクスャ情報のデータマイニング、ゲーム中UIで使われるテクスチャーを別途処理するのに使われています。
PowerShellを使おう
北米のゲーム開発現場では「スピード・バンプ(Speed Bump)」という言葉が良く使われます。これは駐車場等で車の速度制限する為に必要なものですが、ゲーム開発においての「スピード・バンプ」とは開発速度を落とす、取り去るべきものとして扱われています。PowerShellはこのスピード・バンプの多くを取り除き、開発速度の平均速度向上に非常に役立っています。
PowerShellを実際のプロジェクトで毎日のように使ってみて「PowerShellは大規模ゲーム開発でも使用可能」と、考えるようになり、今では「大規模ゲーム開発にPowerShellは必要不可欠なもの」と考えるようになりました。
今までPowerShellを触ったことのない人も、これを機にPowerShellを使ってみてはどうでしょうか？