Git do tworzenia gier

Niezwykle przyjemny Git do tworzenia gier Git do tworzenia gier 14 marca 2012 Przez lata używałem kilku różnych systemów kontroli wersji w produkcji filmowej i gier: CVS , Perforce , a nawet kilku narzędzi wewnętrznych. Zawsze wydawały mi się niezgrabnym, ale koniecznym złem – nieocenionym przy śledzeniu pracy nad dużym projektem, lecz jednocześnie ciągłym źródłem zamieszania, wąskich gardeł i sztywności produkcyjnej.

Git pojawił się na moim radarze około sześciu miesięcy temu. Wyglądał na niesamowicie potężny i elastyczny. Deweloperzy z Massively Fun już korzystali z niego przy rozwoju kodu, gdy dołączyłem do zespołu. Byłem ciekaw, czy uda nam się приспособić go również do produkcji artystycznej.

Ten wpis opowiada historię tego, co się wydarzyło. Tło: Czym jest Git? Git to rozproszony system kontroli wersji . Prawie każdy w branży gier zna już co najmniej jeden inny system kontroli wersji, taki jak Subversion lub Perforce .

Podobnie jak te inne systemy, Git pozwala nam śledzić wiele różnych wersji wszystkich plików wchodzących w skład projektu. Jednak Subversion i Perforce to systemy scentralizowane – wszystkie pliki są wysyłane do lub pobierane z repozytorium znajdującego się na centralnym serwerze. Git działa inaczej.

Nie zależy od centralnego serwera. Każdy użytkownik otrzymuje pełną kopię całego repozytorium wraz z całą jego historią i rewizjami. Taka architektura niesie ze sobą szereg ważnych konsekwencji , z których większość jest pozytywna.

Jednak tym, co w moich oczach najbardziej wyróżnia Gita, jest to, jak bardzo upraszcza operacje tworzenia gałęzi i scalania. Możesz utworzyć gałąź do pracy nad eksperymentalnym pomysłem, inną do naprawy unrelated problemu, a jeszcze kolejną dla nowej funkcji. Możesz szybko przełączać się między tymi różnymi gałęziami i scalać je z powrotem w razie potrzeby. To niezwykle przydatna funkcja.

Powiązane: Unity Asset Store — Gotowe grafiki, narzędzia i szablony, które można wrzucić bezpośrednio do projektu Unity.

Przeszkody Mimo wielu zalet, standardowy Git ma dwie oczywiste wady w kontekście produkcji artystycznej: Nie jest przyjazny dla artystów. Domyślnym interfejsem Gita jest wiersz poleceń.

Trzeba nauczyć się wielu komend i opcji, a także zrozumieć koncepcje, które wystarczająco różnią się od innych systemów kontroli wersji, by wprowadzać zamieszanie. Dokumentacja jest obfita, ale często trudna do zrozumienia. Wszystko to składa się na pakiet mało przystępny i nieco odstraszający. Nie został zaprojektowany do zarządzania dużymi plikami binarnymi, jakie tworzą artyści.

Fakt, że każde lokalne repozytorium zawiera całą historię i rewizje, oznacza, że dużo szybko zmieniających się prac graficznych może błyskawicznie pochłonąć ogromną ilość miejsca na dysku. Znaleźliśmy rozwiązania obu tych problemów. Interfejs ma znaczenie Istnieje kilka dobrych graficznych interfejsów do Gita.

Nasz wybór: Udemy Game Development Courses — Kursy na żądanie obejmujące Unity, Unreal, C++, C# i programowanie shaderów.

Artyści nadal muszą zrozumieć podstawowe koncepcje Gita, ale dobrze zaprojektowany front-end znacznie ułatwia naukę i korzystanie z niego. W naszym środowisku opartym na Macach świetnie sprawdził się SourceTree od Atlassian: jest potężny, intuicyjny i darmowy (na razie) – co stanowi istotny czynnik dla dynamicznego startupu. Zespół SourceTree odpowiadał również niezwłocznie (< 12 godzin) na nasze pytania dotyczące wsparcia przesłane przez Twittera.

Sprytne rozszerzenie Gita Git-media rozwiązuje niedostatki Gita w zakresie dużych plików binarnych. Jest to rozszerzenie Gita, które pozwala przechowywać pliki poza samym Gitem.

Git nadal śledzi wersje plików; jedynie zawartość plików przechowuje gdzieś poza repozytorium. Planowaliśmy przechowywać nasze duże pliki binarne w chmurze Amazon S3. Nie tak szybko Używanie SourceTree razem z Git-media wiąże się jednak z pewnym haczykiem: transfer plików między naszymi repozytoriami a Amazon S3 wymaga wykonania polecenia powłoki, tj. $ git media sync Przepływ pracy, który zmusza artystów do opuszczenia względnego komfortu aplikacji graficznej i wpisywania poleceń powłoki, nie jest przyjazny dla artystów.

SourceTree oferuje możliwość uruchomienia tego polecenia jako akcji niestandardowej, ale to nie wystarczyło. Artyści nadal musieliby pamiętać o wykonywaniu go we właściwych momentach.

Wcześniej czy później ktoś by o tym zapomniał, a ktoś inny straciłby cenny czas, próbując ustalić, co poszło nie tak, i naprawiając problem. Jak mogliśmy sprawić, by SourceTree i git-media współpracowały ze sobą harmonijnie? Git Wrap Napisaliśmy uniwersalny skrypt opakowujący, który opcjonalnie wykonuje inne polecenia przed i/lub po samym poleceniu git. Skonfigurowaliśmy go tak, aby automatycznie wywoływał ‘git media sync’ przed lub po poleceniach interagujących ze zdalnym repozytorium, stosownie do sytuacji.

Skonfigurowaliśmy SourceTree tak, aby uruchamiał ten opakowacz zamiast standardowego Gita. Kod źródłowy opakowacza jest dostępny tutaj na Github . Przygoda trwa Chciałbym móc powiedzieć, że to był koniec tej historii, że SourceTree i git-media współpracowały bezproblemowo i wszyscy żyli długo i szczęśliwie.

Powiązane: Amazon: Game Dev Books & Gear — Książki o programowaniu gier, klawiatury mechaniczne, monitory i sprzęt komputerowy dla programistów.

Rzeczywiście działały, ale tylko do pewnego stopnia. Niestety, to nie wystarczyło. SourceTree zazwyczaj dobrze radzi sobie z podglądem plików obrazowych. Jest to kluczowe dla artystów podczas zatwierdzania lub scalania zmian w takich plikach.

Jednak użycie git-media zepsuło zdolność SourceTree do podglądu tych plików, ponieważ oznaczało to, że nie przechowujemy już obrazów w Gicie; przechowujemy jedynie informacje o ich wersjach. Nie znaleźliśmy akceptowalnego obejścia tego problemu; było to działanie blokujące.

W momencie pisania tego tekstu podejmujemy kolejną próbę, wykorzystując funkcję submodułów Gita. Przechowywanie zasobów artystycznych w submodule to kolejny sposób na minimalizację rozmiaru głównego repozytorium projektu. SourceTree dość dobrze rozumie i obsługuje submoduły, a jego zdolność do podglądu obrazów pozostaje nienaruszona. Submoduły mają pewne osobliwości, ale nic, co wyglądałoby na zbyt zakłócające przepływ pracy naszych artystów.

Jeśli robisz zakupy: Construct 3 — Oparty na przeglądarce, niewymagający kodu silnik HTML5, który eksportuje do Internetu, urządzeń mobilnych i komputerów stacjonarnych.

Obserwujcie to miejsce w poszukiwaniu aktualizacji; damy wam znać, jak sprawy się potoczą. komentarze do bloga obsługiwane przez Disqus