[PL] Porozmawiajmy o tworzeniu gier – wywiad z Maciejem Siniło z CDP-Red – cz. 3

Spis Treści:
Wstęp
I. Ogólnie o branży GameDev w Polsce i za granicą, akcent Wiedzmina.
II. O społecznościaciach i nostalgii demoscenowej
III. Zawód – twórca gier komputerowych.
IV. Technologie wykorzystywane przy tworzeniu gierV. Słowniczek slangu branżowego oraz nietypowych zwrotów użytych w rozmowie.

{Poprzednia część: O społecznościach i nostalgii demoscenowej }

Zawód - twórca gier komputerowych

DB: Okay Maćku, przejdę bezpośrednio do Ciebie. Co trzeba umieć, aby zostać programistą gier komputerowych?

MS: Przede wszystkim trzeba być dobrym programistą. Ciężko mówić o konkretnych cechach, ale akurat to wymaganie jest konieczne. Idealnie, gdy mówimy tutaj o doświadczeniu praktycznym. Powinien doskonale znać swoje narzędzie, czyli najczęściej C++, i platformę. Nie dlatego nawet, żeby koniecznie używać tych najbardziej egzotycznych konstrukcji, ale głównie żeby wiedzieć czego unikać i z czym one się wiążą. Powinien mieć pojęcie o tym, co dzieje się "pod maską".
Przykładowo, nie wystarcza mi, że ktoś rozumie ogólną ideę funkcji wirtualnych, powinien wiedzieć jak one są zazwyczaj implementowane, z jakim narzutem mogą się wiązać na różnych platformach. Podstawy teoretyczne są bardzo istotne, ale niestety niewystarczające. Dlatego dużą wagę przykładamy do amatorskich projektów, choćby najmniejszych, ale świadczących o tym, że kandydat potrafi swoją wiedzę wykorzystać w praktyce. Jest pewien problem z absolwentami kierunków informatycznych, często operują oni na stosunkowo wysokim poziomie abstrakcji. Mają zaszufladkowane pewne książkowe rozwiązania i nie dostosowują ich do sytuacji. Przykładowo, jeżeli elementy kolekcji będą stosunkowo często usuwane - automatycznie stosują listę powiązaną. Nie uwzględniają dodatkowych informacji, jak choćby faktu, że elementów jest 5-10, więc wystarczy zwykła tablica, która zajmie mniej pamięci i będzie dużo przyjaźniejsza dla cache'a.
Jeżeli chodzi o cechy "luźniej" związane z programowaniem to na pewno (jak w każdym zawodzie) konieczna jest pasja i upór w dążeniu do celu. Często pierwsze 15 rozwiązań będzie do wyrzucenia, ale trzeba próbować po raz 16, być może od samego początku, być może atakować problem z zupełnie innej strony (to nie są liczby brane z sufitu, a doświadczenia sprzed 2-3 miesięcy). Trzeba pamiętać, że jesteśmy częścią zespołu. Nie wystarczy, że nasza działka jest super i gra ładnie wygląda, liczy się efekt końcowy. Najfajniejsze elementy to najczęściej owoce pracy małych, interdyscyplinarnych zespołów. Programista "ożywia" pomysły designerów i grafików, ale powinien robić to w ciągłym kontakcie z nimi.

DB: Czy w tej pracy więcej jest artystycznej kreatywności czy też jest też dużo ciężkiego programistycznego rzemiosła? (w końcu zaprojektowanie dobrze wyglądającej wody w Pixel Shader to trochę inne wyzwanie niż zaprojektowanie spójnej struktury w bazie danych).

MS: Dobre pytanie. W dużej mierze zależy to od specjalizacji, są działki bardziej „koderskie” jak system czy obsługa sieci. Są też bardziej artystyczne jak rendering, a szczególnie efekty specjalne. Podstawowy problem jest taki, że większość programistów ma dosyć umiarkowane talenty artystyczne. Skądś w końcu wziął się pobłażliwy termin „programmer's art". Cechy osobowościowe dobrego programisty zazwyczaj są sprzeczne z tymi przydatnymi grafikowi. Indolencja artystyczna koderów i matematyczna grafików to zresztą temat odwiecznych złośliwostek w każdej firmie z branży. Bardzo rzadko, ale zdarzają się osoby, którym udaje się łączyć te talenty, ludzie tacy są zazwyczaj na wagę złota. W zależności od "wychylenia" mamy wówczas bardzo dobrych artystów technicznych lub programistów renderingu/efektów specjalnych.
Sięgając po przykłady scenowe - taką osobą jest na przykład Unreal,czy Statix/Psychic Link.

(Rys. Unreal czy Statix to pseudonimy koderów demoscenowych z lat 90tych. Poniżej parę zrzutów ekranu z ich produkcji, tzw. dem. Obaj w latach 90tych reprezentowali bardzo znaną na całym świecie grupę demoscenową o nazwie Pulse.)
clip_image002 clip_image004
(video: nagrania dem grupy Pulse, Tribes to dzieło wspomnianego Unreala, Square to demo Statixa, czyli Alexa Evans’a aktualnie z firmy Lionhead Studios – twórcy Fable/Fable2)

MS: Może to już moje "chciejstwo", ale te cechy przebijają zresztą przez LBP, które niby jest platformówka 2.5D, ale równocześnie jest tam masa świetnych rozwiązań na granicy technologii i artu. Polecam też papier Statixa (Alexa Evansa) z Siggraph 2006, który jest świetnym przykładem błyskotliwego balansu na styku tych dwóch obszarów. Dla tych z nas, dla których natura nie była tak łaskawa pozostaje dostarczanie grafikom jak najlepszych narzędzi, które pozwolą im na realizację pomysłów. To jest m.in. siła Unreal Engine. Nie zestaw feature'ów, ale fakt, że daje duże pole do popisu artystom.
Zresztą, w każdym obszarze jest szansa na "wyżycie" się, implementowanie rzeczy, które do tej pory implementowane nie były, zmuszanie do działania w czasie rzeczywistym jakichś skomplikowanych systemów itd. To jedna z fajniejszych rzeczy w tym fachu -- póki coś wygląda ładnie i działa fajnie - nikogo nie obchodzi czy to jest w 100% poprawne czy w jakis sprytny sposób zafake'owane. Być może czasem zostanie to zauważone/docenione jedynie przez grupkę zapaleńców, ale satysfakcja pozostaje. Trzeba pamiętać, że programiści patrzą na pracę swoich kolegów po fachu nieco inaczej. Weźmy bieganie po hałdach śmieci w GTA. Zwykły gracz zauważy może że stopy ładnie dostosowują sie do podłoża i pobiegnie dalej. Koder pomyśli: "o, fajne IK" i będzie łaził po okolicy przez kolejną minutę. Nasz firmowy spec od renderingu - Adam Cichocki - kupił sobie Stalkera: Clear Sky głównie po to, żeby pooglądać efekty graficzne :).

DB: Czy to ciężka praca?

MS: Czasami cięższa, czasami lżejsza, zależy z czym porównywać :) Na pewno nie jest to praca od 9-tej do 17-tej. I nie chodzi tutaj nawet o osławiony crunch-time, bo przez większość czasu projektu pracujemy normalnie, ale po prostu o ciągłą konieczność bycia na czasie, doszkalania się. Technologia galopuje, ciągle pojawiają się nowe platformy, nowe rozwiązania, odbywają się konferencje, ukazują ciekawe papiery. Jeżeli ktoś chce nadążać musi poświęcić na to trochę wolnego czasu.
Specyfika zależy od firmy i tworzonych rozwiązań, ale na najwyższym poziomie dodatkowo dochodzi element niepewności. Większość wyzwań, przed którymi stajemy, to coś nowego, czego nigdy wcześniej nie robiliśmy, więc często nie do końca wiadomo jak się do nich zabrać. Bywa to stresujące, ale jednocześnie daje dużo satysfakcji, kiedy wreszcie problem udaje się rozwiązać.
Jeżeli ktoś umie oddzielać pracę od czasu wolnego, to jest mu łatwiej, ja jeszcze się tego nie nauczyłem, więc często "marnuję" popołudnia rozmyślając nad nieskończonym problemem. Nie jest to jednak coś niezwykłego, myślę, że norma w każdej dziedzinie związanej z technologią i wymagającej odrobiny kreatywności.

DB: To chyba akurat faktycznie swoista norma dla naszej branży :) Jak to wygląda z metodyką pracy w zespole. Czy takie metodyki jak Agile/CMMI/Scrum i tak dalej w jakikolwiek sposób mają swoje odzwierciedlenie przy projekcie, jakim jest gra czy raczej w swojej branży macie swoje własne najlepsze praktyki?

MS: Chcielibyśmy takie mieć. Generalnie nie odbiega to jakoś dramatycznie od innych typów projektów (na tyle, na ile mogę ocenić, nigdy nie robiłem niczego innego), choć jest może nieco większy opór przed co bardziej sformalizowanymi procesami. Gdy pojawia się jakaś nowa metodologia, ludzie próbują ją dostosować. Agile/Scrum też miały swoje 5 minut i bardzo silnych propagatorów (głownie High Moon Studios). Teraz fala powoli zaczyna opadać, ale wiele firm przejęło przynajmniej część praktyk. W CDPR część zespołów pracuje w SCRUMie (z tego co wiem, na razie rezultaty są zachęcające). W skali globalnej - poszukiwania idealnego procesu cały czas trwają, szczególnie, że skala projektów nieustannie rośnie, koszty idą w górę. Momentami zaczyna to przybierać dosyć zabawne form. Na Gamasutrze jest na przykład artykuł o próbie wprowadzania Kanban do GD. Ciekawe metodologie, które narodziła się w branży to tzw. Cerny method (od nazwiska propagatora) i Valve'owski Cabal, ale dotyczą one głownie strony designu/gameplaya.

DB: Programista gier komputerowych to szerokie pojęcie. Niektórym osobom kojarzy się głównie z umiejętnością programowania grafiki komputerowej. To oczywiście nieprawda. Możesz co nie co powiedzieć o różnych programistycznych specjalizacjach na przykładzie Wiedzmina?

MS: Wiedźmin może nie być najbardziej standardowym przykładem, bo mieliśmy względnie mały zespół, ale spróbujmy. Na samym początku podział był bardzo płynny i każdy robił, co trzeba było (dość powiedzieć, że sam zaczynałem, jako programista narzędzi, później programowałem rendering a skończyłem jako programista gameplayu/systemowy). Z czasem dział programistów rozbity został na 3 mniejsze pododdziały. Mieliśmy dział renderingu pod komendą Michała Iwanickiego, dział narzędzi dowodzony przez Maćka Czerwonkę i wreszcie programistów gameplaya/silnika, którymi miałem przyjemność kierować. Na jeszcze większym poziomie szczegółowości można wymienić takie działki jak: system dźwiękowy, interfejs użytkownika, sztuczna inteligencja, system, walka, questy, fizyka, skryptowanie (w naszym przypadku wiele z tych działek było łączonych), sieci, systemy buildów... Nowe tytuły wprowadzają coraz to nowe specjalizacje, ostatnio na Gamasutrze zamieszczono bardzo ciekawy wywiad z programistą z Ubisoft, który przez ponad rok zajmował się się tylko i wyłącznie realistyczną symulacją ognia w FarCry 2.

DB: Oj tak, mój powyższy przykład z wodą też pochodzi z Gamasutry. W Post-mortem do Bioshocka autorzy pochwalili się, że woda, którą tam widać, to 2 letni efekt pracy dedykowanego wakatu, gdzie programista tylko i wyłącznie skupiony był na efektach PS/VS związanych z wodą.
W każdym razie, czy łatwo przy tych wszystkich rolach i specyfice projektu wpaść w pułapkę w odpowiedzi na pytanie: czy piszemy grę czy silnik na grę? Ja obserwując branżę trochę z boku i widząc ile trwa stworzenie niektórych gier czasem zastanawiam się czy właśnie w taką pułapkę nie wpadacie? Przez specyfikę kreatywności i częstych zmian wizji jest to nie uniknione, czy może sprawa jest bardziej skomplikowana?

MS: Myślę, że powodów jest wiele. Pierwszy z brzegu to tzw. NIH (Not Invented Here) Syndrome. Wiele firm ma poważne opory przed używaniem "obcych" technologii, uważają (nie bez racji często), że sami są w stanie zrobić to lepiej (szczególnie "pod" jakiś konkretny tytuł). Różne zespoły stosują różne podejścia, są firmy, w których silnik powstaje zupełnie "obok" gry, jest robiony przez innych ludzi, a zespół nie dostaje nawet źródeł. Są i takie, gdzie związki są dużo bliższe (myślę, że to lepsze podejście). Pisząc silnik nie powinniśmy nawet na moment zapominać, że nadrzędnym celem ma być gra, a nie fajna technologia, to co najwyżej bardzo miły efekt uboczny. Tworzenie "bazy" ma swoje uroki, można projektować rzeczy po swojemu, dłubać w spokoju, co większości programistów bardzo odpowiada. Jest niestety dosyć nudne dla reszty ekipy, która czeka na silnik/edytor żeby ruszyć z pracą. Dla niektórych to może być trudne do zaakceptowania, ale ostatecznie taka jest nasza rola -- dostarczyć środków do zrobienia gry. Taka filozofia przyświecała choćby twórcom God of War i sądząc po rezultatach -- sprawdza się niekiepsko.
Zmiany wizji, o których wspominasz, to inny ważny powód. Przekleństwo i błogosławieństwo tej gałęzi. Na początku wyrzucanie pracy do kosza może być dołujące, ale później człowiek zaczyna sie przyzwyczajać :) Staramy się temu przeciwdziałać prototypując gdzie się da, ale to minimalizuje zagrożenie, nie eliminuje go do końca. Nie ma niestety/na szczęście (niepotrzebne skreślić) naukowej metody pozwalającej ocenić z wyprzedzeniem czy feature spowoduje, że gra będzie po prostu "fajna".

DB: Programowanie to oczywiście nie wszystko. Jakie inne role można rozpatrywać chcąc, cokolwiek to znaczy, współtworzyć gry?

MS: Na najwyższym poziomie mamy podział na kilka podstawowych gałęzi:
- kod,
- grafika (3D (animacje, modele (u nas jest tutaj dalsze rozbicie na lokacje i postacie)), 2D, koncepty, cutsceny),
- muzyka + efekty dźwiękowe, voice,
- design (tutaj znowu mamy rozbicie na zespoły od historii i od mechaniki) + dialogi,
- produkcja,
- QA
W każdym z tych działów jest wiele konkretniejszych specjalizacji, których z czasem będzie tylko przybywać. Na dzień dzisiejszy produkcji gier AAA to naprawdę złożone przedsięwzięcie przy którym pracuje kilkaset osób przez kilka lat.

{Następna część: Technologie wykorzystywane w GameDev }

Technorati Tags: Polish Posts,gamedev