Varlık Yönetimi, veritabanı veya versiyonlama sistemi?

Oyunun varlıklarını geliştirirken, (kafesler, dokular, sesler, videolar) onları yönetiyor musunuz?

1. Onları versiyonlama sistemi içindeki kaynak kodla bir arada tutmak? (performans, git vb.)
2. Ya da merkezi bir yedekleme, varlıklara adanmış bir veri tabanına sahip olmak ve editörlerin her zaman çalışmasını sağlamak? (PostgreSQL, MySQL, vb…)
3. Diğer?

Her birinin avantaj ve dezavantajları nelerdir ve neden biri diğerine seçmeli?

Birçoğumuz için - özellikle daha küçük oyunlar üzerinde çalışıyoruz - kesinlikle kaynağınızla aynı depoda varlıklara sahip olmalısınız .

Varlıkların ayrı bir depoya ait olduğu önerisi, yalnızca çok büyük bir varlık kümesi için veya açıkça tanımlanmış bir motor / veri sınırı olduğunda bir miktar büyük varlık grubu için anlamlıdır. Belirli bir teknik sebep olmadığı sürece - bu kötü bir tavsiye!

Sürüm kontrolünüzün sürüm kontrolü gibi davranmasını istiyorsunuz . Geri sarmak, hızlı ileri sarmak ve revizyonları dallamak ve birleştirmek ve hala oyununuzu çalışır durumda tutmak istiyorsunuz. Ve kodunuz ve varlıklarınız birbirine bağlı olacaktır .

Örneğin: Kodunuz bir gölgelendirici üzerinde bir parametre ayarlamayı umabilir ve bu gölgelendirici orada bulunan bir dokuya bağlı olabilir. Belki de seviyelerinizin veri formatı oyun kodunuzun belirli bir versiyonuna bağlı olabilir.

Neredeyse kesinlikle dağınık olacak. Ve yapmayı denemekten ve düzenli tutmaktan daha iyi işleriniz var.

Şimdi, Mike Wagner'in dediği gibi ( bu cevap üzerine ) - varlıklarınızın sürüm kontrolü altındaki tüm "devam eden" sürümlerini istemiyor veya buna ihtiyacınız yok! Kodunuzda kullanıldığı gibi sadece son / çalışan sürüm bunu yapacak - genellikle bu araçtan dışa aktardığınız şeydir.

(Varlıkların devam eden sürümlerini denetlemek istiyorsanız - bu sorun değil. Ve ayrı bir depoya çok uygun. Kişisel olarak bu iyi klasör organizasyonunun ve uygun bir yedekleme sisteminin yeterli olduğunu buluyorum.)

Söyleniyor - bazen sürüm kontrolü altında "devam eden" varlıkları yapıştırma seçeneğine sahip olmak güzel. Bu genellikle sizin için herhangi bir 'dışa aktarma' adımını işleyebilecek bir içerik boru hattına sahip olmayı içerir - örneğin: çok katmanlı bir görüntüyü tek bir dokuya düzleştirmek.

Sürüm sistemi

Kendinize özel bir yaklaşımla, bir versiyonlama sistemini etkin bir şekilde kullanmaya başlayacaksınız, bu sayede yıllarca süren tasarım / kod / test döngüleri olan bir raftan geçmek daha iyi.

Çıkış / senkronizasyon zamanlarını minimumda tutmayı kolaylaştırmak ve ne kadar tarih tutacağınıza dair farklı kararlar almayı kolaylaştırmak için (disk alanı ucuz olsa da, mümkün olduğunda hepsini saklayın. bir projenin ömrü boyunca bu kadar değişmez).

XML dosyalarını ikili olarak işaretleyin, birleştirme araçları iç içe biçimlendirmeyi birleştirme konusunda çok kötü olma eğilimindedir ve araç çakışma olmadığını düşünürse sanatçıların bozuk biçimlendirmeyi görmesi beklenmez.

Yapabiliyorsanız, her taahhüt üzerine bir sözdizimi kontrolü veya hatta varlık oluşturmayı düzenleyin ve söz konusu işlemi başarısız olursa taahhüt eden kişiye bir e-posta ile reddedin; Bu, çok fazla takım zamanı kazandıracak.

Bir depodaki her şey, boyut olarak karşılayabiliyorsanız. 1 TB civarındaki Subversion depolarını duydum. Şu anda 400 GB'ın biraz altındayız.

Ayrıca, sanatçılar bir kavramın 30 kaba hatları da dahil olmak üzere her şeyi kontrol ediyor; "kaynak varlıklar" ve "dışa aktarılmış" dosyalar için ayrı ayrı ağaç ağaçları kullanıyoruz - varlık oluşturma komut dosyasına girenler. Eğer sanatçıya yarın bir otobüs çarptıysa, ertesi gün birisinin mal varlıkları üzerinde çalışmaya devam etmesini sağlamanız gerekir, yalnızca depoya bakarak (kişisel makinesinde arkeoloji olmaz). Bir zamanlar oyunların 2B olduğu ve hareketli oyunların karmaşık animasyonlu Max sahnelerinden çekildiği bir zamanlar, bir RTS oyununda bir sürü üniteyi biraz berbat ve çok tutarsız bir görünümle (ünitelerin geri kalanına karşı) gönderdik. Her ne kadar biraz farklı ışıklandırma ve antialiasing ayarlarıyla yeniden yaratma meselesiydi - çünkü orijinal sanatçı istifa etti ve orijinal Max sahneleri yoktu. Don'