資産管理、データベース、またはバージョン管理システム？

ゲームのアセット（メッシュ、テクスチャ、サウンド、ビデオ）の開発中に、それらを管理しますか？

1. それらをバージョン管理システム内のソースコードと一緒に保管しますか？（perforce、gitなど）
2. または、中央のバックアップされたアセット専用のデータベースを持ち、編集者が常に気に入って作業できるようにしますか？（PostgreSQL、MySQLなど）
3. その他？

それぞれの長所と短所は何ですか、なぜ他の人よりもそれを選択する必要がありますか？

私たちの多くにとって-特に小さなゲームで作業している-あなたは絶対にあなたのソースと同じリポジトリにアセットを持っている必要があります。

アセットが別のリポジトリに属しているという提案は、非常に大きなアセットのセット、または明確に定義されたエンジン/データ境界がある場合にやや大きなアセットのセットに対してのみ意味があります。特定の技術的な理由がない限り、それは悪いアドバイスです！

バージョン管理をしたい 動作さ。リビジョンを巻き戻したり早送りしたり、リビジョンを分岐およびマージしたりしながら、ゲームを機能させたいと考えています。そして、コードとアセットは互いに依存します。

たとえば、コードがシェーダーにパラメーターを設定できることを期待し、そのシェーダーがそこにあるテクスチャに依存する場合があります。または、レベルのデータ形式は、ゲームコードの特定のバージョンに依存する場合があります。

それはほぼ間違いなく面倒になります。そして、あなたはそれをきちんと維持しようとするよりもやるべきことがあります。

さて、マイク・ワーグナーがコメントしたように（この答えについて）-バージョン管理下にあるアセットのすべての「進行中」バージョンを必要としないか、必要としません！コードで使用されているように、最終バージョン/作業バージョンだけで十分です。多くの場合、これはツールからエクスポートするものです。

（アセットの進行中のバージョンをバージョン管理したい場合でも-それは問題ありません。別のリポジトリに適しています。個人的には、適切なフォルダ構成と適切なバックアップシステムで十分です。）

とはいえ、バージョン管理下にある「進行中の」アセットをそのまま保持するオプションがあると便利な場合があります。通常、これには、「エクスポート」ステップを処理できるコンテンツパイプラインが含まれます。たとえば、マルチレイヤーイメージを単一のテクスチャに平坦化することです。

バージョン管理システム。

独自のアプローチを使用すると、バージョニングシステムを効果的にローリングすることになります。そのため、既に長年の設計/コード/テストサイクルを経ている既製のものを使用する方が適切です。

アセットをソースとは別のリポジトリに保存し、チェックアウト/同期時間を最小限に抑え、保持する履歴の量を簡単に決定できるようにします（ディスク領域は安価ですが、可能な限りすべてを保持します。個々のテクスチャはドンプロジェクトの存続期間中はそれほど変化しません）。

XMLファイルをバイナリとしてマークし、マージツールはネストされたマークアップのマージが非常に悪い傾向があり、ツールは競合がないと判断した場合、壊れたマークアップを見つけることはできません。

可能な場合は、コミットごとに構文チェックまたはアセットビルドを手配し、失敗した場合はコミットした人に返信するメールでコミットを拒否します。これにより、チームの時間を大幅に節約できます。

サイズの面で余裕がある場合は、1つのリポジトリ内のすべて。1 TB近くのSubversionリポジトリについて聞いたことがあります。現在、400 GBを少し下回っています。

また、アーティストは、概念の30の大まかなアウトラインを含むすべてをチェックインします。「ソースアセット」と「エクスポート済み」に別々のフォルダツリーを使用します-アセットビルドスクリプトに入るフォルダツリー。明日バスにアーティストが襲われた場合、リポジトリを閲覧するだけで、誰かが自分のアセットで作業を続けられるようにする必要があります（個人のマシンでは考古学はありません）。かつて、ゲームが2Dであり、スプライトが複雑なアニメーションMaxシーンから事前レンダリングされていたとき、RTSゲームで大量のユニットを出荷する必要がありました。ただし、照明とアンチエイリアス設定がわずかに異なる再レンダリングの問題でした。元のアーティストが終了し、元のMaxシーンがなかったためです。ドン'