Programowanie gier komputerowych – jak zacząć

Transkrypcja

Dziś moim gościem jest Grzegorz Wątroba. Opowie nam o tym, od czego i jak zacząć, jeśli chcemy zostać programistami gier komputerowych. Grzegorzu, dziękuję, że przyjąłeś moje zaproszenie na rozmowę.

Bardzo dziękuję za zaproszenie.

Zacznijmy od Twojej osoby. Powiedz nam, co łączy Cię z branżą IT?

W IT, a konkretnie w gamedewie, spełniam swoje dziecięce marzenia, bo przygodę z komputerami zacząłem w zasadzie od atari i commodore’a. Mając zaledwie kilka lat, dostałem od wujka na urodziny Pegasusa. Grając w Super Mario, z racji mojego charakteru bardzo chciałem dowiadywać się, jak te rzeczy działają, więc stwierdziłem, że muszę się dowiedzieć, jak ta postać rusza się na ekranie.

Z racji tego, że było ciężko o jakiekolwiek materiały w latach 1994-95, udało się po jakimś czasie odnaleźć Bajtki, czyli czasopisma wydawane do 1996 roku włącznie, które były poświęcone tematyce komputerów. W nich były tak zwane listingi, czyli zrzuty programów, które można było przepisać w języku BASIC do komputera. W momencie, kiedy udało się je odgrzebać (naprawdę nie pamiętam już, czy to był atari, czy commodore), zacząłem widzieć relację, że jeżeli coś napiszę, to jakaś postać się rusza, coś się dzieje itd. Więc stwierdziłem, że to jest to. Czasami nawet sprawiało mi to większą radość, niż samo granie, stąd całą edukację ukierunkowałem właśnie pod informatykę.

Ukończyłem Uniwersytet Jagielloński, licencjat zrobiłem na Wydziale Matematyki i Informatyki na specjalizacji inżynierii oprogramowania, magisterkę obroniłem na Wydziale Fizyki, Astronomii i Informatyki Stosowanej w specjalizacji modelowanie komputerowe, grafika komputerowa.

W zasadzie od drugiego roku studiów już pracuję zawodowo. Zamiast praktyk zacząłem pracę zawodową w firmie Bloober Team, ale po drodze też dla urozmaicenia i sprawdzenia, czy faktycznie gamedev jest dla mnie, raz na jakiś czas pracowałem, powiedzmy, w standardowym IT, czyli w firmie Autodesk, dla Nokii, Xary, czyli brytyjskiej spółki, będącej częścią korporacji MAGIX, gdzie tworzyłem oprogramowanie do projektowania graficznego, takie bardziej użytkowe, więc ileś takich projektów udało mi się zrobić.

Aktualnie 12 rok spędzam z gamedevem, pracuję dla firmy Fool’s Theory jako lead programmer i pomijając projekt Vitriol dla 11bit studios, chociaż za niedługo będzie ujawnienie właściwej nazwy projektu, to jeszcze dodatkowo kolejnym naszym projektem jest The Witcher Remake, czyli remake pierwszego klasycznego Wiedźmina na zlecenie CD PROJEKT RED.

Brzmi super. Będziemy o tej matematyce i fizyce trochę rozmawiać, żeby wszystkich nie przestraszyć, że studia to jest taka niezbędna rzecz.

Absolutnie nie jest.

Tak jest. Wrócimy do tego tematu, ale może zaczniemy po kolei.

Uwielbiamy grać w gry komputerowe i chcemy zostać programistami, którzy specjalizują się w grach. Czy już na tym etapie popełniamy jakiś błąd?

Myślę, że akurat w tej branży nie ma czegoś takiego jak jedyna właściwa droga. Nie ma jedynej właściwej drogi, żeby tworzyć gry czy je programować. Na pewno trzeba się interesować czymś więcej niż tylko samym graniem w gry. Często spotykam się z tym, że ludzie po prostu lubią grać w gry i tyle, i nagle chcą je tworzyć.

Jednak tworzenie gier to jest troszeczkę coś więcej niż samo granie. Trzeba interesować się, jak są produkowane, analizować, jak funkcjonują. Należy być takim świadomym graczem, porównajmy to ze świadomym oglądaniem filmów. Analizujemy sceny, grę aktorską. W grach analizujemy, jak wygląda grafika, oceniamy czy jakieś efekty są lepsze, czy gorsze, czy mechanika ma jakieś błędy itd. Może mamy pomysł, jak by coś zrobić lepiej. Takie ukierunkowanie myślenia świadczy o tym, że może właśnie robienie gier w jakimś zakresie, w tym programowanie, może być dla nas.

W takim razie mamy już informacje, jak mniej więcej powinniśmy rozpoznać, czy to jest tylko granie, czy coś więcej. Ale jeżeli byśmy chcieli się jakoś bardziej zagłębić w programowanie, to jak możemy się ukierunkować? Jak wybrać język? Jak w ogóle podejść od tego tematu?

Wydaje mi się, że aktualnie mamy najlepsze czasy, żeby zacząć tworzenie gier, gdyż mamy masę darmowych tutoriali i mnóstwo naprawdę świetnych, profesjonalnych narzędzi dostępnych za darmo.

Najlepiej po prostu usiąść do jakiegoś tutoriala i zrobić tę pierwszą grę, pracując z silnikiem, chociażby z Unreal Engine czy z Unity. Sami twórcy silnika dają wiele ciekawych dokumentacji i porad. Na YouTubie możemy krok za krokiem stworzyć jakiś projekt. Jeżeli sprawia nam to radość, jeżeli przebrniemy przez pierwsze trudności i będziemy chcieli dalej rozwijać to, co zrobiliśmy za pomocą tutoriala, to możliwe, że jest to dokładnie coś dla nas.

Często te pierwsze kroki w ogóle nie muszą być związane z programowaniem, tylko bardziej z ogarnięciem samego narzędzia, a potem można schodzić ten poziom głębiej i zacząć programować pierwsze mechaniki.

Tutaj oczywiście potrzebne są podstawy C++ albo C#, w zależności czy wybierzemy Unreal, czy Unity, oraz co nas bardziej interesuje: czy chcemy zrobić grę trójwymiarową, taką bardziej strzelaninę lub strategię, czy na przykład dwuwymiarowego platformera, ale pewnie za chwilę i do tego dojdziemy.

Pewnie tak. To jeszcze może dopytam, bo wspomniałeś o tych silnikach. Czy one faktycznie są darmowe? Rozumiem, że jeżeli chcemy się uczyć, to nie ma problemu z tym, żeby zainstalować na swoim sprzęcie i z tego korzystać. Dopiero jeżeli byśmy wypuszczali grę, to musimy mieć jakąś licencję. Jak to jest?

Od pewnego poziomu zarabiania z gry te licencje są bardzo nastawione w stronę twórców. Jeżeli mamy pierwszy projekt, na którym być może w ogóle nie zarobimy, to też nie musimy nic płacić. Dopiero od pewnego poziomu zarobków, kiedyś to było chyba $100 000, musimy odprowadzać jakiś tam ułamek dochodów powyżej tej kwoty.

To może bym tylko dodał, że taki problem, to nie problem.

Tak. Natomiast jeżeli mamy potrzebę dodatkowego wsparcia, jakichś dodatkowych narzędzi czy w przypadku Unity potrzebujemy zajrzeć do silnika, bo to jest silnik z architekturą zamkniętą, wtedy faktycznie musimy wykupić dodatkowy abonament, wyłożyć dodatkowe pieniądze itd. Natomiast w przypadku Unreal dostęp do kodu silnika jest bezpłatny. Opłaty są raczej dla osób, które faktycznie profesjonalnie i w miarę dużo w pojęciu pierwszych kroków zyskują z wyprodukowania tej gry.

To może jeszcze dopytam, bo przynajmniej w mojej działce, czyli front end, mówi się, żeby dobrze najpierw poznać język, czyli JavaScript, a potem dopiero iść w stronę frameworków, czyli na przykład React, Angular czy Vue. Rozumiem, że tutaj jeśli chodzi o gamedev, to wygląda to trochę inaczej, tak? Dobrze jest zacząć od silnika i wcale nie musimy tutaj poznawać jakoś bardzo dogłębnie C++ czy C#, o których wspomniałeś?

Tak. Do pierwszych kroków praktycznie nie potrzebujemy w ogóle umieć kodować, gdyż oba silniki zapewniają tak zwany visual scripting, czyli możemy dosłownie montować całą mechanikę na takich kolorowych bloczkach, które łączymy sobie sznureczkami. W przypadku Unreala są to Blueprinty. W przypadku Unity ten system nazywa się Bolt.

Możemy się wręcz uczyć tworzenia logiki gry na tym, jednocześnie nie umiejąc nic programować, a dopiero potem możemy wskoczyć, mając tę bazową wiedzę o tym, jak faktycznie konstruowane są gry, do faktycznego programowania.

Oczywiście nikt nam nie zabroni pisać kodu od razu, bo do tego też są odpowiednie dokumentacje i tutoriale, natomiast jeżeli ktoś ma lekką wysypkę już na samą myśl o kodowaniu, a jednocześnie chce sprawdzić, jak się robi gry, to może to zrobić bez wiedzy programistycznej.

Brzmi bardzo dobrze. Sądzę, że wszyscy, którzy myślą o programowaniu, już są zadowoleni.

Przejdźmy do kolejnej kwestii. Uznajmy, że już wiemy, że to jest ścieżka dla nas. W takim razie czy trzeba ukończyć studia informatyczne? Już na samym początku powiedziałaś coś na ten temat. Ale jeżeli nie, to z jakich dziedzin, mimo wszystko, musimy mieć trochę wiedzy?

Jeżeli chodzi o same studia, to nie trzeba mieć studiów w ogóle. Większość największych nazwisk i specjalistów w ogóle nie ma studiów kierunkowych, niezależnie od dziedziny, więc akurat gamedev to jest bardziej ta dziedzina branży IT, w której bardziej liczą się faktyczne, praktyczne umiejętności niż teoretyczna wiedza – ale ta też jest na pewnym etapie już potrzebna.

Jeżeli chodzi o teoretyczną wiedzę, w największym stopniu przydaje się znajomość logiki, algebry, geometrii analitycznej, podstaw fizyki, takich jak kinematyka czy optyka, oraz zasad matematycznych rządzących grafiką komputerową.

Oczywiście trzeba znać już od pewnego etapu język C++ bądź C# i narzędzia, czyli Unreal lub Unity, chociaż jest wiele innych silników, jak chociażby Godot czy Lumberyard, ale akurat Unreal czy Unity to są te najbardziej popularne.

Należy też uzupełniać braki z innych dziedzin, bo trzeba pamiętać, że gamedev to branża bardzo interdyscyplinarna. Łączymy wiedzę techniczną z wiedzą bardzo artystyczną. Sam co prawda interesowałam się kinematografią, ale dopiero gdy tworzyłem pewien system automatyzacji montowania scen dialogowych, musiałem przerobić masę wiedzy teoretycznej związanej stricte z operowaniem kamerą: czym jest zasada trójpodziału sceny czy jak powinno się kierować światło na postać, gdy prowadzimy dialog w 2, 3, 5 osób itd.

Mamy masę różnych, czasami, wydawałoby się, dość nietypowych dziedzin wiedzy, z których musimy czerpać, ale generalnie wiedza o grafice komputerowej, o udźwiękowieniu, o UI i UX designie – to są rzeczy, które warto wiedzieć i w sumie każdy game developer do pewnego stopnia powinien się nimi zainteresować po to, żeby wiedzieć, jak to się spina z jego własną działką i specjalizacją.

To ja bym może jeszcze dopytał o kinematykę i optykę, bo wspomniałeś o tych dziedzinach. Pewnie większość osób nie wie, o co chodzi, a jeżeli powiemy im, do czego to wykorzystujemy, to pewnie będzie im łatwiej i chętniej przejdą do tych dziedzin, bo jak słyszą słowo „fizyka”, to pewnie już są niechętni. Może mógłbyś nam coś więcej powiedzieć na ten temat?

Sama kinematyka jest istotna we wszystkich popularnych zagadnieniach związanych z ruchem, czyli chociażby rzut pionowy w górę, skakanie, rzut poziomy, zasady dynamiki Newtona czy ruch sprężynowy.

Optyka przydaje się w shaderach, czyli efektach graficznych. To jest troszkę osobny język programowania. Należy tu zrozumieć zasadę odbijania świateł, czym jest ogniskowa, poznać zasady działania kamer, soczewek itd.

Idziemy dalej. Chciałbym się od Ciebie dowiedzieć, od czego zacząć naukę programowania gier i jak wytyczyć sobie taką ścieżkę rozwoju. Jakie języki i narzędzia cieszą się największą popularnością, żebyśmy mogli jak najszybciej trafić do tej branży?

Najpopularniejsze dwa silniki, jak już wspominałem, to jest Unreal Engine i Unity. Jest jeszcze Godot i Lumberyard.

Jeżeli chodzi o języki programowania, C# jest używany w przypadku Unity i paru pomniejszych silników, natomiast w reszcie wykorzystuje się C++. I to jest jakby tyle, jeżeli chodzi o urozmaicenie językowe.

Oczywiście są jakieś skrypty narzędziowe pisane w Pythonie, czasami przydaje się wiedza z Perla, ale to jest już w bardzo takich wąskich działkach i raczej w pojedynczych narzędziach, więc głównie C# i C++.

A jak byś miał komuś powiedzieć: OK, jeśli chcesz się nauczyć tego programowania, to od razu pobierz sobie Unreala, włącz tutorial i zacznij to robić. Co dalej?

W zasadzie tak. Może najpierw warto troszeczkę już przejść przez ten taki proces produkcyjny w głowie i zastanowić się, co bym chciał stworzyć, albo co mnie ostatnio zainteresowało, bo ważne, żeby zaczepić sobie w głowie też ten motyw, co byśmy chcieli osiągnąć.

Na przykład chcielibyśmy zrobić prostą strzelaninę, gdzie widzimy broń i strzelamy do jakichś celów, postaci, czegokolwiek. To już determinuje nam, czy chcemy zrobić grę trójwymiarową, czy dwuwymiarową, więc czy potrzebujemy Unreala, czy Unity.

Unreal jest bardziej do tych gier trójwymiarowych, dużych, do FPS-ów, do strategii, natomiast Unity jest bardziej do gier dwuwymiarowych, do takich 2,5D, czyli trójwymiarowych, ale z zamkniętym, jakby zafiksowanym ujęciem kamery, więc tutaj warto też wiedzieć, co chcemy osiągnąć, a od tego punktu może warto wtedy wystartować.

Natomiast ja o tym opowiadam tak od strony praktycznej, ale nie ma reguły. Gdziekolwiek nie zaczniecie, jesteście w stanie z odpowiednią ilością czasu i determinacji osiągnąć to, czego chcecie.

Ważne, żebyście chcieli to osiągnąć.

I żebyście zaczęli robić, tak? Żeby nie zastanawiać się, tylko działać?

Tak, dokładnie.

A jeszcze tylko dopytam: czy w Unity można pisać w C++, czy tylko w C#?

Pisanie w C++ jest możliwe, natomiast tym domyślnym kompilatorem i językiem programowania jest C#.

Tak pytam, bo jeżeli ktoś C++ już zna, to ma wybór: albo Unreal, albo właśnie Unity i w zasadzie nie musi myśleć o innym języku programowania. Wiem, że mówiłeś na początku, jak sobie rozmawialiśmy, że programowanie to jest rozwiązywanie problemów, a nie język, ale też wiem, że na początku to też może być istotne. Jak się już coś umie, to można iść dalej, a nie trzeba się zastanawiać nad nowym.

No dobrze, to idźmy dalej. Już wspominaliśmy o tym działaniu, to pytanie do Ciebie. Jakie projekty powinny trafić do naszego portfolio? Czy sama taka gra w węża to już coś, czy można się pochwalić, czy to zdecydowanie za mało?

Zawsze jest ten problem ze startem w branży, bo wtedy jeszcze nie mamy nic w portfolio, nie mamy nic do wpisania w CV, ale właśnie w momencie, kiedy nie mamy nic na start, to cokolwiek, co zrobimy, jest świadectwem tego, że próbujemy, że się tym interesujemy.

Czasami lepszym dowodem na przysposobienie do branży jest gra zrobiona od początku do końca i wydana na Steamie czy Google Store niż bardzo rozbudowana wydmuszka, która nie ma żadnego elementu zrobionego do końca.

Czasami na przykład jakiś element interesującej mechaniki, której nie widzi się w takiej konfiguracji, to może być coś ciekawego: stworzona grafika, jakiś efekt, ciekawy system, ale ważne, żeby to było zrobione od początku do końca. W jakiś sposób przemyślany – coś, co można włączyć do istniejącego projektu. To jest już świadectwo generowania jakiejś wartości i to się najbardziej docenia.

Dobrze pokazywać nawet starsze projekty. Często ludzie mają takie: A, bo pisałem to trzy lata temu i może to wyglądać słabo. Ale właśnie istotne jest czasami to, żeby mieć te wszystkie projekty, chociażby na GitHubie, po to, żeby potem w momencie, kiedy jesteśmy na rozmowie kwalifikacyjnej czy wysyłamy swoje CV, pokazać, jak wyglądał nasz progres.

Często sam, jak rekrutuję ludzi, chętnie zaglądam na GitHuba, patrzę i myślę: ha, to widać, było pisane parę lat temu, było kopiowane z tutoriala i robione na byle jak, ale po dwóch latach widzę już klasy ładnie poukładane, kod poformatowany. O, czyli się uczył. Ten progres i tempo, w jakim on następuje, jest też dla mnie wyznacznikiem tego, że jest to osoba, która uczy się w taki a taki sposób, idzie w tym i tym kierunku, czyli dla mnie czy mojego zespołu, czy dla firmy będzie miała określoną wartość i że jest to osoba, którą bym rozważył do zatrudnienia.

Znowu mi się pojawią dodatkowe pytania. Czy jesteś w stanie nam powiedzieć, jak wygląda proces dodawania gry na Steama? Czy to jest coś trudnego? Jest to sprawdzane, czy w zasadzie zakładamy konto, wrzucamy i to jest wszystko?

Jeżeli chodzi o Steama, to musimy założyć konto developerskie, zapłacić chyba $100 i możemy wtedy założyć kartę projektu, gdzie musimy uzupełnić pewne dane, pokonfigurować pewne rzeczy. Wtedy tworzymy projekt, budujemy go, czyli robimy tę formę wykonywalną, czyli exe plus pliki assetów. Mamy taki specjalny program, w którym wysyłamy to na stronę z określoną certyfikacją itd. i to jest sprawdzane technicznie przez Steama.

Co prawda ta kuratela teraz nie jest tak bardzo jakościowa jak kiedyś, dlatego też na Steamie mamy codziennie wydawane dziesiątki gier. Natomiast jest tam sprawdzanie podstawowe, techniczne i wtedy możemy to wydać.

W momencie, kiedy mamy już, powiedzmy, gotowy projekt, to od złożenia wniosku o przydzielenie konta developerskiego do wrzucenia gry na Steama może minąć 24 godziny, potem tydzień na sprawdzanie i gra już jest na Steame, więc to nie jest proces bardzo trudny. To jest proces, który kosztuje, powiedzmy, to wpisowe, ale poza tym nie jest jakoś bardzo żmudny. Natomiast doprowadzenie do tego, żeby potem ktoś zauważył, zagrał w tę grę i nie narzekał, że mu się wysypuje, to już jest inna sprawa.

Co innego, kiedy się wydaje gry na konsolę, bo wtedy mamy cały proces certyfikacyjny, który zakłada używanie określonych słów, określonych grafik. Musi spełniać pewne założenie, jeżeli chodzi o wydajność. Nie może zajmować więcej niż x gigabajtów. Jeżeli zajmuje więcej niż x gigabajtów, to musimy zapewnić, że jeżeli się ściągnie pierwsza paczka danych, to da się już uruchomić grę. Jest masa, masa, masa obostrzeń, dlatego gry na konsolę uśredniając, są często lepszej jakości, bo ten proces certyfikacyjny jest znacznie bardziej skomplikowany i wymagający.

1. Drugie pytanie pojawiło mi się w głowie, bo wspominałeś właśnie o tym, że rekrutujesz. Czy dużo nowych osób chce wejść do branży i czy to jest taka liczba, która jest naprawdę duża, i ciężko przeprowadzić rekrutację, czy raczej nie? Nie ma problemu, powiedzmy, tak jak z front endem, że jest bardzo dużo chętnych zgłaszających się na stanowisko? Pytanie, czy w ogóle się ogłaszacie, czy po prostu ludzie tak przychodzą z ulicy i mówią, że chcą spróbować.

Jeżeli chodzi o rekrutację, sam proces i jej widoczność, to działa często w obie strony. Firmy wystawiają swoje ogłoszenia na swoich stronach internetowych, dlatego warto obserwować te strony. Czasami nawet jeżeli nie wystawiają, to można napisać do firmy z pytaniem, bo akurat może się wstrzelimy w to właściwe okno.

Poza tym mamy takie serwisy jak Skillshot, gdzie agreguje się oferty pracy i można tam znaleźć coś dla siebie. Chętnych, w zależności od działki, jest różna liczba, natomiast cała branża gamedevowa jest bardzo chłonna i nadal potrzebujemy bardzo dużo ludzi. To jest oczywiście kwestia działki, bo jest na przykład bardzo dużo grafików 2D, tylko że tych grafików 2D, którzy robią to, co większość grafików 2D, jest bardzo dużo. I miejsc dla takich osób jest stosunkowo mało w stosunku do reszty zapotrzebowania.

Ale jeżeli na przykład ktoś potrafi robić szkieletowe animacje 2D, czyli jest w dość wąskiej specjalizacji, która wymaga trochę więcej wiedzy, to już jest człowiek skarb, bo takich osób jest dosłownie kilka, kilkanaście w Polsce, a zapotrzebowanie jest na kilkadziesiąt.

Tak samo programiści… ale zanim wejdę na programistów, to ludzie od efektów specjalnych, czyli VFX-y. To też jest działka, która wymaga jednocześnie zacięcia artystycznego, ale i wiedzy technicznej. I to jest coś, czego się ciężko uczy. Ciężko jest być na takim bardzo satysfakcjonującym poziomie, ale jeżeli się na niego wejdzie, to można przebierać w ofertach.

Jeżeli chodzi o programistów, to cały czas jest zapotrzebowanie na zdolnych, niekoniecznie młodych, ale zdolnych, natomiast największe zapotrzebowanie aktualnie jest na dobrych programistów właśnie Unreala, C++, bo ich jest po prostu mniej, a coraz więcej projektów się na tym silniku robi. Więcej jest troszeczkę na Unity, ale generalnie jeżeli dana osoba pokaże, że potrafi przejść ten proces rekrutacyjny albo ma coś interesującego w portfolio, to bardzo szybko można znaleźć pracę.

To pewnie to będzie trudne pytanie, ale może będziesz w stanie mi na nie odpowiedzieć. Ile czasu taka osoba powinna poświęcić, żeby móc w ogóle wejść do branży? Zakładając, że wie, co to jest programowanie, zna trochę C++, potrafi napisać prostą klasę, coś się wyświetla, powiedzmy, w terminalu – coś się dzieje, ale tak na poważnie nie programowała, ale chciałaby zostać programistą gier komputerowych. Jaki okres czasu mogłaby założyć sobie, żeby móc zostać tym programistą, żeby dostać pierwszą pracę?

Odpowiem tutaj bardzo ogólnikowo. Niestety to zależy, bo każdy ma inne tempo uczenia się, więc nie można tego uśredniać. Jeżeli powiem określony wyznacznik czasowy, to niektórzy będą się później stresowali: dlaczego ja nie mogę tak szybko się nauczyć.

Ale tutaj bardziej chodzi o zakres wiedzy wymagany do tego, żeby coś zrobić. Jeżeli dojdziemy do etapu, w którym jesteśmy w stanie zrobić prostą grę, na przykład klon Angry Birds na telefon i wydać to na przykład na Google Playu, pal licho, że nikt tego nie pobierze, ale przejdziemy przez ten cały proces, to znaczy, że już coś umiemy i to jest bardzo dużo w oczach potencjalnego pracodawcy.

Sam kiedyś współtworzyłem taki profesjonalny, płatny kurs od zera do game developera w Unity, używając C#. Ten kurs zakładał dobrych kilkanaście tygodni pracy, gdzie trzeba było spędzić codziennie tak z pół godziny / godzinę na rzeczy teoretyczne i tyle samo czasu na praktyczne, ale to zakładało takie równomierne, spokojne tempo pracy. Jeżeli ktoś miał szybsze, to po prostu szybciej się tego wszystkiego nauczył, ale wtedy to i tak trwało parę miesięcy takiej regularnej pracy, żeby czegoś się nauczyć, utrwalić i potem zastosować.

Natomiast każdy ma inne zdolności uczenia się, stąd może to inaczej wyglądać w danym przypadku.

Ale z tego, co mówisz, i z mojego doświadczenia wynika, że jeżeli ktoś jest zawzięty, ma mentora czy osobę, która jest w stanie coś podpowiedzieć czy zwrócić uwagę na błędy itd., i ma ścieżkę, ma materiały, no to powiedzmy, że zajmie to pół roku. Czy uważasz to za możliwe przy założeniu, że jest to na przykład 20 godzin tygodniowo?

Jak najbardziej.

OK, no to super. To muszę przyznać, że sam jestem zdziwiony, bo takie założenia mam przy front endzie. Myślałem, że przy gamedevie trzeba poświęcić więcej czasu, ale super, że to wyszło.

No dobrze, jak już jesteśmy przy tej nauce, to pytanie do Ciebie: jakie błędy na etapie nauki i przygotowań do poszukiwania pracy są najczęściej popełniane przez osoby, które chcą zostać programistami gier komputerowych?

Jak już zaznaczałem: takie przekonanie, że tworzenie gier jest proste. Nie jest. Myślenie, że jest przyjemne, bo klika się rzeczy i są – to też nie jest prawdą.

Tworzenie gier bywa żmudne, bardzo ciężkie, frustrujące, bo robimy kilkukrotnie jakąś rzecz i nie wychodzi. Jeżeli jesteśmy osobą, która się bardzo szybko poddaje i frustruje, to możemy mieć duże trudności.

Tak samo przekonanie, że jeżeli gramy setki godzin w jakąś jedną grę, to sprawi, że znamy się na tworzeniu gier i wiemy, jak to wszystko działa. Jeżeli nie zastanawiamy się nad tym, co robimy, nie podchodzimy świadomie do naszego grania, to też nie działa w ten sposób.

Jeżeli się nie wiąże praktyki z wiedzą teoretyczną, to wydaje mi się, że to też jest błąd. Wiele osób na studiach skupiało się stricte na nauce, nie uczestnicząc po drodze w żadnych projektach, nie robiąc niczego chociażby do szuflady, nie próbując się organizować w jakieś projekty zespołowe. Trzeba pamiętać, że w dominującej większości tworzenie gier to jest tworzenie zespołowe, dlatego należy szlifować umiejętności komunikacyjne. W zasadzie idąc na 5-letnie studia, nie robiąc nic praktycznego, niestety marnujemy swój czas, bo po wieku 23-24 lat będziemy mieli mocno pod górkę względem osób, które już coś stworzyły czy przeszły przez te pierwsze trudności związane z produkcją chociażby jakiejś malutkiej gry, nawet na Steama, czy jakiegoś studenckiego projektu zespołowego.

Wydaje mi się, że warto bardzo mocno cisnąć też w to, żeby nabywać wiedzę teoretyczną, ale bez wiązania tego z praktyką to się nie utrwali tak dobrze, przez co mamy troszeczkę niższą wartość na rynku pracy.

To ja może też dodam, bo wspominałeś o tych studiach. Również zauważyłem, że osoby, które robiły coś dodatkowo podczas studiowania, czyli zdobywały doświadczenie komercyjne, potem po studiach w ogóle nie miały problemu ze znalezieniem pracy, a osoby, które jak gdyby, brzydko mówiąc, tylko zaliczały egzaminy, a nic ponad to nie robiły, to w zasadzie ciężko miały, żeby się odnaleźć w branży. Więc studia OK, mogą dać nam coś dodatkowego, ale to nie jest wystarczające, żeby znaleźć tę pracę. Przynajmniej z mojej perspektywy.

Tak.

No dobrze, to kolejny temat. Mówiliśmy trochę o silnikach gry, to może mógłbyś nam powiedzieć, co to jest ten silnik gry i czy w ogóle polecasz tworzyć własny podczas nauki programowania gier komputerowych.

Myślę, że stworzenie własnego silnika gry to jest często marzenie osoby bardzo technicznej, jednak przestrzegam, młodzi adepci; napisanie chociażby zwykłego renderera od zera nie jest zajęciem prostym i przyjemnym. Dojście od bazowego API graficznego do wyświetlenia oteksturowanego trójkąta to jest już czasami droga przez mękę.

Stąd silnik gry, taki gotowy, komercyjny, to jest zestaw narzędzi i bibliotek ułatwiających stworzenie gry właśnie przez odpowiednie fasady, interfejsy na API: graficzne, dźwiękowe, obsługę wejścia-wyjścia, ładowanie plików, odtwarzanie dźwięków, tworzenie interfejsu użytkownika czy nawet samo projektowanie świata gry.

Na pewno w trakcie nauki warto dowiedzieć się, jak taki silnik funkcjonuje, chociażby żeby wyłapywać błędy i umieć przeanalizować problemy. Myślę, że osoby, które bardzo chcą siedzieć niskopoziomowo, powinny spróbować stworzyć jakiś prosty framework, którym na przykład wyświetlam jakiś model, spróbują go zanimować, obsłużą prostą kolizję czy jakąś interakcję z graczem.

Natomiast w dzisiejszych czasach, o ile ktoś nie chce stricte siedzieć w silnikach, to w pierwszej kolejności warto zaznajomić się z całym procesem tworzenia gry i używania gotowego narzędzia; dowiedzieć się, jakie są aktualne standardy i tak dalej, a dopiero potem schodzić niżej, bo zaczynanie tej całej nauki od silnika to bardzo długi, żmudny proces. Coraz więcej firm na rynku wręcz odchodzi od wewnętrznych silników, bo utrzymywanie własnego silnika w tak pędzącym technologicznie czasie i w takiej branży, w której rok to jest czasami kamień milowy, jest bardzo kosztowne, bardzo trudne.

Często te wewnętrzne silniki są tragicznie stworzone od strony narzędziowej, więcry na wewnętrznych silnikach, o ile nie są tworzone z giga budżetami, powstają w ciężkich warunkach, stąd też bywają niższej jakości. Dlatego też wydaje mi się, że warto raczej zająć się najpierw poznawaniem tego, jak wyglądają aktualne standardy branżowe na gotowych silnikach i dopiero potem schodzić niżej.

A to też nie jest tak, że dla nas lepiej poznać taki gotowy silnik, bo jesteśmy w stanie pracować dużo szybciej, od razu wpadając do teamu, po prostu możemy coś zrobić i w zasadzie nie musimy się tego uczyć? Na rynku pracy wydaje się, że jesteśmy bardziej interesującym pracownikiem, bo już to znamy, prawda? Nie trzeba nas wdrażać nie wiadomo jak długo.

Tak, dokładnie.

OK, to powiedzieliśmy sobie trochę o tych umiejętnościach technicznych, to chyba czas powiedzieć, jak wygląda sprawa, jeśli chodzi o umiejętności miękkie. Jak to jest w środowisku programistów gier komputerowych?

Komunikacja i organizacja potrafi nadal kulać nawet w dużych zespołach, w których wydawałoby się teoretycznie, że wszystko powinno funkcjonować jak dobrze naoliwiona maszyna, ale niestety nawet tam są problemy z odpowiednimi nawykami, higieną pracy, planowaniem, ćwiczeniem estymacji itd. To są właśnie te cechy, które są bardzo pożądane, ale rzadko kiedy dobrze praktykowane.

Jeżeli chodzi o gamedev, najwięcej takich dobrych praktyk zauważyłem w firmach, które mają dużo wspólnego z systemem pracy standardowego IT, nieco korporacyjnym, czyli w studiach, w których tworzy się gry mobilne. Mobilne gry jako serwis, gdzie musimy non stop utrzymywać projekt w stanie używalnym dla klienta i nie możemy sobie pozwolić na błędy. Wtedy musimy mieć ten cały system testowania, odpowiedniego planowania, odpowiedniej estymacji.

Mam wrażenie, że cała branża uczy się troszeczkę na takiej zasadzie: IT, gdzie już zostały te rzeczy przetestowane odpowiednio, potem mobilki i gry jako serwis, a dopiero potem duże i mniejsze studia próbują brać te praktyki, chociaż czasami podchodzą na zasadzie: O fu, mobilki, to od nich się nie będziemy uczyć, a to właśnie jest bardzo duży błąd, bo tam mamy to przecięcie prawidłowego systemu pracy, produkcyjnego podejścia itd. i gamedevu.

Poza tym, tak jak już mówiłem, na pewno z racji tego, że tworzenie gier jest często pracą zespołową, umiejętność komunikacji jest kluczowa, czyli umiejętność zadawania pytań, wyjścia poza swoje blokady, przebicie się przez tę barierę, taką dumę, że ja wszystko wiem. Nie, nie, nie. Naprawdę, jeżeli ktoś mi pisze nawet w CV, że on po dwóch latach zna C++ w stopniu zaawansowanym, to właśnie widać ten problem. Ja po 12 latach dalej mam wątpliwości, czy mogę w dany sposób coś napisać, a już w zasadzie ze 20 lat pracuję z C++.

Trzeba umieć przebić się przez swoje bariery i zadawać pytania, nie wstydzić się tego, umieć dawać feedback, czyli informację zwrotną, co jest nie tak, ale w sposób nie wyśmiewający, nie oceniający, tylko prowadzący do rozwiązania, i tak samo przyjmować tę informację zwrotną, czyli nie obrażać się, że ktoś akurat krytykuje naszą pracę, bo krytykuje naszą pracę, nie nas. I często zrozumienie tego, zwłaszcza w branży, w której ludzie bardzo emocjonalnie podchodzą do swojej roboty, jest ciężkie i praktykowanie tego, szlifowanie tej umiejętności jest naprawdę bardzo potrzebne.

Tak samo umiejętność przyznania się do błędu, komunikowanie potrzeb i stawianie pewnych granic, gdzie staramy się spełnić np. potrzeby szefa i zawsze mówimy: tak, szefie, zrobimy to, tak, szefie, zrobimy tamto. A potem siedzimy 16 godzin w robocie, bo naobiecywaliśmy nie wiadomo ile. Czyli jest to umiejętność znalezienia swoich ograniczeń i postawienia tego znaku stopu, że czegoś nie jesteśmy w stanie zrobić. Przyznanie się do tego też bywa czasami trudne. Z tego później wychodzą różne historie o crunchu, o różnych problemach z produkcją, o tym, że gry nie wychodzą takie, jakie powinny być itd. Komunikacja tutaj na pewno jest bardzo istotna.

OK, to mamy już trochę powiedziane na temat umiejętności miękkich i twardych. Co prawda już trochę na ten temat mówiliśmy, ale powiedzmy sobie jasno, jak to jest z tym rynkiem pracy dla programistów gier komputerowych. Czy jesteśmy w stanie znaleźć pracę bez doświadczenia w IT, czy może jednak ta ścieżka wygląda trochę inaczej?

Myślę, że jesteśmy w stanie bez doświadczenia, o ile tylko coś robiliśmy. Jest takie durne powiedzenie, ale się sprawdza, że żeby robić gry, trzeba umieć robić gry, czyli trzeba robić gry.

Jeżeli nic nie zrobiliśmy, mamy tylko za sobą przekonanie, że jesteśmy w stanie coś zrobić, to mamy wtedy nikłe szanse, ale jeżeli mamy już jakieś projekty robione przynajmniej do szuflady, gdzie pokazujemy, że coś umiemy wykonać, dodatkowo przejdziemy przez jakieś zadanie testowe, to już jest świadectwo, że jednak mamy jakąś potencjalną wartość dla przyszłego pracodawcy.

Przed pandemią było na pewno łatwiej. Teraz to się już też odbija, natomiast przez te ostatnie dwa lata był duży kryzys jeżeli chodzi o zatrudnienie juniorów, gdyż zdalnie dość kłopotliwie się mentoruje, a przynajmniej jest takie przekonanie w firmach, stąd też firmy podchodzą z dużą rezerwą do tego, żeby zatrudniać juniora zdalnie.

OK, to może właśnie tak podpytam, bo to ciekawy temat. Ty i ja uczymy ludzi zdalnie, siedzimy w tym temacie i ja widzę same zalety. W zasadzie są narzędzia, które pozwalają działać w ten sposób, jak byśmy siedzieli obok siebie. Zastanawiam się, co firmom się nie podoba albo czego się boją? Zastanawiałeś się nad tym?

Tak, to jest problem z zaufaniem. Nie mają tego przekonania, że jeżeli kogoś zatrudnią, to on faktycznie spędzi te kilka godzin ciągiem w robocie. Ciężko po prostu taką osobę upilnować.

Myślę, że to jest błędne podejście, ale z drugiej strony firmy mają często okrojony budżet na takie rzeczy. Często nie uwzględnia się tego w ogóle przy podpisywaniu projektu z wydawcą, bo wydawcy to nie obchodzi. Firma ma zrobić projekt w takim stanie, jaki ma, i koniec. A często jest tak, że w trakcie tworzenia wychodzi, że jest zapotrzebowanie na kolejnego programistę lub artystę, trzeba kogoś zatrudnić i co wtedy zrobić, jeżeli nie ma ludzi dostępnych na rynku?

Trzeba by było zatrudnić jakiegoś juniora, ale to jest raz, że koszt ze względu na to, że trzeba przeszkolić taką osobę, a dwa, czy ona faktycznie spędzi ten czas w pracy. Ja jestem tutaj innego zdania: da się to wszystko zrobić online przez różne metody komunikowania, przez różne systemy pracy, tylko że to wymaga znowu chęci oraz pewnego zrozumienia.

To nie jest takie trudne, tylko że firmy czasami z racji tego, że myślą o zatrudnianiu jakby w ostatniej możliwej chwili, nie uwzględniają tego wszystkiego w planowaniu, przez co potrzebują doświadczonej osoby na teraz, a nie pomyślą o tym, że może zatrudnią jakiegoś juniora i on będzie doświadczonym specjalistą po paru miesiącach u nas. Więc brak tego perspektywicznego myślenia często jest dużą bolączką na rynku pracy w gamedevie.

To może jeszcze bym dopytał odnośnie do tego sprawdzania, bo nawet jeżeli ten junior byłby w tej firmie, w tej pracy, to przecież nikt mu nie patrzy cały dzień na ręce i nie widzi, co robi, nie?

Oczywiście, dlatego mówię, że to jest przekonanie.

To, że jest, to nie znaczy, że w ogóle coś robi. To jest na takiej samej zasadzie, jak gdy siedzi w domu. To działa tak samo.

Oczywiście. W praktyce w 8-godzinnym trybie pracy pracuje się kreatywnie w zasadzie 4-5 godzin, co wydajniejsi, bardziej skupieni potrafią 6, ale nie więcej.

Często w firmach, w których panuje luźna atmosfera, a w takich też pracowałem, to pracuje się praktycznie jeszcze mniej, bo a to się wychodzi na kawę, a to zaczyna się rzucać piłkami, a to zaczyna się na przykład analizować, gadać o jakiejś grze, bo bazujemy na tym jakiś pomysł, siadamy do gry i na przykład pół dnia gramy i analizujemy jakiś tytuł.

W tym momencie to też jest praca: inspirowanie się, analizowanie, to jest mentalnie zajmowanie się pracą, ale to nie jest produkowanie. I teraz w momencie, kiedy byśmy oczekiwali, że junior będzie nam te 6-8 godzin faktycznie produkował wartość w firmie albo się uczył, to jest mrzonka. To jest czasami po prostu błędne postrzeganie tego przez pracodawcę.

No dobrze. Trochę Cię pewnie wybiłem z rytmu, bo dopytałem o ten mentoring zdalny, ale czy chciałbyś jeszcze coś dodać do tego pytania, które Ci zadałem odnośnie do znajdowania pracy bez doświadczenia w gamedevie?

Nie, po prostu, ludzie, zacznijcie robić rzeczy. To jest pierwsza sprawa.

Zacznijcie robić rzeczy, piszcie do firm, przeszukujcie Skillshota, chwalcie się tym, co robicie, nauczcie się też przyjmować informacje zwrotne od ludzi bardziej doświadczonych, nie przejmujcie się trollami, tylko po prostu pracujcie i docierajcie swoje umiejętności, ale też patrzcie na to zdroworozsądkowo.

Albo ktoś was zauważy, albo w końcu gdzieś siądzie: przejdziecie tę rozmowę kwalifikacyjną i się dostaniecie. Branża jest na tyle chłonna, że każdy, kto jest w stanie wygenerować jakąś wartość dla firmy, nie będzie miał/miała problemu z zatrudnieniem.

No dobrze, to idźmy dalej. Wiem, że pewnie znowu będzie odpowiedź to zależy, ale fajnie, jak by się dało to zakreślić w jakiś krąg. Czy jesteś w stanie określić, jakie minimalne umiejętności techniczne powinien mieć junior, by dostać pierwszą pracę?

Na pewno podstawy danego języka programowania, czyli słowa kluczowe, klasy, struktury, dziedziczenie, eventy, delegaty, bo większość rzeczy mimo wszystko w grach bazuje na tym. Przydaje się operowanie na zbiorach danych, filtrowanie informacji, przeszukiwanie kontenerów. Tego typu rzeczy, stricte takie suchoprogramistyczne. Potem znać podstawy najpopularniejszych mechanik w grach, czyli ruch postaci, interakcja, kolizje, operacje fizyczne, odbijanie się kul od ścian – tego typu rzeczy, stąd mówiłem wcześniej o fizyce.

Najpopularniejsze zagadnienie matematyczne, o które często się pyta na rozmowach wstępnych, to jest iloczyn wektorowy i iloczyn skalarny – zrozumienie tego i gdzie to możemy zastosować. To są dwie magiczne operacje, które mają masę zastosowań, tak że polecam sobie o tym poczytać.

Potem umieć pracować w miarę swobodnie w danym silniku i po dostatecznie precyzyjnym opisie zaprogramować jakąś mechanikę, która funkcjonuje, czyli obsłużyć ten bazowy tutorial na stronie autorów silnika – to jest takie absolutne minimum.

Potem znać podstawowe zasady funkcjonowania i ograniczeń silnika, żeby unikać pewnych błędów. Nie możemy na przykład w tak zwanym updacie czy ticku, czyli tej instrukcji, która się wykonuje co klatkę, wywoływać funkcji przeszukiwania komponentów w drzewie sceny, bo wtedy zabijemy kompletnie wydajność. To jest taki najpopularniejszy, kardynalny błąd. Kiedy zdajemy sobie sprawę, jak coś działa, jakie są ograniczenia silnika, to wiemy, że takich rzeczy nie należy robić. Często ludzie się na tym wysypują.

No i oczywiście w momencie, kiedy chcemy zabłyszczeć, warto znać wzorce projektowe.

To może jeszcze jakieś przykłady właśnie tych wzorców, takie na początek, żeby wiedzieć, od czego zacząć.

Bazowo to singleton (chociaż jest uważany za antywzorzec), fasada, model view controller. Model view controller to jest absolutna bazówka, bo cały system, cała architektura gier zazwyczaj polega na tym, że rozdzielamy sobie warstwę danych, warstwę mechaniki, warstwę prezentacji, więc ten model view controller jest bardzo istotny.

Observer, czyli eventy, delegaty, tego typu rzeczy. Często wykorzystuje się też service locator, chociaż podejrzewam, że to w generalnych projektach IT jest uważane za antywzorzec, natomiast często może się przydawać w grach.

Dobra, to jednak wychodzi, że trochę tego jest, ale jak mówiłeś, jesteście w stanie to zrobić w sześć miesięcy, jeżeli tylko poświęcicie odpowiednią ilość czasu i będziecie mogli skupić się na tym, co robicie.

A czy jest jeszcze coś, co pomoże nam wyróżnić się na tle innych kandydatów, na przykład streamowanie, jak gramy, ale też jak opowiadamy o tym świecie i co się dzieje tam wewnątrz? Jest coś jeszcze, co może nam pomóc?

Jeżeli jesteśmy w stanie wykazać to, że analitycznie podchodzimy do gier, to jest to duża wartość. Widziałem też tego typu streamy, gdzie ktoś się uczył od zera, jak robi jakieś gry, i uczył się na bieżąco. To jest też na pewno ciekawe i bardzo otwarte podejście do tego, jak na przykład oceniamy swoje umiejętności.

Tworzenie własnych, nawet małych gier i opowiadanie o nich też jest czymś wartościowym. Własna strona z pracami, prezentacją kodu, nagraniami utworzonych mechanik, wyjaśnieniem rozwiązań. To jest umiejętność opowiadania o tym, co się robi i dlaczego tak się robi. Przekazanie tego procesu myślenia też jest niezwykle cenne.

No dobrze, to może jeszcze powiesz nam, jaką polecasz książkę albo książki, które pozwolą zostać młodym adeptem, programistą gier komputerowych?

Wszystkim, którzy w ogóle planują robić gry niezależnie od działki, polecam (z racji tego, że raz: to jest mój znajomy, a dwa, że to jest naprawdę dobra książka) książkę Patryka Polewiaka Tworzyć gry. Jest tam opisana praktycznie każda działka od strony tego, co trzeba wiedzieć, jak wygląda dzień pracy danej osoby w danym dziale i jakie są mroczne zakamarki pracy w danej działce. Tak że naprawdę to jest bardzo wartościowe kompendium wiedzy na start.

To może ja tylko tutaj powiem: podziękowania dla Patryka za to, że nas w ogóle skontaktował.

A tak, zdecydowanie, pozdrówka, Patryk.

Polecę taką klasyką, bo o tym się często zapomina, ale Niklaus Wirth, czyli Algorytmy + Struktury danych = Programy. To zbiór podstawowych algorytmów, które warto znać. Tego się uczy na studiach i często sam język programowania ma już zaimplementowane gotowe rozwiązania, ale też silniki do gier mają częściowo te algorytmy gdzieś tam w sobie zaszyte. Natomiast wciąż umiejętność czy wiedza na temat tego, jak to działa pod spodem, często pozwala nam dostosować to, co jest gotowe, do aktualnej potrzeby, co często jest bardzo dużą wartością przy tworzeniu gier.

Oczywiście jeżeli już czujemy się bardziej na siłach, to Scott Meyers, czyli język C++ efektywny czy bardziej efektywny, czyli Effective C++, Effective modern C++, oraz takie typowo gamedevowe, programistyczne, czyli Game Programming Patterns Roberta Nystroma i Game Engine Architecture Jasona Gregory’ego.

No to widzę, że będziemy mieli co robić. Pewnie książki dość rozbudowane, więc polecamy, żeby sobie zarezerwować trochę więcej czasu.

To na koniec, Grzegorzu, gdzie możemy Cię znaleźć w sieci, jeżeli ktoś będzie chciał coś podpytać, coś się dowiedzieć, to w jaki sposób możemy Cię znaleźć?

W sieci możecie mnie znaleźć, wpisując moje imię i nazwisko, ale wszystkie możliwe sociale prowadzę pod nazwą Okiem Deva. Jeżeli to wpiszecie w dowolnym miejscu w sieci, powinienem wyskoczyć: okiemdeva.pl, na YouTubie, na Medium. Prowadzę newsletter na beehiiv, gdzie wrzucam często kompendium ciekawych informacji, nadchodzących gier, wykłady, które mnie zaciekawiły w danym tygodniu. Jeżeli chcecie jednocześnie mieć trochę zabawy, trochę nauki, to zapraszam, bo co tydzień wysyłam subskrybentom pigułę najciekawszych rzeczy z Giereczkowa.

Super, zapraszamy wszystkich do odwiedzenia strony, sociali i do zapisania się do newslettera. Tobie, Grzegorzu, bardzo dziękuję za rozmowę i podzielenie się z nami tymi wszystkimi informacjami.

Również dziękuję bardzo za zaproszenie.