Kiedy mówimy o tworzeniu gier, bardzo łatwo jest uprościć obraz do kilku etykiet: programista, grafik, designer, producent. Brzmi znajomo, prawda? Problem w tym, że to uproszczenie działa tylko na slajdzie w prezentacji albo w opisie stanowiska na LinkedInie. W rzeczywistości produkcja gry to proces znacznie bardziej złożony — i to właśnie w tej złożoności najczęściej się gubimy.
Ten tekst nie jest encyklopedycznym opisem ról w studiu gier. Jest próbą odpowiedzi na pytanie, dlaczego mimo jasno nazwanych stanowisk tak często nie wiemy, kto właściwie za co odpowiada — i co z tym zrobić.
Studio gier to system, nie lista stanowisk
Jednym z największych błędów, jakie popełniamy, jest myślenie o studiu gier jak o zbiorze ról. Tymczasem studio to system zależności, w którym decyzje jednej osoby niemal zawsze rezonują w pracy innych.
Programista nie „robi kodu”.
Designer nie „wymyśla mechanik”.
Producent nie „pilnuje Jiry”.
Każda z tych ról istnieje w relacji do pozostałych, a nie w próżni. Kiedy zaczynamy je postrzegać jako odrębne byty, bardzo szybko pojawiają się klasyczne symptomy:
-
„to nie mój problem”
-
„to było w design docu”
-
„nikt mi nie powiedział, że to ważne”
To nie są problemy ludzi. To są problemy architektury odpowiedzialności.
Odpowiedzialność ≠ decyzyjność
Jedna z najbardziej zdradliwych pułapek w produkcji gier polega na myleniu odpowiedzialności z decyzyjnością. Ktoś odpowiada za feature, ale nie ma realnego wpływu na decyzje, które ten feature kształtują. Ktoś inny podejmuje decyzje, ale nie ponosi konsekwencji ich wdrożenia.
W efekcie:
-
decyzje są podejmowane „gdzieś”
-
odpowiedzialność rozmywa się „wszędzie”
-
frustracja ląduje „na dole”
Dobrze działające studio to nie takie, w którym wszyscy mają głos we wszystkim, tylko takie, w którym wiadomo, kto i dlaczego podejmuje decyzje — oraz kto ponosi ich koszt.
Rola to kontekst, nie tytuł
W trakcie pracy nad grą ta sama osoba bardzo często pełni różne role — czasem nawet w ciągu jednego dnia. Raz jest ekspertem, raz egzekutorem, raz facylitatorem, a czasem po prostu kimś, kto musi powiedzieć „nie”.
Problem zaczyna się wtedy, gdy:
-
tytuł stanowiska zaczyna ograniczać rozmowę
-
zamiast „kto powinien podjąć decyzję?” pytamy „czyja to rola?”
To subtelna, ale bardzo ważna różnica. Rola powinna wynikać z kontekstu problemu, a nie z opisu stanowiska sprzed dwóch lat.
Chaos nie zawsze oznacza brak procesu
Często słyszę, że „u nas jest chaos”. Ale chaos bardzo rzadko wynika z braku procesu. Dużo częściej wynika z tego, że proces nie odpowiada na realne pytania zespołu.
Jeżeli:
-
proces nie pomaga podejmować decyzji
-
nie skraca czasu reakcji
-
nie redukuje liczby konfliktów
to zespół i tak znajdzie swoje nieformalne ścieżki działania. I nie ma w tym nic złego — pod warunkiem, że potrafimy je zauważyć i nazwać, zamiast udawać, że oficjalny diagram organizacyjny nadal ma znaczenie.
Najtrudniejsze pytania są… bardzo proste
W produkcji gier najwięcej odwagi wymaga zadawanie pytań, które brzmią banalnie:
-
po co to robimy?
-
kto faktycznie podejmuje tę decyzję?
-
co się stanie, jeśli tego nie dowieziemy?
-
kto poniesie koszt tej decyzji za pół roku?
To są pytania, które często wstrzymują spotkanie. Bo podważają założenia. Bo wymagają wątpienia. Bo zmuszają do przyznania, że nie wszystko jest tak poukładane, jak byśmy chcieli.
A jednak to właśnie te pytania kalibrują system, zanim zacznie on produkować problemy z przemysłową skutecznością.
Na koniec: rola studia to tworzenie warunków
Najważniejsza rola studia gier — niezależnie od skali — nie polega na definiowaniu ról. Polega na tworzeniu warunków, w których:
-
decyzje mają właścicieli
-
odpowiedzialność jest czytelna
-
ludzie rozumieją wpływ swojej pracy na całość
Jeżeli to działa, tytuły stanowisk schodzą na drugi plan.
Jeżeli nie — żaden proces, framework ani reorganizacja nie pomoże.
Bo w grach, tak jak w samych mechanikach, najważniejsze rzeczy dzieją się między systemami, a nie w ich nazwach.
