JSetpack – gra co miesiąc: luty – Kompletna gra.

Z przedstawieniem kompletnej gry miesiąca, musiałem czekać na ostatnią chwilę. Inaczej być nie mogło… Na szczęście luty w tym roku dłuższy niż zwykle, akurat żebym ze wszystkim zdążył 🙂

Mój klon starusieńkiego Jetapaca – Jsetpack jest już gotowy.

Aby pograć w finalną wersję kliknij w obrazek powyżej. Jest też (jak zawsze) paczka z kodem.

Aktualizacji wbrew pozorom nie jest tak dużo. Pierwsza większa nowość to przeciwnicy. W budowaniu rakiety, będą od teraz przeszkadzać graczowi niebezpieczni kosmici. Kolizja z kosmitą oznacza dla gracza utratę życia oraz cofnięcie na początek aktualnego.

Na szczęście dla gracza, jego postać może się teraz bronić. Wyposażona w pistolet plazmowy, może odpędzać kosmicznych natrętów 🙂 .

Kolejna nowość to bonusowe przedmioty pojawiające się losowo w czasie gry. Kosmiczne szafiry i kosmiczne gluty to cenne materiały, których zebranie daje graczowi dużo dodatkowych punktów. Punkty naliczane są także po ustrzeleniu kosmity oraz po ukończeniu poziomu. Jednak każdy kolejny poziom będzie trudniejszy, ponieważ potworów będzie coraz więcej.

Pojawiło się też mnóstwo drobniejszych zmian ale nie będę opisywał każdej. Można bez problemu zerknąć do kodu i poszukać wszystkich nowości na własną rękę. Zresztą, jak zawsze, bardzo do tego zachęcam. Studiowanie czyjegoś kodu to zawsze dobry sposób na naukę 🙂 .

Zacznę od obiektu potwora:

Tak naprawdę nie ma tu nic czego nie używałbym już wcześniej. Na początku znajdują się pola potrzebne do narysowania obiektu oraz do określenia jego położenia. Następne są pola odpowiedzialne za wyświetlanie kolejnych klatek potwora (są tylko dwie). Jest też pole direction zawierające informacje o tym, w którą stronę leci kosmita.

Pola angle, waveRange oraz baseY wykorzystywane są tak aby potwór poruszał się ‚po fali’. Tak samo poruszałem czarownicą w poprzedniej grze. Wiem, że obiecałem post, w którym dokładniej opisuje zagadnienie wykorzystania funkcji trygonometrycznych… będzie 🙂 .

Pole value, to wartość punktowa jaką gracz otrzymuje za zestrzelenie potwora. W grze jest ona przemnażana przez aktualny poziom.

Trzy ostatnie pola potrzebne są do obsługi zachowania potwora po jego ustrzeleniu. Gdy zostaje postrzelony wartość isShotdown zmienia się na true. lingerAfterShotdown to ilość klatek gry przez jakie widzimy grafikę postrzelonego potwora. pole shotDownFor to licznik tych klatek.

Ten obiekt ma też dwie standardowe metody update oraz draw.

Jeżeli isShotdown nie jest równe true, update, normalnie aktualizuje obiekt. Oznacza to zmianę klatek animacji, poruszanie potworem w poziomie (x rośnie lub maleje w zależności od kierunku potwora), oraz manipulacje wartością y tak aby potwór ‚falował’.

Jeżeli isShotdown jest równe false, inkrementowana jest wartość pola shotDownFor.

Metoda draw, wyrysowuje odpowiednią klatkę potwora w odpowiednim miejscu. Warto zwrócić uwagę na to, że rysowany jest inny kolor potwora od tego zależnie od tego który jest aktualnie poziom gry. Trzy różnokolorowe rysunki potworów znajdują się pod sobą w pionie na planszy obrazków. SourceY obiektu jest zwiększane o jego wysokość przez poziom modulo trzy. Oznacza to, że co trzy poziomy kolor potwora będzie inny a potem zaczną się powtarzać.

W metodzie stanu update, także pojawiły się nowe fragmenty kodu, które obsługują potwory.

Pierwsza pętla sprawdza czy potwór został zestrzelony i czy jego shotDownFor nie przekroczyło wartości lingerAfterShotDown. Jeżeli tak, potwór jest usuwany z listy przechowującej potwory. To samo dzieje się, kiedy potwór wyleci ponad 100 pikesli poza ekran.

Kolejny krok to wywoływanie metody checkMonsterCollision, odpowiedzialnej za wykrycia kolizji.

Ostatni if wykorzystuje pola głównego obiektu: lastMonster oraz monsterInterval. Drugie pole to czas co jaki pojawi się nowy potwór, pierwsze to licznik tego czasu. Reszta kodu powinna być jasna. Gdy minie odpowiednia ilość czasu, wywoływana jest metoda spawnMonster.

Oto treść wymienionych wyżej metod. Są to metody głównego obiektu stanu:

W metodzie checkMonsterCollision sprawdzany jest każdy potwór z każdym pociskiem w grze oraz z graczem. Kolizja z pociskiem ustawia pole potwora isShotDown na true, a pocisk jest usuwany z gry. Jeżeli nastąpi kolizja z postacią gracza, wartość true otrzymuje pole isHit obiektu player .

Wewnątrz metody spawnMonster losowo sprawdzane jest czy powstanie nowy potwór. Szansa zapisana jest w polu głównego obiektu stanu monsterChance. Ewentualny nowy potwór ma najpierw losowo generowane odpowiednie właściwości a następnie dodawany jest do tablicy przechowującej wszystkie potwory w grze.

Nie będę opisywał mechanizmu strzelania. Jest on praktycznie taki sam jak w poprzedniej grze. Skupie się za to na obiekcie skarbu.

Oto jak wygląda:

Jest to bardzo prosty obiekcik. Oprócz standardowych pól, posiada pole onScreen. To dlatego, że w grze na raz może być tylko jeden obiekt skarbu, a pole onScreen będzie pomagać w ustaleniu czy jest aktualnie widoczny czy nie. To mechanizm bardzo podobny do tego, który obsługuje kanister z benzyną

Obiekt posiada też metody update oraz draw. Pierwsza zmienia tylko wartość pola y. Na skarby będzie wpływać grawitacja i będą one spadały ‚z nieba’. Druga metoda to rysowanie obiektu w najprostszej postaci. Skarby mają tylko jedną klatkę, która się nie zmienia.

W głównej metodzie update, także pojawił się fragment kodu wpływającego na obiekt skarbu:

najpierw wywoływana jest metoda spawnTreasure. Jeżeli skarb znajduje się na ekranie, wywoływana jest jego metoda update. Jeżeli do tego wykryta jest kolizja pomiędzy nim a graczem, wywoływana jest metoda collectTreasure.

Nie wkleję fragmentu kodu odpowiadającego za blokadę skarbów na platformach, to tylko dodatkowa linijka w metodzie update stanu.

Oto kod metod obsługujących zachowanie skarbu:

Metoda collectTrasure jest banalnie prosta. Najpierw naliczam punkty za skarb, pomnożone przez poziom gry. Następnie wyrzucam obiekt poza obszar gry przypisując mu negatywne wartości pól x oraz y. Na koniec pole obiektu onScreen otrzymuje wartość false.

Metoda spawnTreasure jest trochę dłuższa ale też bardzo prosta 🙂 . Jeżeli wartość pola onScreen nie jest równa true. Losowana jest liczba, Jeżeli jest ona mniejsza niż 0.005, skarb wrzucany jest z powrotem do gry. Może się wydawać, że szansa jest naprawdę mała, jednak biorąc pod uwagę to jak często wywoływana jest ta metoda, skarb pojawia z powrotem się dość szybko po jego zebraniu.

Losowo wybierane jest też miejsce w poziomie, z którego ‚spadnie’ skarb. Obiekt ten może mieć jedną z dwóch grafik, to która to będzie również ustalam losowo 🙂

Gdy nowa odsłona obiektu skarbu jest gotowa, pole onScreen znów ustawiana jest na true.

Oczywiście opuściłem trochę nowego kodu. Oprócz wspomnianego wcześniej mechanizmu obsługującego strzelanie, nie opisałem też na przykład kodu odpowiedzialnego za utratę żyć przez gracza. Pojawiły się dwa nowe stany, a te istniejące też trochę się zmieniły. Jednak opisanie wszystkie zajęło by zbyt wiele miejsca a chyba nie są to zbyt skomplikowane mechanizmy.

Ponownie zachęcam do przestudiowania kodu i odszukania odpowiednich fragmentów. Jeżeli coś jednak będzie niezrozumiałe, daj znać w komentarzach. Na pewno postaram się wyjaśnić wszystkie wątpliwości 🙂 .

I to tyle jeśli chodzi o luty. Gra gotowa. Zobaczymy co przyniesie kolejny miesiąc.

Jeśli nie chcesz tego przegapić, zachęcam do polubienia mojej strony na facebooku. Na bieżąco umieszczam tam informacje o nowościach. Jest to też dobre miejsce na kontakt ze mną. Pytania zadane na fanpage’u także nie zostaną bez odpowiedzi 🙂 .