Bookmark and Share  

Notatnik projektanta: dlaczego projekty pisemne są ważne

By Ernest Adams
Translated by Jacek Wesłowski

[Please note that I do not speak Polish. This article, "Why Design Documents Matter," was kindly translated for me by Jacek Wesłowski.]

Od czasu do czasu spotykam się z pytaniami ze strony moich uczniów, a także z wypowiedziami początkujących producentów zamieszczanymi w Internecie, w których żądają oni uzasadnienia potrzeby tworzenia projektów pisemnych. Woleliby zabierać się od razu do modelowania i kodowania, a robotę papierkową uważają za stratę czasu. Skoro gracz nigdy nie przeczyta projektu, to po co męczyć się ze spisywaniem go?

Rozumiem ten punkt widzenia. Podzielałem go, gdy dopiero zaczynałem tworzyć gry. Pamiętam, że kiedyś zaczynałem pisać kod w FORTRANie na długo zanim nabierał wyraźnych kształtów sam pomysł na grę, rozumianą czy to jako forma rozrywki, czy to jako program komputerowy. Co prawda w tamtych czasach nie było doświadczonych projektantów, którzy podpowiedzieliby, jak się to powinno robić. Każdy uczył się na własnej skórze.

Jednym z zastrzeżeń najczęściej wysuwanych przez początkujących jest to, że projektów pisemnych nikt nie czyta. Ten argument na pierwszy rzut oka brzmi słusznie, jednak w rzeczywistości rozmija się z istotą problemu. Książek telefonicznych też nikt nie czyta, a jednak bez nich nie moglibyśmy odnajdywać numerów obcych osób i instytucji, co znacznie ograniczyłoby pożytki z posiadania telefonu. Podobnie jak książka telefoniczna, projekt pisemny nie służy do tego, żeby go czytać, tylko żeby się do niego odwoływać. Nikt nie czyta go od deski do deski, ale zarówno kierownicy jak i wykonawcy wyszukują w nim informacje niezbędne w codziennej pracy.

Inne powszechne zastrzeżenie mówi, że produkcję gier zwykle zaczyna się od prototypowania. Prototyp można wykorzystać jako podstawę, do której stopniowo dodaje się kolejne elementy, w efekcie uzyskując pełną grę, po co więc tworzyć dokumentację? Jednakże prototyp nie do tego służy, a wykorzystywanie go w taki sposób odziera go z jego walorów. Prototyp powinien być szybki i niechlujny, a im bardziej jest niechlujny, tym szybciej powstaje. Nie jest projektem, lecz poligonem - można w niego zagrać, ale nie można polegać na nim jako źródle danych i planów.

Mark Cerny, autor słynnej koncepcji projektowania gier, ostrzega autorów, że powinni wyrzucać do kosza wszystkie materiały powstające na potrzeby prototypów. Dzięki temu mogą poświęcać im mało uwagi i mieć pewność, że żadna wstępna prowizorka nie trafi do ostatecznej wersji produktu. Próby przekucia prototypu w kod gry zawsze są niebezpieczne, więc Cerny odrzuca je w całości, by usunąć ryzyko.

Co więcej, prototypy prawie nigdy nie zawierają całej treści gry. Tworzymy je głównie z myślą o testach mechaniki i interfejsu. Jeśli gra liczy trzydzieści plansz, to w prototypach pojawiają się trzy lub cztery, a może nawet tylko jedna. Pozostałe też trzeba zaprojektować i udokumentować, tak by ktoś mógł je potem wykonać. Prototyp nie zastąpi diagramów, map, list obiektów i tak dalej.

Powyżej odniosłem się do niektórych zarzutów, ale nie przedstawiłem jeszcze konstruktywnego uzasadnienia, dlaczego projekty pisemne są ważne. Zna je doskonale każdy, kto kierował dużym przedsięwzięciem w głównym nurcie branży. jednakże osoba, która nie doświadczyła tego wątpliwego przywileju, wciąż może mieć wątpliwości. Jest kilka ważnych argumentów, które przedstawię w kolejności od najmniej do najbardziej istotnego.

 

Powód pierwszy (najmniej ważny): instytucje finansujące, takie jak wydawcy, wymagają projektów pisemnych jako dowodu, że projektant wie co robi.

Wielu ludzi w naszej branży chętnie najpierw wzięłoby pieniądze, a dopiero potem zastanawiało się nad szczegółami. Właściwie kto by nie chciał, gdyby to uchodziło? Czasami udaje się naciągnąć w ten sposób prywatnego inwestora, szczególnie takiego, który nie ma dobrego pojęcia o tym biznesie. Jednak rozsądny wydawca po prostu nie przekaże kilku milionów dolarów komuś, kto nie ma konkretnego pomysłu, jak je wydać.

Producenci nadzorczy chcą mieć coś na piśmie. Inaczej niż 15 lat temu, nie żądają już 300-stronnicowych biblii, jednak wciąż lubią wziąć do ręki coś, co można pokazać w dziale sprzedaży. Obecnie będzie to zapewne 30-stronnicowe streszczenie, ale to też jest dokument, który ktoś musi napisać. Dopóki nie ma projektu, nie ma pieniędzy.

Powyższy problem znika przy samodzielnym finansowaniu, ale nawet ci, którzy działają na własną rękę, mają kilka innych, dobrych powodów, by zadbać o dokumentację.

 

Powód drugi: projekty pisemne czasami służą do określania warunków kontraktów.

Większość umów między wydawcami a producentami zawiera harmonogram określający, w jakich terminach producent ma dostarczać kolejne podzespoły, a wydawca - wypłacać kolejne zaliczki. Nie można ułożyć harmonogramu, jeśli się nie wie, z jakich elementów ma się składać gra, a tego z kolei nie można wiedzieć, jeśli się tych elementów przynajmniej częściowo nie zaprojektuje. Jeśli z tych projektów ma powstać harmonogram, to trzeba je trwale zarejestrować.

W praktyce harmonogram zawsze zmienia się w trakcie produkcji, podobnie jak lista kluczowych elementów gry. Ale to nie szkodzi - od czegoś trzeba zacząć. Dopóki nie ma listy kluczowych elementów, nie ma też harmonogramu, a dopóki nie ma harmonogramu - nie ma kontraktu. Ponadto jest w dobrze pojętym interesie producenta, by każdy wymóg wpisany do harmonogramu był możliwie jasny i jednoznaczny.

Pozycja producenta jest silna, gdy jego działania dowodzą niezbicie, że wykonał pewną konkretną pracę, za którą należy się konkretna suma pieniędzy. Jeśli jednak projekt gry składa się głównie z szybkiego machania rękami, to wydawca może równie szybko machać swoimi tłumacząc, dlaczego wstrzymuje wypłatę i żąda dodatkowej pracy. Im lepiej zdajemy sobie sprawę, co obiecaliśmy, tym większą później mamy pewność, że na czas wywiązaliśmy się ze swoich zobowiązań.

Producent umawia się nie tylko z wydawcą, ale także z zewnętrznymi podwykonawcami. Muzykę, modele, animacje i prozę często powierza się niezależnym specjalistom. Aby można było wymagać od nich efektów, trzeba dostarczyć im dokumentację określającą, czego się od nich oczekuje. Podobnie jak w przypadku wydawców, ta dokumentacja może stanowić podstawę kontraktu.

 

Powód trzeci: projekt pisemny przekazuje nasze zamierzenia pozostałym członkom zespołu i pozwala im zaplanować wykonanie poszczególnych zadań.

Przekazywanie informacji innym jest, teoretycznie, główną przyczyną powstawania projektów pisemnych. Dla małych zespołów ma to mniejsze znaczenie, ponieważ ich członkowie często pracują w jednym pomieszczeniu i rozmawiają ze sobą na bieżąco. Dlatego też uczniowie i nowicjusze nie widzą potrzeby spisywania dokumentacji: wydaje im się, że nie muszą marnować papieru na coś, o czym mogą w każdej chwili pogadać.

Jednak, jak się już przekonaliśmy, niektóre dokumenty powstają na potrzeby prawników i biznesmenów, mają też inne funkcje. Co ciekawe, komunikacja z resztą zespołu nie jest najważniejszym argumentem na rzecz projektu pisemnego. Niemniej to też jest argument, i to dobry.

Nauczyciele każą kursantom pisać dokumentację, nawet jeśli nie jest ona niezbędna do komunikacji z zespołem podczas szkolenia, ponieważ wiedzą, że dany uczeń nie zawsze będzie pracował w tak małym gronie i że musi się na tę zmianę przygotować zawczasu. Duże zespoły liczą nawet do 150 osób i często są rozsiane po kilku salach, a jeśli część prac zlecono podwykonawcom, to nawet po kilku krajach. W takich warunkach nawet telefon i wideokonferencje stają się niepraktyczne.

Im większa jest gra, tym ważniejszą rolę pełni dokumentacja w konstruowaniu harmonogramów. Jeśli chcemy, żeby w naszej grze występowało 45 różnych stworzeń, to artyści muszą dla każdego z nich przygotować model, tekstury i animacje. Jako punktu odniesienia używają szkiców koncepcyjnych, które też są częścią projektu. Inżynierowie dźwięku muszą dla każdego stworzenia znaleźć lub wymyślić zestaw odgłosów. Jeśli stworzenie podejmuje samodzielne decyzje, to trzeba scharakteryzować jego zachowanie, tak by programiści wiedzieli, co mają zaprogramować. Jeśli nie spiszemy tego wszystkiego, to skąd ci wszyscy ludzie będą wiedzieli, co mają robić? Nie możemy tak po prostu opowiedzieć im tego na spotkaniu i oczekiwać, że wszystko zapamiętają.

Gdy odpowiadałem za produkcję dźwięku i wideo w grach z udziałem Johna Maddena, pisałem inny rodzaj dokumentów: skrypty sesji lektorów nagrywających komentarze do meczów. Łącznie liczyły 75 stron. Nagrywaliśmy słowny opis każdej sytuacji, jaka mogła zajść w grze, jak również komentarze towarzytszące Johna Maddena. Nikt nie byłby w stanie zapamiętać tego wszystkiego, nie mówiąc już o tym, że potrzebowaliśmy czegoś, z czego Madden mógłby czytać podczas nagrania i do czego inżynier dźwięku mógłby sięgać podczas montażu.

Gry sportowe wymagają więcej dokumentacji niż możnaby się spodziewać. Reguły rozgrywki są ściśle regulowane przepisami ligowymi, ale ktoś musi rozgryć wszystkie strategie (w przypadku futbolu amerykańskiego: stworzyć dla każdego zespołu zestaw typowych zagrań), a także opracować animacje i interfejs, przy pomocy którego dany sport zostanie przeniesiony na komputer lub konsolę. Wykonywaniu tej pracy towarzyszy powstawanie dokumentacji. Na koniec warto wspomnieć, że czasami nie wszyscy członkowie zespołu mówią tym samym językiem. Dosłownie. Zetknąłem się z taką sytuacją podczas prac nad grą "S.T.A.L.K.E.R.: Cień Czarnobyla", powstającej we współpracy między THQ (z Anglii) a GSC Game World (z Ukrainy). Większość autorów w ogóle nie mówiła po angielsku, a tylko po rosyjsku i ukraińsku. Nie mogliśmy zatrudnić tłumaczy symultanicznych do pracy po 40 (czy 60) godzin w tygodniu, więc znaczna część komunikacji między wydawcą a producentem zachodziła za pośrednictwem przekładów dokumentów.

 

Powód czwarty: projekt pisemny przetwarza ogólniki w konkrety.

Proces spisywania projektu zamienia ogólną ideę w szczegółowy plan. Łatwo jest powiedzieć na zebraniu, że "w naszej grze Harpie będą latać", ale to znacznie mniej niż potrzeba do podjęcia pracy. W gruncie rzeczy, jeśli tylko tyle mamy do powiedzenia, to nie warto zabierać się za pisanie. Wykonawcy potrzebują szczegółów: jak wysoko latają Harpie? Jak szybko? Czy wpływa na nie pogoda? Czy Harpie lądują na ziemi? Czy mogą też po niej chodzić, a jeśli tak, to po jakim podłożu i jak szybko? Czy na ziemi są bardziej, czy mniej delikatne niż w powietrzu? Pytania można mnożyć, a wszystkie odpowiedzi trzeba spisać, tak by każdy członek zespołu dysponował wszystkimi informacjami niezbędnymi do powstania produktu.

Byłoby miło, gdyby projektowanie gier polegało na wylegiwaniu się i snuciu marzeń o cudownych treściach i pomysłach. Spotkałem kilku projektantów, którzy mniemali, że do tego sprowadza się ich praca. Otóż nie, ci ludzie byli leniami. Lwia część pracy projektanta polega na obmyślaniu szczegółów.

Choć później te szczegóły zawsze zmieniają się podczas testowania i regulowania, to trzeba od czegoś zacząć. Tak naprawdę proces pisania dokumentacji jest projektowaniem, ponieważ właśnie wtedy z abstrakcyjnych koncepcji wykuwamy konkretne zamiary. Nawet jeśli zupełnie nikt nie przeczyta naszego projektu, to z każdym spisanym pomysłem podejmujemy jakąś decyzję, dochodzimy do jakiegoś wniosku.

 

Powód piąty (najważniejszy): projekt pisemny to zapis i trwały ślad podjętych decyzji.

Projektowanie gier to czynność wysoce zespołowa, znacznie bardziej niż kręcenie filmów. O ile władza reżysera nad dziełem jest niemal absolutna, o tyle niewielu projektantom powierza się pełną kontrolę nad grami. Wykonawcy tolerują dużą liczbę nadgodzin i stosunkowo niskie płace, ponieważ mają szansę na twórczy wkład, bez którego ich praca nie byłaby zbyt ciekawa. Główny projektant nie tworzy całego projektu samodzielnie, lecz stopniowo wplata w pewną całość pomysły większej liczby osób. Musi też (możliwie taktownie) odrzucać te propozycje, które nie pasują.

W efekcie olbrzymią część decyzji projektowych podejmuje się nie przy biurku, ale na spotkaniach, przy ekspresie do kawy lub na przerwie obiadowej. Niektóre z nich, zapewne dokonywane przez mniej doświadczonych pracowników, mają jedynie przybliżony charakter i wymagają dopracowania przez głównego projektanta lub innych członków zespołu. W każdym razie, gdy do rozwiązań dochodzi się w rozmowie lub negocjacji, koniecznie trzeba je spisać - nawet wtedy, gdy od razu wiemy, że później się zmienią.

Przyczyna leży w potrzebie posiadania trwałego śladu - zapisu decyzji podjętych do tej pory. Zbyt wiele razy uczestniczyłem w spotkaniach, na których wybuchały kłótnie, ponieważ różni ludzie różnie pamiętali decyzje, których nikt nie spisał. "Czy nie mieliśmy zrobić X? - Wcale nie, miało być Y!". W efekcie marnuje się czas i energię. Po tygodniu lub dwóch od spotkania, na którym podjęto decyzję, może okazać się, że przez cały ten czas zespół pracował w oparciu o mylne przypuszczenia.

Z tego powodu na każdym spotkaniu należy wyznaczać sekretarza odpowiedzialnego za wykonanie notatek i dostarczenie ich zainteresowanym stronom. Tak jak omawiane na spotkaniu kwestie reprezentują określone zagadnienia projektowe, tak samo notatki są częścią dokumentacji projektu i powinny być archiwizowane jako takie. Dzięki temu można do nich sięgać, gdy ludzka pamięć zawodzi.

Projekty pisemne pozwalają też zorientować się, co już zostało zrobione, a co dopiero trzeba przemyśleć. Jeśli jakiś element naszej gry nie został opisany, występuje spore ryzyko, że o nim zapomnieliśmy i że ktoś kiedyś będzie musiał przyjść i o niego zapytać, o ile - co gorsza - nie wymyśli własnej koncepcji, której z nikim nie skonsultuje. Grozi to katastrofą: poszczególne zespoły mogą wypracować odmienne wyobrażenia na temat naszych zamiarów i na tej podstawie stworzyć elementy nie pasujące do siebie nawzajem. Dużo łatwiej i taniej jest poprawić nieścisłości projektu, zanim zacznie powstawać kod i treść.

Przedstawiłem powyższy powód jako najważniejszy, ponieważ projekt pisemny jest przede wszystkim narzędziem organizacyjnym. To nie są książki ani historie do poduszki, tylko plany: zapis zamiarów do urzeczywistnienia. Przyjmują wiele postaci, takich jak: diagramy, szkice koncepcyjne, referencje graficzne, teksty objaśniające, tabele cech i statystyk, wszelkiego rodzaju listy, storyboardy, grafy przepływu (tak, nawet w dzisiejszych czasach, choć służą opisowi interfejsów, a nie kodu), notatki ze spotkań, skrypty sesji nagraniowych, a nawet prezentacje handlowe pomocne w przekonywaniu inwestorów do sfinansowania przedsięwzięcia.

Gdy gra jest już ukończona, a pozostała praca sprowadza się głównie do testowania i regulowania, można wyrzucić dokumentację do kosza, tak jak budowniczy zdejmuje rusztowanie, aczkolwiek warto zachować ją na wypadek, gdybyśmy jeszcze kiedyś chcieli z niej skorzystać. Dopóki jednak wszystko dopiero powstaje i ulega zmianom, tylko pisemne projekty pozwalają zachować orientację w tym, co się dzieje i co należy zrobić w następnej kolejności.

 

Podsumowanie

Projekt pisemny sam z siebie nie gwarantuje, że gra będzie świetna, ani nawet zwyczajnie dobra, ani że powstanie w terminie. Przeciwnie, jeśli podejdzie się do niego niewłaściwie, można na niego zmarnować bardzo dużo czasu i wysiłku. Niektóre pułapki czyhające na autorów opiszę w jednym z następnych artykułów. Mam jednak nadzieję, że udało mi się odpowiedzieć na niektóre pytania nurtujące niewinnych i bezbronnych.

Owszem, mały zespół pracujący nad małą grą, być może niezwiązany terminami, nie potrzebuje rozbudowanego projektu na piśmie. Być może nigdy żadnego nie stworzymy, o ile całą karierę poświęcimy quizom na komórki (z drugiej strony, ktoś musi spisać pytania do quizu, czyż nie?). Niemniej wartość dokumentacji nie budzi wątpliwości poważnych profesjonalistów, którzy pracują przy dużych przedsięwzięciach i muszą zdążyć przed Bożym Narodzeniem. To ona organizuje i nadaje kierunek całemu procesowi, a także zapewnia komunikację między wykonawcami. Żaden kierownik nie może stworzyć harmonogramu ani listy zadań, ani też przypisać do nich ludzi, ani nawet śledzić ich postępów, jeśli nie wie dokładnie, co konkretnie trzeba stworzyć. Te dane muszą istnieć w pisemnej postaci.

W gruncie rzeczy, pisanie - szkicowanie, diagramowanie, układanie list i tabel, a nawet pseudo-kodowanie - to wszystko jest projektowaniem. Każdy wykręca się na własne ryzyko.