目次
ビルドをクリーンに保つ利点
ゲームのビルドをクリーンで安定した状態に保つことで、定常的に次のようなメリットが得られます。
- より安定したゲームを、少ないバグでリリースできる。
- バグが少なく、よりクリーンなコードベースになることで制作時間が短縮される。
- 「ビルドが壊れる」可能性を下げる。
- デモ版や特殊なビルドをより簡単に制作できる。
AAA のビルドプラクティスによっては、インディーチームに適さないものもあります。ただし、クリーンで安定した状態にビルドを保つために、無料（または手ごろな価格）で、チームの規模を問わず実装可能なものはたくさんあります。
1 人で作業している場合でも、ここで紹介するヒントは作ったゲームをより優れた、さらに健全な状態へ保つことに一役買ってくれるでしょう。
バージョン管理を使おう
無料のバージョン管理システム（Version Control System：VCS）が普及した現在でも、いまだに共有フォルダーやファイル共有サービスで作業しているチームがいます。バージョン管理なしで開発することは、シートベルトなしで運転するようなものです。シートベルトを着用することは必ずしも快適とは言えず、多少は制限があるのは事実ですが、フルスピードで木に衝突する事故を起こしてしまった時には、シートベルトが命を守ってくれるのです。
どんな規模のチームであろうとも、行っていた作業を喪失するわけにはいきません。ファイル共有サービスのアカウントのハッキングやハードディスクの破壊によって、数日、数週間の作業を失うようなトラブルがあってはならないのです。
無料のソリューションならいくらでもあります。Perforce、Git、SVN はすべて無料のバージョンを用意しています。さらに、Unity に直接 Unity Teams が組み込まれることで、取り扱いがより簡単になります。
チェンジリストを活用しよう
VCS を使用すると、安全性が提供されることに加えて、変更の概要把握に役立つチェンジリストが追加されるという利点もあります。上の画像は Perforce フォルダーの履歴で、すべての変更が表示されています。
ほとんどのシステムでは、行った変更についての詳細を提出することは強制ではありませんが、変更記述はしておく方が良いでしょう。
ちなみに、次に示すように変更内容に合わせてプレフィックスを使用しておけば「パッチノート」や類似したドキュメントの作成が簡単になります。
- !B：バグの修正。
- !V：ビジュアルの変更や改良。
- !G：ゲームプレイの変更。
- !X：パッチノートで無視するべき変更。
VCS に変更を提出するときにプレフィックスを追加して記述することで、後ですべてのエントリーに対してスクリプトを実行でき、わかりやすくきれいに整理されたパッチノートのドキュメントとしてまとめることもできます。
きれいに整理して VCS に提出した状態は、次のようになります。
「!V 爆発のパーティクルエフェクトを大きくした」
「!B 武器を拾うときのクラッシュを修正」
「!G メディカルキットで回復する体力の量を増加」
すべてのチェックインをクリーンな状態に保ち、整理して記述しておけば、必要に応じてパッチノートのドキュメントを簡単にまとめることができます。パッチノートの一覧に表示されるものについては、この方法の方が直近の変更を見直して特定するより効率的です。
健全性を保つよう努めよう
ビルドの健全性を保つ基本というものをチームの全員が理解しておくことが重要になります。ここでは、ビルドをクリーンに保つための 5 つのベストプラクティスを紹介します。
- ビルドを壊すコードはチェックインしない
壊れているとわかっているものはチェックインしないでください。まだ完成していない作成中の機能をチェックインする必要がある場合は、チームの他のメンバーが取り組んでいるものを壊さないように、その機能を無効にするか、変更をシェルブします。機能しないコードをチェックインしたことが原因で壊れたビルドが、チームの他のメンバーの作業を阻むようなことがあってはなりません。 - ハードコードされたキーボードショートカットを使用しない
特定のチート機能やデバッグ機能用に、カスタムショートカットを追加することは便利です。「F12 キーをお金を増やすチートキーにしちゃおう。どうせ誰も押さないし。」
しかし、このように機能をキーにハードコーディングしたことは危険です。失念しやすいからです。誤って出荷してしまう事態に陥ったり、テスターが意図せずアクティベートしてバグレポートを汚染してしまったりする可能性があります。 - 不正なコードや不足しているコードをマークする
ときにはハックを設ける必要があります。どれほど避けたくとも、コード内に一時的にハックがある状態は避けられません。ハックつまり迂回路を追加するときは、見つけやすいキーワードを使用してそのことをコード内にマークしておくようにしましょう。ハックを //HACK、不足しているコードを //TODO でマークします。これにより、後でコード全体に対してそれらのタグを簡単に検索して置換できます。 - ログスパム
コード内にログを記録すると便利で、問題を追跡するのに役立ちます。ただし、重大な警告やエラーが埋没しないように時々ログスパムのクリーンアップを実行することが重要です。機能を作成している途中でない限り、コンソールはできるだけクリーンかつ空の状態に保つべきです。これは、ポップアップを見逃さないようにし、すぐ確認できるようにするためです。 - ファイル名と命名規則
ビルドのサイズは、最終的に数百および数千のファイルに及びます。そのため、わかりやすい命名規則を維持することが重要です。
新しいプロジェクトを開始するときは、自分にとってわかりやすい命名規則を考え出し、それに従うようにしてください。ビルドに texturetestFinal01.png や backup22.fbx などのような名前があると、すぐにわけがわからなくなってしまいます。
プロジェクト内に作成された規則に従っていないファイル名を定期的にチェックし、クリーンアップします。
以下に簡単なヒントをご紹介します。
- わかりやすい名前を使用する
「atkBtn.cs」ではなく「AttackButtonBehavior.cs」 とする - キャメルケース（camelCase）あるいはパスカルケース（PascalCase）を使う
「notsocleanfilename.cs」よりも「MyCleanFilename.cs」のほうがわかりやすい - アンダースコアを使用してファイル名の内容をより明確にする
「WoodenHouse_Blue」、「WoodenHouse_Green」など
チート機能をクリーンに保とう
ゲームを開発している間は、常にデバッグとチートが必要になります。別のゲームステージにジャンプしたり、お金を増やしたり、自分を不死身にしたり、新たな敵をスポーンしたり、さまざまなことを実行する必要があります。
このようなチートを適宜追加し、使用後に無効にするという方法を取ることもできますが、この種のチート機能のオン/オフを切り替える形の明確な方法を手配したほうが便利です。
小規模なプロジェクトであっても、少し時間をかけて手軽に使用できるデバッグ/チートメニューを構築する価値はあります。これにより、開発者がオン/オフを簡単に切り替え、一般的なすべてのチートオプションやデバッグオプションにアクセスできるようになります。
この対応を行うことで、ゲームにチート機能が残ったまま公開してしまうリスクを最小限に抑えることができます。さらに、「チートコード」を 1 か所で集中管理することで、すべてが機能することを確認できるほか、拡張も簡単になります。
このアプローチのもう 1 つのメリットは、開発中のチートの扱いが格段に手際良くなり、毎日の制作時間を短縮できることです。スクリプト内で値をハードコーディングなんてするよりも、なじみの便利なデバッグウィンドウでボタンを押すだけの方がはるかに短時間で済みます。
バグを管理して追跡しよう
ゲームにバグは付き物です。すべてのゲームにはバグが存在し、皆さんのゲームも例外ではありません。問題は、どのようにバグに対処するかです。
バグを効率的に処理するワークフローは実に単純明快です。まず QA 部門がバグを見つけ、バグ追跡システムに入力します。そして、その問題を開発者へ割り当て、担当開発者が問題を修正し、解決済みとマークします。最後に、QA チームが問題が修正されていることを確認し、クローズとマークします。たった 3 ステップのプロセスです。簡単でしょう？
えっ？なんですって？QA 専門の部署がない場合はどうすれば、という顔ですね。なるほど、テスターが開発者を兼任しているところもありますね。
いえいえ、心配はご無用です。バグを完全に把握している必要はありません。
なにより、まずはバグを追跡しましょう。たった 1 人のチームであってもこれなら簡単です。
バグ追跡ソフトウェア（無料のソフトウェアや安価なソフトウェアが大量に出回っています）を選び、セットアップします。そこまではする気がないと思う人は、Excel や机にあるメモ帳などでも全然かまいません。ここで重要なのは、問題の収集と追跡を 1 か所に集約することなのです。問題を追跡するシステムを用意したら、後は統制の問題です。バグの多いビルドは制作スピードを下げ、新しい問題を引き起こすことすらあります。
ここではバグを常に把握しておくための簡単なヒントをご紹介します。
Bug-Fix-Fridays
「Bug-Fix-Fridays」は、ビルドにバグのない状態を保つよい方法です。毎週金曜日は、新しい機能に取り組む代わりに、全員がバグリストにある項目にのみ取り組むのです。このアプローチにより、バグのない安定したビルドで新しい週を迎えることができます。
長い間先送りにしない
バグが手に負えなくなっていることがわかっている場合は、新しい機能に取り組むことを止め、再び軌道に乗るまではビルドの安定化に重点を置くことをお勧めします。
いつも同じ手段を用いない
何回も出現するバグがある場合は、根本原因を調査します。ゲームステージが壊れるのは、いつもゲームステージのビルドパイプラインの特定部分が原因となっていませんか？1 日おきに故障するのは .xml ファイルからゲームプレイの値を解析する、そのやり方が原因となっていませんか？
常に問題を引き起こしているシステムを特定した場合、その誘因により発生した問題を繰り返し修正するのではなく、対象のシステムを再構築するほうが時間をかける価値があるかもしれません。
これらすべてのベストプラクティスとヒントを頭に入れておけば、さしずめ後は統制とビルドの状態にどのくらいの注意を払えばよいか、という所にかかってきます。こういった推奨事項は組み合わせたり工夫すれば、インディー制作にも適用できると思います。常にビルドを良い状態に保つためにと気を配っていたその時間は、絶対に無駄にはなりません。
