JS Platformer – wstępna architektura projektu

Mam już ogólny zamysł tego jak będzie wyglądać moja gra platformowa. Stworzyłem podstawowy prototyp, z którego jestem zadowolony i na bazie tego właśnie prototypu, będę dalej rozwijał swój projekt.

Trochę posprzątałem w tym prototypie i myślę, że w obecnym stanie gra jest gotowa aby zacząć pracować nad nią dalej. w dzisiejszym poście, przedstawię podstawową architekturę, mojego projektu oraz objaśnie działanie jego konkretnych elementów.

Zaraz, zaraz… Czy ten gość własnie napisał „wezmę ten prototyp, trochę w nim posprzątam i to od teraz będzie właściwy produkt” ? Spokojnie, matki mogą przestać zasłaniać dzieciom oczy a wrażliwi czytelnicy mogą spokojnie kontynuować lekturę. Tak naprawdę, te prototypy, które stworzyłem były bardzo malutkie. mogłem więc w miarę rozsądnie rozplanować ich kod i pisać je tak żeby mogły być dalej rozwijane bez problemów.

Szczerze mówiąc, pisałem je najlepiej jak potrafię 😉 . Nic lepszego, póki co, sam nie jestem w stanie wymyślić. Liczę, że na koniec projektu to się zmieni.

Początkowo chciałem opisać dokładnie cały kod projektu, tak jak robię to z innymi swoimi pracami. W końcu, zazwyczaj moim celem jest napisanie takiego posta, po przeczytaniu którego, czytelnik będzie mógł sam ze zrozumieniem odtworzyć mój projekt. W tym wypadku zrobię wyjątek i będę dawał tylko ogólne opisy. Do pełnego kodu, każdy ma łatwy dostęp. Jest on zamieszczony jest na githubie (link w menu bloga).

Jeżeli jakiś fragment programu będzie dla kogoś niezrozumiały, lub ktoś będzie miał jakiekolwiek pytania, niech nie zawaha się do mnie napisać, czy to w komentarzu, czy na FB, czy nawet w mailu.

Zanim jednak zacznę mówić o zmianach i nowościach w projekcie, muszę opisać jak wygląda jego początkowa architektura. O tym właśnie będzie dzisiejszy post. Czas więc zakończyć ten przydługawy wstęp i przejść do konkretów.

Projekt składa się z modułów node’a. Dla czytelności i łatwego dostępu, podzieliłem je na grupy, które umieściłem w odpowiednich folderach. Obecnie pliki projektowe wyglądają tak:

pomijam pliki gita i pliki konfiguracyjna.

Zacznę od plików nie znajdujących się w folderach. index.html oraz bundle.js, nie wymagają opisywania. Pierwszy to po prostu plik html do odpalenia w przeglądarce a drugi to pakiet tworzony przez browserify.

main.js to punkt wejściowy dla innych modułów. Jedyny moduł w nim używany to game.js.

Wewnątrz game.js korzystam z modułów pobierających dane wejściowe od gracza (mouse.js i keys.js), modułu obsługującego płótno (canvas.js) oraz moduły stanów. W tym module aktywuję klawiaturę i myszkę oraz odpalam główną pętle gry. To własnie ta pętla będzie obsługiwała stany.

Przejdę teraz do folderów. GFX oczywiście przechowywać będzie grafiki gry. W tej chwili znajduje się tam tylko strzałka wskazująca, w którym kierunku zwrócony jest gracz 🙂 .

Folder Config zawiera wszystkie moduły pomocnicze. Pierwszy z tych modułów to assets. assets przechowuje dane o plikach grafik i dźwięków gry. Moduł ten posiada też logikę obsługującą te assety, czyli metody pobierające oraz zwracające dane.

Moduł canvas.j pobiera element płótna z DOMu oraz zwraca te jego właściwości, które są mi potrzebne (kontekst dwuwymiarowy, oraz wymiary płótna 🙂 ).

Moduł config docelowo zawierać ma wszystkie ustawienia gry. Póki co jest tam tylko liczba klatek, na sekundę oraz współczynnik grawitacji. Są też metody, które zwracają te wartości.

Kolejny moduł to helpers.js. Tutaj znajdują się wszelkie metody ‚pomocnicze’. Obecnie są to dwie metody na wykrywanie kolizji, oraz metoda na obliczanie kąta pomiędzy dwoma punktami.

Dwa ostatnie moduły w katalogu Config odpowiadają za obsługę inputu gracza. Są to mouse.js oraz keys.js. Oba przechowują dane o tym, jaki informacje są aktualnie przekazywana przez gracza, oraz metody, które pozwalają te dane odzyskać.

Następny folder grupujący moduły to States, jak łatwo się domyślić przechowuje on stany gry. Każdy moduł to osobny stan. Obecnie są ich trzy: loadingState, menuState oraz gameState.

Pomimo tego, że stany wyglądają trochę inaczej niż w moich wcześniejszych grach, działają praktycznie tak samo. Najważniejsze ich metody to updateState oraz draw, wywoływane w module game.

Najciekawszy moduł stanu to zdecydowanie gameState, czyli ten który renderuje faktyczną grę. W przyszłości takich modułów będzie więcej i każdy z nich będzie osobnym poziomem. To własnie w nich ustawiam lokacje obiektów odpowiednią dla aktualnego poziomu. W tej chwili są to platformy oraz postać gracza. Każdy z tych obiektów ma własne metody aktualizujące oraz rysujące go, wywoływane w odpowiednich metodach stanu.

Ostatni folder to Actors. Tutaj znajdują się moduły reprezentujące obiekty/sprite’y gry. Moduł entity przechowuje wzorzec obiektów, oraz metody pozwalające tworzyć nowe instancje tego wzorca.

Moduł particles, odpowiada za obsługę systemu cząsteczek. Nie wiem na ile będzie wykorzystywany w przyszłości, ale istnieje szansa, że zostanie bardziej rozwinięty.

Kolejny moduł to platform. Tutaj znajduje się kod odpowiedzialny za tworzenie nowych platform. Póki co jest on dość mały. Tak naprawdę platforma nie różni się zbytnio od wzorca, w module jedynie znajduje się metoda zwracająca nowy jego egzemplarz. W przyszłości będzie tu więcej rodzajów platform, np poruszające się, lub znikające 🙂 .

Ostatni moduł to Player. Zawiera on kod, który kontroluje logikę obiektu postaci gracza. W obecnym stanie projektu, jest to zdecydowanie najbardziej rozbudowany moduł. Znajdują się tu wszystkie mechanizmy kontrolujące ruch oraz ataki gracza. Pobiera on wszystkie te moduły które normalnie będą potrzebne każdemu obiektowy gry. Przede wszystkim jest to moduł entity, na bazie którego tworzę obiekt gracza. Są też oczywiście mouse oraz keys, które przekazują modułowi input użytkownika, na co obiekt gracza może odpowiednio zareagować. Pobierany jest też moduł assets, który dostarczy odpowiednią grafikę. Dwa ostatnie potrzebne moduły to canvas (aby wyrysować obiekt) oraz helpers (aby sprawdzać kolizje).

Jak widać podstawowa architektura projektu, nie jest specjalnie złożona. Możliwość poukładania logiki modułami, bardzo mi pomogła. Uważam, że znacznie ułatwia to pracę. Teraz kiedy już objaśniłem jak mniej więcej co jak działa, będę mógł dokładniej przedstawiać przyszłe aktualizacje.

Na koniec, jak zwykle, zachęcam do polubienia mojej strony na facebooku. Zamieszczam tam informacje o wszystkich nowościach. Polubienie strony gwarantuje bycie na bieżąco zamieszczanymi na blogu 🙂 .