Tworzenie gier może być piękne - wizualizacje przy użyciu Gource

Zastanawialiście się kiedyś, jak wygląda tworzenie gier komputerowych? Nie w sensie widoku bandy informatyków w trampkach siedzących w dusznych pomieszczeniach, ale w sensie tego jak powstaje sama konstrukcja gry? W przypadku robotników budujących dom sprawa jest prosta, ale jak zwizualizować powstawanie kodu? Otóż nie tylko jest to możliwe, ale na dodatek efekt końcowy bardzo ładnie wygląda.

Do wizualizacji procesu powstawania oprogramowania można użyć kilku różnych programów, ale moim ulubionym narzędziem jest Gource, przede wszystkim ze względu na to, że generuje ładne animacje, ale też dlatego, że bardzo czytelnie przedstawia strukturę tworzonego kodu. Pamiętacie jeszcze Lugaru? Jej odświeżona wersja HD była jedną z gier indie wchodzących w skład Humble Indie Bundle, promocyjnego pakietu, o którym w maju pisałem na Polygamii. Oto jak wyglądał proces powstawania Lugaru:

Wersja systemu kontroli... że co proszę? Zacznijmy od tego, że Gource tworzy wizualizację w oparciu o dane z systemu kontroli wersji (ang. version control system). Co to w ogóle jest takiego?

Jak głosi odpowiednie hasło na polskiej Wikipedii (jak zwykle żałośnie wręcz ubogie w porównaniu z wersją angielską), jest to oprogramowanie służące do śledzenia zmian w kodzie źródłowym oraz pomocy programistom w łączeniu i modyfikacji zmian dokonanych przez wiele osób w różnych momentach. Spróbujmy teraz wytłumaczyć to jakoś bardziej przystępnie.

Powiedzmy że w pięcioosobowym zespole piszemy jakiś program, na przykład grę. Rzadko kiedy zdarza się taki podział pracy, żeby każdy pracował nad czymś innym - zwłaszcza w większych projektach konieczność często zmusza by nad tym samym fragmentem programu pracowało więcej osób. Wyobraźmy sobie, że jeden plik pobrany z miejsca w którym trzymamy kod gry, na przykład dysku sieciowego, edytują jednocześnie dwie osoby - każda robi sobie lokalną kopię na swoim komputerze, wprowadza zmiany, a potem kopiuje plik z powrotem tam skąd go wzięła. Problem polega na tym, że przy takim podejściu zmiany pierwszej osoby zostaną stracone w momencie, kiedy druga z nich nadpisze plik.

System kontroli wersji służy właśnie do zapewnienia, żeby takie sytuacje się nie zdarzały. Teoretycznie użytkownicy mogliby za każdym razem używać jakiegoś narzędzia do porównywania plików (taką opcję udostępnia popularny Total Commander, służą też do niego dedykowane programy jak WinMerge) i jeden po drugim sprawdzać, czy nie pojawiły się w nich jakieś nowe zmiany. Byłoby to jednak dosyć czasochłonne i męczące - a oprogramowanie użytkowe powstaje właśnie po to, żeby czynności nudne i pracochłonne robiło się łatwiej i szybciej. System kontroli wersji sprawdza za programistę czy edytowane przez niego pliki nie zostały zmienione w centralnym miejscu, w którym zespół trzyma kod (nazywamy je repozytorium, ang. repository) i jeśli tak, to najpierw próbuje scalić te zmiany w sposób automatyczny (ang. merge), a jeśli nie daje sobie rady sam, pyta użytkownika. Niektóre programy działają nie w oparciu o centralne repozytorium, a inne w sposób rozproszony - jednak ogólna idea jest ta sama.

Dendrologia, czyli o pniach i gałęziach W zależności od potrzeb, systemy kontroli wersji mogą pełnić też wiele innych, bardziej skomplikowanych funkcji, jak to na przykład tworzenie gałęzi (ang. branch). Powiedzmy, że z jakichś względów potrzebujemy mieć dwie różne wersje tworzonego programu. Częściej zdarza się to w przypadku oprogramowania biznesowego - dwóch różnych klientów może chcieć bardzo podobnych programów, różniących się jednak trochę funkcjonalnością czy wyglądem - ale podobnie bywa też przy pisaniu gier. Przykładem może być tu Starcraft II: w wywiadzie dla strony Gamesutra Dustin Bowder z Blizzarda opisuje, jak zdecydowano się rozdzielić tryby single- i multiplayer po tym jak zmiany mające zbalansować tryb dla wielu graczy popsuły cztery misje z trybu dla jednego gracza.

W tekście wywiadu pada słowo trunk, czyli pień - tak nazywa się główną gałąź projektu, czyli najbardziej bazową wersję na której pracuje zespół. Często robi się tak, że aby nie narażać pnia na błędy będące efektami ubocznymi dodawania nowych elementów programu, większe zmiany przeprowadza się na gałęzi, a dopiero kiedy zostały one już przetestowane i zespół jest pewien, że nie wprowadzono przy okazji bugów, taką gałąź łączy się z powrotem z pniem.

Kwiatki i pszczółki Jeżeli przebrnęliście przez powyższe tłumaczenia, to uzbrojeni w tę wiedzę będziecie już w stanie spojrzeć na pokazane w tym artykule animacje z nowej perspektywy. Za drugi przykład posłuży nam Bee Spelled, prosta gra na iPhone'a:

Jeśli zaś chcielibyście zobaczyć wizualizację powstawania czegoś bardziej skomplikowanego, to na zakończenie polecę animację przedstawiającą prace nad nową wersją Blendera, darmowego narzędzia do tworzenia grafiki trójwymiarowej. Wprawdzie nie pokazuje ona produkcji gry, ale niestety wielkie firmy z branży gier nie udostępniają tego rodzaju danych, a ta animacja jako ilustracja skali dużego projektu robi wrażenie - widok programistów uwijających się jak mrówki przy dynamicznej strukturze kodu jest naprawdę niesamowity.