(WIP) Space Attack – Gra napisana w JavaScript. Kolejny update.

Space Attack – Gra napisana w JavaScript zaczyna nabierać rumieńców. W tym poście przedstawię kolejny update, prosto z edytora tekstu 🙂 . Nowości jest sporo. Przede wszystkim, Space Attack nadaje się już do grania. Można spróbować klikając w obrazek poniżej. Jak zwykle, przygotowałem też paczkę z kodem oraz grafikami projektu.

Gra napisana w JavaScript - Space Attack

Projekt znacznie się rozrósł. Rozmiar pliku .js to obecnie ponad 600 linijek kodu. Między innymi dlatego nie będę dokładnie opisywał wszystkiego po kolei, było by ciężko 🙂 zresztą większość mechanizmu działania gry opisałem już w poprzednim poście. Omówię zatem tylko ważne zmiany i to nowości 🙂 . Najpierw zacznę ogólnego opisu kondycji gry.

Space Attack – Gra napisana w JavaScript – ogólny opis zmian

W głównej mechanice nie zmieniło się nic. Zmiany w samym obiekcie silnika gry, GameEngine, są nieznaczne. Przede wszystkim w obiekcie config pojawiło się kilka nowych pól. Głównie są to pola przechowujące takie wartości jak etap gry czy punktacja gracza.

W obsługujących stos stanów gry metodach changeState i removeState usunąłem sprawdzanie warunku, czy stany posiadają metodę leave. Ostatecznie, żaden stan, nie miał takiej. Do ustawiania wartości gry przy zmianie stanu wykorzystuję tylko metody enter.

Za to pojawiły się dwa nowe stany: LevelAnnouncement oraz GameOver. Pierwszy stan obsługuję scenę przed uruchomieniem głównego stanu. Wyświetla informacja o tym, że gracz zostanie za chwilę przeniesiony do kolejnego etapu. Co robi stan GameOver chyba nie muszę tłumaczyć 🙂

Główny stan gry GameState rozrósł się znacznie. Przede wszystkim w grze pojawili się wrogowie, których można unieszkodliwiać rakietami 🙂 Za każdego ustrzelonego wroga gracz otrzymuje punkty. Im wyższy etap gry, tym szybciej poruszają się przeciwnicy. Jeśli zielony kosmita (dron) dotrze do dolnej krawędzi sceny gry, gracz traci życie. Do tego na wyższych etapach gry pojawiają się inni przeciwnicy, którzy wypuszczają własne pociski w stronę gracza! Jeżeli gracz zostanie trafiony, również traci życie. Po utracie trzech żyć, gra kończy się. Jeżeli natomiast gracz ustrzeli odpowiednią ilość obcych, zostaje przeniesiony do kolejnego etapu. Ilość wrogich statków, które należy zestrzelić, wzrasta wraz z etapami.

Okej tyle jeśli chodzi o ogóły, czas przejść do tego co najciekawsze, czyli do kodu 🙂

Space Attack – Gra napisana w JavaScript – nowy kod

Na początek szybki rzut okiem na nowe pola w obiekcie config silnika gry

  • score – w tym polu przechowywana będzie ilość punktów, którą zdobył gracz.
  • level – czyli aktualny etap gry. Domyślnie jest to oczywiście pierwszy etap.
  • toKill – liczba kosmitów jaką musi zestrzelić gracz aby przejść do kolejnego etapu.
  • lives – liczba żyć gracza, jeżeli je straci, gra kończy się.

Do tego jest kilka nowych pól przechowujących adresy grafik obiektów.

Kolejny kod to dwa nowe stany LevelAnnouncement oraz GameOver. Zacznę od kodu LevelAnnouncement.

Tak naprawdę nie dzieje się tu nic skomplikowanego. Jak każdy stan gry, i ten gdy jest tworzony otrzymuje w argumencie wskaźnik na silnik gry (jeżeli nie wiesz w jaki sposób tworzę stany i jak są one obsługiwane przez silnik gry, przeczytaj poprzedni post, w którym to opisuję). Pierwsze pole to odnośnik do kontekstu płótna. Dwa następne służą do kontrolowania czasu wyświetlenia tego stanu. displayTime to czas jaki ten stan ma być wyświetlany. timer przechowuje wartość równą czasowi wyświetlania. Metoda draw po prostu wypisuje tekst na scenie gry, nic specjalnego 🙂 . Metoda update tego stanu, liczy jaki czas upłynął od początku wyświetlania stanu. Jeżeli timer jest równy displayTime, silnik zmienia stan na główny stan gry. Jeżeli timer jest mniejszy, zostaje zwiększony o wartość równą ilości upłyniętego czasu. Na koniec metoda enter, która odpalana jest jako pierwsza, ustawia po prostu timer na zero.

Kolejny nowy stan to GameOver:

Tak jak poprzedni i ten stan podczas tworzenia otrzymuje w argumencie referencje do silnika gry. Po utworzeniu pola, zawierającego kontekst płótna są tylko metody. Draw po prostu wypisuje na ekranie smutną wiadomość oraz informacje co gracz ma robić dalej. Metoda enter resetuje dane gry z obiektu config silnika gry, tak aby w kolejnej rozgrywce, zaczynał od początku. Resetowane informacje to etap gry, zdobyte punkty, liczba kosmitów do ustrzelenia oraz ilość żyć gracza. Wszystko to, co zmienia się w czasie rozgrywki. Na koniec metoda keyDown sprawdza czy została wciśnięta spacja. Jeśli tak, gra przechodzi w stan menuState.

Skoro to już mam za sobą, czas na ‚mięcho’ tego wpisu, czyli zmiany w stanie GameState. Nie będę wklejał całego kodu, tylko nowości i zmiany. Jeżeli ktoś nie pamięta co dokładnie działo się w tym stanie może zerknąć do poprzedniego wpisu, w którym wszystko jest przedstawione 🙂 zawsze można zerknąć w kod z paczki i próbować rozgryźć system na własną rękę.

Na początek nowe pola:

Pierwsze pole to oczywiście kontekst płótna. Kolejne to aliensKilled. Przechowuje ono informacje o tym ile kosmitów zostało już zestrzelonych w tej scenie. Ta informacja przyda się później. Kolejne pola to tablice. Będą zawierały one informacje o aktorach gry. Odszedłem od opcji, gdzie wszystkie obiekty wrzucane były do jednej tablicy actors. Podzielenie tego wydaje mi się być bardziej czytelne. Do tego każdy z tych obiektów zachowuje się inaczej, co też łatwiej jest zakodować, kiedy są odpowiednio pogrupowane. Następne sześć pól to liczniki czasu respawnu kosmitów. Pola tillSpawn to czas na respawn konkretnego wroga. Pola spawnTime przechowywać będą informacje o tym ile czasu upłynęło od pojawienia się poprzedniego wroga tego typu. Na końcu znajduje się pole aliensLeft. To zmienna pomocnicza, przechowująca różnicę pomiędzy liczbą kosmitów, która należy zestrzelić a już zestrzelonymi.

Muszę przyznać, że ta część kodu trochę mi zgrzyta. Z jakiegoś powodu nie odpowiada mi, że te pola tak po prostu tu „wiszą”. Nauczyłem się ufać przeczuciom gdy programuje, więc pewnie w ciągu dalszej pracy przyjże się temu bardziej. Może powinny być w innym miejscu, a może zapakować je w obiekt coś ala config… Zobaczymy 😉

Kolejna część stanu GameState to wykorzystywane przez niego obiekty. Ship oraz Rocket są już znane. Nowe obiekty to Plasma, czyli pocisk kosmitów, Drone, Bomber i Fighter czyli rodzaje przeciwników oraz Explosion czyli obiekt reprezentujący to co zostaje po kosmicie gdy zostanie trafiony 🙂

Nie będę pokazywał kodu każdego z tych obiektów. Zachęcam za to do studiowania źródła w miarę czytania wpisu. Plasma działa dokładnie tak jak Rocket, po prostu będzie leciał w przeciwną stronę 🙂 . Obiekty Drone, Bomber oraz Fighter, są do siebie bardzo podobne, dlatego na tapetę wezmę tylko jednego z nich.

Bombowiec obcych podczas tworzenia przyjmuje dwie wartości: x czyli poziomą lokację na planszy, oraz speed, czyli ilość pixeli jakie pokonuje w ciągu sekundy. Pole size to po prostu wielkość obiektu. Pole speed to prędkość, jest ona generowana na zewnątrz ponieważ zależy od etapu gry (im wyższy, tym szybciej poruszają się obcy). w przypadku bombowca, jest ona trochę zmniejszana ponieważ z założenia ma on być wolniejszy niż inne statki przeciwnika. Pole value to ilość punktów jaką zdobywa gracz po zestrzeleniu tego obiektu. Znaczenie x oraz y powinno być już jasne, warto zwrócić uwagę, że x początkowo jest ujemny, ponieważ chcę aby wrogowie spawnowali się poza plansza i dopiero na nią wlatywali.

Pole vector to nowość. Zawiera ono obiekt,który z kolei ma własne pola x oraz y. Mogą one być równe 0, 1 lub -1 i oznaczają przesunięcie. Ta wartość jest brana pod uwagę podczas wyliczania nowej lokacji obcego przy zmianie klatki. Na tę chwilę warto zapamietać ze 1 oznacza poruszanie się zgodnie z iksami lub igrekami (chodzi oczywiście o to jak są one liczone w układzie canvas), -1 poruszenie w przeciwnym kierunku, a zero brak przesunięcia na tej osi. Dla przykładu bombowiec, który ma vector.x równy zero, nie przesunie się w poziomie. vector.y równy 1 oznacza, że bombowiec będzie przesuwał się w dół płótna. Dla przykładu myśliwiec ma początkowy vector równy x:1 y:1 co oznacza, że będzie przesuwał się po skosie z prawej na lewo i z góry na dól.

Następne dwa pola lastBombed oraz bombInterval potrzebne są w mechanizmie odliczania czasu kolejnego strzału kosmity. Wartość pola lastBombed każdej instancji bombowca zmniejszana będzie co klatkę gry. Gdy dojdzie do zera, kosmita wypuści bombę. Następnie pole lastBombed otrzyma wartość równą wartości pola bombInterval i tak w kółko. Na początku lastBombed wynosi już 2 aby przeciwnik nie strzelał gdy tylko pojawi się na planszy. Myśliwce mają wbudowany taki sam mechanizm.

Kolejne pola odpowiadają, za ustawienie obiektu obrazka dla bombowca. Na koniec bardzo prosta metoda draw, która dla wszystkich aktorów gry wygląda tak samo.

Kolejny obiekt w głównym stanie gry, który chcę opisać to Explosion

Jak widać jest to bardzo prosty obiekt. Jako argumenty przyjmuje wartości dla x oraz y, które potem przypisywane są do odpowiednich pól. Obiekt posiada też pola odpowiedzialne za obrazek oraz metodę draw. To na co chcę skupić tutaj uwagę to pola visibleTime oraz visibleFor. Jak łatwo się domyślić, służą one do kontrolowania czasu wyświetlania eksplozji.

visibleFor wzrasta co klatkę gry. Gdy osiągnie wartość równą visibleTime, znika. Oznacza to, każda eksplozja będzie widoczna na planszy przez pół sekundy.

To tyle jeśli chodzi o obiekty stanu gry. Kolejny punkt do omówienia to metody, które obsługują zachowania wszystkich obiektów w głównym stanie gry.

Pierwsza jest metoda enter, odpalana za każdym razem, gdy główny stan gry zostanie uruchomiony.

Najpierw usuwam wszystkie dane z obiektu pressedKeys silnika gry. Następnie tworzę nową instancję statku. Nie znajduje się on już w jednej tablicy z rakietami a jest osobnym obiektem. Następnie aliensKilled jest zerowane, ponieważ każde wejście tego stany to nowy etap gry. Z tego samego powodu w kolejnych paru linijkach czyszczę wszystkie tablice zawierające obiekty gry. Nie chcę aby w nowym etapie gry od razu latali jacyś kosmici, nie mówiąc już o kulach plazmy 🙂 . Ostatnie trzy linijki to ustawienie czasu co jaki będą spawnawać się odpowiedni przeciwnicy. Program oblicza te wartości za każdym razem, gdy wchodzi nowy stan gry. Wartości te, obliczane są na podstawie poziomu gry. Metodą prób i błędów doszedłem do wzorów, które są tam obecnie.

Kolejna metoda to draw:

Pomogłem tu sobie komentarzami. Przypominam, metoda ta wywoływana jest przez game loop co sekunda dzielona na liczbę klatek. Czyli to tutaj rysowane są klatki tworzące animacje gry. Oczywiście, najpierw czyszczony jest canvas. Następnie, metoda przechodzi przez wszystkie obiekty we wszystkich tablicach zawierających aktorów i wywołuje ich metody draw.

Gdy to jest gotowe rysowane jest GUI czyli graficzny interfejs użytkownika 🙂 . W wypadku mojej gry jest on bardzo prosty. w górnym lewym rogu wyświetlam ilość punktów zdobytych przez gracza oraz numer, etapu na którym się znajduje.

W prawym górnym rogu wyświetlam ilość żyć, która pozostała graczowi. Zamiast po prostu wypisać liczbę, za pomocą pętli for rysuję mały obrazek statku tyle razy ile żyć gracz posiada (Jak narysować taki mały obrazek używając istniejącego już obiektu image? Warto wiedzieć, więcej informacji tutaj).

W prawym dolnym rogu wyświetlana jest informacja o tym ilu jeszcze kosmitów należy zestrzelić aby ukończyć dany etap.

kolejna metoda to update:

Metoda update w pierwszej kolejności aktualizuje pole aliensLeft, którego wartość oznacza ile jeszcze zostało kosmitów do zestrzelenia. Następnie sprawdzany jest obiekt keysPressed silnika gry. Jeżeli został wciśnięty odpowiedni przycisk, zostaje odpalona odpowiednia metoda (nic nowego, było). Następnie metoda update uruchamia po kolei wszystkie metody, odpowiedzialne za zaktualizowanie aktorów gry. Po tym uruchamiane są metody odpowiedzialne są za spawnowanie nowych przeciwników. Nowe drony, spawnowane są od razu, natomiast bombowce i myśliwce dopiero na wyższych poziomach. Gdy to jest już gotowe, metoda update uruchamia checkCollision czyli sprawdzanie kolizji.

Ostatnią rzeczą jaką robi update stanu gry to sprawdzenie czy gra nie powinna zmienić stanu. Jeżeli pole aliensKilled jest równe polu toKill z obiektu config silnika gry to poziom gry jest zwiększany o jeden, a wartość toKill o 5 i wstawiany jest stan levelAnnounce. Jeżeli natomiast pole lives obiektu config silnika gry ma wartość równą zeru, oznacza to, że gracz przegrał i wstawiany jest stan gameOver.

Metody związane z aktualizowaniem statku i rakiet zostały już opisane wcześniej, nie licząc zmian kosmetycznych, są wciąż takie same. Pierwsza nowa metoda obiektu stanu GameState to updateExplosions.

Jak widać, nie jest zbyt skomplikowana. Sprawdzany jest po prostu stan pól visibleFor każdej z instancji eksplozji znajdujących się w tablicy explosions. Jeżeli któraś osiągnęła wartość równą visibleTime, jest usuwana z tablicy.

Kolejną nową, prostą metodą jest updatePlasmas:

Działa ona bardzo podobnie, wszystkie plazmy znajdujące się w tablicy plasmas, mają uaktualniny stan ich pól y. Jeżeli któraś wyleci poza mapę, jest usuwana z tablicy.

Kolejne nowe metody, to te odpowiedzialne za spawnowanie oraz aktualizowanie przeciwników. W stanie GameState każdy rodzaj wroga ma takie metody. Działają one praktycznie tak samo, zmieniają się jedynie wartości liczbowe. Jako przykład zaprezentuję metody myśliwca, czyli spawnFighter oraz updateFighter.

spawnFighter najpierw sprawdza czy wartość pola fighterTillSpawn jest równa zero. Jeżeli tak, zostaje wylosowana wartość x dla nowego obiektu myśliwca. Wartość speed jest stała. Myśliwce i tak będą poruszać się bardzo szybko, nie chciałem aby zwiększały prędkość wraz z etapem gry jak w przypadku innych statków obcych. Następnie do tablic fighters dodawany jest nowy obiekt o odpowiednich parametrach. Na koniec wartość fighterTillSpawn ustawiana jest na równą wartości fighterSpawnTime. Jeżeli fighterTillSpawn nie jest równe zero, jest pomniejszane o wartość równą jeden dzielone na liczbę klatek.

Metoda updateFighters jest dłuższa, przez co wydaje się być trochę bardziej skomplikowana, ale to pozory. Ponownie, metoda przechodzi przez tablice zawierającą wszystkie obiekty myśliwców. Dla każdego z nich aktualizowane są wartości x oraz y są one obliczane na podstawie speed obiektu, ilości klatek na sekundę oraz odpowiedniego wartości z pola vector. Jeżeli vector równe jest -1 ruch jest odwracany, jeżeli 0, nie ma żadnego ruchu. Pisałem o tym wcześniej, ale tutaj można zobaczyć to ‚w naturze’.

Kolejna część metody odpowiada za zrzucanie przez myśliwiec pocisków. Ten mechanizm wszyscy powinni już znać na pamięć. Jeżeli upłynie odpowiedni czas zostaje zrzucona kula plazmy. Jest ona dodawana jako nowa instancja obiektu Plasma do tablicy plasmas. Jej x jest wyliczany na podstawie położenia myśliwca, który ją zrzucił.

Ostatnia część metody updateFighters zawiera cztery if’y. Służą one to sprawdzenia i zmiany kierunku, w którym będzie leciał myśliwiec. Wspomnę tutaj o ogólnym zachowaniu statków obcych. Dron, porusza się pionowo w dół, jeżeli opuści pole gry, gracz traci życie. Bombowiec również porusza się pionowo ale gdy osiągnie dolną krawędź mapy zaczyna lecieć do góry (wartość jego vector.y jest obracana), gdy osiągnie górną krawędź znów zaczyna lecieć w dół. Jego celem jest przeszkadzanie graczowi i odebranie mu żyć za pomocą bomb. Myśliwiec jako jedyny porusza się zarówno poziomo jak i pionowo. Niczym odbijająca się od krawędzi pola gry kuleczka. Do tego właśnie służą te if’y w metodzie updateFighters, sprawdzają czy mysliwieć dotarł do którejś z krawędzi i sprawdzają czy dalej leci w jej kierunku (ta informacja jest zawarta w vector). Jeżeli tak, kierunek lotu jest zmieniany.

Ostatnia metoda jaka została mi do opisania to checkCollision:

Pomimo pokaźnej wielkości (przynajmniej w porównaniu z innymi funkcjami) ten potworek wcale nie jest taki skomplikowany. Po dokładnym przyjrzeniu się widać, że metodę tę można podzielić na dwie pętle for. Pierwsza z nich przechodzi przez tablicę rockets a druga przez tablicę plasmas. Czyli sprawdzane są położenia wszystkich pocisków, ma to sens 🙂 W pierwszej pętli dla każdej z rakiet, tworzone są kolejne trzy pętle, dla każdej z tablic przeciwników. Kod przechodzi przez każdego przeciwnika i sprawdza, czy rakieta nie zajmuje tej samej przestrzeni co on. Jeżeli tak, zarówno rakieta jak i przeciwnik usuwani są z odpowiedniej tablicy, a do tablicy explosions dodawana jest nowa instancja eksplozji o x oraz y równym tym samym wartościom przeciwnika.

Sprawa podobnie ma się z drugiem for’em. Tym razem lokacja każdej z plazmy, porównywana jest z lokacją statku gracza. Jeżeli przypadkiem znajdują się w tym samym miejscu, gracz traci jedno życie a plazma jest usuwana z gry.

Muszę się przyznać że do sposobów porównywania lokacji dochodziłem metodą prób i błędów. Niestety same obiekty są większe niż obrazki, co czasem skutkowało dziwnymi zachowaniami. Myślę jednak, że efekt, który ostatecznie udało mi się osiągnąć jest zadowalający. Chociaż na pewno jest to coś co w przyszłości mogę poprawić, jeśli nie w tej grze to w kolejnych.

I takim pozytywnym akcentem udało się dotrzeć do końca tego postu. Reszta kodu jest już znana, lub powinna nadawać się do interpretacji przy pomocy informacji, które zamieściłem powyżej. Myślę, że to jeszcze nie koniec tej gry. Mam parę pomysłów na to aby ją rozwinąć, ale zobaczymy jak to pójdzie.

Jeżeli masz jakieś pytania nie wahaj się zadać ich w komentarzach. Świetnym miejscem na kontakt ze mną jest również moja strona na facebooku (bardzo zachęcam do polubienia), którą odwiedzam i aktualizuję na bieżąco.

Dodaj komentarz

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