GCM – Czerwiec: Robot. Modularyzacja kodu.

W ostatniej grze, którą zbudowałem przy użyciu phasera, próbowałem podzielić kod na moduły. Mógłbym je dzięki temu z łatwością łączyć i uniknąć powtarzalności kodu. Niestety poległem okrutnie. Do teraz śni mi się po nocach ten straszny, przerośnięty i nieczytelny główny stan gry.

Obiecałem sobie, że to się więcej nie powtórzy. Dlatego kolejnym krokiem podczas tworzenia mojej nowej platformówki, było wprowadzenie modularyzacji kodu. I tym razem mi się udało 🙂 .

Phaser programowanie gier

Opisywaną w tym poście wersję gry sprawdzić można klikając w obrazek powyżej. Aktualizowany na bieżąco kod dostępny jest na moim koncie github. W razie czego, zawsze możesz zajrzeć w źródło strony 🙂 .

Nowości w kodzie nie ma zbyt wiele. Główne zmiany polegają na rozdzieleniu go na osobne pliki. Zacznę może od tego jak są one podpięte do HTMLa. Nie korzystam tutaj z żadnego automatycznego czary mary, po prostu w nagłówku dokumentu dodaję (ręcznie) kolejne znaczniki script. Nie jest to może idealne podejście, tym bardziej, że tych znaczników będzie sporo, ale w tym projekcie musi wystarczyć. Na pewno jest to coś co zaadresuję w kolejnych grach. Oto jakie pliki podłączem w index.html (reszta pliku wygląda tak jak ostatnio):

Oczywiście kolejność ustawienia plików ma znaczenie. Nie będę już tego zaznaczał dalej, ale patrząc od góry, żaden plik nie może występować wcześniej niż plik, który zawiera dane mu potrzebne.

Pierwszy plik, to oczywiście kod źródłowy frameworka. Jest on oczywiście potrzebny reszcie kodu 🙂 . Kolejna pozycja to init.js:

Na początek tworzę zmienną Robot, to będzie mój główny namespace. Następnie przypisuję do niego pierwszy stan czyli init. Tutaj nie dzieje się nic nadzwyczajnego, najpierw w metodzie preload ładuję wymagane assety a następnie, wewnątrz create ustawiam zmienne konfiguracyjne, które przypisuję do głównego obiektu game. Najważniejsze to levels, tablica zawierająca spis kluczy do stanów poziomów oraz zmienna currLevel, która zawiera liczbę równą indeksowi aktualnego poziomu w tablicy levels. Wrzuciłem tu parę linijek kodu, które wcześniej znajdowały się w stanie gry a nie musiały 🙂 teraz każdy poziom będzie miał swój stan, bez sensu byłoby w każdym z nich włączać fizykę czy ustawiać referencje do przycisków, skoro mogę zrobić to teraz.

Kolejny plik dodany w index.html to config.js:

Nie jestem pewny, czy dobrze nazwałem ten moduł, ale to najwyżej się zmieni. Przypisuję go oczywiście do głównego namespace’a gry. Wewnątrz znajdują się funkcje pomocnicze, pierwsze dwie, na podstawie przekazanych w argumentach danych, włączają mapę oraz jej warstwę kolizyjną.

Trzecia funkcja, sprawdza kolizje pomiędzy robotem a wyjściem z poziomu. Referencje do tych dwóch obiektów, przekazywane są jako parametry. Jeżeli się zetkną zmieniana jest wartość game.currLevel i włączany jest stan z listy game.levels o indeksie równym nowemu currLevel.

Kolejne pliki dodane do index.html to obiekty gry: plasma, robot oraz exit. Pierwszy obsługuję strzały robota, drugi samego robota a trzeci wyjścia z poziomu. Wszystkie działają na podobnej zasadzie, jako przykład zaprezentuję plik robot.js:

Wewnątrz pliku, do głównego namespacea przypisuję funkcję-fabrykę createRobot. Przyjmuje ona cztery argumenty. Pierwszy to obiekt gry phasera, jest mi potrzebny aby wywoływać metody frameworka. Kolejne dwa argumenty to po prostu początkowe współrzędne postaci gracza. Ostatni argument to referencja do obiektu plazmy. Przyda się aby robot mógł strzelać 🙂

Wewnątrz funkcji tworzę obiekt robota dokładnie tak samo jak robiłem to do tej pory, nic się tutaj nie zmienia. Gdy wszystko jest już gotowe, zwracam przyszykowany obiekt. Dzięki tej konstrukcji mogę szybko i bez duplikowania sporej ilości kodu, stworzyć nowy obiekt robota w każdym nowym stanie.

Kolejne dwa pliki dodane do index.html to level.js oraz level2.js. Są to oczywiście stany poziomów gry. W tej chwili są one do siebie bardzo podobne, więc pokażę tylko ten pierwszy.

Prawda, że jest bardzo zwięzły i zgrabny? 🙂 w metodzie create tworzę nową mapę i obiekty gry używając zdefiniowanych wcześniej funkcji pomocniczych i fabryk. Wewnątrz update również używam aktualizujących metod poszczególnych obiektów. Wystarczy porównać to z poprzednią wersją stanu, od razu widać różnicę.

I to wszystko, kiedy cały kod jest już przygotowany, mogę całość zainicjalizować wewnątrz pliku game.js:

Tutaj nie zmieniło się nic, nie licząc tego, że stany wywołuję z wnętrza mojego namespace.

Teraz kiedy gra jest dużo lepiej zmodularyzowana, dodawanie nowych obiektów do gry będzie znacznie prostsze. Moim kolejnym krokiem będzie dodanie właśnie takich elementów 🙂

Na koniec, jak zawsze, zachęcam do polubienia mojej strony na facebooku. Zawsze na bieżąco zamieszczam tam informacje o nowościach, więc warto polubić aby nie przegapić żadnego nowego wpisu.

Dodaj komentarz

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