■ 1. 背景
- 一般的なソフトウェア開発では、複数人が同じファイルを編集後に変更を統合する「マージ」が標準的な手法
- ゲーム開発では、マージよりも「排他ロック」を多用する独自の作業手順が存在する
- ゲーム開発者のアレックス・クリリン氏が、その背景にある技術的・実務的な事情を解説
■ 2. 一般的なソフトウェア開発でマージが成立する理由
- ソースコードはテキスト形式で保存されており、Gitが行単位で変更前後の差分を比較できる
- 変更箇所が重なっていなければ、複数人の編集を自動的に統合可能
- 衝突（コンフリクト）が発生しても、開発者が差分を確認して手動で解決できる
- ゲーム開発のC++などテキスト形式で書かれたコードにも同様のマージが適用される
■ 3. ゲーム開発でマージが困難な理由
- バイナリファイルの問題:
- ゲームには画像、音楽、アニメーション、3Dモデル、動画、視覚効果、マテリアルなど多数のバイナリファイルが含まれる
- バイナリファイルは行単位で差分を比較できないため、自動マージが不可能
- 2人が同じファイルを編集した場合、片方の変更を破棄するか、手動で反映するしかない
- 複雑な素材では数日分の作業が失われる可能性もある
- Unreal EngineのBlueprintも同様の問題を抱える:
- Blueprintはノードを線でつなぐビジュアルスクリプト機能であり、テキストではない
- 差分表示機能は存在するが、別々の変更を自動マージすることは困難
- 必要な変更は差分を見ながら手作業で反映する必要がある
■ 4. 排他ロックによる対策
- 排他ロックの仕組み:
- あるファイルをチェックアウトすると、作業が完了するまで他の開発者は同じファイルを変更できない
- 複数人の作業を後から統合するのではなく、同時編集そのものを禁止して事故を防ぐ
- Perforce P4の活用:
- 中規模以上のゲーム開発で広く使われるバージョン管理システム
- 中央サーバーがファイルとロックの状態を管理する
- Unreal EngineはPerforce P4との標準連携機能を備えており、アーティストにも馴染みやすい
■ 5. 排他ロックの問題点
- 主要キャラクターのファイルを数日間ロックすると、アニメーターやゲームデザイナーが作業を進められない
- ロックを解除し忘れたまま退勤すると、時差のある地域で働くメンバーが編集できなくなる場合がある
■ 6. ファイル分割による待ち時間の軽減
- 1つのファイルに多くの機能を集めず、役割ごとに小さく分割する設計が重要
- 機能を詰め込んだ場合の問題:
- 体力、持ち物、移動、特殊能力を1個のキャラクターファイルへ集約すると、どの機能を変更する場合でも同じファイルのロックが必要になる
- Unreal EngineのActorComponentによる解決策:
- アクターに独立した機能を追加する「アクターコンポーネント」を使い、各処理を別々のファイルへ分割できる
- 体力の修正担当は体力用コンポーネントのみをロックすればよく、他のメンバーは別ファイルで並行作業できる
- 再利用性の向上だけでなく、開発者間の作業待ちを減らすための分割でもある
■ 7. ブランチ運用の違い
- 一般的なソフトウェア開発で使われる「作業用ブランチ」は、ゲーム開発では役割が小さい
- バイナリファイルでは実用的な自動マージが困難なため、別ブランチで同じ素材を編集しても最終統合ができない
- チーム全員がメインブランチ上で作業し、必要なファイルだけをロックする運用が多く選ばれる
■ 8. 大容量データへの対応
- 4Kテクスチャ1枚で数十MBに達する場合があり、開発中のゲーム全体が数TB〜数十TBになることもある
- ビルドのたびに全データをダウンロードするのは現実的ではない
- CI用コンピューターにはP4の作業領域を維持し、変更されたデータだけを同期する手法が採用されている
- 配布版では対象プラットフォーム向けにデータを変換・最適化するため、ユーザーがダウンロードする容量は開発データ全体より小さくなる
■ 9. 人間同士の取り決めの重要性
- ロックの解除を忘れない、頻繁に編集されるファイルを把握する、特定の素材の担当者を決めるといったチームルールが必要
- テキストファイル中心の開発ではGitのマージ機能が処理していた作業の衝突を、ゲーム開発ではファイル設計とチーム内の連絡で回避する
■ 10. 結論
- ゲーム開発が一般的なソフトウェア開発より遅れているわけではなく、巨大なバイナリファイルという制約に合わせて異なる手法を採用している
- 自動マージ技術が今後発展する可能性はあるものの、現状では排他ロックが数日分の作業を守るための実用的な解答