GoniecRM

Warsztat pracy

Na wstępie pragnąłbym wspomnieć, że mój styl tworzenia gier zmieniał się co kolejną produkcję, zatem w poniższym artykule przedstawię sposób, jaki wypracowałem sobie w ostatnim czasie. Oczywiście wszystko bazuję na doświadczeniach z RPG Makera 2003, ponieważ tylko takiego używałem, co nie przeszkadza w zastosowaniu moich porad w innych wersjach silnika.

PRZYGOTOWANIE DO TWORZENIA
Pierwszą rzeczą nie jest, i podkreślam, NIE JEST uruchomienie RPG Makera i uderzenie w klawisz "Nowy projekt". Nie, nie nie i jeszcze raz - nie. W ogóle mój pierwszy krok w tworzeniu gry nie wymaga nawet użycia komputera. Najpierw wymyślam ogólny koncept gry - czyli jaki gatunek, jakie klimaty, jaka mechanika. Raz zajmowało mi to chwilę (co kończyło się albo nie wydaną grą albo nie "trzymającą się kupy", patrz - "Kościak & Friends"), a w przypadku mojego ostatniego projektu minęły dobre 3 lata , zanim zacząłem faktycznie realizować swoje zamiary (w międzyczasie tworzyłem inną grę). Nie, dalej nie dotknąłem się do RPG Makera, ale do komputera już tak. Uruchomiłem MS Word i zacząłem pisać dokument projektowy (ang. design document). Wcześniej rozpiska do gry to była albo kartka papieru z zeszytu, albo plik Notatnika, jednak dopiero porządny dokument, ze spisem i rozplanowaniem treści, pozwoli mi pomieścić informacje na temat świata, fabuły, postaci, przeciwników i masy innych elementów gry. W czasie pisania tego tekstu ma on blisko 7 tysięcy słów, co stanowi więcej, niż moja praca licencjacka ;) Świadczy to tylko o tym, jak bardzo zaangażowany jestem w projekt. Taki dokument najlepiej aby zawierał: listę autorów zasobów, lista zmian w grze (pozwoli śledzić postęp - motywuje!), ogólny przegląd gry, opisy mechaniki, przedmiotów, fabuła, elementy świata, oraz lista przeciwników. Po opisaniu podstawowych zagadnień, zebraniu grafik, których chcesz użyć (bohaterowie, jakieś animacje i inne najbardziej przydatne), możesz w końcu uruchomić RM i zacząć tworzyć projekt. W czasie tworzenia oczywiście aktualizujesz dokument projektowy o nowe rzeczy, zmiany zapisujesz w liście. Pamiętaj oczywiście o odpowiednim opisywaniu tego, co tworzysz, gdyż bez tego w przyszłosci możesz pogubić się w np. swoim rozbudowanym systemie walki - opisz zmienne, przełączniki, działanie zdarzeń. Warto też dokumentować swoje osiągnięcia robiąc filmiki z gry! To kolejny dobry sposób na zmotywowanie się do działania, przynajmniej w moim przypadku.

TECH-DEMO, FUNDAMENTY TWOJEJ GRY
Faktyczne znaczenie tego określenia oznacza demo technologiczne silnika gry. I choć my już silnik, tj. RPG Makera, mamy gotowy, to jednak mechanika naszej gry będzie wymagała mapy, na której będzie się eksperymentowało ze zdarzeniami i krok po kroku tworzyło szablon dla zasadniczej gry. Zanim jednak przystąpisz do tego punktu, włącz bazę danych i usuń wszystko. Wszystko, co do jednego. Wszystkie te podstawowe wpisy do bazy na 99,9% nie przydadzą Ci się w grze, będą tylko zagracać potrzebne miejsce. Możesz także przechowywać statystyki i inne wartości wyłącznie w zmiennych gry - rozwiązanie dla hardkorów, jednak ja preferuję korzystanie z bazy danych. Uporządkowanie bazy danych da także możliwość łatwiejszego uporania się z brakującymi plikami z RTP, dzięki czemu łatwiej dostosujemy swój tytuł do grania na maszynach bez zainstalowanego RM/RTP. Po uporządkowaniu bazy danych gry można wreszcie zacząć się bawić. Ważnym jest wzięcie pod uwagę ID wpisów, bardzo ważnym wręcz. Dla przykładu: kolejność przedmiotów w grze jest bezpośrednio uzależniona od ich kolejności w bazie danych. A nawet jeśli ID nie będą miały bezpośredniego wpływu na rozgrywkę, warto wziąć pod uwagę porządek (o czym później). Wracając do kwestii tech-dema, pamiętaj aby póki co zebrać/stworzyć TYLKO te grafiki, które są Tobie potrzebne. Ja użyłem tylko grafik dotyczących postaci, reszta to były na szybko robione (albo wstawiane z RTP) zastępstwa (lub po ang. placeholdery). Większość zdarzeń na mapie testowej będzie służyła zazwyczaj do resetowania, zmieniania zmiennych, przełączników, i innych szczegółów. Dość dokładnie przetestuj wszelkie aspekty mechaniki, które chcesz wykorzystać, zanim będziesz chciał zacząć robić grę. Dlaczego? Bo potem będzie za późno na poprawianie, gdyż trzeba by było na każdej mapie poprawiać tę samą, błędną kopię zdarzenia. Przerabiałem to w "Z archiwum Tsukuru", gdzie stworzyłem tylko podstawowy typ wroga, który podbiega do gracza i go uderza bezpośrednio. Potem, jak chciałem stworzyć nowych wrogów, wykorzystujących nieco inne manewry, musiałem ich wklejać osobno na każdą mapę, co było niebywale czasochłonne i stwarzało przy okazji bugi. Ta sama rzecz miała się ze skrzyniami z przedmiotami. Po osiągnięciu żądanego efektu w postaci działającej mechaniki, kopiujemy obecną mapę, zmniejszamy do jak najmniejszego MOŻLIWEGO rozmiaru (tak aby zdarzenia nie poginęły) i mamy gotowy szablon do tworzenia map w faktycznej grze. Wystarczy tylko skopiować, usunąć to, co niepotrzebne, przerobić na szybko, i mamy np. przeciwników na mapie bez kopiowania ich pojedynczo! Oczywiście ważnym elementem do stworzenia dobrej gry jest wykorzystanie zdarzeń typowych (common events), bez tego ani rusz, chociaż z nimi jest o tyle łatwiej, że są globalne, czyli występują w całej grze, bez względu na mapę. Jeśli uważasz, że tech-demo zostało skończone (oczywiście po testach), odnotuj ten fakt w liście zmian, spakuj w archiwum i wstaw na hosting, aby nie zaginęło. No i pierwszy krok masz za sobą, zasłużyłeś na mały odpoczynek ;)

MECHANIKA - czyli jak to się wszystko dzieje
Dobra, mam swoją głowę generującą mnóstwo pomysłów, mam dokument na kompie w którym rozpisuję wszystko co się da. Ale mimo wszystko mam przed komputerem brudnopis, w którym znajdują się rzeczy różne i różniste. Pytanie po co? Cóż, zeszyt i długopis mimo wszystko są elastyczniejsze od dokumentu Worda. Szczególnie dobry jest jeśli chodzi o pisanie o luźnych konceptach, projektowanie map, rysowanie prostych concept-artów, schematy decyzyjne (niezastąpione przy projektowaniu skryptów!), i podobne. Spójrz zresztą na moje super-ambitne bazgrołsy ;)

PRIORYTETY W PROJEKTOWANIU
Tak, ważne jest ustalanie priorytetów, bo nie jesteś przecież jednoosobowym wcieleniem Square-Enix, Konami czy innej firmy która może zatrudnić nie wiadomo ilu ludzi od nie wiadomo czego, i zrobić wielką grę w 2 lata. Nawet jak masz jakiś zespół, musisz pomyśleć, co jest najważnejsze do zrobienia. Przedstawię to na przykładzie słynnej gry "DooM". Dlaczego wrogowie, kiedy żyją, to (pomimo zastosowania sprite'ów) widać w którą stronę są odwróceni? Ponieważ ma to bezpośredni wpływ na grywalność, wiemy czy wróg patrzy na nas (i chce zaraz strzelić) czy nie. Natomiast po zabiciu wroga (czy też dajmy na to gracza) zostaje trup, który odwraca się w naszą stronę za każdym razem. Tak, chłopcy z iD mogliby zrobić że trup tak samo udaje perspektywę jak żyjące potwory, ale po co? Żeby tylko "dla picu" się narobić? Jakby tego było mało, ówczesne komputery nie były zbyt zaawansowane, nośniki danych nie mogły przyjąć dużo "wagi" (wspomniany "DooM" był sprzedawany na 4 dyskietkach 1,44 MB zdaje się), no i sam silnik iD-Tech1 ma sporo ograniczeń i toporności, jak zresztą używany przez nas RPG Maker. Dlatego tworząc grę radzę, aby zająć się konkretami, nawet jakby miały wyniknąć z tego drobne bezsensy. Lepiej trochę drobnego bezsensu, jak zepsuta grywalność lub stracony czas przy tworzeniu przez pseudo-realistyczne szczegóły. Należy też wziąć pod uwagę ograniczenia silnika, na którym tworzymy, inaczej czeka nas brutalna walka z wiatrakami. Oceń także swoje możliwości i umiejętności, bo mimo ustalenia w dokumencie projektowym konceptów gry, nie zawsze uda Ci się je zrealizować. I pamiętaj, aby nie upierać się nad zrobieniem czegoś, co nie działa, albo po prostu czegoś, co nie potrafisz zrobić. Gdybym uparcie pracował nad dwiema minigierkami w "Z archiwum Tsukuru", to najpewniej dawno straciłbym wenę, a gra nie zostałaby ukończona. Zobacz zresztą na produkcje komercyjne, ile można tam znaleźć zasobów wyrzuconych z finalnej wersji ze względu na za dużą ilość bugów, niedopracowań. To, że tak się dzieje, jest całkiem naturalne. Przez popełnianie takich błędów kilka moich wcześniejszych projektów poleciało do kosza lub kisi się gdzieś na archiwach płyt DVD, i z obecnego punktu widzenia nawet nie chcę tknąć tej kaszany, którą robiłem dawno temu :)

PORZĄDEK!
Porządek w projekcie jest rzeczą wbrew pozorom bardzo ważną. Dość dużo czasu spędzimy w bazie danych, tak więc wypada we wspomnianym już brudnopisie przydzielić zakresy ID dla przedmiotów, umiejętności itp. (screen poniżej). Nie tylko będzie miało to wpływ na estetykę oraz łatwość poruszania się po projekcie, ale także na samą grę. W RPG Makerze, przynajmniej 2000/2003, umiejętności i przedmioty w menu ułożone są według tej samej kolejności, co w bazie danych. Czy Ty, jako gracz, mógłbyś w trakcie walki szukać przedmiotu leczącego pośród różnych śmieci, podczas gdy na Ciebie czycha morderczy potwór? Szybko skończyłoby się to game overem, a także użyciem kombinacji klawiszy Alt+F4 i Shift+Delete na grze. Kolejna kwestia to porządek w mapach. Z pozoru prosta rzecz, gdyż mapy w RM są posortowane w taki sam sposób, jak foldery na dysku. Należy zatem pamiętać o prostej zasadzie - mapa świata>mapa lokacji>mapa podrzędna w mapie lokacji. Mapy specjalne, takie jak intro, napisy końcowe, czy też wspomniana mapa z tech-demem najlepiej umieścić w oddzielnym "folderze". W końcu porządek z zasobami użytymi do tworzenia gry. Na screenie poniżej widać, jak poukładałem pliki w folderze z muzyką. Nazwy plików wyraźnie wskazują na sytuację, do której utwory pasują, a także zawierają tytuł i autora/pochodzenie kawałka. Podobnie należy postąpić z resztą, dopisując przedrostki w nazwach plików, np. "Hero-", "Items-", "Enemies-" itp. itd.

ODCHUDŹ KOD I OGRANICZ BUGI
RPG Maker jest dość prostym silnikiem, jednak ma bardzo potężne funkcje, które ułatwią projektowanie gry oraz pozwolą na uniknięcie wielu bugów. Wyobraźmy sobie, że robimy własny system walki, zrobiłeś zdarzenie sterujące nim na mapie. Potem kopiujesz je na pozostałe mapy, wraz z wrogami, innymi zdarzeniami, itp. Ups! Mamy buga. Ale gdzie? Na której z map? Naprawiasz tegoż buga, ale potem okazuje się, że tym samym narobiłeś sobie nowych kłopotów, a gra nie trzyma się całości, o czym już chyba przestrzegałem. Z pomocą przychodzą tu "zdarzenia typowe" (common events). Są to zdarzenia, które istnieją globalnie, w całej grze, a co za tym idzie, występują tylko raz, wywoływane są odpowiednimi przełącznikami lub poleceniem wywołania tegoż zdarzenia. Skoro mamy jedno takie zdarzenie na całą grę, mamy też tylko jedno miejsce, w którym może się coś posypać lub możemy narobić bugów. Naprawiasz zdarzenie typowe - problem raz na zawsze z głowy! A ile roboty, czasu i nerwów zaoszczędzone! Niestety ta funkcja ma swoje ograniczenie, a mianowicie nie może się odwoływać do eventów na mapie, chyba że odpowiednio je ustawisz pod względem ID, ale to jest bardzo ciężko osiągnąć nawet najbardziej zaawansowanym. Tak więc niektóre zdarzenia, np. wrogowie w ABS, muszą mieć wpierw dopracowane odpowiednie prototypy na mapie testowej, by potem można było je kopiować na inne mapy bez obaw o bugi. Kolejną funkcją, tym razem przydającą się między innymi przy drzewkach dialogowych, są etykiety (labels). Tak jak wspomniałem - powtarzalność kodu w grze powoduje zwiększenie prawdopodobieństwa, że wyskoczy nam gdzieś bug, albo gra będzie niespójna. Tym razem załóżmy, że mamy dialog z NPC, i w pewnym momencie chcemy, a by zdarzenie tegoż wyświetliło ten sam fragment tekstu, co wcześniej. Nie, nie kopiujemy tegoż tekstu!! Dołożysz sobie wtedy niepotrzebnych poleceń zdarzeń. Po co, skoro można ustawić w wybranym momencie etykietę, do której gra przeskoczy? Poniżej jak zwykle screeny obrazujące, co mam na myśli.

CZŁOWIEK POMUSZ ;_;
Szukasz pomocy przy grze? To pewnie zaraz polecisz machnąć temat na forum, że chcesz zebrać wielką ekipę na epicką przygodę w świecie RPG Makera, która zakończy się wielkim hitem wśród innych makerowców. Tak? No to się mylisz, to nie działa w ten sposób. Wpierw spróbuj skumplować się z kimś ze sceny, jeśli już tej pomocy naprawdę potrzebujesz. Serio, to działa - przykład mój i Ska'cia czy też TagTeamu jest na to dowodem. Chcesz muzyki? Grafiki? W moim przypadku muzyka znalazłem po prostu pytając się go na YouTube, czy użyczy mi utworu do gry, co skończyło się wyrażeniem chęci współpracy, zupełnie za darmo! Grafika prawie że udało mi się "zatrudnić" poprzez między innymi komentowanie jego prac na deviantART. Prawie, bo niestety współpraca zerwała się nagle, w niezbyt ciekawych okolicznościach, a była to kolejna osoba skora mi udzielić bezinteresownej pomocy przy grze.

I to by było na tyle, mam nadzieję że moje "pro tipy", bazowane na moich własnych doświadczeniach, pomogą Wam w tworzeniu własnych projektów. Na zakończenie jeszcze pewna sprawa - dlaczego nic, ale to nic nie napisałem o tym, jak robię mapy? Uznałem to za kwestię nieistotną, bo co Ci po mapach, jak gra będzie nieznośna dla gracza, który potraktuje ją Alt+F4, Shift+Delete? Tak jak ci kulturyści mówią - wpierw masa potem rzeźba, tak ja mówię - wpierw solidna podstawa techniczna gry, potem mapy i kwiatki na nich.

PS. A, i regularnie róbcie kopie zapasowe! Żeby nie zaatakował was Spalony Dysk™ albo Zuy Crasnal nie dokonał formatu. Aby nie dopuścić do tego, dbajcie także o swój sprzęt, aby służył wam jak najdłużej bezawaryjnie i nie zagrażał projektom ;)