ゲーム開発のための Git
ゲーム開発のための Git | 圧倒的に楽しいゲーム開発向け Git
ゲーム開発のための Git
2012 年 3 月 14 日
これまで私は、映画やゲーム制作において CVS、Perforce、さらにはいくつかの社内ツールなど、さまざまなバージョン管理システムを使用してきました。これらは常に、「扱いにくいけれど必要不可欠な悪」という印象でした。大規模プロジェクトでの作業追跡には不可欠ですが、同時に混乱、ボトルネック、そして制作プロセスの柔軟性の欠如という問題をもたらす要因でもありました。
Git が初めて私の視野に入ってきたのは約 6 か月前のことです。それは驚くほど強力で柔軟に見えました。私がチームに加わった当時、Massively Fun の開発者はすでにコード開発に Git を使用していました。私は、これをアート制作にも適用できるかどうかを試してみたいと強く思いました。この投稿では、その顛末をお話しします。
背景：Git とは何か？
Git は分散型バージョン管理システムです。ゲーム開発に携わる方のほとんどは、Subversion や Perforce といった他のバージョン管理システムの少なくとも一つにご存知でしょう。これらのシステムと同様に、Git を使えばプロジェクトに含まれるすべてのファイルのさまざまなバージョンを追跡できます。
しかし、Subversion や Perforce は集中型システムであり、すべてのファイルは中央サーバー上にあるリポジトリへチェックインまたはチェックアウトされます。Git はこれらとは異なります。中央サーバーに依存しません。各ユーザーが、履歴やリビジョンを含むリポジトリ全体のコピーを完全に保有します。
この設計には多くの重要な意味があり、そのほとんどはプラスに働きます。しかし、私にとって Git が際立って見える最大の理由は、ブランチ操作とマージ操作をほぼ自明のものに変えてしまう点です。実験的なアイデアに取り組むためのブランチ、無関係な問題を修正するための別のブランチ、新機能用のさらに別のブランチを作成できます。これらの異なるブランチ間を素早く移動し、必要に応じてそれらを再びマージすることができます。これは非常に有用な機能です。
関連: — Unity プロジェクトに直接ドロップできる既製のアート、ツール、テンプレート.
つまずきポイント
数多くの利点があるにもかかわらず、そのままの Git にはアート制作にとって明白な欠点が二つあります。
-
アーティストフレンドリーではない
Git のデフォルトのインターフェースはコマンドラインです。学ぶべきコマンドやオプションが多く、他のバージョン管理システムとは十分に異なる基礎概念があるため、混乱を招きがちです。ドキュメントは豊富ですが、しばしば理解しにくいものです。これらが合わさり、親しみやすくなく、やや威圧的なパッケージになっています。 -
アーティストが作成するような大きなバイナリファイルを管理するように作られていない
各ローカルリポジトリがすべての履歴とリビジョンを含むという事実により、急速に変化する大量のアートワークはあっという間にディスク容量を圧迫してしまいます。ショッピングの場合: — Web、モバイル、デスクトップにエクスポートできるブラウザベースのコード不要の HTML5 エンジン.
私たちはこれら二つの問題に対する解決策を考案しました。
インターフェースが重要
Git にはいくつかの優れたグラフィカルインターフェースがあります。アーティストは依然として Git の基本概念を理解する必要がありますが、よく設計されたフロントエンドがあれば、習得と使用が considerably 容易になります。
私たちが見つけたのは、Mac ベースの環境で素晴らしく機能した Atlassian の SourceTree です。これは強力で直感的、しかも（現時点では）無料です。これは資金繰りの厳しいスタートアップにとって重要な考慮事項でした。SourceTree チームは、Twitter 経由でのサポート問い合わせに対しても迅速（12 時間以内）に対応してくれました。
洗練された Git 拡張機能
Git-media は、大きなバイナリファイルに関する Git の欠点を解消します。これは Git の拡張機能であり、ファイルを Git の外側に保存できるようにします。Git は引き続きファイルのバージョンを追跡しますが、ファイルの内容自体はリポジトリ外のどこかに保存されます。
私たちは大きなバイナリファイルを Amazon の S3 クラウドに保存する計画を立てました。
そう簡単にはいかない
しかし、SourceTree と Git-media を組み合わせる際には落とし穴があります。リポジトリと Amazon S3 間でファイルを転送するには、シェルコマンドを実行する必要があるのです。つまり、以下のコマンドです。
$ git media syncアーティストに対して、グラフィカルアプリケーションという比較的安全地帯から離れてシェルコマンドを入力させるワークフローは、アーティストフレンドリーとは言えません。SourceTree にはこのコマンドをカスタムアクションとして実行する手段がありますが、それだけでは不十分でした。アーティストは適切なタイミングでこれを実行することを覚えておく必要があります。迟早誰かが忘れ、何が間違っていたのかを特定して修正するために貴重な時間が浪費されることになるでしょう。
では、どうすれば SourceTree と git-media を仲良く共存させられるでしょうか？
Git Wrap
私たちは、Git コマンド自体の実行前後に任意で他のコマンドを実行する汎用ラッパースクリプトを作成しました。リモートリポジトリと相互作用するコマンドの実行前後に、状況に応じて自動的に git media sync を呼び出すように設定しました。
さらに、SourceTree が標準の Git ではなく、このラッパーを呼び出すように構成しました。ラッパーのソースコードは Github で公開されています。
冒険は続く
ここで話が終わればよかったのですが、SourceTree と git-media が完璧に連携し、誰もが幸せに暮らしました、というわけではありませんでした。確かに、ある時点までは機能していました。残念ながら、それだけでは不十分だったのです。
通常、SourceTree は画像ファイルのプレビューをうまく処理します。アーティストがそのようなファイルへの変更をコミットまたはマージする際、これは極めて重要です。しかし、git-media を使用すると、画像を Git 内に保存せず、画像に関するバージョン情報のみを保存することになるため、SourceTree の画像プレビュー機能が壊れてしまいました。
これに対する許容できる回避策は見つからず、これが決定打となりました。
この記事を書いている時点で、私たちは Git のサブモジュール機能を用いて再度挑戦しています。アートアセットをサブモジュールとして保存することは、メインプロジェクトリポジトリのサイズを最小限に抑えるもう一つの方法です。SourceTree はサブモジュールをかなり 잘 이해하고 지원하며、画像プレビュー機能も intact に保たれています。サブモジュールにはいくつかの特徴的な挙動がありますが、アーティストのワークフローを大きく妨げるようなものはありません。
今後の更新情報にご期待ください。結果如何につきましては、改めてお知らせいたします。
blog comments powered by Disqus
開発デスクに在庫を用意する
ゲーム プログラミング書籍、メカニカル キーボード、モニター、開発デスク ハードウェア