Gamedev część druga

Jak często spotykamy się z zagadnieniem game devu w życiu codziennym? Prawdopodobnie wielu z nas świetnie bawi się przy grach komputerowych i to częściej niż raz na tydzień. Dla niektórych ludzi jest to integralna część życia, ale tylko nieliczni wiedzą jak wygląda "dzień świstaka" twórców gier komputerowych. Chciałbym przybliżyć ten proces czytelnikom Poltera na przykładach amatorskich projektów, które wskazują pewne praktyki stosowane podczas produkcji. Artykuł powstał dzięki uprzejmości i pomocy zespołu SystemSzok. Zapraszam do lektury.




Jak wygląda przeciętny dzień developera gier? Na pewno od czasu do czasu, w ramach pracy, pobawi się własnym projektem, ale przede wszystkim musi go najpierw stworzyć, a więc: wymodelować trójwymiarowe modele, zaprogramować zachowanie obiektów, dodać możliwość interakcji, przetestować czy wszystko działa poprawnie. A to dopiero wierzchołek góry lodowej. W każdym razie, pracy jest zdecydowanie za dużo, aby to wszystko zrobić naraz. Przeciętny dzień twórcy sprowadza się do wykonania pojedynczego, drobnego elementu gry - przykładowo stworzenie modelu przedstawiającego broń palną używaną przez bohatera, albo zaprogramowanie w grze możliwości korzystania z takiej zabawki.

Pozostaje pytanie: co dzieje się z danym elementem gry po jego wykonaniu? Jeśli jest się jedyną osobą tworzącą projekt, to nie ma problemu: developer jest wtedy zarówno sterem i okrętem:

"Jeżeli dodany element u mnie działa, to znaczy, że automatycznie zadziała u graczy. Bo tylko ja modyfikuję grę, tylko ja jeden mogę ją popsuć . W każdym razie, u mnie przecież działa."

Jednak w przypadku rozproszonego zespołu trzeba naszą pracę w jakiś sposób przetransmitować do pozostałych osób. W teorii wydaje się to przejrzyste i logiczne, w rzeczywistości jednak sprawa ta nie jest aż tak banalna.




Dlaczego należy często udostępniać swoją część ciężkiej harówy innym osobom współpracującym nad grą? Przecież można by w spokoju popracować kilka tygodni nad innymi elementami gry, a dopiero później zbiorczo takie poprawki podesłać reszcie zespołu. Można?

Można, ale jest to nieopłacalne. A to dlatego, że koszt naprawy kolizji i błędów jest wprost proporcjonalny do momentu ich wykrycia. Przykładowo: jeśli zdarzy się sytuacja, że dwie osoby naraz zajęły się stworzeniem zestawu dziesięciu broni palnych w grze, to o wiele mniej strat nastąpi, jeśli osoby te dowiedzą się o kolizji na etapie produkowania pierwszej pukawki, aniżeli po wykonaniu dwóch kompletnych zestawów po dziesięć sztuk. W tym pierwszym przypadku zostało zmarnowane dziesięć razy mniej czasu. W tym drugim trzeba by wyrzucić cały zestaw do kosza jako niepotrzebny. A to wystarczająco zaboli autora, aby go zdemotywować do dalszej pracy nad projektem, co ma dość istotne znaczenie w kontekście projektów darmowych. Inna sprawa, że takie kolizje nie mają prawa występować w dobrze zorganizowanym projekcie (co będzie poruszone w innym artykule). Ale jeśli już się zdarzą, to dzięki szybkiej komunikacji (np. codziennej) z innymi członkami zespołu tracimy o wiele mniej niż przy rzadszym porozumiewaniu się (np. raz w miesiącu).

To samo tyczy się błędów w projekcie. Bugi w publikowanych wersjach będą negatywnie nastawiać graczy do produkcji. Błędy generowane w trakcie tworzenia projektu utrudniają pracę zespołu, w efekcie implikują opóźnienia w całym procesie i frustrację twórców. W jaki sposób natychmiastowa synchronizacja dokonywanych zmian wewnątrz ekipy może mieć wpływ na ilość błędów? Przecież przekazując wadliwe elementy projektu innym osobom nie spowodujemy, że te wady same z siebie się naprawią. Zgoda. Ale w przypadku wytwarzania oprogramowania (w tym gier) kluczem do rozwiązywania problemów jest wczesne ich wykrycie.

Człowiek pamięta dokładnie czym zajmował się wczoraj, pamięta mniej więcej czym zajmował się tydzień temu. Ale nie pamięta już, co zrobił miesiąc temu na tyle dokładnie, żeby szybko skojarzyć co powoduje dany problem i to poprawić. Dodatkowo błędy kumulują się. Im więcej "bugów" naraz, tym trudniej jest wyśledzić i usuwać poszczególne. Jest to częściowo spowodowane przez nawarstwianie się niewłaściwych zachowań, co utrudniania skupienie się na pojedynczym problemie, ale także ma podłoże w psychologii - ludzie mają o wiele mniej energii do walki z problemami, jeśli widzą ich naraz za dużo. Dodatkowo, w przypadku produkcji dużych systemów jeden człowiek nie jest w stanie ogarnąć całości. Wobec tego może być nieświadomy faktu, że spowodował błąd w jakiejś zupełnie innej części projektu.

A oto przykład. Grafik, widząc nieestetyczną reprezentację graficzną danego potwora, może postanowić ją poprawić. Załóżmy, że zmienia lekko proporcje, trochę powiększa, trochę wygina. Niby nic wielkiego, ot drobnostka jakich wiele. Taka poprawka może jednak spowodować niepoprawne działanie aplikacji w nieoczekiwanych rejonach. Scenariusz gry wymaga, aby podczas przechodzenia pewnej misji do głównej komnaty został teleportowany egzemplarz tego potwora. Tylko, że scenarzysta przygotowywał punkt teleportacji biorąc pod uwagę poprzedni rozmiar, przez co nowa wersja bestii, owszem teleportuje się do komnaty, ale jest „wmurowana” w podłogę i potwór zamiast zaatakować zaskoczonego gracza, stoi w miejscu nie mogąc się ruszyć z powodu wykrycia przez moduł fizyki niepoprawnych kolizji z posadzką. Oczywiście jest to błędne zachowanie gry, jednak grafik nie wie (i nie ma prawa wiedzieć, bo skąd?), że jego niewinna poprawka powoduje skazę w całkowicie innym miejscu produktu.

Dlatego warto jak najszybciej przekazywać dodawane elementy gry innym osobom, bo one mogą podczas swojej pracy wcześniej wykryć błędne zachowania. I to pozwala na minimalizowanie kosztu pozbywania się kolizji. Tyle teorii, a jak z praktyką?




W praktyce pierwsze o co trzeba zadbać to automatyczny proces budowy projektu. Zasadniczo, posiadając źródła gry (temat czym są dokładnie źródła i jak je udostępniać zostanie poruszony w innym artykule. Na potrzeby tej części devbloga można myśleć o źródłach projektu, jak o zbiorze plików reprezentujących obiekty w grze, ich zachowanie i możliwe z nimi interakcje w „surowej” formie, zrozumiałe dla człowieka, ale niezrozumiałe dla komputera), dowolna osoba powinna móc zbudować działającą aplikację za pomocą jednego kliknięcia/jednej komendy. Jeśli się o to nie zadba, to wtedy zniechęca się ludzi do aktualizowania roboczych wersji gry. A to zmniejsza szybkość wykrywania kolizji, którą to właśnie próbujemy zmaksymalizować.

Dodatkowo, w przypadku darmowych projektów należy wziąć pod uwagę wysoką rotację wśród ludzi współtworzących program. Z reguły większość osób angażujących się w tego typu projekty ma niskie doświadczenie i słomiany zapał. Zanim zdążą wyprodukować coś użytecznego, często rezygnują ze współpracy. Takie osoby uczestniczą zwykle na okres kilku tygodni, w każdym razie nie dłużej niż miesiąc. Dlatego warto posiadać prosty i sprawny proces budowy gry od zera, po to, by takie osoby, zamiast tracić czas na wdrażanie się w projekt, od razu dodawały do niego kolejne elementy.

(Po informacje ile może trwać sama walka z konfiguracją środowiska deweloperskiego odsyłam do Dodatku A umieszczonego pod artykułem).

Sam proces zamiany źródeł w gotową do dystrybucji grę może być skomplikowanym etapem wymagającym kompilacji kodu źródłowego, przetwarzania i przesyłania danych, przenoszenia plików, pakowania, a wszystko to jeszcze uzależnione jest od wersji kompilatora i platformy docelowej. Mimo to, większość tych zadań można całkowicie zautomatyzować - niech odpowiedni skrypt z pomocą komputera zrobi to za nas. I tak właśnie się robi - wymaganie od ludzi wpisywania dziwnych komend lub "przeklikiwania" się przez okienka dialogowe jest marnowaniem czasu i wylęgarnią pomyłek.




W poprzednich paragrafach zachwalaliśmy zalety szybkiego wprowadzania zmian oraz automatyzacji procesu budowy gry. Obie te praktyki usprawniają także komunikację wewnątrz zespołu, gdyż każdy widzi dokładnie jaki jest aktualny stan projektu, czy się "buduje" i czy działa poprawnie. Ale co z ludźmi spoza zespołu, albo z osobami, które do wykonania swojej pracy nie potrzebują i nie chcą budować gry ze źródeł (np. testerami)? Takie persony, aby obejrzeć aktualny stan projektu musiałyby poprosić kogoś kompetentnego o zbudowanie aplikacji, a jest to niepotrzebna strata czasu, której warto uniknąć. Pytanie tylko jak?

Rozwiązanie jest dość proste. Z procesu automatycznej budowy gry można wykluczyć zbędne ogniwo, tj. człowieka. Idealnym rozwiązaniem jest użyć maszyn - niech komputery monitorują zmiany, niech pobierają poprawki i niech same próbują zbudować aktualną wersję programu, a w przypadku porażki niech wysyłają e-maila twórcom z dokładną informacją, co się nie powiodło. Umożliwia to twórcom efektywniejszą pracę nad projektem.

Taki proces całkowicie automatycznej budowy aplikacji jest fachowo nazywany ciągłą integracją. Pozwala on m.in. na szybsze wykrywanie dwóch najważniejszych (a zarazem uciążliwych) problemów przy zdalnej produkcji oprogramowania. Pierwszy dotyczy projektów rozwijanych na wiele platform (np. na Windows i Linux). Rzadko który amatorski programista ma pod ręką wszystkie docelowe systemy operacyjne wspierane przez grę. Zwykle pracuje tylko na jednym i nie ma możliwości przetestować, czy jego kod kompiluje się poprawnie w innym środowisku. Dzięki serwerom ciągłej integracji ów programista ma możliwość dowiedzieć się o spowodowanych błędach zanim odejdzie od komputera, zmuszając tym samym pozostałych członków zespołu do naprawienia jego błędów (co do przyjemnych nie należy i znacznie opóźnia rozwój gry).

Drugi problem jest popularniejszy i dotyczy nie tylko programistów. Zdarza się często, że wraz z naszą poprawką zapominamy wgrać kilku wymaganych, ale niewinnie wyglądających plików. I mimo że wydaje się nam, że wszystko jest w porządku (syndrom "U mnie działa!"), to na innym komputerze nie da się zbudować i uruchomić gry z powodu braku zasobów. Oczywiście takie braki uniemożliwiają rozwijanie i testowanie aplikacji, zaś system do ciągłej integracji jest w stanie zgłosić taki problem w ciągu kilku minut, pozwalając naprawić pomyłkę zanim ktokolwiek z pozostałych osób się w ogóle zorientuje, że coś jest nie tak.




Jedną z zalet posiadania systemu ciągłej integracji jest możliwość tworzenia tzw. migawek gry. Codziennie specjalnie oddelegowany do tego serwer może pobierać aktualne źródła projektu, budować i udostępniać działającą wersję aplikacji, np. na stronie internetowej. W ten sposób twórcy mogą skupić się na właściwym rozwijaniu projektu, a wszelkie zainteresowane osoby otrzymują swobodny dostęp do aktualnej wersji gry bez konieczności zgłębiania procesu budowy.

Technika ta ułatwia także naprawianie błędów. Sprawdzając migawki utworzone na przestrzeni ostatnich miesięcy można dowiedzieć się, którego dokładnie dnia nastąpiło wprowadzenie niepoprawnego zachowania do gry. Czasami ta wiedza pozwala wyśledzić przyczynę problemu i rozwiązać kolizję. Jednakże udostępnianie kompletu takich "punktów" z całego okresu produkcji projektu może sprawiać problem. W przypadku Wielkiego Mistrza na dzień dzisiejszy (ponad rok produkcji), migawki zajmują łącznie 12,2 GB przestrzeni dyskowej.

Sam proces udostępniania materiału jest wartościowy ponieważ pozwala graczom testować nowe funkcjonalności szybciej i częściej, co z kolei przekłada się na ilość i szybkość otrzymywania sugestii i opinii użytkowników. Dzięki temu twórcy lepiej wiedzą co jest aktualnie niezbędne w grze, a co niepotrzebne, albo wręcz niewskazane. Szybsze cykle publikacji zmniejszają bariery pomiędzy graczami a twórcami. Jeśli ludzie widzą, że ich uwagi są traktowane serio, to bardziej angażują się w projekt - a to jeden z kluczy do stworzenia udanej aplikacji.




Dużym wyzwaniem dla amatorskiego zespołu jest zorganizowanie i utrzymywanie fizycznych maszyn w stanie gotowości. Żeby maksymalizować zyski z ciągłej integracji potrzebne są serwery pracujące non-stop tak, aby szybko wykrywały problemy niezależnie od pory dnia. Im więcej docelowych platform i wspieranych środowisk developerskich, tym więcej potrzebnych jest osobnych komputerów. W przypadku projektu Wielki Mistrz wspierającego systemy operacyjne Windows i Linux potrzebne okazały się trzy fizyczne maszyny. Jedna do monitorowania i budowy gry pod Linuksem, druga, analogicznie, do obsługi wersji na Windowsa, a trzecia służąca za magazyn migawek. W innym darmowym projekcie, Warsztat Game, system ciągłej integracji został rozłożony tylko na dwóch osobnych komputerach.

Jak coś takiego zorganizować? Można wynająć serwery od firm hostingowych, ale niezbędne narzędzia do stworzenia kompletnego systemu integracji są dostępne tylko w droższych pakietach. Można szukać darmowych serwerów po "znajomych" i na uczelniach. Coraz częściej zdarza się, że komputerowi hobbyści stawiają domowe serwery i są skłonni udostępnić część jego zasobów. A i na uczelniach przy odrobinie znajomości można zorganizować trochę miejsca na jakiejś akademickiej maszynie.

Ale to nie wszystko. Podczas rozwijania projektu dochodzi spory koszt utrzymania systemów. W przypadku korzystania z cudzej uprzejmości, ma się nikły wpływ na częstotliwość usterek i zmian w konfiguracji serwerów. Jako że każda awaria systemu ciągłej integracji opóźnia tworzenie gry, wszelkie wyłączenia prądu, aktualizacje oprogramowania, administracyjne zmiany nazw katalogów i inne zdarzenia, niezależne od woli twórców, wymagają ich szybkiej reakcji, co na dłuższą metę jest męczące. W Wielkim Mistrzu system potrafi psuć się do kilku razy na miesiąc, wymagając kilkugodzinnych poprawek.




Przedstawione w tym artykule techniki dominują w świecie współczesnego tworzenia oprogramowania. Rzadko które projekty informatyczne (a do takich należy zaliczyć także gry) obywają się bez nich. Projekty korzystające z ciągłej integracji mają tendencję do posiadania mniejszej ilości błędów, zarówno w wersji finalnej jak i podczas procesu ewaluacji. A jak wiemy to właśnie "bugi" najczęściej spędzają deweloperom sen z powiek, opóźniając produkcję i narażając budżet na dodatkowe koszty. Dobry projekt to przede wszystkim projekt rozsądnie zarządzany, z solidnym harmonogramem i elastycznym systemem nadzoru. W kolejnych artykułach jeszcze co najmniej raz nawiążemy do tego aspektu produkcji.




W dodatku został zilustrowany proces budowy gry ze źródeł na przykładzie amatorskiego projektu: Wielki Mistrz. Czytelnik będzie mógł z jego pomocą sam, w oparciu o system Windows, zbudować działającą aplikację i poczuć się jak prawdziwy programista gier komputerowych. Przy okazji będzie mógł na własnej skórze przekonać się, ile trwa samo przygotowanie środowiska developerskiego. Zatem do dzieła!

Pierwsze, co trzeba zrobić, to zaopatrzyć się w kompilator, dzięki któremu możliwa będzie budowa plików wykonywalnych gry. W tym projekcie korzystamy z oprogramowania Visual Studio 2008 C++ udostępnianego przez Microsoft nieodpłatnie do celów niekomercyjnych. Pobieramy zatem ze strony producenta odpowiedni instalator i pozwalamy oprogramowaniu zainstalować się w domyślnej konfiguracji. Chwilę to potrwa i będzie wymagać ponownego uruchomienia komputera.



Następnie należy pobrać źródła (mirror1, mirror2) samej gry i rozpakować je na dysku twardym.



Aby zbudować grę, należy w rozpakowanych źródłach odnaleźć plik build/msvc/9/WielkiMistrz.sln i dwukrotnie kliknąć na jego nazwę. Uruchomi się Visual Studio, w którym wybieramy tryb RELEASE: Następnie klikamy na zielony przycisk Buduj i uruchom, zgadzając się na budowę projektów. Proces kompilacji chwilę potrwa, można w tym czasie porobić coś innego. Po parędziesięciu minutach gra powinna się ostatecznie zbudować i uruchomić.

Dopiero od tego momentu programista gier zaczyna właściwą pracę... Zaloguj się, aby wyłączyć tę reklamę