ゲーム開発ではなぜファイルのマージよりも「ロック」を多用して開発を進めるのか？

ゲーム開発の現場では、複数人が同じファイルを編集して後から変更内容を統合する「マージ」が一般的なソフトウェア開発ほど使われていません。ゲーム開発者のアレックス・クリリン氏が、画像や3Dモデルなどのバイナリファイル、ファイルの排他ロック、巨大なデータ容量といった事情から、ゲーム開発特有の作業手順が生まれる理由を解説しています。

Why Game Devs Don't Merge Files | Alex Kurilin
https://www.kuril.in/blog/why-game-devs-dont-merge-files/

ウェブサービスの開発なら、Aさんがボタンの処理を書き換え、Bさんが同じファイルのエラー処理を修正しても、Gitは変更された行を比較し、修正箇所が重なっていなければ両方の変更を自動的にまとめられます。変更箇所が重なった場合も、開発者が差分を確認して必要な内容を手作業で統合できます。プログラムの多くが文字として保存されているため、変更前後の差分を機械的に比較できるわけです。ゲーム開発でもC++などのテキスト形式で書かれたコードには同様のマージが使われます。

一方でゲームには、キャラクターの画像、音楽、アニメーション、3Dモデル、動画、視覚効果、マテリアルなどが含まれます。例えば画像ファイルを2人が別々に加工した場合、片方が行った色調補正ともう片方が描き加えた傷を後から組み合わせるなど、開発者の意図に沿って自動合成するのは困難です。

画像や音声はGitが行単位で比較できる文字列ではなく、専用形式のデータとして保存される「バイナリファイル」です。バイナリファイルでは変更内容を行単位で比較できないため、同じファイルを2人が編集すると、片方の変更を捨てるか、一方の変更内容をもう一方のファイルへ手作業で反映する必要が生じます。複雑な素材では数日分の作業が失われる可能性もあるとのこと。

Unreal Engineのビジュアルスクリプト機能「Blueprint」も、同じ問題を抱えています。Blueprintは処理を表す箱状の「ノード」を線でつなぎ、ゲームの動作を組み立てる仕組みです。テキスト形式のコードを書かなくても利用できるため、ゲームデザイナーやアーティストも処理を作成できます。変更箇所を見比べる差分表示機能は用意されていますが、別々の変更を自動的にマージすることは難しく、差分を見ながら必要な変更を手作業で反映する必要があります。

作業の上書きを防ぐために使われるのが「排他ロック」です。誰かがキャラクターのテクスチャを編集対象としてチェックアウトしたら作業が終わるまで別の開発者は同じテクスチャを変更できません。複数人の作業を後から統合するのではなく、同時編集そのものを禁止して事故を防ぐ方式です。

中規模以上のゲーム開発で広く使われているバージョン管理システム「Perforce P4」は、中央サーバーがファイルとロックの状態を管理します。排他設定されたファイルを開発者がチェックアウトすると、作業を提出するか変更を取り消してロックを解除するまで、他のメンバーは同じファイルをチェックアウトできません。Unreal EngineはPerforce P4との標準連携機能を備えており、ゲーム業界のアーティストにも使い慣れた仕組みになっているとクリリン氏は説明しています。

排他ロックを使えば上書き事故は避けられますが、別の問題が発生します。ある開発者が主要キャラクターのファイルを数日間ロックすると、同じファイルを必要とするアニメーターやゲームデザイナーは作業を進められません。ロックを解除し忘れたまま退勤すると、時差のある地域で働くメンバーが編集できなくなる場合もあります。

ゲーム開発ではロックによる待ち時間を減らすため、1つのファイルに多くの機能を集めず、役割ごとに小さく分割する設計が重要になります。例えば体力、持ち物、移動、特殊能力を1個のキャラクターファイルへ詰め込むと、どの機能を変更する場合でも同じファイルのロックが必要です。

Unreal Engineでは、キャラクターなどの「アクター」に独立した機能を追加する「アクターコンポーネント」を使い、体力や持ち物の処理を別々の部品として切り出せます。体力の仕組みを修正する開発者は体力用の部品だけをロックすればよく、移動や持ち物を担当するメンバーは別のファイルで作業を続けられます。再利用性を高めるだけでなく、開発者同士の作業待ちを減らすための分割でもあるというわけです。

一般的なソフトウェア開発で使われる作業用ブランチも、ゲーム開発では役割が小さくなります。多くのバイナリーファイルでは実用的な自動マージが難しいため、別々のブランチで同じ素材を編集しても最終的な統合ができません。チーム全員がメインブランチ上で作業し、必要なファイルだけをロックする運用が選ばれることが多いとのこと。

ゲーム開発ではプロジェクト全体のデータ量が大きいことも開発手順に影響を与えています。4Kテクスチャ1枚だけで数十MBに達する場合があり、開発中のゲーム全体が数TBから数十TBになることもあります。ゲームを実行可能な形に組み立てる「ビルド」のたびに、全データをダウンロードするのは現実的ではありません。そこで、変更を取り込んでゲームを自動的に組み立てる継続的インテグレーション(CI)用のコンピューターには、P4の作業領域を残し、変更されたデータだけを同期する手法が採用されています。配布版では対象プラットフォーム向けにデータを変換し、サイズや形式の調整、未使用素材の除外などを行うため、利用者がダウンロードする容量は開発データ全体より小さくなるとのこと。

ロックの解除を忘れない、頻繁に編集されるファイルを把握する、特定の素材の担当者を決めるといった人間同士の取り決めも欠かせません。テキストファイル中心の開発ではGitなどのマージ機能で処理していた作業の衝突を、ゲーム開発ではファイル設計とチーム内の連絡で避けているわけです。

クリリン氏は、ゲーム開発が一般的なソフトウェア開発より遅れているわけではなく、巨大なバイナリファイルを扱うという制約に合わせて異なる手法を採用していると述べています。自動マージ技術が今後発展する可能性はあるものの、現状では同じバイナリーファイルを複数人が同時編集しない排他ロックが数日分の作業を守るための実用的な答えになっているとのことです。