Zapytałem programistę nowych Wiedźminów o prawdę na temat pracy w gamedevie [WYWIAD]

Konrad Słoń podczas prelekcji na temat skalowania systemów gameplayowych

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 cały artykuł u źródła — Chip.pl