Unity3d QuickTip – czyli szybkie porady, rozwiązania częstych problemów i sztuczki w Unity3d!

Dzisiejszy odcinek: Dziennik zadań

Uwaga! Jest to poradnik typu QuickTip. Zatem skupia się on na osiągnięciu założonego celu. Zatem zakładamy że użytkownik zna na tyle program Unity3d, aby samodzielnie wykonać najprostsze czynności, jak np. dodanie modelu kostki do sceny czy dodanie modelowi jakiegoś komponentu. Jeżeli brakuje Ci tej podstawowej wiedzy, zapraszam do tutoriala:
Unity Tutorial – Podstawy

Teoria

Dziennika zadań nie trzeba przedstawiać żadnemu fanowi gier RPG. Jest to miejsce, gdzie spisujemy wszystkie zadania gracza oraz ich postępy.

Zaproponowana przeze mnie metoda tworzenia zadań, niekoniecznie będzie najlepsza. Raczej nie sprawdzi się też przy zadaniach z masą rozgałęzień i z wieloma zakończeniami. Jednak daje dobry punkt zaczepiania, do tego, żeby taki system rozwinąć. Z racji, że kodu jest sporo, przejdziemy od razu do rzeczy.

Przygotowanie

Z racji, że elementów jest sporo, dodam screen i szybko omówię, co jest czym:

Przygotowana plansza testowa
Przygotowana plansza testowa

Oświetlenia i podłogi nie ma za bardzo co omawiać. FPSController, wzięty ze standardowych assetów Unity (Paczka Character). Podłoga i kolory wzięte ze standardowych assetów, paczka: Prototyping.

Obiekty: Quest_1_1, Quest_1_2, Quest_1_3, to te różowe kulki, symulujące zadanie w którym mamy dostarczyć kilka zebranych przedmiotów.

Enemy, to pomarańczowy walec. Key to mały zielony (seledynowy?) sześcian. Te dwa obiekty, służą do symulacji zadania, w którym ktoś każe nam zabić kogoś, a potem przynieść jeszcze jakiś przedmiot.

NPC_Quest_1 i NPC_Quest_2, symulują dających zadanie NPC. Jedynka to różowy, dwójka to żółty.

Każdy z obiektów ma Collider typu Trigger!

Przygotowujemy dziennik

Zanim przystąpimy do tworzenia faktycznego dziennika, stworzymy sobie klasę zadania. Tej klasy nie będziemy nigdzie przypisywać, ale to ona odpowiada za stan danego zadania i pozwala nim operować.

Klasa nazywa się: Quest, więc mamy ją w pliku Quest.cs

Zaczynamy od zmiennych:

Pierwsza rzecz to enum statusu zadania. Pomaga nam w ogarnięciu statusu, żeby używać ACTIVE, FAILD etc. zamiast nic nie mówiących numerków.

Reszta to dane, które mogą się przydać: unikalne id zadania, jego tytuł i opis, status, obecny stan, finalny stan, liczba zebranych przedmiotów (wykorzystana przy zadaniach, ze zbieraniem przedmiotów) i nagrody – ja ich później nie wykorzystałem, ale jak najbardziej można to zrobić. Można też dodać inne elementy.

Teraz tworzymy konstruktor:

Aby zadanie mogło istnieć musi mieć id, tytuł i opis.

Tutaj wypadałoby sprawdzić, czy zadanie o podanym ID już nie istnieje, ale nie chciałem dodatkowo komplikować kodu.

Teraz kilka prostych funkcji, które zamieszczę razem i razem omówię:

Nie ma tutaj cudów. Funkcję, które pozwalają szybko zmienić status zadania i dodać przedmiot do zebranych.

Na koniec najważniejsza chyba funkcja:

Przejście do kolejnego etapu. Etap można zmienic tylko, gdy zadanie jest nieaktywne, albo aktywne. Gdy gracz zakończył zadanie sukcesem, albo porażką, nie ma sensu zmieniać jego stanów.

Później zwiększamy numer etapu i sprawdzamy czy etap jest równy 1 (wtedy gracz musiał aktywować zadanie, więc ustawiamy taki stan), albo czy etap obecny to numer etapu końcowego. Jeśli tak, to ustalamy status zadania na zakończone sukcesem.

Jak widać, ta klasa przechowuje informację o konkretnym zdaniu i będziemy się do niej odwoływać. Czas na dziennik!

Klasę dziennika nazwałem: QuestDiary.cs

Najpierw zmienne i podstawowe funkcję:

Pierwsza zmienna to lista zadań – oparta o klasę, którą wcześniej stworzyliśmy, więc jeśli Twoja klasa zadania nazywa się inaczej, musisz to teraz uwzględnić.  Aby móc korzystać z listy, należy do skryptu dopisać: using System.Collections.Generic; Druga zmienna to zwykła flaga mówiąca czy dziennik jest otwarty.

W funkcji Start wywołujemy sobie funkcję, ładującą zadania, a w funkcji Update, zmieniamy wartość flagi po kliknięciu klawisza J.

Przykładowa funkcja loadQuests może wyglądać tak:

Czemu przykładowa? Bo tutaj dla ułatwienia, ładujemy sobie dwa zadania na sztywno. W normalnych warunkach, lista zadań powinna znajdować się w pliku XML czy CSV, którą projektant zadań, mógłby sobie łatwo edytować. I w tym miejscu, powinniśmy taki plik załadować i przerobić na listę klas. Ja tego nie robiłem, aby po pierwsze nie rozbudowywać zbytnio całości, a po drugie zostawić rozwiązanie otwartym. Bo równie dobrze zadania można ładować z pliku tekstowego czy bazy danych. Samo ładowanie danych w ten czy inny sposób to temat bardzo otwarty i jeśli będzie taka potrzeba, opiszę jak to zrobić w oddzielnym poradniku, bo ta wiedza przyda się w większej liczbie miejsc niż dziennik zadań.

Przechodzimy do wyświetlania dziennika:

Budowa niezwykle prosta i oczywista. Wyświetlamy wszystkie zadania jeden po drugim, opisując je sobie. Prawdopodobnie nie wykorzystasz tego kodu w faktycznej grze. Całość jest brzydka i wyświetla dane, których gracz nie powinien widzieć. Jednak nam ten kod bardziej służy do debugowania i pokazania jak dane zadań wyświetlić. Tworzenie pięknego dziennika mija się z celem, bo dla każdej gry, będzie wyglądał inaczej. Mi chodziło o pokazanie funkcjonalności, a nie strony artystycznej. Jeśli będzie zainteresowanie, w kolejnym poradniku, mogę opisać jak zrobić dziennik bardziej funkcjonalnym, czyli pozwolić graczowi na wybieranie aktywnego zadania, wyświetlanie opisu zadania po kliknięciu w nie, etc.

Zostało nam dodanie kilku funkcji do operowania zadaniami:

Funkcja podobna do tej z klasy Quest. Posuwamy zadanie do przodu, o kolejną fazę. Tylko tutaj, konkretne zadanie o konkretnym ID. Teraz widać, czemu id musi być unikatowe i czemu jest ważne.

ID może się wydawać nieporęczne, ale w momencie kiedy masz zadania spisane w tabeli (plik CSV) to numeracja będzie naturalna i nie utrudni sprawy.

Kolejna funkcja określa zadanie jako porażkę. Nasza funkcja zmieniająca fazę zadania, potrafi zmienić status na aktywne i zakończone sukcesem, ale porażka może wyniknąć z tak wielu czynników, że sami będziemy ją wymuszać.

Te funkcję daję razem bo są ze sobą powiązane. Pierwsza zwraca liczbę zebranych przedmiotów w danym zdaniu, a druga dodaje zebrany przedmiot.

Ostatnia funkcja sprawdza czy zadanie jest nieaktywne. Przyda nam się to później.

Tyle, jeśli chodzi o główny dziennik. Skrypt QuestDiary powinien być przypisany do FPSControllera.

Obiekt zadania

Gracz ma swój dziennik, ale teraz fajnie jak by inne obiekty mogły wchodzić z nim w interakcję. Stworzymy coś, co nazwałem QuestObject.cs. Czyli skrypt, mający za zadanie operować danym zdaniem. Znów zaczniemy od zmiennych:

Znów mamy enum, który określa nam rodzaje zadań, jakie można obsłużyć. Zbieranie przedmiotów, danie przedmiotu graczowi, odebranie przedmiotu od gracza i zabicie kogoś.

Zmienne to ID zadania, do którego się odnosimy. Obiekt dziennika, obiekt statystyk i inwentarza gracza (to zaraz dodamy).

Następny jest typ etapu, będący tablicą. Czemu? W naszym przykładzie jeden NPC będzie chciał uśmiercić przeciwnika i zdobyć klucz – co daje dwa etapy. Nie moglibyśmy przypisać dwa razy tego samego skryptu, dlatego pomaga nam tu tablica.

Następnie mamy obiekty zależne od rodzaju questu: Dla zbierania, liczba przedmiotów, które trzeba zebrać, dla otrzymania i odebrania: przedmiot, którego oczekujemy. Dla zabicia, lista obiektów do zabicia. Na koniec nagrody za dany etap – jeśli chcemy za różne etapy, dawać różne nagrody, można tutaj również umieścić tablicę.

Na samym początku szukamy sobie dziennika, statystyk gracza i inwentarza.

Warto tutaj zauważyć, że gracza szukamy po tagu. Więc, jeśli jeszcze Twój FPSController nie ma tagu „Player”, dodaj go teraz do swojej postaci.

Ta funkcja, sprawdza czy wszystkie obiekty, które miał zabić gracz, zostały zabite. Zakładam tutaj, że po zabiciu przeciwnika wywołujemy funkcję Destroy. Wtedy odwołanie do obiektu da null. Sprawdzamy wszystkie obiekty w tablicy i jeśli, któryś z obiektów nie jest nullem to znaczy, że żyje. Przy samych nullach wszystkie obiekty zostały uśmiercone.

Teraz najważniejsza funkcja:

 

Zanim cokolwiek zrobimy, sprawdzamy czy obecna faza, jest mniejsza niż maksymalna – nie chcemy wyjść po za zakres tablicy. Chodzi tutaj o stany dla danego obiektu, czyli tą naszą tablicę, a nie stany całego zadania.

Innymi słowy, jeśli całe zadanie ma 10 etapów, ale jakiś NPC realizuje etapów 4, to będzie miał ten skrypt, stageType będzie miała 4 elementy. Nie chcemy przekroczyć indeksu tej tablicy.

Teraz sprawdzamy czy zadanie jest nieaktywne, jeśli tak, to przechodzimy do kolejnego etapu i kontynuujemy działanie funkcji przechodząc do Switcha.

Tutaj należy rzucić parę słów wyjaśnienia. Czasami zdarza się tak, że wykonamy jakieś zadanie, zanim ktoś je nam zleci. Np. zabijemy 5 groźnych wilków w drodze do miasta, gdzie ktoś nam zleca to zadanie. Bez tej linijki, gdy dojdziemy do kupca to po rozmowie z nim zadanie by się aktywowało, zamiast od razu zakończyć sukcesem.

Case’y w switchu są dość podobne, dlatego omówię jeden z nich, a reszta to analogia:

Najpierw jest warunek przejścia danego etapu. Jeśli chodzi o zbieranie, to tutaj musimy mieć tyle elementów ile wymaga zadanie. W przypadku odebrania przedmiotu, gracz musi mieć je w ekwipunku, w przypadku zabicia, lista musi być pusta.

To co robimy później to dodajemy graczowi nagrody, potem wywołujemy funkcję questNextStage w dzienniku. Teraz jeśli zadanie zakończyło się sukcesem to będzie to już zaznaczone. Zwiększamy też obecną fazę zadania dla tego obiektu i… rekurencyjnie wywołujemy jeszcze raz tą funkcję.

Po co? W przypadku gdy dla tego obiektu będziemy mieli x etapów, np. przyniesienie klucza i zabicie wroga i wykonalibyśmy te zadania na raz to bez rekurencji uznano by nam tylko jeden etap. Efekt w grze? Mamy 3 etapy u jednego NPC i wykonaliśmy wszystkie na raz. Musimy teraz z NPC rozmawiać 3 razy, żeby powiedzieć o realizacji całego zadania.

Skrypty testowe

Mamy już wszystko odnośnie dziennika. Czas na kilka skryptów, które pomogą nam w testowaniu dziennika.

PlayerStats – Przypisany do: FPSController

Nie ma nic do wyjaśniania

Inventory – Przypisany do: FPSController

W tej wersji jako przedmiot mamy tylko klucz. Ale w normalnych warunkach funkcje powinny realizować swoje zadania i odpowiednio dodawać/usuwać przedmiot, oraz sprawdzać czy ten faktycznie jest w ekwipunku – co jest kluczowe dla zadań typu dostarczenie czy odebranie przedmiotu.

Enemy – Przypisany do: Enemy

Przeciwnik ginie, gdy się do niego zbliżmy.

Key – Przypisany do: Key

Dodajemy klucz do ekwipunku.

TalkScript – Przypisany do: Obu NPC

Ten skrypt, pozwala symulować rozmowę z NPC. Wtedy odwołujemy się do skryptu QuestObject i kontynuujemy zadanie.

QuestCollect – Przypisany do: Kulek, które ma zbierać gracz

Kiedy gracz wejdzie w Trigger, dopisujemy zadaniu obiekt.

W przypadku większej różnorodności, można w zadaniu opisać obiekt, jaki ma być zbierany i tutaj sprawdzać, czy obiekt pasuje do oczekiwanego przez zadanie.

Konfiguracja QuestObject

Skrypt QuestObject przypisujemy do obu NPC. Ich konfiguracja wygląda następująco:

Dla NPC od zbierania:

NPC od zadania ze zbieraniem
NPC od zadania ze zbieraniem

Dla NPC od dwuetapowego zadania:

NPC od dwuetapowego zadania
NPC od dwuetapowego zadania

Zmienne Diary, Stats i Inventory zostawiamy puste, bo skrypt sam je sobie znajdzie. Etapy ustawiamy tak jak powinny być realizowane i wypełniamy dane potrzebne do realizacji danych etapów. Na koniec nagrody.

Podsumowanie

Kod jest już rozwlekły, a nie realizuje wszystkiego. Co jest nie do końca OK?

  • Jeden NPC nie może odpowiadać za kilka różnych zdań.
  • Zadania są liniowe i nie mogą mieć rozgałęzień
  • Nie omówiliśmy wyglądu dziennika
  • Nie pobieramy danych z zewnętrznego źródła jak plik XML, CSV czy baza danych
  • Etapy u jednego NPC nie mogą się pokrywać – tzn. jeden NPC nie zleci 3 zadań zbierania, ale to da się rozwiązać, zmieniając pojedyncze zmienne na tablicę.
  • Każdy etap ma tą samą nagrodę – to się da zmienić, zmieniając zmienne nagród na tablicę

Kod nie jest perfekcyjny i sam nie do końca jestem z niego zadowolony, ale to było w sumie pierwsze podejście i pomysł na jaki wpadłem. Może za jakiś czas spróbuję stworzyć coś bardziej uniwersalnego.

Do prostej gry RPG, to powinno starczyć, albo dać wam przynajmniej inspirację, do stworzenia czegoś lepszego.

 

  • Pawel Spychalski

    Jak zawsze super poradnik.

    mam pytanie:
    czy nagrał byś może poradnik jak wywołać animacje w ten sposób że trzymając jakiś klawisz odpala sie animacja a po puszczeniu go odpala sie druga. np: podczas trzymania klawisza „fire2” broń jest przysuwana do kamery a puszczajac go zalacza sie animacja odsuwania broni.

    • Rozumiem, że chodzi Ci o coś w rodzaju „przycelowania” w grach FPS? Podobny motyw zrobiłem w kursie przy robieniu gry FPS. Rzuć okiem na to, jeśli nie rozwiązuje to Twojego problemu, możesz go nieco dokładniej opisać w „Zaproponuj tutorial” to przyjrzę się mu przy jakiejś okazji. :)

  • Krzysiek Konis Konarski

    Mam pytanie można ładować zadania z pliku txt tak?
    Bo z xml mam problem a csv nigdy nie używałem.

    • Radzę zapoznać się z formatami XML i CSV. Na plikach tekstowych za daleko nie zajedziesz. :) Ale owszem, z pliku tekstowego też da się importować.