Poradniki

 
 
 
Warsztat pracy
(X-tech)

Witam. Zostałem poproszony o wyjaśnienie w jaki sposób robiłem gry w makerze. Nie ma na to żadnego schematu i cudownego sposobu, ponieważ za każdą grę zabierałem się inaczej. Niech za przykład posłuży 8bit quest, bo to w sumie jedyna gra, która była tworzona jako oficjalna i została ukończona. Pierwszą rzeczą, którą ustaliłem jest mój cel. Jaki cel chce osiągnąć robiąc projekt? W przypadku 8bit quest chciałem zwyczajnie wykreować rozgrywkę bazując na idei pacmana, ale tak, aby dać zarazem coś nowego i aby mieć z tego przyjemność i dać w tym projekcie to co podobało mi się w grach, które mogły być wdrożone do idei pacmana. Drugi cel - dodać gameplay do kolekcji ulubionych utworów modułowych. Trzeci cel:  dać rozgrywkę, która nie może zawieść graczy (!). Trzeba się było więc zastanowić nad tym, jak realizować grę, by gracz nie mógł się nudzić w trakcie każdej spędzonej z grą chwili w odróżnieniu od projektów, które robiłem po cichaczu. Przyszły mi na myśl elementy z wielu różnych gier zręcznościowych, jakie przewinęły się przez moje życie i dały mi mnóstwo radochy. Głównie chodziło tu o przeszkadzajki i zdolności, które jednak, jak sie w końcu okazało,  wymyśliłem bazując na ograniczeniach rpgmakera XD.
Inną ważną rzeczą, nad którą się zastanowiłem to styl graficzny, na jakim będę robił grę. Musiałem jakiś wybrać, gdyż w grze, w której liczy się w miarę spójność grafiki najważniejsze to wybrać styl przed przystąpieniem do jakiegokolwiek tworzenia fabuły. Mówię tutaj o stylu zasobów z gotowych już gier, z których to czerpiemy ripy.


Przed przystąpieniem jednak do tworzenia gry najważniejsze to pomyśleć o tym, kto będzie miał w to grać - czy użytkownicy makera czy wszyscy ludzie, którzy go nie posiadają. Mi zależało na tym, aby mógł zagrać każdy, więc stworzyłem pusty projekt, który nie wykorzystuje żadnych materiałów RTP. Dzięki temu wszystkie zasoby były zewnętrzne i miałem pewność, że każdy kto nie posiada makera będzie mógł w to zagrać. Projekt, tak zwany pusty, umieściłem na stronie tsukuru.pl w dziale z programami. Jest tam do pobrania (pusty projekt) i to właśnie na nim radzę zacząć tworzyć każdemu kto chce stworzyć grę w rpgmakerze. Nie będzie wtedy problemu z działaniem gry u osób, które nie posiadają tego rtpowego dobrodziejstwa, a zarazem rozmiar gry nie przerazi.
Nadszedł czas obmyślenia stylistyki graficznej. Miało być totalnie w stylu final fantasy 1,2,3, oraz pierwszych dragonquestów. Tutaj zdecydowałem się na tytuł uwzględniając, że to ma być prosta zręcznościówka odnosząc się do głębi tych zasobów, a także wdrożonej muzyki. Pod maniackim uporem komentujących, że grafiki są niespójne, ograniczyłem styl graficzny do grafiki DE z zestawu grafik pod tytułem AKROPOLIS. Niech ta rada jednak (ODNOŚNIE GRAFIKI) będzie dla was nauczką, że nie warto się sugerować opiniami innych, ponieważ z powodu wyboru tego stylu graficznego zawierającego śladową ilość grafik, byłem ograniczony do totalnego uproszczenia tworzonej później fabuły do tego świata (a także tworzonych przeszkadzajek) do poziomu grafik jaki ten zestaw Akropolis reprezentuje. W przypadku postaci, na szczęście nie ograniczyłem się do postaci od DE i dzięki temu mogłem pozostać bardziej swobodny w wymyslaniu wrogów.W moim projekcie chciałem zastosować niestandardową muzykę w formacie modułowym, więc zainstalowałem do projektu powermode2003, którego osobiście w ogóle nie polecam. Są inne narzędzia, które obsłużą formaty (xm,it,mod), ale powermoda2003 nie polecam, gdyż są z nim problemy. Także, jeśli ktoś chce mieć muzykę modułową w projekcie niech poszuka innego rozwiązania lub zostanie przy muzyce midi, ale lepiej na tym wyjdzie, czego się dowiedziałem obcując z tym dodatkiem w trakcie tworzenia 8bitquest.


Nadszedł czas obmyślenia podstawowych założeń gry, jak ona bedzie przebiegać. Postanowiłem, że będzie to zręcznościówka, w której będzie można wracać do odkrytych już poziomów. Uznałem, że najlepsza będzie mapa z wieloma drzwiami, które będą się stopniowo otwierać i dawać nam dostęp do kolejnych etapów. Bardzo proste i wygodne, i nie wymagało dorabiania osobnego menu. Zależało mi na tym, aby wprowadzić sklep więc musiałem pomyśleć o tym jak go zrealizować i kiedy będzie można do niego uzyskiwać dostęp. Postanowiłem, że będzie to sprzedawca na mapie głównej, a sklep stworzę na osobnej mapie na zdarzeniach. Kolejnym ważnym elementem są moce specjalne, które można było dokupić - musiałem więc jednocześnie zacząć projektować jedną mapę TESTOWĄ wraz z wrogami i przedmiotami do zebrania, na której musiałem (uwaga!) przewidzieć wszystkie MOŻLIWE do użycia na przyszłych kopiach tej mapy zdarzenia(eventy).Dzięki temu będę mógł już w miarę szybko zacząć przystępywać do tworzenia poziomów (kopiująć i przerabiając mapę testową)i jednoczesnie mieć z czasem możliwość do wymyślania kolejnych specjalności, wykorzystam te eventydo wytworzenia kolejnych mocy. Mapa testował musiała też zawierać zasady rozgrywki, czyli wszystko to, co się dzieje na początku etapu (ustawienie wszystkich wartości na początkowe) i to co się dzieje po jego zakończeniu (powrót na mapę główną).
Jednocześnie pracowalem nad sklepikiem zbudowanym na osobnej mapie i na każdy nowo wymyślony skill dorabialem od razu grafikę ikony do sklepu za pomocą painta. Musiałem zastanowić się nad hudem, który reprezentowałby ilości pozostałych umiejętności w trakcie rozgrywki, ale to odłożyłem na koniec, aby dokładnie wiedzieć ile miejsca będę potrzebował, aby przedstawić go na ekranie. Jednocześnie musiałem pracować nad założeniami rozgrywki, ale chciałem nie być zależny od jednej mapy, ale móc robić wszystko w locie, więc postawiłem na eventy w zakładce typowe zdarzenia (common events) W przypadku takiego wymyslania gry, nie byłem już zależny od eventów na mapie I MOGŁEM używać własnych skryptów w każdej mapie i w każdej chwili. Odniesienia jednak do eventów na mapie zostały totalnie ograniczone do wartości zmiennych w tych eventach, a odniesienia do grafik zostały zastąpione pokazywaniem na ekranie obrazków z folderu pictures takich jak ilość zebranych punktów. W przypadku tworzenia mechaniki rozgrywki każda najmniejsza funkcja czy skrypt były osobnym eventem typowym. Za przykład podam licznik kroków: to osobny event, obok niego event, który coś wywołuje zależnie od ilości kroków, następny zajmujący się odmierzaniem czasu, a kolejny, który sprawdzał czy czas dobiegł końca. Jak widzicie, kiedy tworzyłem grę, aby wszystko było przejrzyste, chciałem każdy skrypt uczynić osobnym zdarzeniem typowym (common eventem). Chciałem też ZARZĄDZAĆ zdarzeniami, więc każda grupa zdarzeń włączała się tylko, jeśli został wywołany jej typ np: zdarzenia poziomu uruchamiały się kiedy znajdowaliśmy się na planszy, a po niej na mapie głównej, gdzie wszystkie te zdarzenia zostały wyłączane, o co dbał przełącznik, który na mapie głównej wszystko wyłączał. Co najważniejsze - wszystkie zdarzenia, które znacie z makera jak np: GAMEOVER musiałem zaprojektować jako osobne zdarzenia typowe "common events" aby w nich mogły zajść zmiany, które były dla mnie istotne jak np.: decyzja czy mamy zostać przeniesieni do menu głównego czy może tylko na początek poziomu lub na mapę główną. Także powiem tylko tyle, że najlepiej wszystkie zdarzenia, które znacie z makera i chcecie zrealizować jako główne zrobić osobno.



W przypadku tworzenia pojedynczego etapu podstawowego:
Bardzo ważne było wytworzyć zdarzenie, które będzie zerowało wszystkie wartości na początku , a więc jeśli na mapach zastosowałem jakieś zmienne, które ulegały zmianie, a chciałem by po przejściu na inną zostały przywrócone do pierwotnego stanu musiałem wytworzyć zdarzenie, które będzie wywoływane zawsze przed kolejnym etapem lub na jego początku, które zawsze te wartości wyzeruje. Wartościami zerowanymi były np.: pozostały czas licznika, zebrane przedmioty, punkty zdobyte na poziomie itd. Musiałem też zastanowić się, jak tworzyć etapy tak, by każdy był trochę trudniejszy od poprzedniego i tu nie decydowała ilośc przedmiotów do zebrania, ale ukształtowanie terenu i związane z nim niebezpieczeństwa. Najlepsze etapy to małe etapy, a jeśli duże to wypełnione różnorodnymi przeszkadzajkami. Muzykę na etapach dodawałem różnie - czasem tworzyłem etapy pod utwór jaki mi się podobał, a czasem dodawałem utwory, które pasowały by mi do charakteru gotowego juz etapu.


Pewnie interesuje was, jak zostało zrobione mini-menu w grze na mapie głównej. To nic innego jak zwykłe okno wiadomości wyświetlające wartości zmiennych, które według mnie mogą interesować gracza. Które to zmienne i jak zostało zrobione to menu dokładnie widać na powyższym screenie.


Teraz pytanie odnośnie fabuły. Dlaczego nic nie piszę na jej temat? Jeśli ktoś od razu tego nie chwycił OD RAZU to wyjaśnię. Założeniem było stworzenie gry zręcznościowej, a więc dopisałem sobie fabułę trochę później kiedy już miałem obmyślany i zrobiony główny trzon schematu rozgrywki/przeszkadzajki/wrogów i sporą częśc umiejętności/sklepu i etapów. Z czasem trzeba było uczynić pracę w makerze bardziej przejrzystą, więc stworzyłem sobie podział map w rpgmakerze. Stworzyłem pustą mapę, ktorą nazwałem INTRO i pod nią było miejsce na INTRO, oraz trening. Stworzyłem kolejną pustą mapę o nazwie OUTRO i pod nią było zakończenie. Stworzyłem kolejną pustą mapę o nazwie SKLEP i pod nią stworzyłem wspomniany sklep. Stworzyłem mapę o nazwie TITLE i pod nią stworzyłem ekran tytułowy. Stworzyłem mapę RUN QUEST pod nią były mapy nastawione na bieganie. Pod mapą REAL QUEST były typowe poziomy, a pod mapą BATTLE QUEST były poziomy walki. Dodałem na końcu pracy kolejną pustą mapę, którą nazwałem CREDITS i w ten sposób miałem miejsce na przedstawienie listy ludzi, których zasobów użyłem. Credits było tworzone ciągle wraz z każdymi dodawanymi zasobami. Wszystkie te mapki zawarły się pod mapą MAPA GŁÓWNA, która to zawierała wybór poziomów i sklep. Przed zrealizowaniem OUTRA musiałem jeszcze doszlifować cechy liczbowe gry tak, aby wszystko stopniowo narastało (wartości bonusów, punkty za zdobyte przedmioty, poziom trudności) Dodałem też ukryte bonusy na planszach, oraz dopieściłem ekran tytułowy.

W ten sposób powstał 8BITQUEST. To wszystko. Niektóre z tych moich rad mogą się przydać, ale to nie jest złoty środek i nie sprawdzi się w każdej grze. Wbrew pozorom wszystko co tu zawarłem jest bardzo proste. Dziękuję za uwagę.
Tekst by wasz ulubiony X-TECH (AI-RPG).