en spildt dag

Vi har spildt en dag pga. at vi efter ændrede variabler ikke kunne få AI'en til at virke.

Powerups

Vi har besluttet os for at lave powerupsklassen.

Powerupsne skal have fælles collision detection på player og skal allesammen random smides af zombierne. Vi har besluttet at lægge instantieringen af powerupsne i den funktion i Level, der holder styr på hvor mange zombier, der er på scenen. Dette kommer af at hvis vi instantierer den fra den zombie, der dør mister vi parent.

3. iteration påbegyndt

Vi har nu påbegyndt 3. iteration, og er startet med det grafiske UI. Vi har brugt os selv som modeller til Player og Zombie, ved at tage billeder af os selv oppe fra et punkt og lodret ned. På billederne står vi og stikker armene ud(Zombie) eller holder et objekt der kan fungere som våben(Player), og med skiftende ben fremme, så vi kan skabe en animeret gang i spillet ved en gif-fil. Vi har fået implementeret grafikken til player, men vi vurderer stadigvæk hvorvidt Zombiens grafik skal implementeres i den nuværende Zombie-klasse, eller om der skal laves tre forskellige under-klasser hvori grafikken ligger i, mens fællesfunktionaliteterne ligger i den overordende klasse.

Efter vi har implementeret grafik på Player, er vi stødt på det problem at vores collision-detection ikke fungerer optimalt. Dette er fordi at playeren nu ikke mere blot er en cirkel, og derfor skal vi have fundet en matematisk måde at udregne punkterne på Playeren i hans nuværende form.

UPDATE:

Vi har nu implementeret grafik på de tre typer zombier og oplever en form for lag omkring lvl 25. Vi vil forsøge at udbedre dette ved at foretage trashcollection, da vores kode ikke bare glemmer de zombier fra forrige levels og derfor holder styr på alt for meget.

UPDATE 2.0:

Vi har nu lavet weak references på de eventlisteners, der tilgår zombieklassen. Lag = no more.

Tredje iteration

Anden iteration:

Vi har afsluttet denne, dog med et tilbagevendende kasseproblem, hvor de stadig lægger sig oveni hinanden. Vi vil forsøge at komme dette til livs ved at kigge tjekpunkterne igennem igen, da det højst sandsynligt er her fejlen ligger. Vi vil endvidere forsøge at kondensere tjeksne på kugler vs. kasser.

Tredje iteration:

I denne vil vi forsøge at implementere de sidste af opgavens krav:

• Powerups: Ekstra liv, et supervåben over en lille periode eller et bestemt antal skud og speedboost.
• Vi laver det så at spilleren bliver flyttet ned i hjørnet når han dør, samtidigt med at zombierne bliver flyttet lidt op på banen for at de ikke står og dræber spilleren oveni spawn-zonen.
• Score-, liv- og levelcounter oppe i hjørnet.
• Tekstur og grafik: Stengulv og trækasser/containere samt billeder i fugleperspektiv af os som zombier såvel som helten med en stor skyder.

Denne iteration forventes afsluttet d. 28. maj.

For at spillet skal have nogen grad af sværhed, er det nødvendigt at fjenderne følger efter spilleren. Selve bevægelsen af zombierne er identisk med den hos Player, da denne udregnes ud fra en hastighed og en retning.
For at bestemme zombiens retning imod Player, fandt vi den indbyggede funktion Math.atan2(y,x):Number, som beregner vinklen fra (0,0) til (y,x). Funktionen returnerer en radian, som kan omregnes til grader med radian*180/Math.PI. Punktet som vi ønskede at finde vinklen til, var (zombieX-playerX , zombieY-PlayerY), og zombiens retning kunne altså findes ved:
Math.atan2(this.y-_player.y, this.x-_player.x)*180/Math.PI;

Zombierne ville således altid søge at bevæge sig imod players position, hvilket giver et problem idét de ofte vil "sætte sig fast" på den modsatte side af en kasse i forhold til playeren. Det virker heller ikke super "troværdigt" at zombierne altid ved nøjagtig hvor player er - uanset om de kan se ham eller ej (Overnaturlig lugtesans?). Behovet for en kunstig intelligens implementeret på zombierne er derfor nødvendig.

Dette har vi løst ved at implementere et check hver frame, som afgør hvorvidt zombierne kan se player, eller om han er skjult bag en eller flere kasser. Figuren nedenfor viser hvordan dette check forløber:



















Der checkes hver frame på hver femte pixel i en lige linje mellem zombien og player, om koordinatsættet befinder sig indenfor en af kasserne i banen. Hvis der er klart udsyn, vil zombien sætte efter Player, og hvis udsynet er blokeret, vil zombien gå tilfældigt rundt.
Vi har yderligere implementeret en "glemme-timer", som gør at zombierne vil "glemme" at de følger efter Player hvis de mister den visuelle kontakt i seks sekunder, hvorefter de igen stener rundt og kigger efter player.

Klassediagram

Som en ny ting har vi implementeret MovingObject og Zombie i vores klassediagram. Vi har jf. tidligere blog indlæg samlet alt funktionalitet for bevægelse i MovingObject, og det ses fra nedarvningen at MovingObject er superclass for Zombie og Player. Vi har endvidere tillføjet en association mellem Zombie og Level, da et level indeholder et bestemt antal zombier, afhængig af variablen currentLevel.

Zombie apocalypse

LOL

Ahab

Skydefunktion
Vi har nu ligeledes fået implementeret en skydefunktion til spilleren. Vi er blevet inspireret meget af vores tidligere Astroids projekt, og er arbejdet ud fra samme principper med, at skyde den vej spilleren vender. Player bliver sendt med som parameter i Bullet klassen. ’Check impact’ funktionen er næsten den samme, som den der findes i Player klassen. Den tjekker på x og y koordinator på kuglen, og tjekker på om den er indenfor scenen eller inden i en kasse. Hvis dette er tilfældet, så dør kuglen! Kuglen har yderligere en levetid på 1½ sekund, hvilket tjekkes op på af en timer, som kører funktionen ’timeisup’.
I controlleren tilføjes mellemrumstasten som skydefunktion til spilleren.

Kasserne på scenen

Kasseproblemet:

Vi har løst kasseproblemet ved at sætte flere tjekpunkter ind. Som det var før blev der kun tjekket for overlapninger af andre kasser i øverste venstre hjørne. Dette har vi udvidet sådan at der bliver tjekket i alle hjørner, midten og midten af alle sider på kasserne. På denne måde tjekker den alle mulige scenarier for overlapning. De mulige scenarier på nær et ses på billedet nedenfor. Tjekpunktet i midten er i tilfælde af at en mindre kasse genereres oven i en større.

Dette fungerer kodemæssigt således, at hver ny kasses position tjekkes af Level-klassen. Hvis den nye kasse overlapper en anden, tjekkes et nyt tilfældigt sted der ingen overlapninger er. Efter et succesfuldt tjek oprettes kassen på scenen.

I teorien kan dette tjek gentage sig i en uendelighed, men sandsynligheden for dette problem er så lav at, det tæt på ingen risiko udgør.

Afslutning af første iteration og planlægning for næste

Vi har i dag afsluttet første iteration uden dog helt at nå målet. Vi har ikke fundet en løsning på problemet med kasserne, der overlapper hinanden. Vi har imidlertid fået implementeret en spiller med fungerende styresystem via piltasterne. Vi har ligeledes lavet collision detection således at spilleren ikke kan gå igennem kasserne eller uden for banens sider.

Plan for næste iteration

Planen for næste iteration er at implementere en skydefunktion til vores player. Vi vil endvidere forsøge at få forskellige typer zombier ind på scenen, som ligeledes har collision detection i forhold til kasserne samt banens sider. Zombierne skal efterfølgende gerne kunne skydes til døde af spilleren.

Vi forestiller os at lave tre typer zombier, med varierende hastighed, hit points og farve.

Vi vil sideløbende med denne iteration forsøge at løse problemet med kasserne.