Unityのワークフローのスケーリング：中規模から大規模なプロジェクトから得られる教訓
このブログ記事は、Mega Cat Studiosによる連載の第1弾です。同スタジオは、Unityに関する専門知識や、実際の商用ゲーム開発における課題への解決策を共有しています。ぜひ役立つヒントを見つけてください！
あなたには素晴らしいアイデアがあり、コードはタイプするのとほぼ同じ速さで書き上がっていく。コミットを重ねるごとに、新しい特徴の形状が形成されていきます。しかし、アイデアが次々と浮かんでくるそのスピードこそが、やがてバグだらけのひどい外観を招く結果になりかねないのです。
Mega Cat Studiosでは、すべてのプロジェクトを情熱を持ってスタートさせています。だからこそ、型にはまらず柔軟に、そしてできるだけ早く物事を成し遂げたいという気持ちもよく理解しています。プロトタイプとしては、このアプローチで問題ありません。むしろ、私たちはこの方法を推奨しています！賢明な開発者は、いつイテレーションのスピードを優先すべきか、いつ安定性を優先すべきかを理解している。なぜなら、プロトタイプ段階を脱すると、その「大雑把で柔軟な」アプローチが足かせになってしまうからです。
Mega Cat Studiosでは、これまで何度もこのような遷移を乗り越えてきました。そして、プロジェクトを重ねるごとに、私たちは新たなことを学んでいます。今回の最新プロジェクト『Backyard Baseball』のリリースに向けて、私たちが学んだ教訓をいくつか共有したいと思います。
第1課：スケールに応じた構造体
スケーリングの問題は、コードの質が悪いことが原因で起こることはめったにありません。むしろ、計画性のないアーキテクチャが原因で生じることが多いのです。開発者やアーティストが10秒以内にアセットを見つけられないのであれば、ワークフローを見直す必要があります。プロジェクトをスケール可能な状態に構築するためのヒントをいくつかご紹介します：
- 種類や用途別に整理する：「タイプ」でグループ分けし、次に「目的」でグループ分けします。「タイプ」には、アート、コード、オーディオなどのカテゴリが含まれます。「目的」とは、それらが何のために使われるかということです。直感的な構成により、導入時の摩擦係数を軽減します。新しいアーティストは、誰に聞かなくても「キャラクターの待機」スプライトがどこに配置されるべきかを正確に把握できるはずです。
- シーンはシンプルに保つ：「メガシーン」は廃止し、代わりに、セーブデータや重要システムを格納するメインシーンに加え、プレイヤーが試合中かどうかによって追加ロードされるタイトル画面や野球場のシーンなど、より小規模なシーンを採用しました。同様に、独立した特徴にはプレハブを使用するため、それらを含むシーンファイルに変更が反映される可能性は低くなります。これにより、アーティストが環境の制作に取り組んでいる間、デザイナーが同じ「レベル」内でゲームプレイを調整しても、ファイルの競合が発生することはありません（これについては後ほど詳しく説明します）。
- Addressables システムの設定：従来のリソースフォルダーに代わって、Addressablesシステムを採用し、必要な時にのみアセットをロードすることで、メモリ使用量を抑えています。さらに、Addressableキーを使用してアセットをロードする方が、Resourcesフォルダー内の特定の場所へのファイルパス経由でロードするよりも、分かりやすく、不具合が発生しにくい。
難しいのは、これらのベストプラクティスを理解することではありません。それは、開始時からそれらに全力を注ぎ、何年経ってもその姿勢を貫き通すことです。
自分が現在どの開発段階にあり、その段階で何を優先すべきかを把握しておくこと。
『Backyard Baseball』の開発者であるパオロ・ロクサス氏は、「プロトタイピングの段階では、コードがほとんどないため、モジュール化よりもまず機能させることを優先してもOK」と語る。「プロジェクトがどのように進展するかを見極めてから、さらに複雑化させたいと考えています。」
第2課：Unityと協力し、対立しない
「コンポーネントであれ、ScriptableObjectであれ、あるいはカスタムクラスであれ、目的が明確で、簡潔かつ独立した構成要素を作り出すことほど強力なことはありません」と、Mega Cat Studiosのエンジニアリング責任者であるDavid Chávez Armenteros氏は語る。Unityは、その中核においてモジュール性を重視しています。柔軟性を保つために、私たちは以下の3つの基本的な原則に従っています：
1.単一責任の原則：各スクリプトやクラスは、明確に定義された役割を1つ持つべきです。
2.疎結合：システム間の相互作用は、直接リファレンスではなくインターフェースやイベントを通じて行うべきであり、それも適切な場合に限る。循環的なアーキテクチャや複雑に絡み合ったアーキテクチャを避けるため、コードに実装する前に、システム間の依存関係をグラフ化することをお勧めします。
3.プラグアンドプレイ：広範囲にわたる「神スクリプト」を書くのではなく、小規模で目的を絞った単位を組み合わせることで、複雑な動作を実現する。
第3課：制限を活用して、自由を手に入れよう
アセンブリ定義（AsmDefs）は、コードをグループ化するC#の構文です。宣伝されている利点はコンパイル時間の短縮ですが、その真の強みはモジュール性を徹底させる点にあります。
リード開発者であり、スパゲッティコードを嫌うニコ・ガウデンツィは、それらを絶賛している。
「Backyard Baseball では、入力レイヤーとゲームプレイレイヤーは別々の DLL に格納されています。」「このゲームプレイは、入力の詳細に一切依存しません。」
これにより、各依存関係を熟考した上での判断とすることで、エンジニアが誤った判断を下すのを防ぐことができる。どうしても必要であれば、プレイヤーの物理演算やAIの動作を損なうことなく、ゲームパッドの処理からNetcodeに至るまで、Input System全体を書き直すことも可能です。むしろ、これにより、1人のエンジニアがコードベースの特定の領域だけで作業できるようになり、誤って変更が他のシステムに波及することを防げるほか、特徴実装やバグ修正の際に開発者が把握しておく必要のあるコードの量を減らすことができます。
第4課：「努力するのではなく、賢くテストする」
プロジェクトが大きくなるにつれて、「ドミノ効果」が引き起こされることがあります：こちらでちょっとした変更を加えると、あちらで問題が発生してしまう。優れたアーキテクチャは大きな効果をもたらしますが、万能薬というわけではありません。
新機能の特徴変更内容が、当社の優秀な品質保証チームによる手動テストの段階に入る前に、一連の自動化された単体テストを通じて厳格に検証されます。
「テストは要件のリストとして機能する」とニコは言う。「そこでは、求められる要件が説明され、キーのユースケースが紹介されています。」
『Backyard Baseball』のキャラクターが速球を投げたり、盗塁をしたり、ホームランを打ったりするとき、私たちは特定のゲームプレイの結果を実現したいと考えています。例えば、投球にふさわしいリアルなスピードでボールが飛ぶようにすること、走者のタイミングが盗塁のメカニクスと合致すること、あるいは野手がヒットに対して適切に反応することなどです。キャラクターは地面と正しく衝突する必要があり、ボールは適切なスピードで動く必要があります。また、構える、スイングする、あるいは塁間を全力疾走するといったアクションを追跡するプレイヤー・コントローラーのフラグなど、より粒度の細かいシステムも正常に機能する必要があります。
パブロ・サンチェスのパワーを調整する際、あるいはさらに重要なこととして、バットのスイングを制御する共有コードを調整する際には、接触タイミングからボールの軌道に至るまで、あらゆるインタラクションがゲーム全体を通じて一貫した挙動を示すようにする必要があります。
たいていの場合、不具合が発生するのは思いもよらない部分であり、それこそがテストがこれほど重要である理由なのです。
このシステムをワークフローにインテグレーションすることで、特定の要件が満たされなくなった瞬間にそれを把握できるようになり、まるで「藁の山から針を探す」ような手間のかかるテストやトラブルシューティングのセッションを大幅に削減できます。
UnityのTest Runnerは、システムがモジュール化されている場合に最も効果的に機能します。これが、私たちがアセンブリ定義を使用するもう一つの理由です。
第5課：アセット運用を始めましょう
「過ちを犯すのは人間らしいことだが、許すのは神々しいことだ。」
しかし、そもそも人為的なミスを防ぐためのシステムを構築するというのは、まさに伝説的だ。
何時間もコードのコーディングやデバッグに没頭していると、目が血走った開発者が誤ってクリックしたり、本来は一時的なものだった変更を誤ってリポジトリにプッシュしてしまうのは避けられない。（私自身も時折目が霞むことがある身として言えば）許されることではあるが、インポート設定が不適切なアセットは、甚大な影響を及ぼす可能性がある。また、多くの開発者は高性能なマシンで作業しているため、最悪のシナリオとしては、キャラクターやアニメーション、効果が盛り込まれたスタジアムのシーンが、スペックが低いハードウェア上で動作した際に、動作の遅延や不安定さを引き起こすようになるまで、パフォーマンスの問題に気づかないという事態が考えられます。
このリスクを軽減するために、アセットへのアクセス権限を制限することも考えられますが、ゲームコンテンツには調整が必要な点が多いため、これがボトルネックとなってしまいます：
- このモデルは大きすぎて、現在のカメラの設定には収まりません。
- このオーディオクリップは音量が小さいため、特定の効果をかける必要があります。
- シェーダーが変更されたため、すべてのテクスチャを調整する必要があります。
『Backyard Baseball』のような、ビジュアルの質が極めて重要なゲームでは、リリース前にルックアンドフィールを完璧に仕上げるため、モデルやVFXに対して何百もの調整が行われます。
「どんなに技術仕様を詳細に盛り込んでも、コンテンツの多様性があるということは、異なるアセット間の些細ながらも重要な違いに対処しなければならないという事実を覆い隠すことはできない」とニコは言う。
ここでも自動化が役立ちます：
- AssetPostprocessor:プロジェクトの基準を遵守するための、カスタマイズされたインポートロジックを作成します。
- OnValidate:エディタ内でリファレンスの欠落をレポートするために OnValidate メソッドを使用しています。このメソッドは、ビルドの前に必ず呼び出されます。
とはいえ、自動化の話ばかりに気を取られて、手作業による簡単な修正の方が早い場合は、そちらを軽視してはいけません。
「手作業で10分しかかからない作業を、自動化するために10日も費やすようなことは決してしてはいけない」とデビッドは警告する。
第6課：「人的要素（協働）」をマスターする
毎日数十人の開発者から数百件もの変更を調整する際、Gitのようなバージョン管理システムは真っ先に思い浮かぶものの一つです。デビッドは、Mega Catのすべてのプロジェクトにおいて、こうした実績のある手法を採用することを提唱しています：
- ごくわずかな、アトミックレベルの変化：一度に多くのシステムに影響を与える「大規模なコミット」は避けてください。個々の特徴ブランチでの作業は、安定し、レビューが完了するまで分離してください。個々の変更は個別のコミットにまとめることで、バージョン履歴が明確になり、必要に応じてチェリーピックやその他のGitの便利な機能も使いやすくなります。
- mainからの毎日のマージ：機能ブランチ、部門ブランチ、および長期ブランチをメインブランチと同期させておきましょう。これにより、最終的なマージ時の規模や複雑さを軽減でき、大規模な競合を防ぐことができます。
- マージリクエストを確認する：ここは品質保証の第一線であり、ここでバグを発見し、プロジェクトの基準を遵守させ、システム全体との整合性を確保します。
「大規模なUnityプロジェクトにおいて、コードレビューは単なる形式的な手続きではない」とデビッドは助言する。「これらは紛争予防とプロジェクト全体の品質確保において重要な役割を果たしています。」
コードレビューを行う担当者が、実装対象の分野に関する専門知識を持ち、コーディングのベストプラクティスを理解していることを確認してください。そうすることで、正確性と保守性を的確に評価できるようになります。
Unityでバージョン管理をできるだけ滑らかに行うための具体的なコツやテクニックがあります。シーンとプレハブはプロジェクトの基盤となるため、CPUパフォーマンスだけでなく、開発者間の共同作業の面でも最適化してください。
私たちは、大規模なシーンや単一のプレハブよりも、常に小規模で、追加可能な、ネストされたコンポーネントを優先します。こうすることで、開発者は競合することなく並行して作業を進めることができます。
これは重要な点です。シーンやプレハブにおけるマージの競合は、そのデータが開発者にとって読み取りにくいものであるため、解決が最も困難だからです。このプロセスを円滑に進めるため、これらのファイルはバイナリ形式ではなくテキスト形式でシリアル化し、Gitの設定でYAMLファイルの自動マージ機能を有効にしています。これにより、Gitがマージ競合を自動的に解決できる可能性が高まり、開発者は新機能の開発といった重要な業務に時間を割くことができるようになります。
しかし、それにもかかわらず：
「競合を防ぐことは、通常、それを解決しようとするよりも良い戦略だ」とニコは言う。
アセットの所有権を明確にすることは、この点において非常に有効です。
「特定のシーンやプレハブをモディファイアできるユーザーを定義してください」とデイビッドは言う。「その場合、チームメンバーはアセットを直接編集するのではなく、担当範囲外の変更をリクエストすることになります。」
ニコは、同様の手順を「セマフォシステム」と呼んでいる。これは基本的に、開発者がアセットを変更した際にその日時を記録し、事実上そのアセットを「ロック」するためのスプレッドシートです。他の開発者がそのファイルに変更を加える必要がある場合、ファイルをロックした開発者が変更内容をリポジトリにプッシュして「ロックを解除」するまで待つ必要があります。
いつものように、チームにとって最適な方法を見つけてください。
未来に向けた取り組み
Mega Cat Studiosでは、Unityプロジェクトのスケーリングでは、「よりハードにコーディングする」ことよりも、アーキテクチャの設計に厳密さを期すことが重要だと学びました。Unityのコンポーネントベースの特性を尊重し、アセンブリ定義を用いて境界を明確にし、将来を見据えてアセットを整理することで、リリース前にプロジェクトが技術的負債に陥ることなく、プロトタイプ段階のクリエイティブな流れを最大限に維持することができます。
これらの教訓は重要ですが、完璧なコードベースなど存在しないということを忘れないでください。ソフトウェア開発とは、推奨されるプログラミングパターンと実務上の配慮が日々激しくぶつかり合う、壮絶な戦いの場である。もし、以下の原則のいずれかを実践した結果、有益なトレードオフが得られないまま開発がストールしてしまうのであれば、それは教科書的な推奨事項ではなく、自チームの具体的な状況にもっと配慮する必要があるというサインです。何しろ、プロジェクトもチームも人も、それぞれ異なるのですから。
メガ・キャット・スタジオでは、日々そのバランスを保つよう努めています。新しいプロジェクトに取り組むたびに、ゲームライブラリが拡大し続ける中で、私たちはより優れたUnity開発者となり、より良いチームワークを発揮できるようになりたいと考えています。