SCRUM-meeting

SCRUM-meeting

Næste møde forventer vi at afslutte vores kasseproblem og revurdere vores klassediagram i forhold til vores fornyede kode.

Omstrukturering i koden

Vi har fundet ud af at vi for at løse problemet med kassernes overlapninger, vil gå fra tekstbaserede kasser til objektorienterede kasser. På denne måde kan vi bruge den funktion der hedder hitTestObject, og dermed forhåbentligt få en lettere tilgang til kasseproblemet.

Keep it real
Group 3

Godmode on (kodeproblemer og løsninger)

Vi har nu fået implementeret collision detection i spillet, og har derefter påtaget os rollen som brugere og testet det at spillet generer en masse baner(nye levels), altså level-designet.
Vi har hermed fundet ud af, at de tilfældigt generede kasser kan skabe gameplaymæssige problemer, idet playeren kan blive fanget imellem kasserne når der påbegyndes en ny level. Samtidigt bliver vores level-design ikke særlig spændende hvis de tilfældigt oprettede kasser oprettes oven i hinanden i en stor klump.

Pt. har vi kun halvdelen af løsningen klar. Dette indebærer at playeren spawner i det nederste venstre hjørne, og at kasserne generes minimum playerens diameter væk fra det nederste venstre hjørne. Det andet problem vedrørende kassernes klyngedannelser, har vi endnu ikke en løsning på rent kodemæssigt, men vi går efter at få spredt kasserne fra hinanden med en minimum afstand på playerens diameter fra hinanden, så playeren kan bevæg sig imellem alle kasserne. Midlertidigt ser vores kode til at løse det sådan her ud, den er dog ikke ikke tilfredstillende endnu:

c.beginFill(Math.random()*0xFFFFFF);
xLevelArray[0] = Math.random()*50+14
yLevelArray[0] = Math.random()*50+15
widthLevelArray[0] = Math.random()*70+30
heightLevelArray[0] = Math.random()*70+30
for (var i:int = 0; i < int =" 0;"> xLevelArray[l] && xLevelArray[i] <> yLevelArray[l] && yLevelArray[i] < yLevelArray[l]+heightLevelArray[l]){yLevelArray[i] = yLevelArray[l] + heightLevelArray[l] + 20}

}
c.drawRect(xLevelArray[i], yLevelArray[i], widthLevelArray[i], heightLevelArray[i])
}

Når man rammer et hjørne har tests endvidere vist, at kassen ikke helt ved hvor den skal sende playeren ud, og ender derfor med at lade playeren gå igennem kassen.

Let there be light(GUI)

GUI

Vi er nu i gang med kodningen og indtil videre har vi formået at skabe første udkast til vores level- og player-klasse.

I vores første iteration vil vi som sagt gerne have styr på vores player- og level-klasse. Vi vil gerne strukturere vores level-design, således at level spawner en player samtidigt med at den spawner banens fysiske objekter i form af kasser, genereret tilfældigt på banen. For at være tilfredse med vores første iteration, vil vi gerne have implementeret colission detection mellem player og kasserne, samt scenens rammer. Det kodemæssige perspektiv blev taget op til diskussion i gruppen. Det matematiske aspekt ved udregningen af colission detection viste sig at være en stor mundfuld. For at påbegynde udregningen tager vi udgangspunkt i scenen som et koordinatsystem, med en x og y akse. Kassens afgrænsning kan dermed beskrives som ses på figuren på billedet:

Hvis h og w er henholdsvis højden og bredden på en tilfældig kasse, kan hjørnerne koordinatsæt findes som vist på tegningen. Playerens midtpunkt har vi som Px, Py, og han har samtidigt radius 10 i koden som vi kalder Pr. Med disse informationer kan der opsættes if-sætninger der tjekker om spillerens koordinater kollidere med kassen koordinater. Og hvis dette er tilfældet bliver spilleren skubbet ud til kanten af kassen. Vi forestiller os ligeledes at kassen skal deles op i 4 for at spillet ved hvilken side spilleren skal rykkes ud til.

Klassediagram

Vi har påbegyndt vores første iteration som beskrevet under Genesis. Vi har efter overvejelser med kun en level- og en player-klasse fundet frem til, at det bedre kan betale sig at holde styresystemet i sin egen klasse, navnlig Controller jf. princippet om lav kobling. Dette kommer sig af inspiration fra et tidligere projekt, Astroids, hvor opbygningen er den samme. Det giver endvidere logisk mening at holde controller for sig selv, da dette giver lettere mulighed for at ændre de forskellige klasser uafhængigt af hinanden. Derudover er det lettere at implementere styresystemer i senere projekter, da vi på denne måde får en skabelon for dette.

I vores klassediagram har vi indsat en Level-klasse. Under level-klassen har vi indsat variablen +ZombieAmount:Number. Det er meningen et denne variabel skal bestemme hvor mange zombier der er i banen, og dermed ligeledes at der kommer flere zombier jo højere level spilleren er i. Ydermere er ideen at vores level-klasse skal genere tilfældige baner i spillet hver gang der skiftes level. Dette har vi implementeret i vores klassediagram under disse variabler:

public var xLevelArray:Array;
public var yLevelArray:Array;
public var widthLevelArray:Array;
public var heightLevelArray:Array

Ideen med dette er at vi vil oprette 4 arrays der hver især indeholder et parameter for drawrect funktionen. Level-klassen henter så nogle tilfældige værdier fra hvert array, og drawmap tegner så ti tilfældige kasser derudfra, som så udgør banen.

Anden klasse i vores klassediagram er vores Player-klasse, herunder har vi valgt at indsætte følgende variabler:

-xCoordinate:Number

-yCoordinate:Number

+LifeCount:Number
+Name:string
+PlayerDeath()

Og disse funktioner:
+Move()
+Shoot()

Vi forestiller os herudfra at playerklassen skal indeholde styrefunktioner, i forhold til at playeren skal kunne bevæge sig, samt skyde(+Move() og +Shoot()). Derudover indeholder playeren også en LifeCount funktion(+LifeCount:Number), som holder styr på hvor mange liv playeren har tilbage, hertil forestiller vi os også funktionen PlayerDeath( +PlayerDeath()) der skal sørge for at playeren dør når han ikke har flere liv tilbage. Name funktionen(+Name:string) tænker vi skal gøre det muligt at brugeren kan give sin player et navn.

Den sidste klasse i vores klassediagram er Controller-klassen, der består af disse variabler og funktioner:
-_forward:Boolean
-_back:Boolean
-_left:Boolean
-_right:Boolean

+keyReleased()
+keyPressed()
+enterFrame()

Denne klasse er bygget op ud fra det princip at der er nogle Booleans, som bliver sat til true når der trykkes på en knap og så længe denne knap holdes inde. enterFrame() tjekker hele tiden om der trykkes på noget. Dette administreres af funktionerne keyPressed() og keyReleased(), der sørger for de rigtige værdier på vores booleans og dermed sikrer den rigtige bevægelse.

Sammenhængen mellem klasserne er som angivet på klassediagrammet. Controller-klassen står for at fortælle Player-klassen hvilke x- og y-koordinater spilleren skal have i hvert frame.

Level sørger for at få Player ind på scenen.

Domain model

Nedenfor ses vores domænemodel, der viser den forløbelige arkitektur af vores spil.

Vi har Player med et navn, hp og et x-antal liv. Han kan blive opgraderet via powerups.

Både powerups og player befinder sig i det pågældende level, som endvidere bestemmer antallet af zombier, samt det antal point, som gives pr. nedlagte fjende. Zombierne varierer i sværhedsgrad jf. deres hp og fart.

Vi har valgt at balancere sværhedsgraden vha. antallet af zombier pr. level istedet for sværere enkelte zombier.

Glossary:

NPC:

Non player character (computerstyret karakter). Disse kan besidde en vis form for kunstig intelligens, herunder evnen til at forfølge spilleren.

HP:

Engelsk forkortelse for hit points, som er en betegnelse for, hvor meget liv man har tilbage.

Zombie-shooter:

Betegnelsen for et skydespil, der går ud på at skyde zombier

Kollision:

- Eller kollision detection er et element i spillet, der forhindrer både spilleren og fjenderne i at gå igennem banens rammer og forhindringer.

Powerups:

En genstand spilleren kan samle op for derved at forbedre sine egenskaber.

Genesis

Efter at have diskuteret frem og tilbage om rammerne for vores spil, har vi valgt en zombie-shooter. Helten i spillet er udstyret med en skyder og skal bekæmpe horder bestående af 3 forskellige typer zombier, der varierer i sværhedsgrad i forhold til fart og hp.

Der er endvidere 3 forskellige powerups, hvor vi tænker henholdsvis momentær udødelighed, point og bedre våben.

Spillet indeholder levels, der slutter når alle zombierne er døde. Næste level starter derefter med flere zombier end den foregående.

I foreliggende use case ses det centrale element i spillet, tilintetgørelsen af en zombie. Brugeren trykker på en ikke defineret knap, der udløser et skud fra et ikke defineret våben. Hvis dette skud rammer zombien mister den x ud af y antal hit points og dør når y rammer 0, hvorefter spilleren bliver belønnet med point.

Vi forestiller os flere iterationer, som hver især implementerer enkelte nye elementer til spillet:

-scenen

-Spilleren med styresystem

-Kollision på spilleren således at han ikke kan gå uden for scenen eller gå igennem de kasser, der er på den

-Zombieimplementering

I første omgang skal vi bare kunne få en enkelt zombie ind på scenen og førsøge at få den til at forfølge spilleren. Herefter oprettes de andre zombier.

-Skydesystem

-Powerups

Hver iteration vil indholde tests og efterfølgende diskussion i forhold til eventuelle ændringer.

I første iteration, som vi afslutter d. 29. april, forsøger vi at få lavet spillets UI, samt en funktionel spiller, der kan styres rundt på scenen.

Opgavevalg

Vi har valgt at beskæftige os med opgave 1: Computerspil i vores eksamensprojekt.

Grunden til dette valg er, at denne opgave lægger mest op til en kreativ proces, idet opgavebeskrivelsen er mindre fastlåst end de to andre. Vi påbegynder nu inceptionsfacen... so stay tuned for more action! Keep it real!

Gruppen består af:
Anders Lassen
Matti Bugge
Klaus Wrensted Jensen
Martin Bach Kristensen