Kontrola źródła do przechowywania wszystkiego projektu gry?

Czy zwykle zarządza się nie tylko kodem źródłowym, ale wszystkimi zasobami, teksturami, grafiką, plikami dokumentacji itp. W repozytorium git do kontroli wersji? Na przykład chcę odzyskać starą wersję tekstury. Jeśli jest to bardzo zła praktyka, jakich narzędzi używasz do kontroli wersji zasobów i innych rzeczy?

Powiedziałbym, że to bardzo dobra praktyka. Kontrolę źródła należy stosować dla źródła i zasobów. Możesz myśleć o tym jak o kopii zapasowej, chcesz mieć możliwość przywrócenia z kontroli źródła wszystkiego, co jest potrzebne do zbudowania gry.

I powiązany pytanie to o przechowywanie aktywów w repozytorium. Niektóre repozytoria działają lepiej niż inne do przechowywania dzieł sztuki. Umożliwiają „różnicowanie” sztuki i zobaczenie, co się zmieniło. Inni będą traktować zasoby jak dane binarne, więc musisz to sprawdzić, aby zobaczyć, co jest inne. Oznacza to również, że będziesz musiał przesłać cały zasób, gdy się zmieni, ponieważ repozytorium nie będzie mogło „wiedzieć” (analizować) tego, co zmieniło się między wersjami.

Przechowuję wszystko w repozytorium. Kiedy dostałem nowy laptop, mogłem sprawdzić moje repozytorium i zbudować grę, bez potrzeby kopiowania zasobów z dowolnego miejsca. Oznacza to, że przechowuję również biblioteki stron trzecich, zasoby i kontrolę źródła w moim repozytorium.

Git nie jest świetny do plików nietekstowych. Klonowanie repozytorium git wymaga pobrania wszystkich historycznych wersji pliku, chyba że używa się dużego rozszerzenia pliku (niestandardowego, często nieobsługiwanego przez GUI) lub specjalnych poleceń (wymaga bycia git guru). To samo dotyczy większości systemów DVCS. W przypadku tekstury, modelu lub klipu audio oznacza to pobranie wielu kopii bardzo dużego pliku. 1 GB zasobów może z łatwością stanowić 200 GB danych historycznych wersji, a git sprawia, że ​​pobierasz je wszystkie po sklonowaniu nowego repozytorium i pobierasz wszystkie wersje pośrednie, gdy pobierasz najnowsze. Staje się to ogromnym wąskim gardłem na drodze, kiedy można najmniej tolerować opóźnienia w produkcji.

Subversion, Perforce i tak dalej są lepszym wyborem dla zasobów, ponieważ wymagają tylko pobrania żądanej wersji (zwykle najnowszej). Możesz użyć ich tylko do zasobów i użyć git do kodu, a także użyć ich również do kodu źródłowego. Perforce ma pewne funkcje, które pozwalają mu działać jak bardzo niezgrabny DVCS, i jest lepszy niż funkcjonalność SVN (choć znacznie bardziej conplex) z mojego doświadczenia, jednak koszt oznacza, że ​​prawdopodobnie użyjesz Subversion.

Większość profesjonalistów zajmujących się treścią nie potrzebuje DVCS, a niektórzy mają problemy nawet z podstawami klasycznego VCS. Nie osiodłaj gitem. Lub Mercurial, DARCS itp.

Jest to dobra praktyka, nawet jako artysta, gdy pracujesz nad projektem, istnieje pewna forma kontroli wersji, zdarzają się uszkodzenia plików lub błędy, bez kontroli źródła artyści zwykle robią zapisy wersji, co jest ogromnym bałaganem.

Przykładem tego w prawdziwym świecie są projekty filmów otwartych wykonane przy użyciu Blendera (Big Buck Bunny, Durian itp.)

Proces tworzenia grafiki w grze jest mniej więcej taki sam, ale może istnieć krok kompilacji dla samych zasobów w celu dokonania konwersji dużych danych do formatu specyficznego dla silnika, takiego jak kompresja tekstur i konwersja formatu modelu.

Niektóre narzędzia, takie jak GitHub, oferują nawet ładne narzędzia do porównywania obrazów i podobne, co jest o wiele lepsze niż porównywanie binarnych obiektów blob.

Ponieważ repozytorium aktywów może być absolutnie ogromne, preferuję oddzielne repozytorium aktywów, które jest podmodułem w repozytorium projektu. Nie chcesz ściągać gigabajtów zasobów, gdy wszystko, czego potrzebujesz, to na przykład rozgałęzienie źródła.