TheKoder dev diary #3

Kilka słów o tym jak działają Phaser.State, podziale projektu na mniejsze części, „dedlajnach” i kompromisach. Zapraszam do lektury!

W tym wpisie chciałbym pokrótce omówić czym są State (pol. stany) w Phaserze. Myślę, że jest to ważny temat ponieważ to punkt wyjściowy jeżeli chodzi o dzielenie gry na mniejsze części, a jak wiadomo takimi później łatwiej zarządzać.
Od strony konceptu stany można rozumieć jako kolejne fazy w których znajduje się gra. W moim przypadku wyróżniłem 10 kluczowych stanów:

  • Boot
  • Preload
  • Story intro screen
  • Main menu
  • Game level
  • Credits
  • High score
  • Player personalization
  • Advert
  • Game over

Nie ma żadnej odgórnej reguły, która mówi w jaki sposób podzielić grę na części. Wszystko zależy od developera. Najważniejsze, żeby przyjęta struktura była logiczna i czytelna. W pracy ze stanami jest jednak jedna nadrzędna zasada: w danej chwili tylko jeden stan może być aktywny. Znaczy to tyle, że do State Managera możemy załadować tyle stanów ile nam się podoba jednak nie mogą one działać równolegle.

Tworzenie stanów w moim przypadku wygląda w sposób następujący: dziedziczę po klasie Phaser.State i implementuje potrzebne metody. Do metod wrócę później, w tej chwili przyjrzyjmy się plikowi main.js. Jest to punkt startowy całej gry. W nim do State Managera dodaje poszczególne stany i startuje pierwszy z nich – Boot. Najwięcej dzieje się w Game State – tam inicjalizowany jest obiekt gracza, system kolizji, sterowanie oraz proste animacje. Wiem, że na obecną chwilę kod nie jest zbyt piękny 😉 ale jak na razie jest good enough. Jak już pisałem w poprzednim wpisie zależ mi na tym żeby przygotować jak najbardziej grywalną wersję na Digital Dragons Students Talent Show. Więc co mi z tego jeżeli będę miał pięknie napisany kod ale nie dotrzymam terminu – deadline wysyłania zgłoszeń jest do 20 marca. Świadomie zaciągam dług technologiczny który później będę musiał spłacić refaktoryzując kod i dopisując testy. Jestem ciekaw Twojej opinii – uważasz, że lepiej ściśle trzymać się standardów za wszelką cenę i nie dotrzymać terminów ale mieć clean code, czy jak ja, że w szczególnych przypadkach trzeba iść na kompromisy. Zapraszam do dyskusji w komentarzach. 😉




Wracając jednak do stanów jest jeszcze kilka rzeczy o których chciałbym wspomnieć. Po pierwsze stan jest uważany za poprawny tylko i wyłącznie w wypadku kiedy posiada chociaż jedną z tych 4 metod: preload, create, update, render. Bez chociaż jednej z nich stan nie zostanie nawet dodany do Menadżera Stanów. W wypadku kiedy nie używamy którejś z tych metod nie mamy obowiązku jej implementować pozostawiając ją pustą. Ponieważ są to najczęściej używane metody w Phaserze opiszę je w kilku zdaniach:

Preload – jak nazwa wskazuje jest to główna metoda do ładowania zasobów do gry. Warto w tym miejscu wspomnieć że Phaser nie wczytuje zasobu od razu w miejscu wywołania loadera – zamiast tego dodaje je do kolejki. Phaser zaczyna od wyczyszczenia kolejki – później natomiast odpala metodę preload. Następnie sprawdza wielkość kolejki, jeżeli jest pusta od razu zostaje wywołana metoda create. Jeżeli w kolejce znajdują się jakieś elementy rozpoczyna się proces ich wczytywania. Po jego zakończeniu uruchamiana jest metoda create.
Create – uruchamiana zaraz po preload. Jak nazwa wskazuje jest odpowiedzialna za tworzenie obiektów w grze. Zaraz po tym jak zakończy swoje działanie zostaje uruchomiona główna pętla gry.
Update – metoda ta jest uruchamiana automatycznie za każdym razem kiedy zostanie ona wywołana przez główną pętlę gry. Należy wziąć pod uwagę, że wywoływanie tej metody odbywa się z dużą częstotliwością i trzeba uważać co wykonuje się w tym miejscu. Typowym przykładem akcji do umieszczenia w update jest sprawdzacie kolizji.
Render – wywoływana kiedy Phaser zakończy renderowanie wszystkich elementów. W tej fazie obraz został całkowicie wyczyszczony i zaktualizowany do nowego stanu.

Na koniec zapraszam pod ten adres. Co 3 tygodnie będę wrzucał zaktualizowane demo gry po całym sprincie. Plany są aby kiedyś w tym miejscu powstała aplikacja pozwalająca na podejrzenie jak wyglądała gra w poszczególnych cyklach produkcji, jednak na wszystko przyjdzie jeszcze czas. 😉

Leave a Comment

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