Jak zacząć przygodę z GameDev-em?

Cześć, z tej strony Mateusz Bogolbow z serwisu devmentor.pl. Z racji tego, że na co dzień uczę programowania, ten podcast tworzę z myślą o osobach, które są na początku swojej drogi programistycznej. Startujesz w branży IT? Zasubskrybuj ten podcast, aby nie ominął Cię żaden odcinek. Zaczynamy! Dziś moim gościem jest Mateusz Zawistowski. Mateusz opowie nam o branży gamedev, która jest nie tylko programistą, ale również producentem. Mateusze, dziękuję, że przyjechałeś w moje zaproszenie na rozmowę. Cześć, dzięki za zaproszenie. Jestem Mateusz i pracuję w branży gamedev już od 10 lat. Moją główną rolą jest Senior Unity Developer, czyli programista w technologii Unity. Natomiast oprócz stricte programowania zajmuję się też game producer, czyli takie połączenie zarządzania z projektowaniem gier, ponieważ programowanie i projektowanie to są dwie osobne rzeczy.

I też padam się mentoringiem IT, pomagam początkującym i średnio zaawansowanym programistom. w rozwoju, w nabywaniu nowych umiejętności, nowych kompetencji i w ramach usługi TechMentor prowadzę kurs Game Development w technologii Unity właśnie. To będziemy sobie jeszcze o tym mówić. Nie zdążyłem zadać pytania, czy możesz się przedstawić i powiedzieć, co łączy cię z branżą IT, ale od razu to zrobiłeś, więc super, więc przechodzimy do kolejnego pytania. Może zacznijmy właśnie od tych technologii, o których wspomniałeś. Jakie w ogóle warto znać, aby móc w ogóle tworzyć gry komputerowe i jakie ścieżki kariery może rozróżnić, no bo wiemy, że ich jest kilka, więc jakbyś mógł nam je przybliżyć. Kilka to niedoszacowanie. Ogólnie pierwsze pytanie, jakie należy sobie w ogóle zadać, to takie, czy chcemy konkretnie programować gry, ponieważ w gamedev jest kilka tych takich głównych kategorii rule.

I programista jest tylko jednym z nich. Są jeszcze graficy, projektanci, testerzy. Więc jeżeli już się zdecydujemy, że naszym powołaniem jest pisanie kodu, jest programowanie, no to wtedy musimy zdecydować się na wybór technologii. I tutaj technologii jest kilka i każda z nich ciągnie tak naprawdę za sobą to, do czego będziemy je stosować. I tutaj takie ścieżki mógłbym nakreślić przede wszystkim cztery. Są to takie dwie główne, Unity oraz Unreal Engine i jeszcze takie dwie niszowe, które ostatnio też zauważyłem na rynku, Godot oraz JavaScript. To może być tutaj wszedł tylko słowo, bo tak... Troszkę z innej działki bym powiedział. Często jest tak, że na przykład u mnie mamy frameworki, które są wykorzystywane, ale też często ludzie piszą w czystym javascriptie, tak zwanym vanilla.

Stąd właśnie ten podział na te silniki, gdzie właśnie Unity, Unreal Engine, Godot. Czyli w zasadzie stanowiska pracy typu w gamedevie C-Sharp developer raczej nie znajdziemy, jeżeli mówimy o kimś, kto ma tworzyć gry. Nie, tutaj te nazwy stanowisk dla programistów są kierowane technologiami tych silników, czyli właśnie Unity Developer, Unreal Engine Developer, Godot Developer i język programowania jest jakby elementem pracy, czyli jakby jeżeli mamy Unity Developera, no to... siłą rzeczy powinien, czy powinien, musi programować w C-Sharp, ponieważ C-Sharp jest językiem używanym do skryptowania w Unity. W przypadku Unreal Engine jest to C++, w przypadku Godota jest to C-Sharp albo Python, więc to są powiązane ze względu na specyfikę danej technologii. Natomiast tak, takim głównym znacznikiem, główną metodą rozróżniania technologii jest ta technologia growa.

Okej, no dobra, to kontynuuj, wybaczycie, przerwałem. Tak, to chciałem na początku krótko opowiedzieć o tych dwóch niszowych technologiach. Otóż wspomniałem o Godot oraz o JavaScript. Otóż w środku Godota to jest silnik do gier, stosunkowo nowy i stosunkowo prosty. Stara się on być konkurencją przede wszystkim wobec Unity i znajduje swoje zastosowanie głównie wśród gier niezależnych, wśród małych studiów czy też nadpojedynczych deweloperów. ze względu na swoją przystępność, zwłaszcza, że tutaj on wspiera programowanie w Pythonie, które, no dla niektórych Python może być bardziej przystępny niż na przykład C Sharp. Natomiast jest on na tyle niszowy, że raczej będzie ciężko znalezienie pracy w tej technologii, natomiast do własnych potrzeb można się go nauczyć i z nim korzystać.

W przypadku JS natomiast jest tak, że są pewne kategorie gier, pewne gatunki gier, głównie gier przyglądarkowych, które bardzo mocno korzystają z takich typowo frontendowych kompetencji, czyli HTML, JSS, JavaScript i do tego dorzucają zazwyczaj jakiś framework, który powstał z myślą o grach, no to i najczęściej pojawia się jako taki framework PixieJS. Natomiast ponownie, są to niszowe specjalizacje, ofert pracy w nich jest raczej niewiele, więc podaję to raczej jako ciekawostkę. Natomiast takimi głównymi specjalizacjami są właśnie Unity i Unreal Engine. I zacznę od Unity, to jest właśnie moja specjalizacja. Unity to jest jeden z dwóch najpopularniejszych silników do tworzenia gier współcześnie na rynku. ... wykorzystuje C-Sharp do skryptowania i jest dosyć uniwersalnym silnikiem, jeśli chodzi o zastosowanie. Można w nim robić gry komputerowe, gry na konsolę, gry na Google VR, gry mobilne i w praktyce najczęściej jest to silnik stosowany właśnie do gier mobilnych oraz do tak zwanych gier niezależnych, czyli gier o niskim bądź średnim budżecie.

Jeśli chodzi o próg wejścia, powiedziałbym, że on jest taki średni, ponieważ takim wymogiem żeby móc biegle się posłuchać Unity jest najpierw dosyć zaawansowana znajomość samego języka C Sharp i pewnych prawidł programowania, które wraz z tym idą. I właśnie jest to moja specjalizacja, moja ścieżka i właśnie ta ścieżka będzie uwzględniona w kursie na DevMentor. to może dopytałbym odnośnie tej ścieżki Unity, bo tak wspomniałeś o tym, że ona dotyczy raczej gier z mniejszym powiedzmy nakładem, mniejszym budżetem. Czy w takim razie zazwyczaj wygląda to w taki sposób, że zaczynamy od Unity, zdobywamy doświadczenia, potem idziemy w stronę Unreal'a, czy raczej też można trafić na rynek zaczynając od Unreal'a właśnie tworząc gry?

Jak najbardziej można zacząć od Unreala, zwłaszcza jeżeli bardzo konkretnie jesteśmy nastawieni na pracę przy tych większych produkcjach. Natomiast Unreal Engine charakteryzuje się tym, że ma wyższy próg wejścia od Unity. I to wynika z kilku rzeczy. Pierwsza jest taka, że Unreal Engine jest znacznie... potężniejszym, a co za tym idzie, wymagającym sprzętowo silnikiem niż Unity. Jeżeli ktoś nie dysponuje jakimś droższym sprzętem, nie wiem, na przykład laptopem gamingowym za 10 tysięcy albo więcej, no to może mieć problemy z tym, żeby Unreal Engine w ogóle odpalić, żeby w ogóle jakoś w miarę sensownie mu to chodziło. To jest jedna rzecz. Druga rzecz jest taka, że głównym językiem do skryptowania w Unreal Engine jest C++, a C++ jest językiem bardziej niskopoziomowym niż C Sharp, co oznacza, że jest mniej przystępny, ma trochę bardziej skomplikowaną składnię i wiele czynności, które w C Sharpie czy też w innych językach wysokopoziomowych są ogarniane automatycznie, takie jak zarządzanie pamięcią,

alokowanie pamięci, zwalnianie jej. W C++ trzeba robić to ręcznie i to jakby ciągnie ze sobą cały szereg nowej wiedzy, którą trzeba zgłębić, żeby w ogóle móc się biegle C++ posługiwać. Więc po prostu jest to trudniejszy język i trudniejsza technologia do opanowania, zwłaszcza dla początkującego programisty. Więc Unity może być takim pierwszym krokiem, jeżeli chcemy przyswoić sobie jakąkolwiek technologię do robienia gier, ale mieć ją trochę bardziej przystępną. Natomiast później tak naprawdę stoimy przed decyzją, czy idziemy już w specjalizację Unity, ponieważ Unity sama w sobie też ma ogrom wiedzy, którą senior developerzy zgłębiają, w której się specjalizują, czy też właśnie robimy ten schok bok, zmieniamy naszą ścieżkę i wtedy uczymy się Unreal Engine.

występują często przejścia z Unity na Unreal Engine w drugą stronę, trochę rzadziej, ale też występują. Jest to głównie motywowane tak naprawdę tym, czego akurat aktualnie oczekuje rynek pracy. A powiedz mi proszę, bo tak wspominałeś o tym, że Unity pozwala nam tworzyć na różne platformy aplikacje, czy w przypadku Unreala też tak jest, czy raczej tutaj skupiamy się tylko na tych głównych platformach, mam tu na myśli, nie wiem, PC, jakieś Xboxy, PlayStation i tak dalej? Teoretycznie Unreal Engine jest równie portowalny co Unity, natomiast praktyka pokazuje, że Unreal Engine prawie wcale nie jest używany do gier mobilnych oraz do gier projektowanych z myślą o platformach mobilnych, takich jak np. Switch czy Steam Deck, z takiej przyczyny, że jest po prostu zbyt obciążający.

Jest to potężna machina, która służy do generowania i symulowania mega detalicznych, realistycznych światów, I to jest takie trochę overkill, jeżeli chcemy zrobić prostą gierkę mobilną, w której sobie po prostu robimy Candy Crusher na przykład. Więc z tym jest problem, plus w przypadku VR, wirtualnej rzeczywistości, tutaj też w tej niszy głównie dominuje Unity, z tego względu, że Google VR dla komfortu doświadczenia wymagają bardzo... wysokiej częstotliwości odświeżania obrazu, mówimy tutaj tak no minimum 90 Hz, a najlepiej 120 albo 144, do tego jeszcze w dużej rozdzielczości, więc ponownie próba odpalenia gry zrobionej na Unreal Engine z całą zaawansowaną grafiką w tak dużej rozdzielczości, w tak dużej częstotliwości odświeżania obrazu, tym bardziej na Google'ach tak zwanych standalone, które nie są podłączone do komputera, tylko działają tak samodzielnie, na przykład MetaQuest 3,

tutaj możemy natrafić na niewydolność sprzętu. Po prostu nie będzie w stanie tego ogarnąć. Natomiast Unity samo w sobie jest lżejszym silnikiem. Ponadto posiada tryb oddzielny renderowania dla gier o dużym zaawansowaniu graficznym. Jest tzw. HDRP, czyli High Definition Rendering Pipeline i jest do lżejszych zastosowań tzw. URP, Universal Rendering Pipeline. I przełączając, czy może przełączając, tworząc swój projekt, konkretnie w tym jednym rendering pipeline'ie, mówię tutaj o URP, pewne możliwości graficzne wyłączamy, tak jak na przykład ray tracing, ale w zamian za to otrzymujemy bardziej wydajny, mniej wymagający rendering grafiki, dzięki czemu jesteśmy łatwiej i szybciej zrobić grę dostosowaną na przykład pod gogol wirtualnej rzeczywistości.

Z jednej strony otrzymują oni głębsze wsparcie, też może nawet jakieś pieniądze za to, że jakby dokonali tej decyzji, bo też istotną rzeczą jest to, że silnik, technologię promują gry na nie zrobione. Więc Wiedźmin 4 z jednej strony jest to gra, ale z drugiej strony jest to takie, można powiedzieć, demo, taka pokazówka tego, do czego Unreal Engine 5 jest zdolny. Więc to jest jedna przyczyna tej decyzji. Druga przyczyna jest taka, że gdy studio decyduje się na pracę w swoim własnym silniku, to siłą rzeczy tworzą sobie taką barierę pod tytułem mamy na rynku pewną ilość dostępnych do zatrudnienia Unreal Engine developerów, ale nie ma Red Engine developerów, bo to jest zamknięty silnik, on nie jest dostępny dla przeciętnego zjadacza chleba.

Z jakością już bywa różnie, zwłaszcza ostatnimi laty. I właśnie ten silnik jest najbardziej dominujący w tym segmencie. Jakby gier AAA powstających na Unity nie ma prawie, że wcale. Natomiast ostatnio, ostatnimi laty wytworzył się też taki nowy segment, AA. który jest czymś pomiędzy grami niezależnymi, które charakteryzują się pewną prostotą, niskim budżetem, a właśnie grami 3Play, które są takimi megaprodukcjami. Otóż m.in. ze względu na postęp technologiczny oraz wytworzenie się pewnych nowych schematów i etosów pracy, wytworzył się taki segment, który z jednej strony tworzy gry, które są znacznie mniejsze, jeśli chodzi o scope od gier 3Play, na przykład są krótsze, nie mają otwartego świata, tylko zamknięty, ale z drugiej strony ich jakość wykonania w ogóle nie odstaje od gier AAA.

To jest zupełnie inna skala, jeśli mówimy chociażby o koordynacji i organizacji pracy. A czy jesteśmy w stanie powiedzieć, jaki... Część rynku zajmują, nie wiem, programiści Unity, a jaką część programiści Unreal, no bo jeżeli tych produkcji AAA jest kilka, kilkanaście, no a tych mniejszych jest dużo więcej, to tak statystycznie, czy na rynku jest więcej ofert pracy dla Unity? czy jednak dla Unreal developerów, dlatego że tam właśnie mamy setki tych programistów w przypadku takich produkcji, czy jednak skala, czyli ilość tych małych projektów jest dużo większa? Wiesz co, na przestrzeni ostatnich lat trochę się to zmieniło, głównie ze względu na zwiększenie popularności Unreal Engine, właśnie gdy wypierał domowe silniki poszczególnych studiów.

Powiedziałbym, że jeszcze parę lat temu Unity miało tak może z 60-70% ofert pracy na takim ogólnym rynku polskim. Natomiast na dzień dzisiejszy powiedziałbym, że zbliża się to bardziej do 50-50. Ale trzeba też zwrócić uwagę na jedną rzecz, że to nie są dokładnie takie same oferty pracy, ponieważ ze względu na specyfikę pracy studiów AAA, oferty pracy Unreal Engine to często oferty stacjonarne. większość studiów 3Play w ogóle nie oferuje pracy zdalnej. Czasami jest to praca hybrydowa. Natomiast ze względu na różne rzeczy, kulturę pracy, organizację pracy, ale także pewną poufność chociażby dostępu do plików, jest to praca często właśnie na miejscu, w konkretnej lokalizacji. Podczas gdy w przypadku gier postępstw na Unity, głównie mobilnych, te firmy są znacznie bardziej otwarte na pracę zdalną.

Czyli teoretycznie rynek jest większy, bo możemy też pracować dla wielu różnych destynacji, jeżeli nie planujemy przeprowadzki. Tak, dokładnie. Na przykład gdybym nagle zechciał, jako Unreal Engine Developer, gdybym takowym był, gdybym nagle zechciał pracować na przykład w Rockstar Games, no to czekałabym przeprowadzka do Stanów Zjednoczonych. Gdybym chciał pracować dla Ubisoftu, no to musiałbym się przeprowadzić do Francji albo do Kanady. Jeśli chcę pracować przy Wiedźminie 4, no to siłą rzeczy muszę mieszkać w Warszawie albo w okolicach Warszawy. Natomiast jeżeli pracuję jako developer w takim czy innym projekcie gry mobilnej albo gry niezależnej, tak naprawdę mogę siedzieć tu, gdzie jestem teraz na zdalnym. No dobrze, to porozmawialiśmy sobie na temat silników, sporo czasu zeszło.

Natomiast w środku gier AAA pojawiają się często bardzo specyficzne specjalizacje, bo już wewnątrz istnieją specjalizacje. Czyli np. jak mamy Unreal Engine dewelopera, to w dostatecznie dużych projektach AAA powstają specjalizacje np. na dewelopera AI. Mówię tutaj o tym, jak się zachowują postacie w grze. Jest np. deweloper odpowiadający tylko i wyłącznie za kamerę, za to, jak ona działa, jak się porusza, jak reaguje na różne czynności gracza. W przypadku artystów są artyści tzw. character artists, którzy zajmują się tylko postaciami. Environment artists, którzy zajmują się tylko elementami otoczenia. Lighting artists, którzy zajmują się rozstawianiem i regulowaniem światełek na poszczególnych scenach, żeby to tak ładnie cinematic wyglądało.

Więc właśnie im większy projekt, im większy zespół, im większy budżet, tym bardziej w wąskie role specjalizacji idziemy. Natomiast w projektach o niższym budżecie raczej idziemy w generalizm. Rozumiem, że o tym, co teraz przed chwilą powiedziałeś, czyli o tych takich szczególnych... rozwiązaniach, to dopiero na wyższych poziomach, tak? Juniorzy raczej nie dostają takich szczegółowych zadań. Nie, absolutnie. To jakby tutaj jest stara zasada, że zanim się będzie biegać, najpierw trzeba chodzić, więc najpierw się trzeba otrzaskać dobrze w takim ogólnym obyciu jako programista, czyli dotrzeć do tego poziomu takiego silnego mida, albo najlepiej już doświadczonego seniora jako generalista. I dopiero wtedy jest właśnie ten moment, w którym jakby co po seniorze, co chcemy robić dalej. Tu możemy właśnie obrać jakąś konkretną specjalizację.

Jeżeli widzimy jakąś niszę w branży, w której chcemy się może bardziej na stałe zadomowić, albo niektórzy deweloperzy decydują się pójść właśnie w role bardziej producenckie, zarządzające. Tak, natomiast właśnie juniorzy raczej pozostają generalistami przez jakby całość swojego juniorstwa. No dobrze, no to jak tak zahaczyliśmy o ten temat, to może powiedzmy, od czego warto zacząć naukę, aby właśnie nie wpaść w jakiś taki ślepy zaułek po paru miesiącach wydarzonej pracy i myśleć już o porzuceniu tego tematu. Więc jak do tego podejść, żeby osiągnąć sukces? To tak opowiem, bazując stricte na ścieżce Unity. Otóż w pierwszej kolejności polecam, zanim w ogóle się weźmiemy za Unity i za gry, nauczyć się programowania jako takiego. Czyli zacząć naukę C-Sharpa, nauczyć się składni, nauczyć się później programowania obiektowego, nabić też pewną wiedzę teoretyczną dotyczącą programowania.

Mówię tutaj o takich rzeczach jak dobre praktyki, wzorce, antywzorce, solid. I może się to wydawać na początek takie trochę rozmieniające z celem, dlaczego uczymy się o jakichś dziwnych zasadach, prawidłach, gdy ja chcę po prostu robić gierki. Natomiast prawda jest taka, że gra komputerowa to jest program komputerowy, który się programuje. I jeżeli rzucimy się najpierw w Unity i zaczniemy się uczyć o wszystkich rzeczach, które dotyczą Unity, to nas to przytłoczy, bo wtedy mamy cały wór wiedzy związany z Unity. i jeszcze cały wór wiedzy związany z programowaniem jako takim, którego nie opanowaliśmy. I powiem, że widziałem kilka takich przypadków, gdzie ktoś właśnie zaczynał od tej strony, że najpierw Unity, a dopiero potem się będę douczał programowania. I te osoby bardzo kluczyły. Przede wszystkim jedyne, co były w stanie robić, to korzystać z gotowców, coś tam sobie posklejać.

I może czasami nawet coś z tego by chodziło, ale ani to się nie nadawało do wydania na rynek, ani to się nie nadawało do długoterminowego rozwoju. A co najgorsze, twórcy takich dzieł nie rozumieli w ogóle, na czym to polega, jak to działa. Więc to się totalnie mija z celem, to jest tylko zmarnowany czas. Stąd zawsze powtarzam, żeby najpierw się nauczyć programowania, a dopiero jak opanujemy programowanie, tak przynajmniej do poziomu średniozaawansowanego, wtedy możemy już przejść do tej specjalizacji w programowaniu, jaką jest Unity i tworzenie gier. I co dalej? Jeżeli mamy już te fundamenty, to jeśli chodzi o Unity, to od czego tam warto zacząć, co trzeba robić, jaką świadomość mieć na temat komputerów, żeby po prostu wiedzieć, jak osiągnąć też nasz cel, nie wiem, utworzenie pierwszej gry, czy znalezienie pierwszej pracy.

Natomiast jeśli chodzi o samo programowanie gier Unity, no to cóż, tam się pojawia całe mnóstwo narzędzi, za pomocą których możemy po prostu sobie tą naszą grę posklejać. Więc jest cały silnik fizyczny z detekcją kolizji, z nadawaniem sił i jakby patrzeniem, jak poszczególne obiekty, poszczególne ciała reagują na te siły. Jest cała tak zwana przestrzeń kartezjańska, czyli przestrzeń trójwymiarowa, w której nasze obiekty... rozmieszczamy, to jest te słynne XYZ, trzy numerki, które są koordynatami. Jeżeli ktoś na przykład grał kiedyś w Minecrafta i się zgubił w swoim świecie i odpalił F3, żeby zobaczyć tam te numerki, no to jest właśnie przestrzenka tezjańska. Co jeszcze mogę dodać? Jeszcze wspomniałem o fizyce. Powiedziałbym, że fizyka na poziomie, no powiedzmy liceum podstawowego, czyli przede wszystkim dynamika newtonowska, prawa właśnie dynamiki newtona,

Co warto rozważyć przy rozsyłaniu CV? Co warto do niego dodać? No co tam nas wyróżni na tle konkurencji? Tak patrząc z perspektywy Junior Unity David Opera, który szuka swojej pierwszej pracy, to jeśli chodzi o takie rzeczy, które powinien mieć, to moim zdaniem angielski na poziomie komunikatywnym, zarówno w mowie, jak i w piśmie, ponieważ bardzo dużo odsetek projektów jest rozwijanych przez firmy i zespoły międzynarodowe, więc nieuchronnie ten angielski na daily stand-upach, na spotkaniach. się pojawi. Niemalże cała dokumentacja oraz wartościowa wiedza odnośnie game developmentu, odnośnie Unity programowania jest w języku angielskim, więc po prostu musimy znać to angielskie na tyle dobrze, żeby móc to czytać ze zrozumieniem. No i też raz w jakiś czas będziemy taką dokumentację sami pisać, więc tutaj ponownie jakiś składny angielski by się przydał.

Tego poziomu, na przykład powiedzmy A2... Nie ma się czym stresować. Sama nauka programowania i Unity na tyle się wiąże z obcowaniem z językiem angielskim, że sama w sobie ten angielski rozwija. Bo jakby nie patrzeć, będziemy czytać dokumentację, będziemy uczyć się programowania, gdzie w programowaniu, jakby nie patrzeć, używamy mnóstwo angielskich słówek. Będziemy oglądać jakieś tutoriale czy inne ciekawe materiały, na przykład na YouTube, po angielsku. Więc te kompetencje językowe będą się mimochodem też rozwijały. Natomiast jeśli chodzi o jeszcze inne wymagania wobec junior entity developera, no to tak, no to off-stage robisz, wspomniałem, znajomość przynajmniej na poziomie średnio zaawansowanym, znajomość też rzeczy takich ogólnoprogramistycznych, jak paradygmaty programowania, przede wszystkim programowanie obiektowe, troszeczkę też programowanie funkcyjne. znajomość zasad solid, znajomość też dobrych praktyk, złych praktyk, wzorców projektowych, tak nie tylko enumeratywnie, że potrafię je wymienić z głowy, ale też jestem w stanie na ich temat trochę podyskutować.