Moja przygoda z GameDevem zaczęła się +/- 8 lat temu od RPG Makera XP. RPG Makery to programy do tworzenia gier typu JRPG bez konieczności znajomości programowania. Mają dość spore ograniczenia technologiczne (poza głównym, że są tylko 2D), a większość gier zrobiona w nich wygląda tak samo. Mają jednak nad Unity jedną wielką przewagę - tworzenie nowego contentu jest banalnie proste.
Obecnie, od ponad pięciu lat zawodowo zajmuję się Unity w ponad dziesięcioosobowej grupie. Często zauważam, że dodanie drobnej rzeczy w projekcie niepotrzebnie angażuje programistę i trwa zbyt długo. Używając RPG Makera stworzenie w grze jakiejś misji, cutscenki czy dialogu jest jak budowanie z lego i może to zrobić sam designer, bez proszenia się kodera. Wniosek - trzeba sobie zrobić RPG Makera do Unity.
Skryptowanie w RPG Makerze polega na ustawieniu kolejki predefiniowanych akcji z odpowiednimi parametrami. Dostępna jest pula zmiennych, do których można sobie zapisywać np. ilość zabitych wilków lub nieudanych prób poderwania córki kowala. Zapisane wartości można potem wykorzystać np. do modyfikacji dialogów.
RPG Maker für Unity (nazwijmy go RMU):
Okno inspektora zdarzenia. Od góry:
1. Lista stron danego zdarzenia - każda strona jest jakby osobnym zdarzeniem (listą komend). Strony organizuje się w zdarzenia dla większej przejrzystości. Przykładem mogą być różne wypowiedzi jakiegoś NPC w kolejnych fazach zadania. Można oczywiście w ramach jednej listy postawić X warunków sprawdzających zapisany stan zadania, ale osobne strony pomagają w ogarnięciu takich sytuacji.
2. Aktywacja strony - akcja wymagana do odpalenia listy komend. Aktualnie są to: przycisk akcji gracza, wcniśnięcie zdefiniowanego klawisza na klawiaturze, automatyczny start, kolizja z innym obiektem, działanie w tle.
3. Dodatkowe warunki strony - można zdefiniować kilka stanów przełączników (bool) i wartości zmiennych wymaganych do uruchomienia listy. Np. strona ze szczególnymi gratulacjami odpali się tylko jeśli wynik twoich działań będzie większy od X.
4. Lista komend - każda komenda ma opis, by nie trzeba było wchodzić w okno jej edycji chąc sprawdzić co robi. Przyciski widoczne w prawym górnym rogu każdej komendy to funkcje typu Copy, Paste, Cut. Aktualnie są trochę w rozsypce, ale w innym branchu projektu ich funkcjonalność jest całkiem niezła (przenoszenie w górę/dół, etc.).
5. Przycisk "New Command" - otwiera okno z listą dostępnych akcji:
Lista komend: po lewej kategorie, po prawej elementy kategorii. Obecnie działają następujące komendy:
Logika:
- Operacje na zmiennych i przełącznikach. Do zmiennej można zapisać np. pozycję jakiegoś obiektu, współrzędne kursora, wartość losową, etc.
- Sprawdzanie warunków dla w/w, czyli "czy zmienna X >= wartość", tudzież "czy zmienna X >= zmienna Y".
- Czekanie przed wykonaniem kolejnej akcji. Czas ustalony lub zapisany w zmiennej.
Dialogi:
- Wyświetlanie okna wiadomości. Obsługuje kilka tagów, np. pauza przed wyświetleniem reszty tekstu, automatyczne zamykanie po czasie. Można też wyświetlić jako okna dodatkowe (np . nakładające się okrzyki tłumu) - ich maksymalną ilość możemu ustalić.
- Wymuszenie zamknięcia okien dodatkowych.
Mapa gry:
- Teleport na inną mapę. Definiujemy nazwę, pozycję pojawienia się gracza i stronę, w jaką ma być zwrócony. Można też wybrać w jaki sposób nastąpi przejście pomiędzy scenami - np. fade do czarnego, błysk, czy jakikolwiek efekt zdefiniowany wcześniej.
Generyczne funkcje:
Tutaj znajdują się funkcje, które często używane są w samym Unity, czyli np. instancjonowanie, aktywacja obiektów, ustalenie pozycji, odpalenie animacji, wyłączenie kolizji, etc. Game Object, na którym chcemy wykonać operację można wybrać na kilka sposobów: bezpośrednia referencja, skrót do użycia Game Objectu ze zdarzeniem, szukanie po nazwie, szukanie po tagu, użycie wcześniej zapamiętanego GO (podczas instancjonowania).
Audio:
- Odegranie zarządzanego dźwięku. Dźwięk wybieramy z listy dostępnych w SoundManagerze. Można w nim określić maksymalną ilość kopii danego dźwieku, żeby nie urywał się gdy chcemy odegrać drugi, taki sam.
Efekty Specjalne:
- Błyśnięcie ekranu - definiujemy kolor, czas trwania i wybieramy krzywą, po której będzie się zmieniać alfa.
Reszta kategorii widocznych na screenie czeka na wypełnienie/uzupełnienie innymi funkcjami.
Po wybraniu nowej komendy, lub edycji już istniejącej, pokazuje się okno edycji komendy. Jest unikatowe dla każdej komendy, chociaż niektóre elementy się powtarzają (np. wybór GameObjectu). Tutaj screeny z edycji dwóch komend:
Transformacja obiektu.
Odegranie próbki audio.
F.A.Q.
1. Po co to?
Mam nadzieję, że gdy skończę ten system to uda mi się zrobić z jego pomocą grę. Jeśli nie - będę rozważał dystrybucję samego rozszerzenia.
2. Nie lepiej użyć PlayMakera?
Niekoniecznie. Próbowałem, ale dodawanie własnych akcji do PM okazało się dość toporne, a do dodania byłoby sporo. Z kolei tworząc zdrzenie trzeba definiować nowy stan za każdym razem gdy chce się opóźnić akcję o jakiś czas. Wydaje mi się to niepotrzebnie skomplikowane. Poza tym korzyści z pracowania w systemie, który zna się na wylot są nieocenione
3. Czy jest jakaś strata na wydajności w porównaniu z czystm programowaniem?
Z pewnością, ale nie powinna stanowić problemu. Z kolei zysk w wydajności tworzenia gry powinien całkowicie przyćmić tę stratę. Pojedyncze instrukcje są generanie switchami - jeden długi (kilkadziesiąt stanów dla określenia typu komendy), a potem jeszcze kilka po parę stanów każdy. Wykonywanie dużej ich ilości co ramkę mogłoby stanowić problem, ale wtedy można napisać skrypt, który zrobi konieczną rzecz wydajniej. Przy zdarzeniach odbywających się sporadycznie (czyli nie co ramkę) nie powinno być żadnego kłopotu z wydajnością, nawet na platformach mobilnych.
4. Jak wygląda pojedyncza komenda "pod maską"?
Jest to zbiór integerów definiujących zwykle akcję, kolejny zbiór floatów, stringów i objectów będących parametrami danej akcji kilku instancji prostej klasy do wyszukiwania GameObjectów podczas gry. Zlożone komendy, np. operacja na zmiennych mają łącznie kilkanaście elemetów. Prostsze - typu "Czekaj X sekund" mają ich np. 3, więc nie ma niepotrzebnego alokowania tablicy 100 elementów "na wszelki wypadek".
5. Po co ten temat?
Po części dla feedbacku, póki jeszcze mogę wziąć go pod uwagę. Po części by zmotywować się roboty (ostatnio jest całkiem dobrze, ale różnie to bywa). Poza tym może ktoś dzięki temu zainteresuje się pisaniem skryptów edytorowych - drzemie w nich moc!
Wyszło trochę przydługo, ale trudno
Chętnie pogadam na temat.
?
