Sekcja fabularna: Pierwsze koty za płoty

Kierunek Technologie Gier i Symulacji Komputerowych jest realizowany na Wydziale Fizyki Technicznej, Informatyki i Matematyki Stosowanej Politechniki Łódzkiej. Osoby zainteresowane szczegółami, zapraszam na stronę uczelni.

Studia z gier Zacznijmy od kontekstu: wspomniane gry powstawały jako projekty zaliczeniowe, w ramach wyznaczonych przez wymagania poszczególnych przedmiotów. Część z nich była projektami teoretycznymi (tzn. kończyła się na etapie designu), jednak przeważająca większość miała za cel stworzenie grywalnego dema gry. Strona technologiczna różniła się w zależności od semestru studiów. Projekty realizowane na trzecim roku korzystały z różnych powszechnie dostępnych silników (Unity 3D, Unreal), projekty z czwartego roku opierały się na XNA. Każdym projektem zajmował się zespół 3-6 osób.

Prace na częścią projektów miałem okazję śledzić od etapu wstępnej koncepcji, aż do końca - czyli prezentacji design docu lub grywalnego dema:

• Aeon of Strife - sympatyczny ufoludek rozbija się na tajemniczej planecie i zostaje wciągnięty w walkę między dziećmi natury a technomagami (RTS, XNA)
• Anarchia - w totalitarnym społeczeństwie przyszłości jedynie pojedyncze jednostki odważają się przeciwstawić systemowi (adventure, XNA)
• Antychryst - uzależniony od narkotyków pisarz odkrywa, że kandydat na prezydenta Zjednoczonej Ziemi jest opętany przez starożytnego demona (action-adventure, tylko design)
• Bacteria World - w zakątkach łazienki spokojna kolonia bakterii nękana jest przez ataki środków czyszczących. Muszą podjąć walkę lub zginąć (strategia-casual, tylko design)
• Cubism - komandos budzi się w labiryncie złożonym z sześciennych pomieszczeń, nie wie kim jest, lecz wie że musi się stąd wydostać, nim będzie za późno (action, Unity 3D)
• GeeGeE - mały, zielony stworek opuszcza rodzinny dom za szafą i wyrusza w poszukiwania nowego lokum. Po drodze czeka na niego wiele niebezpieczeństw (platformówka, XNA)
• Gmat - adept magii, absolwent szkoły skrytobójców postanawia pomścić śmierć swoich rodziców (action, XNA)
• Grand Theft Tractor - w nieokreślonej przyszłości odcięta od reszty świata Łódź staje się areną walk gangów, ogłupionych tajemniczym gazem bojowym (action, XNA)
• Gremlin Effect - sympatyczny gremlin przypadkiem trafia na statek kosmiczny, tylko cud może pomóc mu wrócić do domu. Albo porządna katastrofa (adventure, tylko design)
• Insomnia - lata 50te, detektyw podążający tropem zaginionej pracowniczki Politechniki trafia do pohitlerowskiego kompleksu w Górach Sowich (action-survival, XNA)
• Itsy Bitsy - opowieść o wypadku w laboratorium, zmutowanym pająku i olbrzymim głodzie (action, XNA)
• Keltoi - armie krasnoludów stoją u bram i tylko legendarny artefakt jest w stanie odwrócić bieg wojny. Mody adept Zakonu Wybranych wyrusza w poszukiwania (RPG, tylko design)
• Księga Przeznaczenia - w zaświatach los każdego zapisany jest w Księdze. Pojawienie się osoby bez przeznaczenia wywraca wszystko do góry nogami (RPG, tylko design)
• Łódź 2012 - profesor historii wchodzi w posiadanie starożytnego atrefaktu i musi wyruszyć w podróż w czasie, by uratować świat. Ma do pomocy jedynie niepoważnego studenta (action-adventure, tylko design)
• Nazi Demolition - czasy współczesne, II wojna światowa wciąż trwa. Były kierowca Monster Truck Derby otrzymuje propozycję nie do odrzucenia i trafia na front (wyścigi-action, Unreal Engine)
• PaperBoy - papierowy ludzik, ożywiony mocą dziecięcej wyobraźni wyrusza na ratunek swojemu stwórcy (adventure, XNA)
• Sole Survivor - tajemniczy wybuch niszczy centrum miasta, jedynie główny bohaterzdaje sobie sprawę, że oznacza to początek inwazji ze świata duchów (action, XNA)
• Technokanclerz - alternatywne lata 70te, zwykły człowiek zostaje wciągnięty w zmagania między siłami oporu a totalitarnym techno-reżimem (shooter, Unreal)
• Turniej - młody giermek wyrusza na swój pierwszy turniej, nie wiedząc że jest tylko narzędziem w spisku, który zagraża całemu królestwu (action-adventure, XNA)
• Ura! - skacowany mechanik budzi się na statku kosmicznym pełnym mutantów, tylko jego pomysłowość, łom i kurczące się zapasy wódki Rasputin (action-shooter, XNA).

Projekty różniły się znacznie tematyką (gry przygodowe, akcji, RTSy, cRPG, platformówki) i sposobem wykonania, jednak dało się zauważyć pewne wspólne elementy - na tyle charakterystyczne, że warto o nich napisać. Zwłaszcza, że wnioski z obserwacji studenckich projektów mogą znaleźć zastosowanie również poza uczelnią.

Zainteresowanym technologiami, które można wykorzystać do niekomercyjnych projektów polecamy http://unity3d.com/ , http://udk.com/ i http://creators.xna.com/en-US/.

Pożytek z dema Drobna dygresja: chyba każdy, kto pracował przy produkcji gier, choć raz brał udział w pracach nad jakimś demem (czasami litościwie nazywanym prototypem). Za każdym razem chodzi o to samo, trzeba coś sprzedać - grę odbiorcy, pomysł na grę wydawcy, pomysł na konkretne rozwiązanie reszcie zespołu itd. W szczególności zaś, dobrze przygotowane demo / prototyp jest w stanie sprzedać nas, jako pracownika, potencjalnemu pracodawcy.

Mało który pracodawca patrzy na ocenę na dyplomie - potrzebuje natomiast dowodów, że potencjalny pracownik przyda się podczas produkcji. Trudno wtedy o lepszy argument, niż działający fragment gry, o którym można powiedzieć: "to moje".

Nie będę omawiał strony programistycznej projektów - dla nie-programistów byłoby to zbyt nudne a programiści i tak mają zwykle swoje własne pomysły. Skupimy się na stronie designerskiej, decyzjom odnośnie kształtu i zakresu projektu. Czai się tam dużo pułapek a jednocześnie trudno znaleźć dobrą literaturę na ten temat.

Cel - zamknięta całość Projekt musi się sprzedać, zainteresować sobą odbiorcę. Innymi słowy, musi coś odbiorcy obiecać a następnie to dostarczyć - przyciągnąć dobrym pomysłem, zrealizowanym w solidny sposób. Zaryzykuję twierdzenie, że choć pomysł na grę jest rzecz jasna ważny, to w większości przypadków jakość wykonania decyduje o sukcesie.

Brutalna prawda jest prosta: pomysły są tanie. Na dobry pomysł może wpaść każdy (uprzedzając dyskusję - nawet jeśli tak nie jest, większość inwestorów i odbiorców gier uważa, że na dobry pomysł może wpaść każdy; warto brać to pod uwagę). Jednak zdecydowanie nie każdy jest w stanie przekuć pomysł na strawną, zamkniętą całość. Dużo łatwiej wpaść na pomysł i zacząć go rozwijać, niż w skończonym czasie zakończyć prace.

Spójna, zamknięta całość, która ma jak najwięcej cech gotowego produktu - to są cele o które opłaca się powalczyć robiąc demo lub prototyp.

Pamiętajmy, dla pracodawcy istotne są umiejętności. Wszystko, co udowadnia, że potrafimy zrobić coś konkretnego, jest na wagę złota. Nic nie przekonuje lepiej, niż praktyczny przykład. Podobnie jest, patrząc od strony inwestora - interesuje go, czy dostanie na czas obiecany produkt. Marketingowe mumbo-jumbo może pomóc w pierwszych etapach rozmów, jednak prędzej czy później trzeba będzie podeprzeć ofertę prototypem. Zresztą, końcowym odbiorcą każdego dema - mniej lub bardziej pośrednio - jesteśmy my, gracze. A wszyscy chyba wiemy, jak irytujące są niedoróbki i nierozwinięte pomysły.

Czasu jest zawsze za mało, więc cała produkcja powinna być podporządkowana jednemu celowi: zamknięciu prac w terminie i osiągnięciu przy tym zakładanego efektu. Podstawa to zawczasu zidentyfikować silne i słabe strony swojego zespołu - i odpowiednio do nich zaplanować produkcję (jeśli mamy do dyspozycji dobrych programistów i żadnego grafika, lepiej od razu założyć, że gra będzie przyciągała dopracowaną rozgrywkę i nie obiecywać graficznych fajerwerków).

Gdy przygotowujemy obietnicę dla gracza świadomi swoich możliwości, zwiększamy szansę, że rzeczywisty efekt prac dorośnie do naszych obietnic.

Studium przypadku Zamiast omawiać wszystkie tegoroczne prace, postanowiłem podzielić się z wami dość egzotycznym wyborem notatek i spostrzeżeń, które zrodziły się podczas oglądania prezentacji projektów. Mam nadzieję, okażą są wystarczająco inspirujące, by warto je było przytaczać i wystarczająco anegdotyczne, by chciało się je czytać.

• Demo to gra w miniaturce, więc powinno mieć te same mocne strony, które mają stanowić o sile finalnego produktu - jeśli obiecuje się grę w otwartym świecie, lepiej nie robić dema w całości rozgrywającego się piwnicach.
• Warto pamiętać dla kogo przeznaczona jest gra. Jeśli robi się grę dla dzieci, lepiej nie zaczynać w chwili, gdy bohater staje się dorosły - i nie przesadzać z wulgaryzmami i alkoholem.
• Interfejs jest ważny, gra musi być zrozumiała sama z siebie, bez komentarza. Jeśli podczas z dema ktoś musi stać przy graczu i mówić: "musisz teraz otworzyć tę skrzynię" to nie jest dobrze.
• Gra powinna być być zrozumiała i czytelna także na poziomie motywacji. Bohater musi mieć coś do zrobienia i gracz musi chcieć to zrobić.
• Jeśli obiecuje się epicką fabułę, lepiej nie robić dema o kameralnych rozmowach o codziennych sprawach.
• Dialogi - warto je wyeksponować jeśli w zespole jest ktoś, kto dobrze pisze. W przeciwnym przypadku lepiej ograniczyć rozmowy do niezbędnego minimum. Żelazna reguła: mniej tekstu to zawsze lepiej. Każdy dialog koniecznie choć raz trzeba przeczytać raz na głos.
• Audio dużo robi. Muzyka (to aż zaskakujące, jak wiele osób ma znajomych muzyków), efekty specjalne (dużo darmowych bibliotek można znaleźć na sieci) no i nagrania dialogów. Nie muszą być bardzo profesjonalne - nagrany dialog robi po prostu lepsze wrażenie niż sam tekst.
• Ludzie dobrze zapamiętują początek i koniec - dlatego warto zainwestować w czołówkę i creditsy. Nie zajmuje to dużo czasu a tworzy wrażenie, że zespół działał według planu - nawet jeśli tak nie było (no ale skoro pomyśleli nawet o creditsach...).
• Klucze są trochę passe. Zaskakujące jest, jak wiele projektów - niezależnie od gatunku - opierało się podnoszeniu leżących w najbardziej ekstrawaganckich miejscach kluczy.
• Warto chwalić się pomysłami. Ten jeden, najważniejszy koncept, który ma sprzedać grę warto pokazać najwcześniej jak się da. Naprawdę warto.
• Pod koniec prac opłaca się poświęcić trochę czasu na dopieszczenie wizualne gry, sprawdzenie interfejsu itp. Prezentacja w przeważającej liczbie przypadków skierowana jest do osób z branży, które zdają sobie sprawę z tego, że w grach są błędy. Nie musi być technicznie idealna. Ale nawet osoby z branży kupują oczami.

Większość projektów wyszła fajnie - zwłaszcza biorąc pod uwagę, że były robione po godzinach, w czasie studiów i zwykle na technologii, która wymagała doszycia sporej liczby mechanizmów. Okazuje się, że największe problemy pojawiały się po stronie organizacji projektu, a najbardziej zauważalne wady dotyczyły nie oprogramowania funkcjonalności ale zakomunikowania graczowi, że może z nich korzystać.

A typ gry? Okazał się nie mieć większego znaczenia - bardzo dobre pomysły pojawiały się w praktycznie każdym gatunku.

Artur Ganszyniec