Zarządzanie zasobami, baza danych czy system kontroli wersji?

Czy podczas zarządzania zasobami gry (siatki, tekstury, dźwięki, filmy) zarządzasz nimi?

1. Trzymasz je razem z kodem źródłowym w systemie kontroli wersji? (perforce, git itp.)
2. Czy posiadanie centralnej kopii zapasowej bazy danych poświęconej zasobom i spodobanie się edytorom? (PostgreSQL, MySQL itp.)
3. Inny?

Jakie są zalety i wady każdego z nich i dlaczego należy go wybrać spośród innych?

Dla wielu z nas - zwłaszcza pracujących na mniejszych grach - absolutnie powinieneś mieć zasoby w tym samym repozytorium, co twoje źródło .

Sugestia, że ​​zasoby należą do oddzielnego repozytorium, ma sens tylko w przypadku bardzo dużych zestawów zasobów lub nieco dużych zestawów zasobów, gdy istnieje jasno określona granica silnika / danych. Chyba że istnieje konkretny powód techniczny - to zła rada!

Chcesz, aby kontrola wersji zachowywała się jak kontrola wersji . Chcesz mieć możliwość przewijania do tyłu i przewijania do przodu oraz rozgałęziania i scalania wersji, a jednocześnie nadal działać. Twój kod i zasoby będą od siebie zależeć.

Na przykład: Twój kod może oczekiwać, że będzie mógł ustawić parametr modułu cieniującego, a ten moduł cieniujący może zależeć od obecności tekstury. A może format danych twoich poziomów może zależeć od konkretnej wersji twojego kodu gry.

Niemal na pewno będzie bałagan. I masz lepsze rzeczy do roboty niż starać się utrzymać porządek.

Teraz, jak skomentował Mike Wagner ( do tej odpowiedzi ) - nie chcesz ani nie potrzebujesz wszystkich „w toku” wersji swoich zasobów pod kontrolą wersji! Zrobi to tylko wersja ostateczna / robocza używana w kodzie - często to właśnie eksportujesz z narzędzia.

(Chociaż jeśli chcesz kontrolować wersje bieżących wersji zasobów - to dobrze. I dobrze nadaje się do osobnego repozytorium. Osobiście uważam, że dobra organizacja folderów i odpowiedni system tworzenia kopii zapasowych wystarczą).

To powiedziawszy - czasem miło jest mieć możliwość po prostu trzymać zasoby „w toku” pod kontrolą wersji. Zazwyczaj wiąże się to z posiadaniem potoku treści, który może obsłużyć wszystkie kroki „eksportowania” - na przykład: spłaszczenie obrazu wielowarstwowego do pojedynczej tekstury.

System kontroli wersji.

Dzięki podejściu typu „roll-your-own” efektywnie skończyłbyś się systemem wersjonowania, więc lepiej skorzystać z gotowego systemu, który ma już lata projektowania / kodu / testów.

Przechowuj zasoby w oddzielnym repozytorium od źródła, aby ułatwić utrzymanie czasów kasowania / synchronizacji na minimalnym poziomie i podejmowanie różnych decyzji dotyczących ilości przechowywanej historii (chociaż miejsce na dysku jest tanie, zachowaj je, gdy tylko jest to możliwe). zmieniają to tak bardzo przez cały czas trwania projektu).

Oznacz pliki XML jako binarne, narzędzia do scalania zwykle źle wpływają na łączenie zagnieżdżonych znaczników, a artyści prawdopodobnie nie zauważą zepsutych znaczników, jeśli narzędzie myśli, że nie ma konfliktów.

Jeśli możesz, zorganizuj sprawdzanie składni, a nawet kompilację zasobów dla każdego zatwierdzenia i odrzuć zatwierdzenie, wysyłając wiadomość e-mail do osoby zatwierdzającej, jeśli się nie powiedzie; pozwoli to zaoszczędzić sporo czasu zespołowego.

Wszystko w jednym repozytorium, jeśli możesz sobie na to pozwolić pod względem wielkości. Słyszałem o repozytoriach Subversion w okolicach 1 TB. Obecnie jesteśmy nieco poniżej 400 GB.

Ponadto artyści dużo sprawdzają wszystko, w tym 30 wstępnych zarysów koncepcji; używamy osobnych drzew folderów dla „zasobów źródłowych” i „wyeksportowanych” - tych, które wchodzą do skryptu budowania zasobów. Jeśli jutro autobus trafi twojego artysty, musisz mieć możliwość, aby ktoś kontynuował pracę nad jego aktywami następnego dnia, tylko przeglądając repozytorium (bez archeologii na jego osobistej maszynie). Dawno, dawno temu, gdy gry były 2D, a sprite'y były wstępnie renderowane ze złożonych animowanych scen Maxa, musieliśmy wysłać kilka jednostek w grze RTS o nieco gównianym i bardzo niespójnym wyglądzie (w porównaniu z resztą jednostek), nawet choć była to kwestia ponownego renderowania z nieco innymi ustawieniami oświetlenia i antyaliasingu - ponieważ oryginalny artysta zrezygnował, a my nie mieliśmy jego oryginalnych scen Maxa. Don'