TheKoder dev diary #6

Pierwsze przekroczenie terminu za mną – ten wpis miał pojawić się wczoraj po południu jednak nie zdążył dojechać na czas. 😉 Nie ma tego złego – wpis dostarczony, a projekt posuwa się do przodu! Zapraszam do relacji z placu boju!

W tym tygodniu napisałem dwie funkcjonalności: logikę odpowiadającą za mierzenie najwyższego punktu osiągniętego przez gracza oraz przyznawanie nagród po osiągnięciu konkretnego progu.
Omówię najpierw pierwszy z nich:

Kod odpowiadający za mierzenie wysokości wyciągnąłem do osobnego modułu, który na razie roboczo nazwałem mesureHeight ale domyślnie będzie on odpowiedzialny za logikę gry. Nie chcę żeby elementy odpowiadające za mechanikę były zawarte w stanach gry. W samym kodzie nic wielkiego się nie dzieje, moduł zawiera 2 funkcje – jedną pomocniczą calculateHeight – odpowiedzialną za obliczanie aktualnej wysokości gracza na planszy oraz getPlayerHighestPoint która zwraca najwyższą osiągniętą przez gracza wysokość.

Logika odpowiadająca za przyznawanie nagród składa się z 2 elementów: pliku prizes.json oraz metody checkForPrize która póki co znajduje się w stanie Play.


Struktura JSONa jest prosta, składa się on z pola limits które zawiera tablicę z progami, które gracz musi osiągnąć aby zdobyć nagrodę oraz polami gdzie kluczem jest wymieniony wcześniej próg a wartością nagroda do zdobycia. Jeżeli macie pomysł na lepszą strukturę zapraszam do zostawienia sugestii w komentarzu lub zrobienia PR 😉
Żeby móc przyznawać nagrody za osiągnięcie odpowiedniego poziomu, do state dodałem 2 pola – gameLimits jest to tablica tworzona na podstawie danych wczytanych z pliku JSON. Użyłem tutaj metody dostępnej na tablicach Array.from – tworzy ona nową kopię tablicy na bazie przekazanej do metody. Wykorzystuję tą funkcję ponieważ jeżeli w JS przypiszemy tablicę do nowej zmiennej to nie jest tworzona kopia tej tablica a przekazywana jest referencja do niej i jeśli wykonujemy operacje na tablicy przy pomocy nowo utworzonej zmiennej tak naprawdę mutujemy również oryginalną tablicę – a tego należy unikać.
Podczas implementacji metody checkForPrize natknąłem się na ciekawy problem – Phaser odświeża stan gry ze stałą częstotliwością, przyjmijmy że jest to 60 klatek na sekundę i może zdarzyć się sytuacja w której omawiana wcześniej funkcja getPlayerHighestPoint nie zwróci równej wartości typu 200, 300, 400 ponieważ mimo że gracz osiągnął ten poziom to odświeżenie stanu gry nastąpiło w momencie kiedy sprite gracza był już trochę wyżej np 201. Dlatego bezpośrednie porównywanie wartości nie jest najlepszym rozwiązaniem, w związku z tym metoda checkForPrize sprawdza czy gracz przeskoczył przewidziany próg, jeżeli tak to z początku listy gameLimits ściągany jest kolejny próg i przypisywany do pola reachedHeight oraz przyznawana jest nagroda.

To tyle jeżeli chodzi o ten tydzień, do zaimplementowania pozostały jeszcze w tym tygodniu system życia gracza oraz zbalansowanie poziomu demo. Jeżeli macie pomysły na optymalizację mojego kodu, zapraszam do zostawiania sugestii w komentarzu.

Leave a Comment

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *