Masa zmian

Co to był za tydzień, tyle planów do zrealizowania w grze, a ostatecznie zrobiłem coś zupełnie innego. Na pierwszy ogień niech pójdzie sposób zapisu wersji. Na swoje potrzeby (częste poprawki) zdecydowałem się na własny zapis, nie jest unikalny (tzn nie był), ale w miarę czytelny "DDMMYYHHVC". Zapis prosty, ale doszedłem do wniosku, że mógłby powodować on drobne problemy w orientacji między kolenymi wersjami, dlatego nowy zapis - "YYMMDDVVCC". Prostota zachowana i nie będzie już problemów w orientacji.

Dźwięki

Niby tylko zwykłe dźwięki, ale jak znacząco wpływają na rozgrywkę. Dodanie do menu głównego utworu pogrywającego w tle nie daje już takiego efektu pustki (tak wiem, UI tam dalej woła o wypełnienie). Długo kombinowałem jakiego utworu potrzebuję, ostatecznie padło na motyw horroru, co idealnie będzie się komponowało z tym co gracz spotka w trakcie rozgrywki. Arena również dostała utwór, który pogrywając w tle wypełnia "coś" czego po części brakowało. Do tego dodanie dźwięków dla broni i podnoszenia zasobób sprawia, że coś dzieje się więcej niż tylko poruszające obrazki.

Nowe zasoby

Zasoby - monety i doświadczenie bojowe. Pierwsze do ulepszania broni i reszty wyposarzenia, a drugie do ulepszania postaci. Na chwilę obecną nie mają one zastosowania, ale dzięki testom będę mógł już za jakiś czas dodać możliwość ulepszania postaci i sprzętu.

Wydajność, jakość i funkcjonalność

Wydajność jest kluczowa, ale nie można zapominać o tym jak dobrze ma to działać. Musiałem sporo popracować nad scenami, a także nad oknami UI, aby nie tylko wydajność była właściwa, ale także aby to działało. Wpadłem na ciekawy pomysł - Bootstrap - źródło, które znacząco pomoże w inicjalizacji obiektów, a także łącznik między nimi. Separacja odpowiedziałności jest kluczowa, dlatego łącznik będzie miał sporo do roboty, tak jak ja oddzielając warstwe logiczną od wizualnej. Samo rozdzielenie tego sprawiło, że kod stał się nie tylko mniejszy ale także czytelniejszy. Wiadomo teraz kto z kim na co i po co. Kolejną robotą nawego bohatera separacji jest inicjalizacja obiektów, a dokładnie pilnowanie tej kolejności. Do tej pory musiałem bardzo ostrożnie działać z elementami UI, ponieważ bardzo łatwo było o problem z kolejnością łądowania. Dane dla UI były gotowe, tylko, że UI nie było gotowe. To w zasadzie było główną siłą napędową potrzeby refaktoryzacji i separacji. Bootstrap przyjmując wszystkie komponenty kolejno je uruchamia (po upewnieniu się, że są wyłączone). Nie które wymagają specjalnego traktowania - UI, przy UI musiałem mieć 100% pewności, że jest załadowane więc z pomocą przyszły magiczne sztuczki - async i Task. To właśnie dzięki nim było możliwe wymuszenie "cierpliwego" oczekiwania na pełne załadowanie się interfejsu. To oczekiwanie dało mi pewien pomysł - ekran wczytywania. Ogólnie ładowanie się sceny to była nie cała sekunda oczekiwania. Praktycznie nie widoczna różnica, ale dodanie ekranu ładowania pokazało jak bardzo byłem w błędzie. Proczes ładowania zaczyna się od wybrania (zatwierdzenia wyboru) postaci, aż do pełnego załadowania komponentów przez Bootstraper. Kiedy wszystko załaduje, ostanie co robi to likwiduje ekran ładowania ujawniając scenę. Sam proces ostatecznie pokazuje, że scena sama w sobie łaaduje się o wiele dłużej. Ale dzięki temu gracz ma gwarancję, że "wchodzi na gotowe". Przed wprowadzeniem ekranu ładowania, gracz mógł zacząć rozgrywkę momentalnie po zobaczeniu postaci, ale były małe problemy - sporadyczne przycięcia. Dawało to jednoznacznie informację o tym, że coś tam się jeszcze doczytywało. Teraz, po zniknięciu procesu wczytywania i wejściu na scenę, gracz nie doświadczy już przycięć, tylko płynną rozgrywkę - wszystko co miało się załadować zostało załadowane przy wsparciu Bootstrapera, który dbał o to by się dod załadowało.

Postanowiłem też zminić mapę Areny - nie tylko jest mniejsza, ale także w pełni generowana losowo. Co prawda losowa jest tylko podłoga - no to zawsze coś. Arena ma stałe wymiary - 30x30. Nie pamiętam ile miała przed zmianą, bo była ona malowana ręcznie, także nie była nawet kwadratowa. Poprawie uległy także granice, które są dopasowane, a jak prędzej - robione na oko.

To tyle. Zmian sporo, można je zobaczyć w changelogu, a my widzimy się za tydzień.

Paski zdrowia

Mieliśmy UI dla wyboru postaci i dla broni, czas zabrać się za postacie w samej grze. Podczas rozgrywki gracz trafienie rozpoznać może tylko przez to, że zniknął przeciwnik. Nie wiedomo czy się trafiło czy może zasięg broni właśnie się skończył i efekt zniknął. Dlatego aby rozwiązać ten problem postanowiłem zaimplementować "pasek zdrowia". Jednak Unity nie dało mi żadnych złudzeń - nie będzie to takie proste. Pierwotny plan zakładał zastosowanie klasycznego slidera, którego drobna modyfikacja pozwoliłaby na bezproblemowe wyświetlanie stanu zdrowia danej postaci.

Struktura wewnętrzna slidera to jawny koszmar. Zmiana jednego elementu dewastowała wizualnie resztę, ciężko było też ustalić co do czego. Skoro jeden plan runął było trzeba sięgnąć po plan "B" - własny pasek HP.

Własny pasek ma jedną istotną cechę - wiesz co w nim jest i wiesz jak tego użyć. Dlatego jego stworzenie było dziecinnie proste - dwa elementy, jeden jako "kontener", a drugi jako właściwy pasek. Następnym krokiem było już tylko zrobienie przyjemnego dla oka stylu. To też nie było jakimś wyzwaniem, ot czerwony kolor paska, ciemniejsze tło, aby było widać ubytek i gotowe. Ostatnim zadaniem było już tylko jego implementacja w kodzie. No i tu zaczęły się przysłowiowe wiosła. Okazało się, że UI nie chciało zbytnio współpracować z kodem - pasek był widoczny... ale go nie było - nie był on widoczny dla kodu. Osadzenie czegoś oczywistego w nieoczywistym miejscu. Przeciwnicy (bo to na nich był testowany ów pasek) nie są generowani normalnie, a co za tym idzie nie mogłem "nienormalnie" zaimplementować paska. Brzmi to zagmatwanie, ale skracając to można powiedzieć - metoda "Start" nie była stosowana. Tak się też złożyło, że to właśnie ta metoda była kluczem do rozwiązania problemów, osadzony tam kod UI paska pozwolił go nie tylko zobaczyć wizualnie, ale także ze strony kodu. Następnie wprowadziłem kilka poprawek, aby pasek nie był zbyt długi oraz nieco zwiększyłem jego szerokość.
Nie można także zapomnieć o tym, że gracz również otrzymał pasek zdrowia, dzięki czemu gracz będzie widział czy może sobie pozwolić na jakieś błędy, czy pozostaje mu już tylko bezbłędna rozgrywka.

Tym o to akcentem kończę na dziś i do zobaczenia już za tydzień.

Jeszcze lepsze UI

Wygląd "Wyboru postaci" został zdecydowanie poprawiony. Jednak nie tylko na samych postaciach bazuje ta scena. Broń. Broń ma równie wielkie znaczenie co sama postać.
Do tej pory gracz miał możliwość wyboru broni na podstawie ikonki, która pojawiała się po wybraniu danej postaci. To było zdecydowanie za mało. Brak informacji o tym co to za broń (obrazek broni sporo mówił, ale dalej za mało), jakie ma parametry i ulepszenia. Jedynie co można było zrobić to zwyczajnie wybrać broń A lub broń B.
Pierwszy plan zakładał tooltip wyświetlany po najechaniu na ikonę danej broni, ale ze względu na ilość dostępnych (i planowanych) atrybutów - byłoby to nieczytelne. Dlatego planem awaryjnym była rozbudowana dawka informacji o broni, która swoje miejsce miała mieć między ikoną broni, a przyciskiem zatwierdzającym wybory. Jednak poprawa (a co za tym idzie powiększenie) kart postaci sprawiło, że ten plan równiesz poleciał do kosza. Na papierze wyglądało wszystko ładnie, ale końcowe szlify pokazały wady w innych miejscach.
Brak miejsca na to by pokazać broń wymusił stworzenie dedykowanego okna dla wyboru broni. W poprzednim devlogu wspominałem o dodaniu przycisku "wybierz broń". Nie będzie go. Zamiast dawać przycisk postanowiłem pokazać najważniejsze informacje o broni. Gracz może klikną ikonę broni, co pozwoli mu otworzyć okno, w którym będzie miał możliwość zobaczyć wszystkie dostępne bronie dla danej postaci, poznać dokładne parametry danej broni, a także stopień biegłości w danej broni.

Biegłość w broni

Całkowicie nowa funkcja, która miała być dodana później, ale z powodu zmiany wyglądu procesu wyboru postaci uznałem, że warto to wprowadzić prędzej. Pozwoli ona graczowi zwiększyć możliwości bojowe danej broni. Każda broń będzie miała cztery etapy biegłość, a każdy z nich będzie wymagał zabicia określonej ilości przeciwników. Im lepszy tier broni, tym większe będą wymagania. Bigłość będzie na stałe zwiększać konkretne atrybuty broni.

Opracowywana jest także metoda obliczania BR dla broni.

Battle Rank

Broń ma otrzymać swoje BR, ale i postacie (w tym wrogowie) muszą mieć je poprawione. Obecny sposób obliczania BR jest bardzo uogólniony, co może prowadzić do pewnych komplikacji. BR gracza jest obliczane inaczej niż BR przeciwników, mimo, że działa na podobnej zasadzie. Zmiany będą dotyczyć nie tylko potencjałów (jak ma to miejsce obecnie), ale atrybutów. Gracza potencjał był obliczany kompletnie (wszystkie 5), zaś u wrogów tylko 3 (S, C i D), głównie za sprawą, że P i W nie miały dla przeciwników zastosowania. W końcu wrogowi nie potrzeba percepcji, jeśli ten zawsze idzie do gracza, ani nie potrzeba wiedzy, bo nie ma ona w niczym zastosowania. Muszę znaleźć jakiś lepszy sposób przeliczania BR, aby przeciwnicy byli odpowiednio dobierani na arenach, a gracz odpowiednio był nagradzany doświadczeniem.

Na dziś to tyle, widzimy się za tydzień.

Lepsze UI

Przynajmniej chciałbym aby było można je nazwać lepszym. Wybór postaci to też doświadczenie gry, dlatego chciałem zrobić coś co będzie wyglądało miło dla oka. Tak właśnie powtało nowe UI dla wyporu postaci.
Stare UI nie powalało wyglądem, ale było w nim coś co wymagało poprawek i to nie wizulanych - kod. Kod był straszny. Miał on coś w sobie, gdyż całość była generowana, ale ciężko projektować CSS dla czegoś czego nie widać.

Plan był następujący - zamiast bawić się w tworzenie sztucznych obiektów by na nich testować CSS - zrobić prefab UI i go kopiować. No nic lepszego spotkać mnie już nie mogło jeśli chodzi o plan z UI.
Kolejną przeszkodą do stworzenia dobrego UI było to jak i ile pokazać ze stratystyk wyświetlanej postaci. Stara wersja pokazywała tylko atrybuty, a do tego czytelność była... no była średnia.

Skoro sama karta postaci została znacząco powiększona (z 300 na 400 px) to może warto byłoby też dodać więcej informacji o danej postaci. Postać jest określana nie tylko przez atrybuty, ale też przez potencjały. Liczba potencjałów jest stała - 5, a liczba atrybutów stoi jeszcze pod znakiem zapytania. Jednak zdecydowałem się na `sztywne` ulokowanie w kodzie UI zarówno potencjałów jak i atrybutów. Jeżeli kiedyś przyjdzie mi dodać jeszcze jakieś atrybuty to i tak bym musiał poprawić UI pod to, więc ostatecznie decyzja ta wydaje się być jak najbardziej słuszna i rozsądna. Odpada mi w ten sposób część kodu, a to plus - czytelniejsze klasy i metody.

Samo zwiększenie czytelności nie wystarczyło. Pobawiłem się trochę na testowych obiektach i udało mi się uzyskać ciekawy efekt. O nim będzie przy okazji omówienia "nowych szat króla". W skrócie efekt nie jest jeszcze wybitny, ale daje sporo możliwości w przyszłości, gdy przyjdzie robić już bardziej precyzyjną grafikę dla gry.

Wracając do czytelności - udało się uzyskać wszystkie oczekiwane rezultaty. Gracz od tej pory będzie widział zarówno potencjały danej postaci, jak i jej atrybuty. I to wszystko z jeszcze mniejszą liczbą kodu, niż miało to miejsce poprzednio.

Nowe szaty króla

Może i żadna z grywalnych postaci nie jest królem, ale zostały one znacząco odświerzone. Poprzednie były wyciągnięte z odmętów innych projektów, przez co średnio pasowały (były ładne, ale tylko tyle). Teraz postacie przypominają wojowników (temtyka zbliżona do średniowiecza), nie są piękni, bo na śmierć raczej miss lub mister piękności nie pójdzie. Jednak na wyglądzie samych potretów się to nie kończy. Poprzedenie portrety jak i sprite'y postaci były... powiedzmy, że były "takie se", teraz mają zbliżone wyglądy do siebie. Widzisz na portrecie typa w hełmie i z brodą, to sprite też będzie miał typa z brodą i w hełmie. Nie jest to 1:1, ale z odległości nie widać aż takich różnic.

Do tego wszystkiego nakładamy dowolne tło i można szaleć z kontekstem. No przynajmniej tak sobie to wyobrażam, rzeczywistość zweryfikuje. Bawiąc się jeszcze obramowaniem UI może uda się uzyskać jeszcze jakiś ciekawszy efekt.

Pozostaje teraz już tylko kwestia broni. Wyboru broni. Tutaj będzie ciekawiej - bo trudniej. Mało miejsca z powodu większych kart postaci, a same bronie również mają atrybuty. Do tego inne niż te, które ma gracz. Do tej pory gracz dostawał ikonkę broni i to musiało mu wystarczyć, brak wiedzy o jej parametrach mógłby mieć negatywny wpływ na odbiór gry. Dlatego też wpładłem na ciekawszy pomysł - jeśli brakuje mi miejsca - to muszę je sobie zrobić. Na całe szczęscie nie będzie to wymagało przebudowy UI na scenie, czy przeniesienia kard postaci. Po wyborze postaci, ta otrzyma swoją domyślną broń (w planach jest aby była to ostatnio użyta) a pod jej portretem (postaci) pojawi się przycisk "Wybierz broń". Jego zadaniem będzie aktywacja okienka z wyborem broni. W tym okienku gracz będzie miał wszystkie odblokowane dla danej postaci bronie, oraz będzie mógł w końcu zobaczyć czym różnią się bronie.

Do zobaczenia za tydzień!