![Chcesz wejść do gamedevu? Dzisiaj samo CV może nie wystarczyć [WYWIAD]](/_next/image?url=https%3A%2F%2Fkonto.chip.pl%2Fwp-content%2Fuploads%2F2026%2F06%2Fgamedev-wejscie-wywiady-gic-sprint.jpg&w=1920&q=90)
Mam wrażenie, że przez długi czas sprzedawano młodym ludziom dość wygodną historię. Naucz się Unity albo Unreala, zrób portfolio, pokaż kilka screenów, napisz w CV, że kochasz gry, a potem cierpliwie czekaj na pierwszą szansę. Problem w tym, że sama miłość do gier nie znaczy dziś właściwie nic. W tej branży prawie każdy kocha gry. Liczy się raczej to, czy kandydat potrafi coś zbudować, doprowadzić do końca, opowiedzieć o swoich decyzjach i pokazać, że rozumie nie tylko narzędzie, ale też sam proces.
Czytaj też: GIC Sprint 2026 właśnie rusza pełną parą, a my jesteśmy na miejscu
Najmocniej wybrzmiało to w kilku rozmowach, które przeprowadziłem podczas tegorocznego GIC Sprint w Katowicach. Rozmawiałem bowiem z osobami z różnych obszarów gamedevu – od programowania, przez portowanie i optymalizację, po quest design. Ich perspektywy różnią się wprawdzie specjalizacją, ale prowadzą do podobnego wniosku – dziś do gamedevu nie wchodzi się deklaracją. Wchodzi się dowodem swojego potencjału. Więcej na ten temat mówią:
- Grzegorz Wątroba – programista gier specjalizujący się w architekturze kodu, optymalizacji i portowaniu, związany m.in. z PixelAnt Games, Fool’s Theory i wieloma studiami w modelu konsultingowym. Twórca na kanale Okiem Deva.
- Konrad Słoń – Senior Gameplay Programmer w Fool’s Theory, który opowiedział mi o gamedevie od strony dużych systemów, gameplayu i technicznych konsekwencji pracy przy rozbudowanych RPG-ach.
- Katarzyna Władyka – doświadczona quest designerka i narrative designerka znana z pracy przy The Thaumaturge, Wiedźminie 3 i Cyberpunku 2077, która mocno akcentuje różnicę między pisaniem historii a projektowaniem narracji w grze.
Kryzys zatrudnienia minął tylko częściowo. Juniorzy dalej mają pod górkę
Z perspektywy graczy ostatnie lata mogły wyglądać wręcz świetnie. Premiery przychodziły jedna po drugiej, wielkie tytuły walczyły o czas odbiorców, a 2023 rok do dziś bywa wspominany jako jeden z najmocniejszych okresów dla samego grania. Problem w tym, że dla ludzi pracujących w branży ten sam okres wyglądał zupełnie inaczej.
Generalnie kryzys w branży jest obecny w zasadzie od końca pandemii. – mówi Grzegorz Wątroba.
Paradoks 2023 roku polegał na tym, że gracze dostali mnóstwo świetnych gier (m.in. Baldur’s Gate 3, The Legend of Zelda: Tears of the Kingdom, Resident Evil 4, Alan Wake 2, Super Mario Bros. Wonder, Street Fighter 6, Hi-Fi Rush, Final Fantasy XVI, Dead Space Remake, Armored Core VI, Marvel’s Spider-Man 2 i Cyberpunk 2077: Phantom Liberty), a ludzie robiący gry coraz częściej tracili pracę.
Szczyt zwolnień był bardzo paradoksalny, bo 2023 to był jeden z najlepszych lat dla graczy. Praktycznie co tydzień był jakiś hit, a jednocześnie to był czas największych zwolnień w branży, bo zwolniono kilkanaście tysięcy osób.
Dla odbiorcy liczy się gotowy produkt. Dla branży liczy się też to, co dzieje się za kulisami – zamykane projekty, sprzedawane spółki, restrukturyzacje, odpływ specjalistów i zespoły, które nagle muszą robić mniej albo inaczej.
Gracze nie zauważyli, że była totalna pożoga w branży, jeżeli chodzi o zatrudnienie. Firmy upadały, duże korporacje się rozpadały, sprzedawano spółki, zamykano projekty. Bardzo to dotknęło branżę.
Według Grzegorza Wątroby w 2025 roku pojawił się pierwszy wyraźniejszy sygnał odbicia, bo liczba ofert pracy zaczęła przewyższać liczbę zwolnień. Nie znaczy to jednak, że rynek juniorów nagle odżył.
W 2025 mimo dużej liczby zwolnień w końcu liczba ofert pracy była wyższa niż liczba zwolnień. To był pierwszy punkt przegięcia. Powolutku to się dźwiga, natomiast bardzo wolno.
Największy problem początkujących polega dziś na tym, że konkurują nie tylko z innymi początkującymi. Po zwolnieniach na rynku pojawili się ludzie z doświadczeniem, a firma w niepewnych czasach naturalnie wybiera mniejsze ryzyko.
Rynek dla juniorów jest bardzo mały i wymagający. Na rynku mamy dużo specjalistów, którzy nie pracują, są wolni, dostępni, zwiększają pewność projektu bardziej niż junior, którego trzeba przystosowywać do pracy.
Nie jest więc tak, że juniorzy są skreśleni. Firmy nadal ich szukają, ale mniej chętnie biorą kogoś tylko dlatego, że “ma potencjał”. Potencjał trzeba dziś udowodnić szybciej i konkretniej.
Firmy dalej poszukują juniorów, tylko że oni muszą mieć określony zestaw umiejętności. Nie jest totalnie źle, ale jest ciężko. Zmieniły się wymagania.
Próg wejścia nie jest tylko wyższy. Jest inny
Najciekawsze w tej rozmowie nie było jednak samo stwierdzenie, że jest trudno. Tyle wie każdy, kto choć raz próbował wejść do branży w ostatnich latach. Ważniejsze jest to, dlaczego trudno. Grzegorz Wątroba nie mówi, że próg wejścia po prostu urósł. Raczej przesunął się w inne miejsce. Kiedyś brak gotowego projektu był łatwiejszy do zrozumienia. Wiedza była trudniej dostępna, silniki nie były tak otwarte, a materiały do nauki nie wyskakiwały z każdej strony Internetu.
Próg wejścia totalnie się zmienił w stosunku do tego, czego ja sam doświadczałem. 16 lat temu nie było tylu tutoriali na YouTubie. Wiedza o robieniu gier głównie była w książkach, a nie w internecie. Nie było żadnego darmowego silnika, trzeba było samemu pisać te silniki i się uczyć.
W tamtym świecie kandydat mógł przyjść z mocną teorią i dostać szansę na praktyki. Dziś sytuacja jest inna, bo narzędzia są na wyciągnięcie ręki. Unity, Unreal, Godot, Twine, Ink, darmowe assety, tutoriale, sample, dokumentacje i AI sprawiły, że samo “nie miałem jak spróbować” brzmi coraz słabiej.
Teraz, mając całą wiedzę na świecie w internecie za darmo, mając dwa największe silniki, które trzęsą 70 procentami branży i są dostępne za darmo, jaki jest próg wejścia? Skoro jedyne, czego ci brakuje, to determinacja i czas, żeby cokolwiek zrobić, to się nie pokazuj bez swojej gry.
To wprawdzie mocne zdanie, ale nie chodzi w nim o wymaganie, żeby każdy junior wydał od razu pełnoprawną grę na Steamie. Chodzi o dowód, że kandydat potrafi przejść od pomysłu do działania. Nawet w małej skali.
Chcesz być w gamedevie, to wydaj swoją grę. Chcesz być w gamedevie, naucz się robić rzeczy od początku do końca. I jeszcze naucz się opowiadać o tym.
Najważniejsze jest tutaj ostatnie zdanie. Opowiadanie o projekcie bywa równie ważne jak sam projekt, bo w pracy zespołowej nie wystarczy “coś zrobić”. Trzeba jeszcze umieć wytłumaczyć, dlaczego zrobiło się to w taki sposób, jakie były ograniczenia, co nie wyszło i co poprawilibyśmy następnym razem.
To nie musi być oczywiście gra wydana na Steamie. Wystarczy pokazać, że się umie zaimplementować jakiś pomysł, nawet jeżeli to nie jest kompletna gra. Zaimplementować pomysł, wrzucić na GitHub, wrzucić filmik na YouTube, jak się to zrobiło, jakiś opis. To jest świadectwo umiejętności, które daje pracodawcy pewność, że jesteś w stanie dowieźć rzeczy.
Z tego punktu widzenia portfolio przestaje być galerią screenów. Staje się dowodem sposobu myślenia. Mała gra, mikromechanika, mod, interaktywny quest, odtworzona minigra, system dialogów, narzędzie w edytorze – wszystko to może powiedzieć więcej niż linijka w CV o znajomości Unreala.
W małym studiu jesteś od wszystkiego. W dużym musisz dogadać się z mikrofirmami wewnątrz firmy
Wielu początkujących patrzy na gamedev przez pryzmat prostego obrazu – studio robi grę, a każdy dział robi swoje. Programiści programują, designerzy projektują, artyści robią grafikę, scenarzyści piszą dialogi. Taki opis jest formalnie prawdziwy, ale mało mówi o realnym procesie.
Konrad Słoń, Senior Gameplay Programmer w Fool’s Theory, dobrze pokazuje różnicę między małą i dużą skalą produkcji. W małych zespołach specjalizacja bywa niczym innym, jak luksusem i sam mogę się pod tym podpisać. Ma to jednak swoje plusy, bo dzięki temu, że niegdyś zamiast “tylko programować”, musiałem wchodzić znacznie głębiej do projektu, to samodzielny rozwój i marketing mojej autorskiej gry DIGSITE ZERO nie doprowadził mnie do szaleństwa.
W małej skali dużo osób ma najczęściej doświadczenie z małą skalą. Pracują sobie z jakimiś studentami. Wiadomo jak to wygląda. Jak jest programista, to jest programista. Nieważne czy ty masz programować AI, UI, czy cokolwiek. Musisz to zaprogramować, bo jest was i tak mało. – tłumaczy Konrad Słoń.
W takim środowisku często nie ma pełnego zestawu ról. Designerów może być mało albo nie ma ich wcale. Tech artysta bywa abstrakcją. Producent, QA czy play designer to role, na które zwyczajnie nie ma budżetu albo miejsca.
W małych firmach czasami w ogóle nie ma designerów. Rola tech artysty też może nie istnieć, a niektórzy nawet nie do końca wiedzą, po co taka osoba jest potrzebna. Podobnie bywa z producentem, QA czy play designem.
Zaletą małej skali jest komunikacja. W pięcioosobowym zespole każdy zna każdego, a wiele rzeczy da się ustalić jednym zdaniem. W dużej produkcji problem wygląda zupełnie inaczej. Tam zespoły zaczynają przypominać mikrofirmy działające wewnątrz większej firmy.
Przy skali AAA, gdy w firmie pracuje kilkaset osób, sam gameplay może być podzielony na mniejsze zespoły: od UI, AI, questów i innych obszarów. Te zespoły działają trochę jak mikrofirmy wewnątrz większej firmy.
Dla juniora to ważna lekcja. W dużym studiu nie wystarczy umieć zrobić “swojego kawałka”. Trzeba rozumieć zależności, komunikację, odpowiedzialności i to, że każda zmiana może dotknąć kilku zespołów.
Quest designerzy mogą potrzebować czegoś od zespołu AI. Idą więc do programistów AI i mówią: wystawcie nam takie narzędzie. Zespół AI pyta wtedy, po co jest ono potrzebne, dlaczego akurat tak i czy nie da się tego zrobić prościej. Potem narzędzie powstaje, quest designerzy zaczynają go używać, coś nie działa, brakuje dokumentacji i trzeba zorganizować rozmowę, żeby wszystko doprecyzować.
W większych produkcjach pojawiają się tymczasowe zespoły powoływane do dowiezienia konkretnej funkcji. Nie chodzi o stały dział, tylko o ludzi z różnych obszarów, którzy na chwilę spotykają się wokół jednego problemu.
Przy większym featurze często tworzy się tymczasowy zespół. Bierze się osoby potrzebne z kilku działów – na przykład programistów od AI, UI, questów i designera – żeby przez jeden sprint dowieźć konkretną rzecz. Potem taki zespół się rozwiązuje i powstaje kolejny, już do innego zadania.
Innymi słowy, praca w dużym studiu szybko niszczy wyobrażenie, że gamedev to głównie swobodna twórczość bez większych ograniczeń. Bardziej przypomina ciągłą synchronizację ludzi, narzędzi, potrzeb i ograniczeń.
W małym zespole pierwsze rozwiązanie często zostaje na zawsze
Konrad Słoń zwraca uwagę na jeszcze jedną wielką różnicę między małą i dużą produkcją. Duże studio zabezpieczone finansowo może czasem pozwolić sobie na zmianę kierunku, dodatkowe trzy tygodnie pracy albo przebudowanie feature’u, jeśli testy pokażą, że ten po prostu nie działa. Małe zespoły często nie mają takiej przestrzeni.
W małych firmach jest polityka golden shotów. Twoje pierwsze rozwiązanie musi być dobre, bo jak nie będzie dobre, to już nie ma czasu i musi zostać.
To zdanie szczególnie dobrze pasuje do realiów początkujących zespołów i projektów studenckich. Bardzo często pierwsza wersja systemu staje się finalną nie dlatego, że jest dobra, tylko dlatego, że zwyczajnie nie ma czasu na drugą.
Gry robione pod taką presją czasu nie są doszlifowane, bo osoby produkujące system nie miały czasu, żeby go dopracować. Musiały podjąć decyzję – doszliśmy do tego punktu i nie możemy tego poprawić, bo musimy iść dalej.
W praktyce oznacza to, że junior w małym studiu może szybciej dotykać wielu obszarów, ale też szybciej odczuje konsekwencje błędnych decyzji. W dużym studiu łatwiej o proces, mentorów i specjalizację, ale trudniej zrozumieć pełen obraz gry. Obie ścieżki uczą czegoś innego.
Programista robi klocki, ale designer musi umieć z nich zbudować sensowną mechanikę
Często mówi się, że programista jest podstawą studia, bo “pisze kod”. W praktyce jego rola w nowoczesnej produkcji bywa ciekawsza. Dobry gameplay programmer bardzo często nie tylko implementuje system, ale wystawia narzędzia, z których później korzystają designerzy. Konrad Słoń opisuje to na przykładzie pracy w Unrealu.
Nowocześniejsi designerzy mówią, czego potrzebują, żeby ustawić jakiś system. Ty część wykonujesz w kodzie, a część wypychasz na silnik. Oni na Blueprintach mogą sobie to poukładać po swojemu, mogą stworzyć dane, których domyślnie nie ma. Wystawiasz im klocki, a oni sobie z tych klocków coś budują. – tłumaczy Konrad Słoń.
Ten obraz jest dla mnie bardzo ważny, bo dobrze pokazuje, czego często brakuje w portfolio początkujących programistów. Nie chodzi tylko o to, czy system działa. Chodzi o to, czy ktoś inny może go użyć. Czy designer rozumie, co dostał? Czy narzędzie ma sens? Czy da się je debugować? Czy nie rozwala wydajności? Czy jego ograniczenia są jasne?
Ja nawet do końca nie wiem, jak oni użyli rzeczy, które im wystawiłem, dopóki nie zacznie być problematycznie pod względem wydajności albo nie wyjdą dziwne bugi. Wtedy trzeba prześledzić tę ścieżkę i im pomóc.
Dla juniora to konkretna wskazówka. Projekt w portfolio może być czymś więcej niż samodzielną grą. Może być narzędziem, systemem, małym edytorem, rozwiązaniem przygotowanym tak, żeby ktoś inny mógł z niego skorzystać. Taki projekt mówi o kandydacie więcej niż kolejny klon gierki z tutoriala, bo pokazuje myślenie stricte produkcyjne.
Najgorsza odpowiedź juniora? “Bo AI mi tak wypluło”
Sztuczna inteligencja naturalnie pojawia się w rozmowie o juniorach, bo trudno dziś udawać, że nie zmieniła nauki programowania. AI potrafi przyspieszyć research, podpowiedzieć rozwiązanie, streścić dokumentację, pomóc z debugowaniem albo wygenerować szkielet kodu. Problem zaczyna się wtedy, gdy początkujący traktuje ją jak zastępstwo dla rozumienia. Konrad Słoń mówi o tym bardzo konkretnie. AI jest używane także w codziennej pracy, ale raczej jako wsparcie, a nie autopilot.
Używam ChatGPT bardziej researchowo. Zamiast szukać w dokumentacji Unreala, wpisuję ogólny przykład i szukam typu albo use case’u. Potem patrzę na to, co mi wypluje, i stwierdzam: to jest dobry pomysł, to jest do niczego, to można zaadaptować.
Taki model ma sens tylko wtedy, gdy osoba korzystająca z AI umie ocenić wynik. Bez tego narzędzie bardzo szybko staje się generatorem złudnej pewności.
AI nie generuje idealnego kodu. Musisz mieć wizję programistyczną, żeby dobrze używać AI. Dużo lepiej działa, gdy nie piszesz “zrób mi X”, tylko “zrób mi X używając takiego wzorca, bo chcemy osiągnąć to i to”. Ale żeby tak napisać, musisz znać ten wzorzec i rozumieć programowanie.
Jeszcze większy problem pojawia się tam, gdzie dokumentacja jest słaba albo narzędzie działa w bardzo specyficznym środowisku. Wtedy AI zaczyna zgadywać, a gdy zgaduje pewnym głosem, początkującemu bardzo łatwo pomylić błąd z rozwiązaniem.
Im mniej masz dokumentacji na dany temat, tym bardziej AI będzie wymyślał. W Unity kod edytorowy jest słabo udokumentowany. Potrafił mi wrzucać zmienne, które jego zdaniem robią to, czego chcę, a których faktycznie nawet nie ma w kodzie. Możesz mu napisać: takiej zmiennej nie ma, a on przeprosi i poda kolejną, której też nie ma.
Najbardziej bezlitosny jest jednak fragment o rozmowach z juniorami.
Spotkałem się z sytuacją, że podchodziłem do juniora i mówiłem: dlaczego to jest tak napisane? A on mi mówił: bo AI mi tak wypluło. Koniec rozmowy.
Trudno o lepsze ostrzeżenie. W pracy nie wystarczy, że kod powstał. Trzeba wiedzieć, dlaczego wygląda tak, a nie inaczej. Trzeba rozumieć wzorce, strukturę, koszt, ograniczenia i błędy. AI może przyspieszyć pracę, ale nie zdejmie z juniora odpowiedzialności za zrozumienie własnego rozwiązania.
Możesz sobie przyspieszyć robotę z AI, oczywiście, ale musisz rozumieć, co ono ci wypluwa. Nie polecam, żeby juniorzy zachłysnęli się AI do tego stopnia, że przestają rozwijać się programistycznie i polegają na tym, że AI wszystko im wypluje.
W gamedevie dochodzi jeszcze jedna rzecz: każda gra jest trochę inna. W typowym IT wiele aplikacji opiera się na powtarzalnych schematach. Logowanie, formularze, baza danych, API, panel administracyjny. W grach powtarzalność też istnieje, ale znacznie szybciej wchodzimy w specyficzne systemy, własne narzędzia i nieoczywiste decyzje projektowe.
Aplikacje w klasycznym IT są często bardziej schematyczne. W gamedevie każda gra jest trochę inna i w każdej chce się osiągnąć coś innego. Nawet jeśli firma przenosi część kodu między projektami, to zwykle trzeba go zmienić. To nie jest okienko logowania, które można po prostu wkleić jeden do jednego.
AI będzie pomagać. Już pomaga. Jednocześnie jednak kandydat, który zamiast rozumieć kod, tylko zarządza wygenerowanymi fragmentami, może szybko odbić się od produkcji. O tym samym wspominał szef krakowskiego oddziału IBM w innym wywiadzie, którego miałem przyjemność przeprowadzić.
Portfolio programisty nie musi być oryginalne. Musi działać
Najbardziej praktyczna część rozmowy dotyczy tego, co junior powinien mieć w portfolio. Konrad Słoń nie oczekuje od początkującego pełnoprawnej gry. Wręcz przeciwnie, bo zamiast tego poleca ograniczyć skalę i zrobić coś małego, ale domkniętego.
Fajnie mieć swoje projekty i to nie muszą być projekty na zasadzie, że musisz zrobić całą grę do końca. Weź swoją ulubioną grę, dużą AAA, bo to wielka kobyła, ale w tej wielkiej kobyle są minigierki, które są już robialne.
Przykład jest bardzo konkretny – minigra z łączeniem obwodów ze Spider-Mana, Pac-Man, Space Invaders. Nie chodzi o oryginalność na siłę. Chodzi o pokazanie umiejętności czysto technicznych.
Weź tę minigierkę i ją odtwórz. Albo weź Pac-Mana i go odtwórz, bo to wcale nie jest takie oczywiste, jak się wydaje. Weź Space Invaders i go odtwórz. Miej takie małe projekciki, żeby pokazać, że umiesz zrobić grę od początku do końca.
Bardzo podoba mi się ta rada, bo zabiera z juniora presję wymyślenia wielkiego pomysłu. Kandydat nie musi udawać, że stworzy hit. Ma pokazać, że umie zbudować działający, zrozumiały, zamknięty system, zamiast siedzieć nad jego projektem przez wiele godzin, które mógłby poświęcić na programowanie.
Jeśli nie jesteś osobą, która jest super w wymyślanie, nie musisz wymyślać. Weź coś gotowego, bo chcesz pokazać, że to umiesz. To da ci duży boost, bo pokazuje, że znasz silnik. Warto też znać kontrolę wersji, jakiegoś Gita.
W takim zestawie nawet osoba bez dyplomu może wyglądać lepiej niż ktoś z formalnym wykształceniem, ale bez żadnego dowodu działania.
Nawet teraz nie patrzysz za bardzo, czy ktoś ma studia, jakie ma studia i w ogóle, tylko co potrafi zrobić. Jeśli ktoś ma magistra z informatyki, a obok jest ktoś bez magistra, ale zrobił trzy gierki i spełnia wymagania, to prędzej weźmiesz osobę, która coś potrafi zrobić, niż tę, która tylko teoretycznie mówi, że coś potrafi.
Nie znaczy to naturalnie, że studia są bez sensu. Znaczy raczej, że same studia przestały być wystarczającym argumentem. Dyplom może pomóc, ale projekt pokazuje coś, czego dyplom nie pokaże, bo kontakt z praktyką.
Game jam może dać więcej niż można się spodziewać
Drugą bardzo praktyczną radą są game jamy. Nie dlatego, że kod z game jamu jest piękny. Zwykle nie jest. Każdy, kto robił projekt w dwa dni, wie, że pod presją czasu powstają rozwiązania, których później najchętniej nikt by nie oglądał. Jednocześnie jednak rekruterzy i seniorzy zwykle wiedzą, czym jest game jam. Nie oczekują tam kodu produkcyjnego. Widzą za to coś innego – zaangażowanie, pracę pod ograniczeniami, komunikację i gotowość do zrobienia gry od początku do końca.
Innym wyróżnikiem jest jeździć na game jamy. Tam też można fajne rzeczy robić i poznać fajnych ludzi. Benefitem jest to, że po takim game jamie zawsze masz grę do portfolio, co by nie było.
Konrad Słoń zauważa, że game jam pokazuje coś więcej niż samą technikę. Pokazuje, że ktoś naprawdę chce wejść w środowisko, jest gotów spędzić weekend na intensywnej pracy i potrafi skończyć mały projekt mimo presji.
Rekruter też wie, na czym polega jam. Technicznie bywa różnie, ale to pokazuje zaangażowanie. Że jesteś zajarany gamedevem na tyle, żeby pojechać na imprezę, która jest wymagająca.
Game jamy mają też drugi, mniej oczywisty sens – pozwalają spotkać ludzi, a w gamedevie kontakty nie są może jakimś magicznym skrótem, ale sposobem na zderzenie się z realnym środowiskiem. Można porozmawiać, pokazać projekt, dostać feedback, dowiedzieć się, czego szukają firmy i jak wygląda praca poza własnym wyobrażeniem. Konrad Słoń przywołuje własny przykład. Po nieudanym doświadczeniu z przerwanym stażem pojechał na jam, gdzie obecny był Techland. Zespół zrobił grę pod temat, który mógł zainteresować tę firmę, dostał zaproszenie na dzień otwarty, a całe wydarzenie zmieniło jego podejście do dalszej kariery.
W zasadzie to całkowicie odwróciło moją percepcję. Stwierdziłem, że jednak chcę robić te gry. Zostałem w gamedevie, a może bym nie został, gdyby nie ten game jam.
Nie robiłbym z tego bajki o jednym wydarzeniu, które magicznie zmienia karierę. Ważniejsza jest prostsza zasada, bo sam fakt, że trudno trafić na okazję, siedząc wyłącznie we własnym pokoju.
Warto jeździć na konferencje. Nie mówię o takich drogich, ale są mniejsze konferencje, targetowane do początkujących twórców gier. Można tam wejść za darmo, posłuchać wykładów, poznać ludzi, pogadać z doświadczonymi osobami i zapytać, jak dostały się do branży.
W praktyce portfolio juniora technicznego mogłoby więc wyglądać bardzo prosto. Kilka małych projektów, repozytorium, krótki opis, nagranie działania, udział w game jamach, znajomość Gita i umiejętność wyjaśnienia własnych decyzji. Bez wielkiej gry AAA. Bez udawania, że trzyosobowy projekt jest nowym Cyberpunkiem. Zamiast tego po prostu konkret, zakres i finalnie dowiezienie całości w sensownej jakości.
Quest designer to nie pisarz. To raczej mini-reżyser doświadczenia
Oczywiście do gamedevu nie próbują wejść tylko programiści. Bardzo podobny problem dotyczy osób, które chcą pracować przy narracji, questach i świecie gry. Tutaj pojawia się inne złudzenie, bo skoro ktoś pisze opowiadania, prowadzi sesje RPG albo ma głowę pełną pomysłów na wielkie uniwersum, to uznaje, że naturalnie nadaje się na scenarzystę growego albo quest designera. Katarzyna Władyka, doświadczona quest designerka znana z pracy przy The Thaumaturge w Fool’s Theory oraz z doświadczenia przy dużych RPG-ach CD Projekt RED, mocno podważa takie założenie.
W grach nie chodzi bowiem o samo “ładne pisanie”. Quest nie jest opowiadaniem pociętym na dialogi, a świat gry nie jest byle dokumentem z lore, który można wrzucić do projektu i uznać za gotowy. Narracja musi tu działać razem z mechaniką, tempem, przestrzenią, ograniczeniami produkcyjnymi i przede wszystkim z graczem, który może pójść w inną stronę, przerwać rozmowę, ominąć wskazówkę albo zupełnie inaczej zrozumieć intencję projektanta.
Pierwszym kardynalnym błędem jest to, że wiele osób próbuje zacząć od tego, że są pisarzami. Piszą opowiadania i myślą, że to doświadczenie można jeden do jednego przełożyć na pracę scenarzysty growego albo quest designera. No niestety nie. – mówi Katarzyna Władyka, obecnie związana z Elsewhere Entertainment, warszawskim studiem należącym do Activision.
W grach narracja nie jest tekstem doklejonym do mechaniki. Dobry quest nie polega na przejściu od punktu A do punktu B i to nawet jeśli na papierze wygląda właśnie tak. Liczy się to, co dzieje się po drodze, a więc reakcje świata, wybory gracza, tempo, przestrzeń, ograniczenia techniczne i sposób, w jaki historia splata się z gameplayem.
Bardziej trzeba myśleć o doświadczeniu gracza niż samym zadaniu. Nie myślimy o tym, że trzeba przejść od punktu A do punktu B, tylko o tym, co dzieje się pomiędzy. W jaki sposób opowiadamy historię, w jaki sposób gracz wchodzi w interakcję ze światem, w jaki sposób świat reaguje na gracza.
Dlatego Katarzyna Władyka opisuje quest designera nie jako pisarza, producenta czy psychologa, ale jako reżysera małego doświadczenia.
Jeśli chodzi o rolę quest designera, najlepiej opisuje ją reżyser. To osoba, która zbiera całe doświadczenie z różnych elementów: scenariusza, settingu, cinematiców, pracy z gameplay designerami. Spina to w jedno wspólne doświadczenie w ramach jednego questa albo wątku fabularnego.
To bardzo ważna lekcja dla osób, które chcą wejść do narrative designu. Samo pisanie dialogów nie wystarczy. Trzeba rozumieć strukturę interakcji, warunki, konsekwencje, rytm, ograniczenia technologiczne i współpracę z innymi działami.
Potrzeba o wiele większych kompetencji, żeby myśleć o doświadczeniu jako całości. O tym, jak narracja spina się z gameplayem i jak jest uwarunkowana technologią, w której operujemy.
Side content nie powinien zapychać mapy. Ma pogłębiać świat albo wybór
Wątek projektowania misji w grach wideo dobrze pokazuje jeszcze jedną rzecz: początkujący często myślą o zadaniach jak o treści do wypełnienia gry. Więcej znaczników, więcej aktywności, więcej dialogów i jeszcze więcej celów. Tyle że współczesny gracz jest już zmęczony takim podejściem. Nie chce odhaczać checklisty tylko dlatego, że mapa ma być pełna.
Side content ma pogłębić główne wątki fabularne albo dać graczowi możliwość ekspresji swoich wyborów czy swojej osobowości. Trzeba myśleć o tym, co fajnego można zrobić w tym świecie, co byłoby interesujące jako przygoda do przeżycia, a nie o tym, żeby usłać mapę kolejnymi znacznikami.
W tym sensie dobry quest designer musi szanować czas gracza. Nie znaczy to, że każda gra ma prowadzić za rękę. Bardziej chodzi o to, żeby nie przedłużać doświadczenia wyłącznie po to, by było dłuższe.
Trzeba szanować czas gracza i nie rozdmuchiwać tego, o czym dany quest ma być. Jeśli organicznie wychodzi, że potrzebne jest pogłębienie albo kolejny wątek, warto przenieść go do side contentu, zamiast wpakowywać wszystko w jedno bardzo gęste doświadczenie.
Katarzyna Władyka bardzo dobrze oddziela tutaj pogłębienie od zapychania.
Jeżeli mamy blokowanie głównej historii grindem i mechanicznymi rzeczami tylko po to, żeby przedłużyć doświadczenie, zamiast pogłębić jego jakość, to wydaje mi się, że to jest ta granica.
Dla portfolio początkującego quest designera ma to bardzo duże znaczenie. Nie chodzi o napisanie jak największej liczby dialogów. Chodzi o pokazanie, że rozumiemy funkcję zadania w strukturze gry. Czy quest coś mówi o świecie? Czy daje wybór? Czy reaguje na decyzje? Czy wzmacnia główny temat? Czy ma rytm? Czy nie jest tylko kurierką z dłuższym opisem?
Mody, Twine i Ink mogą być lepszym portfolio niż zbiór opowiadań
Skoro pisanie opowiadań nie wystarczy, to pojawia się pytanie – co powinien pokazać ktoś, kto chce wejść do quest designu? Odpowiedź Katarzyny Władyki jest bardzo konkretna – mody, interaktywne doświadczenia i narzędzia, które pozwalają pracować na wyborach, konsekwencjach oraz strukturze.
Bliższym doświadczeniem jest prowadzenie RPG-ów, bo to bardziej całościowe doświadczenie. Myślimy o projektowaniu poziomu, scenariuszu, zakładamy, że scenariusz może się rozgałęzić, przygotowujemy graczom różne opcje i odpowiadamy na ich doświadczenie.
Najbliżej realnej pracy w grach są jednak mody.
Najbliższe połączenie to mody. To absolutnie fantastyczny sposób, żeby zacząć pracę w grach jako quest designer. Znam wielu game designerów na różnych szczeblach i w różnych specjalizacjach, którzy zaczęli od modowania.
Mody mają jedną ogromną zaletę, bo zmuszają do pracy w istniejącym systemie. Nie tworzymy czystej historii w próżni. Musimy zrozumieć zasady gry, narzędzia, ograniczenia, tempo, system dialogów, quest log, warunki, triggerowanie zdarzeń i reakcje świata. Właśnie dlatego mod może powiedzieć o kandydacie znacznie więcej niż plik z opowiadaniem.
To daje próbkę tego, jak ta praca może wyglądać, na czym polega i jak skomplikowana potrafi być.
Nie każdy musi jednak od razu modować Skyrima czy tworzyć pełnoprawne zadania w dużym edytorze. Dla początkujących bardzo sensowne mogą być narzędzia takie jak Twine albo Ink, o ile projekt nie kończy się na biernym tekście.
Nawet może być coś prostego, gierka w Twine czy Inku, choose your own adventure, ale bardziej myśląca w kategorii interakcji niż tekstu, którego jest się biernym odbiorcą.
Twine na pierwszy rzut oka może wyglądać jak proste narzędzie do rozgałęzionych historyjek, ale da się w nim pokazać więcej – warunki, zmienne, konsekwencje, powracające wybory, prosty inwentarz, zależności między scenami.
Takie choose your own adventure z konsekwencjami wyborów można naprawdę mocno rozbudować. Można nawet inwentarz zaimplementować.
Dla osoby chcącej wejść do quest designu taki projekt może być bardzo dobrym dowodem kompetencji. Nie musi mieć ładnej grafiki. Musi jednak pokazywać, że autor rozumie interaktywność.
Gamedev jest sportem zespołowym. Nawet solo dev powinien szukać drugiego spojrzenia
Jedno zdanie z rozmowy o quest designie powinno moim zdaniem trafić do każdego tekstu o wchodzeniu do branży.
Gamedev to team sport. Zawsze pracujemy w zespole. Jeśli ma się ambicje robienia dużych, skomplikowanych projektów, nie da się tego robić samemu.
To ważne nie tylko dla quest designerów. Programista, artysta, designer, writer, producent – każdy pracuje w sieci zależności. Trzeba komunikować swoje potrzeby, odbierać feedback, rozumieć ograniczenia innych działów i umieć tłumaczyć własne decyzje. Nawet świetny projekt w portfolio może stracić wartość, jeśli kandydat nie potrafi opowiedzieć, jak zareagował na problemy albo co zrobiłby inaczej.
Katarzyna Władyka podkreśla również, że nawet na wyższych stanowiskach nauka się nie kończy.
Mam ponad 13 lat doświadczenia i cały czas się uczę, bo branża się zmienia, projekty się zmieniają, potrzeby graczy się zmieniają, wymagania dotyczące narracji i technologii też się zmieniają. Nie można stać w miejscu.
Dla juniora to nie powinno być zniechęcające. Wręcz przeciwnie – niższe stanowiska mogą być świetną okazją do zrozumienia, jak naprawdę działa produkcja.
Na niższych stanowiskach jest fantastyczna szansa, żeby dowiedzieć się, jak wszystko działa. Jako quest designer przez spinanie różnych elementów trzeba współpracować z różnymi działami, wiedzieć, czego one potrzebują od quest designera i czego quest designer może potrzebować od nich.
Jeśli zaś ktoś robi grę samodzielnie, to powinien szukać feedbacku. Solo dev nie jest zwolniony z kontaktu z odbiorcą. Może nawet potrzebuje go bardziej, bo bez zespołu łatwo zamknąć się we własnych założeniach.
Nawet jeżeli jesteś solo devem i pracujesz głównie sam nad produktem, warto odbić go od kogoś. Warto zbierać feedback, żeby ktoś inny w niego zagrał, żebyś mógł to doświadczenie zrefinować.
To bardzo dobrze pasuje do doświadczenia każdego, kto kiedykolwiek playtestował własną grę. Dopóki gramy sami, wszystko wydaje się oczywiste. Dopiero obcy gracz pokaże, że można wejść na element, który miał być dekoracją, ominąć tutorial, źle zrozumieć cel, zablokować się w miejscu, którego nie zauważyliśmy, albo potraktować system zupełnie inaczej, niż zakładaliśmy.
Warto pomyśleć o drugim spojrzeniu. Dzięki temu nasza praca jest po prostu lepsza. Jeśli jesteśmy w stanie odbić pomysły, porozmawiać z kimś, zobaczyć reakcję, zobaczyć, co działa, a co nie, o wiele więcej zyskujemy.
Portfolio nie powinno więc pokazywać tylko efektu końcowego. Powinno pokazywać też, że autor potrafi uczyć się na feedbacku.
Szczęście ma znaczenie, ale trzeba mu pomóc
W rozmowach o karierze często udajemy, że wystarczy ciężka praca. Nie lubię tego, bo to półprawda. Ciężka praca jest konieczna, ale rynek nie jest idealnie sprawiedliwy. Czasem oferta pojawia się w złym momencie. Czasem w wymarzonym studiu nie ma rotacji. Czasem firma właśnie tnie zatrudnienie. Czasem ktoś lepszy, bardziej doświadczony albo po prostu dostępny szybciej zgarnia miejsce.
Trzeba mieć szczęście, ale szczęściu trzeba pomóc. – mówi Konrad Słoń.
To bardzo uczciwe ujęcie. Szczęście polega na tym, że oferta w ogóle się pojawi. Na to kandydat nie ma pełnego wpływu. Ma jednak wpływ na to, czy w momencie pojawienia się okazji będzie miał co pokazać.
Nie masz wpływu, kiedy firma zacznie rekrutować. Musisz być w dobrym miejscu i czasie. Ale jeśli nie masz umiejętności, to nic ci to nie da, bo i tak się nie dostaniesz. Musisz mieć trochę szczęścia, ale musisz też być w stanie odpowiedzieć na tę ofertę. – Konrad Słoń.
Z tej perspektywy wnioski wyniesione z rozmów z trzema specjalistami sprowadzają się więc do jednego pytania, bo co zobaczy rekruter albo senior, kiedy ta okazja już się pojawi? Puste CV? Listę kursów? Deklarację pasji oraz ambicji? Czy może jednak konkretny projekt, który działa, ma opis, repozytorium, film i pokazuje proces myślenia?
Czytaj też: Programista w czasach sztucznej inteligencji. Spytałem w IBM, kim musi być dziś junior
Dziś najbardziej odczuwalna zmiana polega na tym, że kiedyś brak projektu można było tłumaczyć brakiem narzędzi, materiałów i dostępu do wiedzy. Dziś ten argument brzmi coraz słabiej. Narzędzia są. Wiedza jest. Społeczności istnieją. Małe projekty da się zrobić. Mody, jamy, Twine, Ink, Unity, Unreal, Godot i GitHub nie sprawiają wprawdzie, że droga stanie się łatwa, ale sprawiają, że brak jakiegokolwiek dowodu działania wysyła jasny sygnał.
Nie: “jestem początkujący”
Raczej: “jeszcze praktycznie nie zacząłem”.
