Grę tworzymy – projektowanie/produkcja cz.2

PROJEKTOWANIE

Posiadając już gotowy oraz konkretny pomysł wraz z opracowanym GVD przystępujemy do drugiego etapu i zaczynamy tą bardziej właściwą pracę kreowania nowego, elektronicznego tworu. Etap projektowania jest moim zdaniem (i nie tylko) bezwzględnie najważniejszy przy całej produkcji i powinien trwać, o ile zaplecze finansowe pozwala, możliwie jak najdłużej. Musimy zdawać sobie sprawę z tego, że błędy lub luki powstałe na tym poziomie prac objawią się w różnych etapach życia projektu i spowodują spotęgowanie problemów związanych z chociażby opóźnieniem prac lub ich dublowaniem. Wtedy często szybko trzeba wymyślić coś „z buta” a wtedy koncepcje mechanizmów mogą przejść negatywną metamorfozę która często staje się powodem niszczenia produktu i zatracania właściwego mu pierwowzoru. Należy być wyjątkowo cierpliwym, każdą rzecz przemyśleć kilkanaście razy i zastanowić się jaką właściwie funkcję/możliwość wprowadza jakim kosztem produkcyjnym. Z uwagi na to, że sam etap projektowania gry nie jest uniwersalny dla każdego projektu (różnice wynikające z: od tego czy pracujemy na gotowym silniku/tworzymy własny po rodzaj stylistyki audio/wideo) i zawsze wygląda trochę inaczej postaram się przedstawić wskazówki oraz „zasady kreatywne” które to pokażą oraz nakreślą bolączki prac nad zaprojektowanie gry wideo.

Start.

Wiem, że ambitni pisarze, i ktokolwiek zaczynający tworzenie gier a posiadający całość gry w swojej głowie, chcieliby już teraz zacząć tworzyć świetną zdetalizowaną historię oraz fabułę i miliony postaci jednak wciąż nie jest to najbardziej priorytetowym zadaniem. Na początku musimy zmęczyć mechanikę, ponieważ to ona będzie nas truła do końca trwania projektu. Tylko jak? Zaczynamy od wypisania głównych cech/elementów rozgrywki a następnie rozdrabniamy je tak, żeby już bardziej podzielić się ich nie dało. Rozbijamy każdą funkcję na części pierwsze. Następnie do każdej dodajemy opis oraz to na jakie inne elementy ona oddziaływuje. Jest to etap bardzo, bardzo czasochłonny i wymagający dużego skupienia i ogromnych nakładów pracy typowo biurowej, chociażby na arkuszach excela. Jego pochopne ukończenie zwiastuje nieubłaganą śmierć projektu lub wydanie słabego produktu.

Kto i jak.

Zależnie od wielkości zespołu model ekipy projektowej może być różny. Jeśli zespół jest mały zaangażowane mogą być wszystkie osoby, jeżeli duży – jeden, wybrany oddział. Główni chodzi o to, że pojedyńcza osoba będzie miała problemy z krytyką własnych pomysłów (chyba, że jest się Peterem Molyneux) i przepuści za dużo baboli; zbyt duża ekipa spowoduje stuprocentowe rozrośnięcie mechaniki jeśli nikt nie będzie ich mocno pilnował (kłopot managera: zbyt duże odrzucanie pomysłów powoduje znaczną utrate morale i zapału do pracy). Najlepiej stworzyć zespół projektowy, składający się (zależnie od wielkości całej ekipy) od kilku do kilkunastu osób przy dużych projektach, zawierając w sobie przedstawicieli poszczególnych działów (lead artist, lead programist itd). Dobrym pomysłem jest również zaangażowanie reszty teamu poprzez wyznaczenie oddziałów dwu lub trzy-osobowych zajmujących się pomniejszymi elementami gry.

Najczęściej popełnianym błędem jest wyznaczenie Projektanta Mechaniki i odcięcie go od reszty zespołu w sensie kreatywnym, czyli na zasadzie: „Masz naszą pomoc ale to jest Twoja działka, więc po prostu nie spartol roboty i zrób to dobrze”. Są znane również kwiatki gdzie ekipa projektowa projektowała a reszta wydziału „fizycznego”(programiści/graficy/osoby tworzące stały content) już działali ze świeżo wypieczonego tekstu i tabelek featursów nie koniecznie rozumiejąc ich znaczenie w całym ogóle tworzonego produktu.  Bardzo ważne jest natomiast aby ekipie projektowej zapewnić wsparcie artystów, którzy będą mogli na szybko przygotować proste koncepty przeniesienia wyobrażonych mechanizmów. Przyda się to nie tylko w projektowaniu wizji produktu ale i w późniejszych etapach dla reszty zespołu która będzie mogła dokładniej zgłębić tajemnice mrocznych excelowskich tabel. Nie zawsze wiadomo co taki pracownik „kreatywny” miał na myśli pisząc chociażby „przejście do inastancji”. Może oznaczać to kilka rzeczy, więc rozrysowanie (jako oczywiście dopełnienie kategorii „opis”) spowoduje szybsze załapanie przez programistę o co chodzi. Wiadomo, że mózgi z kategorii artist/creative działają na innych falach niż developer/constructor (:P) i nie da rady dojść do pełnego porozumienia pomiędzy tymi dwoma działami bez odpowiedniego zabezpieczenia.

Maszerujemy równo.

Problemem który zawsze występuje jest kłopot z sychronizacją osób w projekcie tak aby każdy miał coś do roboty a jego praca nie szła na marne. Oprócz zespołu projektowego możemy mieć jakichś pozostałych pisarzy, programistów czy grafików. Oczywiście, powinni oni zająć się tworzeniem dokumentacji/wzorców dla przyszłych prac na przykładzie tworzenia mechaniki. Tutaj chociażby powstaje stylistyka gry, wzorce programowania czy pierwowzór fabuły. Wpływ na rozdanie zadań ma zbyt duża ilość czynników aby wykombinować jakąś uniwersalną recepturę – po prostu manager lub lead każdej sekcji powinien zależnie od wszystkiego (dosłownie wszystkiego) rozdać propozycję prac. Dysonanse które pojawiają się na tym etapie nie są szkodliwe może dla późniejszej produkcji jednakże mogą znacząco wpłynąć na postęp (ilość potrzebnego czasu) prac projektowych.

Makulatura.

Przy projektowaniu powinna postać Biblia Gry. Jest to dokument (lub ich zbiór) z założenia podobny do Game Vision Document. Różnica polega na tym, że tym razem nie skupiamy się na ogółach a uszczególniamy każdy element gry. Biblia powinna stanowić zbiór dokładnych opisów, wykresów i tabelek, grafik koncepcyjnych i pojęć. W Biblii również powinien znaleźć się dział „Fabuła” przy czym tym razem ma już znaczenie wysokie. BG powinnna być gotowa przed właściwą produkcją , jako podsumowanie etapu projektowania. Musi być ciężko, ładnie ale i przejrzyście. Ta dokumentacja to drugi kontakt w kierunku inwestora/pracownika, przy czym w obu przypadkach ma olbrzymie znaczenie. Powinna dokładnie wprowadzać, pokazywać, ale i również stanowić podręcznik do którego można wrócić w momencie gdy nie za bardzo wiadomo co zrobić lub o co w czymś chodzi.

Podsumowanie

Etap w którym projektujemy grę jest niezwykle dla produktu ważny. Pozostawienie nieścisłości spowoduje duże problemy na etapie produkcji właściwej. Jego przedwczesne zakończenie również stanowczo odbije się na trudnościach wykonywania roboty.  Od strony pracownika jest on etapem trudniejszym ale i dającym często więcej satysfakcji. To właśnie tutaj tworzymy grę, jej założenia i właściwości. Wiadomo, że kreowanie contentu sprawia frajdę i jest elementem składowym produktu ale to drobina pomysłu, mechaniki lub jakiś features sprawia, że gra jest bardziej „nasza”.

Reklamy

Posted on 2012/04/18, in Inne and tagged , , , , , , , , , , , , , . Bookmark the permalink. Dodaj komentarz.

Skomentuj

Wprowadź swoje dane lub kliknij jedną z tych ikon, aby się zalogować:

Logo WordPress.com

Komentujesz korzystając z konta WordPress.com. Wyloguj / Zmień )

Zdjęcie z Twittera

Komentujesz korzystając z konta Twitter. Wyloguj / Zmień )

Zdjęcie na Facebooku

Komentujesz korzystając z konta Facebook. Wyloguj / Zmień )

Zdjęcie na Google+

Komentujesz korzystając z konta Google+. Wyloguj / Zmień )

Connecting to %s

%d blogerów lubi to: