(WIP) JSetpac – gra co miesiąc: luty – pierwsza odsłona

Czas na kolejny wpis z serii gra co miesiąc. Tym razem tworzę JavaScriptowy remake starej gry Jetpac. Kiedys trochę grałem w tę grę na wysłużonym komputerze ZX Spectrum i bardzo mi się podobała. Szczerze mówiąc od dawna chciałem ją odtworzyć. W końcu mam dość umiejętności aby tego dokonać 🙂

W grze mam do czynienia z podstawowymi prawami fizyki. Na postać gracza działa grawitacja i jeżeli żadna siła nie będzie unosić go w górę, zacznie opadać. Na szczęście, wyposażony jest w tytułowy jetpack, czyli plecak odrzutowy 🙂 Dzięki temu może się wznieść i wylądować na platformach znajdujących się w powietrzu (nie, na platformy grawitacja nie działa, cicho!).

Aby sprawdzić jak działa aktualna wersja gry, wystarczy kliknąć w obrazek powyżej. Jak zawsze, Przygotowałem też paczkę z kodem oraz grafikami gry.

Poprzednią grę wrzuciłem na parę for o programowaniu. Chciałem uzyskać opinie bardziej doświadczonych developerów na temat mojej pracy. Jedną z rzeczy, na którą zwracano mi uwagę to to, że wartości gry dostępne są w globalnej przestrzeni nazw. Tym razem chciałem tego uniknąć więc zastosowałem bardzo prosty wzorzec modułu.

Cały kod gry znajduje się w samowywołującej się funkcji, która zwraca jedynie metodę uruchamiającą grę. Jest ona przypisywana do globalnej zmiennej game. Taki zabieg pozwala metodzie uruchamiającej na dostęp do danych, które nie są dostępne w przestrzeni globalnej. Jeżeli nie jesteś pewny o czym piszę, poszukaj w internecie informacji na temat wzorca modułu w JS, enakspulacji oraz domknięć. Ten post to nie czas i miejsce na tłumaczenie szczegółów 🙂

Kolejną ciekawą uwagą jaką otrzymałem odnośnie poprzedniej gry, było to, że używam requestAnimationFrame do zadań niezwiązanych z rysowaniem na płótnie. Zamiast tego zasugerowano abym skorzystał z dwóch pętli. setInterval do kontrolowania aktualizacji danych i rAF do rysowania klatek. Spróbowałem wdrożyć to rozwiązanie. Nie wiem czy do końca mi się udało 🙂 rAF wciąż jest główną pętla, jednak za aktualizacje danych w konkretnych stanach odpowiadają funkcje setInterval. Są one inicjalizowane wraz ze stanami gry i zatrzymywane, gdy stan się zmienia.

JSetpac: pierwsza odsłona – kod

Ok, czas na kod. Postaram nie rozwodzić się nad oczywistymi fragmentami. Skupię się nad tymi rozwiązaniami, które są nowe. Na początku znajdują się pola i metody głównego modułu:

Oczywiście najpierw pojawia się zmienna self, dzięki której będę mógł odnosić się do tego obiektu z wnętrza innych obiektów.

Następnie tworzę pole keys. Zawiera ono tekstowe nazwy dla wartości przycisków. Dzięki temu kod będzie bardziej czytelny. Kolejne pole config zawiera wszystkie zmienne związane z ustawieniami gry. W głównym stanie gry znajduje się również obiekt spriteObject, którego używać będę jako wzorca do tworzenia nowych obiektów wewnątrz stanów gry.

Dalsze cześć to trzy metody głównego obiektu. Pierwsza to activateKeys. Działa ona identycznie jak w przypadku poprzedniej gry. Kod wciśnietego klawisza zapisywany jest jako pole o wartości true w odpowiednim obiekcie. Po puszczeniu przycisku, pole kodu usuwane jest z obiektu pressedKeys.

Kolejna metoda, mainLoop, również działa podobnie do jej odpowiednika w poprzedniej grze. Wewnątrz metody, tworzona jest pętla, na bazie requestAnimationFrame. W pętli sprawdzane jest czy obecny stan jest zainicjalizowany i czy posiada metodę draw. W zależności od wyników tego sprawdzania, metoda wykonuje odpowiednie akcje. Tak jak zaznaczyłem wcześniej, nic więcej nie dzieje się wewnątrz pętli rAF, tylko zmiana stanu i rysowanie.

Ostatnia metoda to start. Odpala ona po prostu dwie poprzednie.

Pozostała część kodu to stany gry. Pierwszy stan to loadingState:

Ttutaj kod również bardzo przypomina ten sam stan z poprzedniej gry. Rożnicą jest to, że teraz w metodzie init aktywuję pętle setInterval, która z kolei wywołuje metodę update stanu co sekundę dzieloną na zdefiniowaną liczbę klatek na sekundę (coś podobnego robiłem już w jednym z wcześniejszych projektów). To właśnie ta druga pętla, o której wspominałem wcześniej. Podobna znajduje się wewnątrz każdego stanu. Uaktualniają one aktualny stan i pozwalają funkcji requestAnimationFrame zająć się przede wszystkim rysowaniem na canvas.

Po za tą jedną różnicą ten stan jest bardzo podobny do tego z poprzedniej gry. Funkcja update uaktualnia napis wyświetlany na płótnie, oraz sprawdza czy wszystkie grafiki dodane przez metodę loadAssets są już gotowe. Jeżeli zadeklarowane obrazki zostały wczytane, stan zmienia się na kolejny.

Mechanizm zmiany stanów również zbytnio się nie zmienił. Jeżeli warunek zmiany stanu zostanie spełniony, metoda update zmienia initalised na false, zatrzymuje pętle setInterval i ustawia nowy stan na głównym obiekcie gry.

Kolejne dwa stany to menuState oraz storyState:

Te dwa stany to, póki co, tylko placeholdery. Są tu po prostu po to aby trzymać miejsce dla stanu z prawdziwego zdarzenia, który pojawi się w przyszłości. Oba są praktycznie takie same. Zmieniają się w kolejny stan po wciśnięciu przez gracza spacji. To czy przycisk został naciśnięty sprawdzane jest w metodzie update. Nie licząc wewnętrznej pętli uruchamianej za pomocą setInterval, takie same stany znajdowały się już w poprzedniej grze. W kolejnych aktualizacjach zostaną trochę bardziej rozbudowane.

W ten sposób przechodzę do serca tematu czyli głównego stanu gry:

Oprócz standardowego initalised, w tym stanie znajdują się też dwa inne pola: player oraz platforms. Pierwsze to obiekt, który reprezentować będzie postać gracza. Drugie to tablica, w której znajdować się będą platformy, na które może wzlecieć gracz.

Pierwsza metoda to standardowo init. Najpierw oczywiście zmieniam wartość pola initialised, następnie zajmuję się obiektami gry. Na podstawie spriteObject tworzę obiekt platform. Będzie on wzorem dla obiektów przedstawiających platformy oraz podłoże. Oprócz ustawienia unikalnych wartości źródła obrazka oraz rozmiarów, definiuję też metodę draw tego obiektu. Każdy obiekt platformy będzie zawierał w sobie tę metodę. Definiuje ona w jaki sposób jest. Ponieważ podłoża nie będą aktualizowane, nie posiadają metody update.

Kolejny krok to zdefiniowanie dwóch instancji platform, oraz instancji ziemi. Są one tworzone na bazie platform. Każda z nich utrzymuje unikatową szerokość oraz położenie.

Następnie na podstawie spriteObject, tworzę obiekt gracza – player. W nim ustawiam wszystkie pola zawierające potrzebne wartości. Rozmiar obrazka oraz obiektu, pole facing, odpowiadająca za kierunek w którym ‚patrzy’ gracz, pola odpowiadające za prędkość ruchu (sideSpeed,enginePower,maxEnginePower), pole onGround, przechowujące wartość odpowiadającą za to czy gracz stoi na ziemi czy się unosi, pola potrzebne do wyświetlania klatek animacji oraz początkowe współrzędne obiektu.

Po za polami, obiekt player posiada dwie metody draw oraz update. draw jest dość proste. Obrazek reprezentujący obiekt jest rysowany na płótnie, biorąc pod uwagę takie informacje jak aktualna klatka animacji obrazka oraz stronę, w którą ‚patrzy’ obiekt.

Metoda update zawiera już trochę więcej logiki. Najpierw sprawdzam czy wciśnięte zostały przyciski, które mogą zmienić stan obiektu gracza. Te przyciski to strzałki w lewo, prawo oraz w górę. Strzałki wskazujące na boki, o ile gracz nie stoi na ziemi, zmieniają wartość jego współrzędnej x o sideSpeed. sideSpeed wyraża prędkość w pixelach na sekundę, dlatego muszę odpowiednio je zmodyfikować, aby przemieszczenie było realnie oddane w każdej klatce (mnożę tę wartość razy jeden dzielone na liczbę klatek na sekundę). W taki sposób traktuje każdą wartość reprezentującą prędkość w grze.

Oczywiście jeśli gracz porusza się w lewo wartość x jest zmniejszana, w przeciwnym wypadku, wzrasta. Nie zapominam również o aktualizowaniu wartości pola facing.

Efekt naciśnięcia strzałki w górę jest trochę bardziej skomplikowany. Postać gracza posiada plecak odrzutowy, po naciśnięciu strzałki w górę silnik uruchamia się i postać unosi się ku górze, najpierw powoli, ale gdy silnik się rozgrzewa, coraz szybciej, aż osiąga pełną prędkość. Gdy silnik zostanie wyłączony (strzałka w górę nie jest już przyciskana), gracz chwilę jeszcze się unosi, po czym zaczyna opadać na dół.

Teraz tę ideę należy przetłumaczyć na kod. Gdy strzałka w górę jest wciśnięta wartość pola enginePower zaczyna rosnąć, aż osiągnie wartość równą wartości pola maxEnginePower. Gdy strzałka w górę zostanie zwolniona, wartość pola enginePower zaczyna stopniowo się zmniejszać, aż osiąga zero.

Przy okazji, trzymanie strzałki w górę powoduje zmiany klatki animacji obiektu gracza oraz ustawia wartość pola onGround na false.

Po wszystkim aktualizowana jest wartość współrzędnej y obiektu gracza (niezależnie od tego czy jakieś klawisze zostały naduszone czy nie). Najpierw dodaje do niej wartość grawitacji, zdefiniowanej w głównym obiekcie a następnie odejmuje wartość pola enginePower. W ten bardzo prosty sposób udało mi się zamodelować zjawisko grawitacji oraz przyśpieszenia. Jeżeli nie działa moc silnika, gracz opada, jeżeli moc silnika działa i jest większa niż przyciąganie podłoża, gracz unosi się w górę :). Proste! 🙂

Następnie w metodzie update obiektu player. Sprawdzam, czy gracz nie wyleciał poza granice płótna. Jeżeli tak, zostaje zatrzymany.

To koniec inicjalizacji obiektu gracza, Na końcu metody init, uruchamiam jeszcze pętle, która wywołuje metodę update stanu, co określoną ilość czasu.

W metodzie update stanu wywołuje metodę update obiektu gracza, oraz sprawdzam czy nie koliduje z którąś z platform. Do wykrycia kolizji używam metody blockRectangle, którą opisywałem już wcześniej na blogu. Dzięki temu, gracz może ‚stawać’ na platformach.

Wprowadziłem jedna małą zmianę w metodzie blockRectangle. Jeżeli kolizja z graczem nastąpi od góry, pole onGround obiektu zostaje ustawione na true.

I to póki co cała gra. Następna aktualizacja powinna pojawić się niedługo. Postaram się aby był to początek przyszłego tygodnia. Jeżeli chcesz być na bieżąco z aktualizacjami tej gry, zachęcam do polubienia mojej strony na facebooku. Regularnie zamieszczam tam informacje o wszystkich nowościach na blogu.