ゲームプロジェクトのすべてを保存するためのソース管理?


10

ソースコードだけでなく、すべてのアセット、テクスチャ、アート、ドキュメントファイルなどをバージョン管理のためにgitリポジトリの下で管理するのが普通ですか?たとえば、テクスチャの古いバージョンを取り戻したいです。非常に悪い習慣である場合、アセットやその他のもののバージョン管理にどのツールを使用しますか?



1
ソースコードは、ソースコードから生成できないすべてのものです。アセット、テクスチャ、アート、ドキュメンテーションもその定義の下のソースコードです。
ChristofferHammarström2013年

回答:


12

それはとても良い習慣だと思います。ソースおよび資産にはソース管理を使用する必要があります。あなたはそれをバックアップのように考えることができます、あなたはゲームを構築するために必要なすべてをソース管理から復元できるようにしたいです。

リポジトリへのアセットの保存に関する質問リンクしました。アートを保存するために他のリポジトリよりも機能するリポジトリがいくつかあります。アートを「比較」して、変更点を確認することができます。その他は、アセットをバイナリデータとして扱うだけなので、違いを確認するにはアセットをチェックアウトする必要があります。これは、リポジトリがバージョン間で何が変更されたかを「認識」(解析)できないため、変更時にアセット全体をアップロードする必要があることも意味します。

すべてをリポジトリに保存します。新しいラップトップを手に入れたら、リポジトリをチェックアウトしてゲームをビルドできました。他の場所からアセットをコピーする必要はありませんでした。つまり、サードパーティのライブラリ、アセット、ソース管理をリポジトリに保存します。


7

Gitは非テキストファイルには適していません。大きなファイル拡張子(非標準、GUIでサポートされていないことが多い)や特別なコマンド(実行するにはgitの第一人者である必要があります)を使用しない限り、gitリポジトリのクローンを作成するには、ファイルのすべての履歴バージョンをダウンロードする必要があります。同じことがほとんどのDVCSシステムに当てはまります。テクスチャ、モデル、またはオーディオクリップの場合、これは非常に大きなファイルの多数のコピーをプルすることを意味します。1 GBのアセットは200 GBの履歴リビジョンデータを簡単に作成できます。gitを使用すると、新しいリポジトリを複製するときにすべてをダウンロードし、最新のリビジョンを取得するときにすべての中間リビジョンをダウンロードできます。これは、生産の遅延を最小限に抑えることができない場合に、将来の大きなボトルネックになります。

Subversion、Perforceなどは、目的のリビジョン(通常は最新)のダウンロードのみを必要とするため、アセットに適しています。アセットにのみ使用してコードにgitを使用するか、ソースにも使用できます。PERFORCEには、非常に不格好なDVCSのように機能するいくつかの機能があり、私の経験ではSVN機能(はるかに複雑ですが)よりも優れていますが、コストにより、Subversionを使用する可能性が高くなります。

ほとんどのコンテンツの専門家はDVCSをほとんど必要としませんし、何人かはとにかくクラシックVCSの基本さえも問題を抱えています。gitを使用しないでください。またはMercurial、DARCSなど


良い点は、しかし、あなたはすべての履歴フェッチせずに複製することができstackoverflow.com/questions/11497457/...
アリ

1
@Ali:浅いクローンは問題を十分に解決せず(多くのコマンドを無効にし、ほとんどのGUIのデフォルトではありません)、CIサーバーなど以外のほとんどの場合、本質的に役に立たない。git-lfsのような新しいgitソリューションが登場し、コンテンツの多いチームをgitに乗せようとするときに概説した問題に対処しています。
Sean Middleditch 2016

git lfsは「大きなバイナリファイル」の問題を非常によく解決します。
Nepoxx 2018年

3

アーティストとしてプロジェクトに取り組んでいるときでも、何らかの形でバージョン管理が行われる傾向があり、ファイルの破損やバグが発生する傾向があります。ソース管理なしでは、アーティストはとにかくリビジョンの保存を行う傾向があり、これは大きな混乱です。

これの実例は、Blenderで作成されたオープンムービープロジェクト(Big Buck Bunny、Durianなど)です。

ゲームのアートパイプラインはほぼ同じですが、テクスチャ自体やモデル形式の変換など、ビッグファットデータからエンジン固有の形式への変換をアセット自体が行うためのビルドステップがある場合があります。

GitHubのような一部のツールは、優れた画像比較ツールなども提供しており、バイナリBLOBを比較するよりもはるかに優れています。

アセットリポジトリは非常に大きくなる可能性があるため、プロジェクトリポジトリのサブモジュールである個別のアセットリポジトリを保持することが私の好みです。たとえば、ソースを分岐するだけの場合は、ギガバイトのアセットをプルダウンする必要はありません。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.