Jak zniszczyć marzenia game designera i ujść z życiem: poradnik dla programistów.

Game designer i programista mają bardzo różne podejścia do swojej pracy. Podczas gdy designer wymyśla różnorodne pomysły, to właśnie programista musi je bardzo dobrze zrozumieć i przenieść na kod, co nieraz kończy się zmianą oryginalnej idei. Problemy zazwyczaj pojawiają się na dwóch płaszczyznach: komunikacji i skalowania pomysłów. Ale zacznijmy od początku. 

Kim w zasadzie jest ten game designer?

Designer jest zawodem kreatywnym, nie posiadającym ściśle określonych zasad – jedynie zarys, wokół którego może się poruszać. Z abstrakcyjnych pojęć takich jak: “fajne”, “zabawne” czy “przyjemne” próbujemy stworzyć zasady gry, szukając wspólnego języka z graczem tak, aby zapewnić mu magiczny graal game designu – FUN.

Więc, gdy ktoś nie związany z gamedevem pyta mnie, co tak naprawdę robię w pracy – często odpowiadam: “wymyślam zasady” – i jest to moim zdaniem najprostsza definicja tego zawodu.

Przed nami – game designerami – ciężkie zadanie – przede wszystkim musimy bardzo dobrze poznać gracza, jego zachowania, co go motywuje do grania, a co sprawia, że zaczyna się nudzić lub zniechęcać. Tutaj na pomoc przychodzi analityka i niezawodny excel. Tak! Dobrze przeczytałeś. Jeżeli więc wyobrażałeś sobie siebie, jak siedzisz wygodnie w fotelu i wymyślasz kolejne tytuły, muszę cię nieco zmartwić. Część pracy designera to analiza danych w excelu lub innych programach do tego przeznaczonych!

Dodatkowo game designer nie tylko musi sprawnie poruszać się po analityce danych, ale także wiedzieć gdzie indziej szukać odpowiedzi na pytania: jak działa gracz lub jak stworzyć dla niego idealne doświadczenie. Tutaj z pomocą przychodzi wiedza z psychologii, popkultury, a także także ze zdecydowanie dziwniejszych i zaskakujących miejsc – jak np. z zasad interior designu albo rybołówstwa. To właśnie te wszystkie informacje musi przetworzyć game designer, tak aby zaprojektować najlepszą wersję gry. Ważne przy tym wszystkim jest to aby pamiętać, że nie tworzymy gry dla siebie, tylko dla naszych użytkowników! Każdy ma inne potrzeby i poczucie tego co jest FUN.

Oczywiście to zaledwie jedna strona medalu. Bowiem poza omówionymi wcześniej zagadnieniami, z którymi spotykamy się w procesie kreatywnym, musimy również dbać o dobrą komunikację w zespole, z każdą grupą zawodową, która ma wdrożyć nasze pomysły w życie. Jedną z tych grup, niezwykle odmiennych od naszej, są developerzy. Poza różnicą w sposobie myślenia, napotykamy tutaj zazwyczaj, również barierę wynikającą z wiedzy w zakresie programowania oraz ograniczeń, jakie ono za sobą niesie, a także szeregu innych, o których spróbujemy opowiedzieć w tym artykule. 

Jak tworzy programista?

Programista zawsze dąży do tego, by jego kod był przejrzysty, skalowalny i elastyczny. Osiągnięcie tego jest najprostsze, kiedy kod jest “abstrakcyjny”, czyli nie implementuje żadnej konkretnej wersji funkcjonalności dosłownie, a co najwyżej daje możliwość wyboru co konkretnie ma się dziać. Oznacza to zazwyczaj stworzenie pliku konfiguracyjnego, w którym designer będzie mógł wybrać, co konkretnie ma się dziać. Prostym przykładem takiego podejścia może być turniej, w którym gracze rywalizują ze sobą zbierając elementy w module match 3. Oryginalny pomysł designera był taki, aby gracze zbierali czerwone chipy. Od strony programistycznej będzie to wyglądać jednak tak, że gracze mogą zbierać jakikolwiek element, a to designer, w dołączonej konfiguracji, będzie określał, czy mają to być czerwone, żółte czy niebieskie chipy, czy być może rakiety lub coś innego. Kod powinien zaś obsługiwać wszystkie te możliwe opcje.

Czy porozumienie jest możliwe?

Nie będzie to łatwe zadanie, ale nikt nie powiedział, że wszystko w życiu przychodzi łatwo. Na pewno trzeba uświadomić sobie jedno – każdy w zespole dąży do tego, aby zrobić najlepszą grę na świecie. To jest jasne jak słońce, wszyscy widzimy na końcu ten nasz idealny produkt – grę, przy której bawią się najlepiej miliony graczy. Co niestety nie znaczy, że nasze cele pośrednie są takie same. 

Game Design dąży do tego, aby stworzyć idealne zasady gry, aby gameplay był jak najlepszy, dopasowany do motywu przewodniego ustalonego przy tworzeniu projektu. Jeśli naszym kierunkowskazem jest hasło “gra dynamiczna”, wszystko co będzie tworzone, z punktu widzenia designera powinno wspierać to założenie. Wspólny język z graczem, o którym pisaliśmy wcześniej będzie szukany na wielu płaszczyznach takich jak mechaniki, aspekt wizualny gry, czy animacje. 

Programiści zaś dążą do tego, aby stworzyć grę, jak najbardziej zoptymalizowaną, z najmniejszą ilością błędów. Zależy im na tym, aby kod był skalowalny, prosty i elastyczny. 

Ostatecznie, pamiętamy wszyscy, że cel jest wspólny, więc aby ze sobą współpracować musimy nie tylko zrozumieć, co motywuje każdą z grup, ale także znaleźć wspólny język. I tu na pomoc przychodzą narzędzia takie jak słownictwo, dokumentacja GDD czy user’s stories.

Słownictwo

Przy prezentowaniu swoich pomysłów designerzy czasami posługują się ogólnym, lub nieprecyzyjnym słownictwem, używają zamiennie pojęć i luźno określają zachowania. Programiści oczekują jednak konkretów, ponieważ bez nich, trudno jest zacząć pracę nad funkcjonalnością. Jeśli nowy pomysł jest zawiły, to dobrym zabiegiem jest sporządzenie diagramu przepływu, albo prostej makiety. Te narzędzia obrazują działanie i powiązania z istniejącymi w grze systemami.

Dokumentacja

Głównym narzędziem, jakie służy designerom do przekazywania swoich wizji jest dokumentacja. W sieci można przeczytać o różnych formach GDD (game design document), na baze mojego doświadczenia mogę omówić kilka z nich.

GDD w google docs

Samemu narzędziu google docs nie mam nic do zarzucenia, jednak brak ograniczeń i forma na jaką pozwalają sprzyja zbytniemu rozpisywaniu się. Nie oszukujmy się, część designerów mogłaby opowiadać świetne bajki lub tworzyć obszerne scenariusze do gry fabularnej Dungeon & Dragons. Właśnie dzięki swojej kreatywności i widzeniu całych historii mogą oni tworzyć dobre gry, jednak w pracy z programistami wymagane są zupełnie inne cechy. Więc co cechuje dobrą dokumentację?
Czytelna i zrozumiała dokumentacja powinna być:

• Zwięzła
• Konkretna
• Wizualna

Zwięzła – słowo klucz! Pamiętam jak w mojej pracy, na samym początku, staraliśmy opisać wszystko co możliwe. Dodawaliśmy makiety, diagramy, obszerne opisy różnych skrajnych przypadków. Niestety wynikiem tego były 30 stronicowe lub dłuższe opowiadania z obrazkami. Kiedy do lektury takiego dokumentu siadali programiści, i nawet “zmusili się”, aby przeczytać nasze małe “opowiadanie”, wyciągało ich to z pracy na ponad godzinę, a po skończeniu lektury i tak nie było gwarancji, że będą dokładnie wiedzieli co zrobić. Kolejny czas zabierało im przełożenie naszej prozy na swój język oraz nadanie odpowiednich priorytetów poszczególnym zadaniom. Nie było to łatwe, z tego powodu spróbowaliśmy kolejnego podejścia….

User’s Stories
User Stories to standard w branży IT. Jeżeli skierujecie swoje kroki ku google i wpiszecie historyjka użytkownika (sic! Ang. user story) traficie na bardzo prostą definicję. “Jest to metoda tworzenia wymagań w oprogramowaniu pisana z perspektywy użytkownika końcowego.” 

W rzeczywistości sprowadza się do tego, że designerzy zaczynają swoją specyfikację od kluczowego pytania. Co chce jako gracz.

Jako gracz chcę rywalizować w turnieju, aby zgarnąć nagrody.

To jedno zdanie, pozwala nam określić dokładnie potrzebę gracza, jeśli coś w designie nie wspiera tego lub jeżeli nie jest kluczowe do osiągnięcia założonego celu – możemy z tego spokojnie zrezygnować. Po tym następuje stworzenie diagramów wizualnych, które posiadają podobną formę do diagramów, ale opierają się głównie o makiety. Dzięki temu narzędziu pokazujemy, jaką “szczęśliwą ścieżką” gracz może podążyć. Staramy się tutaj nie rozdrabniać na tzw. edge casey (przypadki skrajne). Bardzo istotne jest, aby skupić się na tym co jest najważniejsze. Zwięzła i krótka forma często wymusza na nas – designerach – podejście bardziej skrupulatne i rzeczowe.
Od razu powstają również odpowiednie zadania dla zespołu razem z nadanymi odpowiednimi priorytetami. Można się tutaj posiłkować konkretnym narzędziem do zarządzania zadaniami jakim jest np. Jira. Pozwala to na łatwą organizację pracy zespołu już od początku. Dodatkowym plusem jest fakt, że wszystko jest odpowiednio podzielone na odpowiednie zadania, co sprzyja wprowadzaniu zmian i tzw. iteracji (i nie trzeba już edytować naszego opowiadania, yey!).

Sztuka kompromisów – czyli jak się nie pozabijać 

Nowy pomysł zawsze przechodzi przez burzę mózgów, w której uczestniczy cały zespół. Poza sugestiami, zazwyczaj przeprowadzana jest wtedy również wycena czasowa, czyli programiści mówią ile zajmą poszczególne części składające się na daną funkcjonalność. Jeśli któraś z nich, okaże się zbyt czasochłonna, mogą oni zasugerować uproszczenie lub jeśli jest mało znacząca – usunięcie. Taka sugestia może oczywiście zostać odrzucona przez designera, jeżeli jego zdaniem, dana część może kluczowa, bowiem komunikuje graczowi jakąś istotną treść albo dostarcza inną ważną wartość. Takie podejście obrazuje różnice w priorytetach obu stron, bowiem to co ważne dla designera, może się programistom wydawać zbyteczne. Konieczne jest więc wspólne wypracowanie kompromisu – na przykład przełożenia wykonania skomplikowanych elementów na kolejną iterację.

Odwrócenie ról – czyli nie tylko Game designer pisze dokumentację.

Często zdarza się, że narzędzia dla designerów, skonstruowane są tak, aby ułatwić im tworzenie lub konfigurowanie jakiejś części gry. Jeśli są one skomplikowane i używanie ich może być problematyczne, warto napisać do nich dokumentację. Jako programista złapałem się na tym, że moje dokumentacje były zbyt techniczne, zawierały pojęcia, których designerzy znali, ale które ja uważałem za oczywiste. Dlatego też pisząc dokumentację warto starać się unikać mocno technicznego słownictwa i pisać jak najbardziej po polsku i w jak najprostszej formie. Dzięki temu współpracujący z nami game designer nie będzie zmuszony do ciągłego  googlowania technicznych pojęć. 

Stabilność versus ciągłe zmiany – jak razem pracować

Tryb pracy designerów jest bardzo elastyczny i zakłada ciągłe zmiany. Nie boją się szalonych pomysłów – przecież ostatecznie to nie oni je implementują do gry ;). Programiści jednak wolą bardziej ustrukturalizowaną formę wykonywania zadań, dlatego, że zmiany potrafią być dla nich bardzo dotkliwe. Modyfikowanie kodu, lub co gorsza, pisanie go na nowo, jest bowiem niezwykle czasochłonne i frustrujące. Jasno oznacza ono problem w komunikacji albo błąd w implementacji i skutkuje ogromnymi stratami czasu. Dlatego konieczne jest ciągłe pokazywanie designerowi efektów pracy, po to, aby jak najwcześniej wyłapać niedociągnięcia koncepcji lub implementacji. Świetnym narzędziem wspomagającym ten proces są zaplanowane prototypy, czyli bardzo bazowe wersje funkcjonalności. Podlegają one stałemu ocenianiu i co najważniejsze, ich przygotowanie nie zajmuje dużo czasu, dzięki czemu zmiana lub przepisanie ich w inny sposób, nie są dla programisty tak dotkliwe.

Podsumowując najistotniejsze jest dobranie odpowiedniej formy komunikacji – tak, aby zaspokoić obie strony i uwzględnić uwagę specyfikę jej pracy. Designerowi zupełnie inaczej będzie się rozmawiało z grafikami, testerami i zupełnie inaczej z programistami. Ci ostatni są zazwyczaj najbardziej wymagający.

Ze strony designerskiej pamiętajmy o tym, aby szanować czas innych – przychodzić do zespołu z konkretami, przygotowani tak, aby w wizualny sposób przedstawić nasz pomysł. Szybki prototyp, który na start zweryfikuje pomysł może zaoszczędzić zespołowi oraz projektowi sporo czasu. A pamiętajmy, że czas w game designie jest równie cenny w fazie produkcji, jak i w dalszych cyklach życia produktu (czyli gry). 

Ostatecznie warto iść na kompromisy. Pamiętajmy, że kompromisy są wtedy, gdy obydwie strony poświęcają coś na rzecz drugiej strony. Nie możemy zrobić super animacji w całej funkcjonalności na start? Ok, zdecydujmy się tylko na te kluczowe. Dzięki temu unikniemy wiecznej batalii, a w zespole będzie panować bardziej przyjazna atmosfera. Zrozumienie, że jeśli programiści nie decydują się na wszystkie pomysły designerów nie wynika to z chęci dokopania im. A dwa główne czynniki, przez które pomysły mogą być okrojone to czas i ograniczenia techniczne.

Na koniec dobrze czasami przysłowiowo wejść w buty drugiej osoby. Programiści nie zawsze mają ochotę na burzę mózgów, czasem wolą skupić się na pisaniu kodu. Designerzy zazwyczaj nie są ekspertami w programowaniu, często będą się uczyć od Was i to jak im będziecie przekazywać tą wiedzę, będzie zależało czy z czasem coraz sprawniej odnajdą się w gąszczu technicznych zagadnień. Takie podejście pozwoli im w przyszłości pisać jeszcze lepsze specyfikacje. A dobra specyfikacja to połowa sukcesu w komunikacji między designerami i programistami!