W gamedevie małym i dużym programista nie tylko pisze kod. Musi również sprawić, żeby cudzy pomysł mógł działać w realnym projekcie, w określonym zespole, przy określonym budżecie czasu i wśród ludzi, którzy potrzebują konkretnych narzędzi. Sama różnica między małym studiem a dużą produkcją AAA nie sprowadza się jedynie do liczby osób w budynku. Między tymi strukturami zmienia się całkowicie sposób podejmowania decyzji, tempo reagowania na błędy, poziom specjalizacji i to, jak wiele pracy programisty polega na komunikacji.
W małej firmie jedna osoba potrafi odpowiadać za kilka obszarów naraz. W dużej firmie jeden feature może wymagać porozumienia między kilkoma wyspecjalizowanymi zespołami. W efekcie sam kod pozostaje oczywiście ważny, ale coraz częściej praca wykracza znacząco poza niego.
W małym studiu programista jest od tego, co akurat trzeba dowieźć
Małe zespoły mają prostą zaletę – wszyscy są blisko problemu. Decyzje zapadają szybko, a komunikacja nie wymaga wielu warstw pośrednich. Jednocześnie ta sama skala oznacza, że specjalizacja bywa luksusem. Jeśli w zespole jest jeden albo dwóch programistów, to rzadko można zamknąć się w jednej dziedzinie.
W małej skali dużo osób ma najczęściej wszechstronne umiejętności w swojej dziedzinie. 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. – komentuje Konrad Słoń z Fool’s Theory.
Taki model potrafi szybko uczyć, ale nie daje komfortu spokojnego wchodzenia w jedną techniczną niszę i jest to z jednej strony błogosławieństwo, a z drugiej przekleństwo. Trudno bowiem wyuczyć się czegoś konkretnego w ekstremalnie dobrym stopniu, ale przynajmniej uczymy się robić cały projekt na poziomie “jako tako”, co nie jest idealne, ale czasem się przydaje. Oznacza to mniej więcej tyle, że programista może jednego dnia pracować nad zachowaniem przeciwników, drugiego poprawiać interfejs, trzeciego łatać zapis gry, a czwartego przygotowywać coś pod playtest. W efekcie sam zakres rośnie szybciej niż nazwa stanowiska.
Czytaj też: Ekspert obala jedno z największych kłamstw o gamedevie [WYWIAD]
Konrad zwraca uwagę, że w małych firmach często brakuje też ról, które w większych studiach są osobnymi specjalizacjami:
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 gameplay designem.
Nie chodzi o wyśmiewanie małych zespołów. Bardziej o zrozumienie ceny, jaką płaci się za małą skalę. Tam, gdzie nie ma osobnego działu narzędzi, QA, produkcji czy designu, obowiązki nie znikają. Zostają rozdzielone między ludzi, którzy są dostępni. Bardzo często trafiają właśnie do programistów.
Pierwsze rozwiązanie potrafi zostać w grze na długo
Najmocniejszy opis pracy w małych zespołach pada przy temacie czasu. Konrad mówi o “polityce złotych strzałów”, a więc sytuacji, w której pierwsze rozwiązanie musi być wystarczająco dobre, bo na drugie może już nie być przestrzeni.
W mniejszych firmach często działa polityka złotych strzałów. Pierwsze rozwiązanie musi być dobre, bo jeśli nie będzie, zwykle i tak zostaje w projekcie. Po prostu nie ma już czasu, żeby zrobić je od nowa. – tłumaczy Konrad Słoń.
Każdy, kto robił grę pod pokaz, konkurs, demo albo playtest, zna ten mechanizm. System powstaje szybko, bo musi. Potem okazuje się, że nie jest idealny, ale projekt ma już kolejne zależności. Oznacza to tyle, że następne funkcje zaczynają opierać się na tym pierwszym rozwiązaniu, a po kilku tygodniach obcowania z takim długiem technologicznym małą poprawka nie oznacza już byle małej poprawki, a ryzyko rozszczelnienia całego fragmentu gry.
Wiele małych gier nie jest dopracowanych nie dlatego, że twórcom nie zależy, ale dlatego, że nie mieli czasu dopracować systemów. Musieli podjąć decyzję: doszliśmy do tego miejsca, nie możemy już tego poprawiać. Musimy przejść do kolejnej rzeczy.
Po kilku latach programowania zarówno na czyiś, jak i swój rachunek zgadzam się z tym w pełni. Produkując grę, trzeba moim zdaniem znaleźć złoty środek między jakością, zaawansowaniem i elastycznością finalnego systemu, a czasem przeznaczonym na realizację. Kod nie jest bowiem czymś, co kiedykolwiek trafi w ręce gracza, ale efekt tego, co ten kod umożliwia już tak. Oznacza to tyle, że trzeba wyrobić w sobie intuicję, ale nawet kilkuletnie doświadczenie nie wystarcza i czasem trzeba zrobić jeden krok wstecz, aby ulepszyć projekt. Świetny tego przykład przeżywałem jako solo developer jakiś czas temu, kiedy musiałem porzucić jedno rozwiązanie na zupełnie inne, które lepiej pasowało do projektu. Więcej o tym w nagraniu poniżej.
Czytaj też: Unreal Engine 6 zniszczy najlepszą zaletę silnika. Teraz ciekawi mnie jedno – co uratuje devów?
Innymi słowy, w pracy produkcyjnej elegancja kodu jest tylko jednym z kryteriów. Liczy się również termin, ryzyko, możliwość testowania, zależności między systemami i koszt zmiany. Początkujący programista może długo myśleć, że dobry kod to kod najładniejszy. Produkcja szybko jednak weryfikuje to podejście, bo rzeczywiście dobre rozwiązanie musi jeszcze pasować do harmonogramu i nie blokować ludzi wokół.
AAA nie jest jednym wielkim zespołem, a siecią zależności
Duża produkcja usuwa część problemów małego studia, ale dokłada do puli swoje własne. Skoro w projekcie pracuje kilkaset osób, to komunikacja przestaje być naturalna. Pojawiają się działy, poddziały, właściciele systemów, priorytety i zależności. Każdy większy feature może dotykać kilku miejsc naraz. Konrad Słoń porównuje zespoły w dużych produkcjach do mikrofirm 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.
Z zewnątrz może się wydawać, że duże studio ma po prostu więcej ludzi do wykonania zadań. W praktyce dochodzi trudniejsza koordynacja. Jeden zespół potrzebuje czegoś od drugiego, drugi ma własne ograniczenia, trzeci musi dostać dane w innym formacie, a czwarty potrzebuje do czegoś konkretnego narzędzia, którego jeszcze nie ma.
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ć. – tłumaczy Konrad Słoń na przykładzie współpracy questów i AI.
W takim środowisku programista nie jest zamknięty w swoim module. Musi umieć zadać właściwe pytanie, zrozumieć potrzebę designu, przewidzieć koszt techniczny i czasem odmówić rozwiązania, które na pierwszy rzut oka wydaje się proste, ale w praktyce może być problematyczne. Zarzucenie programisty konkretnym wymaganiem rozpoczyna więc zwykle nie tyle pisanie kodu, a wstępną analizę tego, jak konkretny feature w ogóle dowieźć i czy aby na pewno jest on potrzebny w takiej, a nie innej formie.
Zespół do zadań specjalnych, czyli co dokładnie?
Duże projekty często korzystają z tymczasowych zespołów powoływanych pod konkretny cel. Konrad mówi o mikroteamach albo strike teamach. Nie są oni stałym działem, a strukturą tworzoną na potrzeby danego feature’u.
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.
Taki model dobrze pokazuje, że funkcje w grach rzadko są czysto czyjeś. System może zaczynać się w gameplayu, ale wymagać UI, AI, questów, animacji, efektów, zapisu stanu i testów. Próba przepchnięcia tego przez jeden dział kończyłaby się opóźnieniami albo nieporozumieniami. Ważne jest jednak rozróżnienie między chaosem małej produkcji a pilną reakcją dużego studia. Konrad zaznacza, że w dużej firmie zadanie “na wczoraj” zwykle nie oznacza wymyślania całego systemu tuż przed premierą. Częściej chodzi o krytyczny błąd, który blokuje grę albo pracę innych osób.
Takie zespoły do zrobienia pracy potrzebnej “na wczoraj” powstają [w dużych studiach – dop. red.] raczej wtedy, gdy pojawia się krytyczny crash albo bug. Coś rozwala grę lub blokuje innych ludzi, na przykład nie mogą uruchomić buildu albo sprawdzić questa. Wtedy trzeba szybko zgasić problem.
W takich momentach programista nie jest tylko autorem kodu. Jest częścią zabezpieczenia całego procesu. Jeśli build nie działa, to gra nie jest testowana. Jeśli quest się blokuje z dziwnego powodu, to inni nie mogą sprawdzić swojej pracy. Jeśli crash występuje często, to cały zespół traci regularnie czas. Naprawienie jakiegokolwiek błędu może być mniej zachwycające niż kolejna nowa mechanika, ale dla produkcji bywa ważniejsze.
Programista przygotowuje narzędzia, których sam nie zawsze używa
W nowoczesnym workflow programista często dostarcza designerom elementy, z których ci budują własne zachowania w silniku. Szczególnie dobrze widać to w Unrealu i Blueprintach. Programista pisze część logiki w kodzie, ale wystawia ją tak, żeby designer mógł dalej pracować bez proszenia o każdą drobną zmianę.
Współcześni designerzy coraz częściej mówią programiście, czego potrzebują, żeby ustawić dany system. Część robi się w kodzie, a część wystawia w silniku. Designerzy mogą potem poukładać to po swojemu w Blueprintach, tworzyć dane i korzystać z przygotowanych elementów jak z klocków. – opisuje Konrad Słoń.
Ten fragment jest kluczowy, bo przesuwa rozmowę z “czy kod działa?” na “czy praca programisty jest używalna dla innych?”. Narzędzie może być formalnie poprawne, ale nieczytelne. Może mieć zbyt mało parametrów albo za dużo swobody. Może pozwalać na błędy, których potem trudno szukać. Może ukrywać koszt wydajnościowy.
Specjalista z Fool’s Theory mówi też, że programista nie zawsze śledzi dokładnie, jak designerzy wykorzystali wystawione elementy. Dopóki wszystko działa, to nie ma powodu zaglądać w każdy graf. Problem pojawia się wtedy, gdy wydajność spada albo zaczynają wychodzić trudne do odtworzenia błędy.
Nie zawsze wiem, jak dokładnie designerzy użyli rzeczy, które im wystawiłem. Często nie zaglądam w konkretne Blueprinty, dopóki nie pojawi się problem z wydajnością albo dziwny bug. Wtedy trzeba prześledzić całą ścieżkę i pomóc to zdebugować.
Tego nie widać w prostych kursach programowania. Tam autor systemu i użytkownik systemu to często ta sama osoba. W studiu bardzo rzadko tak jest. Programista musi pisać z myślą o ludziach, którzy będą korzystać z jego pracy inaczej, niż sam by z niej korzystał.
Blueprinty pomagają, ale nie znoszą kosztów
Blueprinty są jednym z najlepszych przykładów narzędzia, które potrafi przyspieszyć produkcję i jednocześnie wygenerować nową klasę problemów. Dają designerom dużą samodzielność, pozwalają szybko prototypować i zmniejszają zależność od programistów przy prostszych zadaniach do zrealizowania w procesie produkcji gry.
Konrad Słoń nie neguje wartości Blueprintów. Zwraca jednak uwagę na rzeczy, o których rzadziej mówi się poza dużą produkcją.
Blueprinty są świetnym narzędziem, ale mają swoje ograniczenia. Jednym z najważniejszych jest jednowątkowość, o której wiele osób nie myśli, jeśli nie programuje albo nie pracuje przy dużej grze.
Dla gracza liczy się płynność. Dla zespołu liczy się to, co tę płynność zjada. Jeśli za dużo rzeczy trafia na główny wątek gry, zaczynają się zatory. Konrad tłumaczy, że Blueprinty nie pozwalają tak łatwo rozłożyć pracy na inne wątki.
W grze mamy główny wątek, czyli main thread albo game thread. Jeśli coś wykonuje się na tym wątku, inne rzeczy, które też chcą tam wejść, muszą poczekać. Część logiki można przenieść na inne wątki, ale Blueprinty tak nie działają. Kod z Blueprintów wykonuje się na GameThreadzie i może go zapychać.
Drugi problem dotyczy pamięci i ukrytych zależności. Na grafie coś może wyglądać niewinnie. Dwa nody, jeden cast, proste połączenie. Pod spodem może jednak pojawić się łańcuch typów, referencji i ładowanych zasobów.
W Blueprintach łatwo przypadkiem rozbudować zależności. Możesz mieć dwa nody i cast do jakiegoś typu, ale ten typ w środku odwołuje się do kolejnych rzeczy, a one do następnych. Nagle prosty Blueprint zaczyna zajmować kilkanaście megabajtów w pamięci.
Wygodne narzędzia nie kasują kosztów. Czasem tylko chowają je głębiej. Programista musi umieć je znaleźć, zanim trafią do gracza jako spadki płynności, crashe albo problemy z pamięcią.
AI nie zastąpi wiedzy o własnym projekcie
Wątek AI w programowaniu łatwo sprowadzić do prostego pytania – czy sztuczna inteligencja zastąpi programistów? Tak postawione pytanie zwykle więcej zaciemnia niż wyjaśnia. Konrad Słoń patrzy na AI jako narzędzie, które może pomóc, ale zależy od danych, dokumentacji i człowieka, który rozumie wynik.
AI bazuje na dostępnej puli informacji. Jeśli nie ma dobrej dokumentacji silnika albo wewnętrznych narzędzi, nie ma skąd wziąć wiedzy potrzebnej do wygenerowania sensownego kodu.
W firmowym projekcie problem staje się jeszcze wyraźniejszy. Własne narzędzia, wewnętrzne konwencje, silnik, pluginy, ograniczenia licencyjne, NDA – tego nie da się traktować tak samo jak publicznego przykładu z dokumentacji. Narzędzie AI może pomóc w researchu, ale nie zna całej historii projektu, jeśli nie ma do niej bezpiecznego i legalnego dostępu. Konrad zwraca też uwagę na różnicę między grami a bardziej schematycznymi aplikacjami:
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.
Gry korzystają z powtarzalnych wzorców, ale ich ostateczny kształt rzadko jest prostym zlepkiem gotowych rozwiązań. Nawet podobne mechaniki mogą mieć inne wymagania animacyjne, sieciowe, narracyjne, wydajnościowe czy produkcyjne. AI może podsunąć szkic, ale ktoś musi wiedzieć, czy ten szkic pasuje do gry.
Przyszłość programisty nie sprowadza się do mniejszej liczby linijek kodu
Im więcej narzędzi dostają designerzy, im skuteczniejsze staje się AI oraz im wygodniejsze są warstwy wizualnego skryptowania, to tym łatwiej uznać, że rola programisty będzie się kurczyć. Jednak czy aby na pewno? Rozmawiając z deweloperami na GIC Sprint 2026 wysnułem inny wniosek. Rola programisty w dobie AI może się zmieniać, ale jej produkcyjne znaczenie nigdy nie zniknie. Ktoś ciągle musi rozumieć koszt narzędzi, strukturę systemów, wydajność, debugowanie i to, jak jedna decyzja wpływa na pracę kilku działów.
Czytaj też: GIC Sprint 2026 właśnie rusza pełną parą, a my jesteśmy na miejscu
Programista gier coraz rzadziej jest bowiem tylko osobą, która dostaje opis funkcji i oddaje gotową implementację. Częściej przygotowuje środowisko pracy dla innych, pilnuje wydajności, gasi blokujące błędy, wystawia narzędzia, pomaga designerom, sprawdza Blueprinty i ocenia, gdzie sztuczna inteligencja rzeczywiście może pomóc, a gdzie zaczyna szkodzić. Byle głupi przykład? AI może wypluć Wam system, który w każdej klatce będzie robił masę niepotrzebnych procesów szukania na całej scenie, zamiast podejść do tematu np. referencjami w byle prostej tablicy. Oba podejścia działają, oba będą dawać z perspektywy gracza to samo, ale wydajność między nimi będzie przepaścią.
Dobry programista gier nie kończy pracy na tym, że coś działa u niego. Musi jeszcze zadbać o to, żeby działało w projekcie, w zespole i w rękach ludzi, którzy będą korzystać z jego rozwiązań długo po zmergowaniu kodu do maina.
