Utviklingen

V-modellen

Designfaser Testfaser
Kravspesifikasjon Akseptansetesting
Systemdesign Integrasjonstesting
Programdesign Enhetstesting
Implementasjon

Klikk på ulike navn for å hoppe til det avsnittet i dokumentet.

Designfaser

Kravspesifikasjon

Oppgaven

Lag et spill inspirert av det klassiske arkade-spillet Lunar Lander (søk på "Lunar Lander Atari"YouTube). I den grad du synes det er til hjelp i planleggingen og utviklingen å lage en strukturert liste med funksjonelle krav til spillet, brukergrensesnittskisser, flytdiagram, pseudokode, handlingsdiagram og/eller testspesifikasjon, så gjør du det, og dokumenter det. Du bør uansett ta i bruk noen av disse planleggingsteknikkene for å demonstrere at du behersker noe fra den delen av læreplanen som har med planlegging å gjøre. I tillegg skal du lage selve spillet.

Merknad: Utifra oppgaven kan man gjennomføre kravspesifikasjonen, men siden dette er en eksamen så vil denne spesifikasjonen bli laget på grunnlag av oppgaveteksten, altså i det virkelige liv hadde denne designdelen blitt gjennomført i samarbeid med oppdragsgiver i en større grad.

Oprasjonelle krav:

Funksjonelle krav:


Systemdesign

Hva skal systemet/spillet gjøre?

Hvilke moduler består systemet/spillet av?

Hovedsakelig består spillet av en modul som er kode i seg selv. Utover dette så benyttes det ikke biblioteker eller tilleggspakker utenom HTML5, Javascript (ES5) og CSS

Hvordan skal dataflyten foregå i systemet/spillet?

Dataen flyter innad i app.js og vises på skjermen gjennom bruk av canvas og evt. HTML elementer

Hvordan skal brukeren samhandle med systemet/spillet?

Som nevnt i første punktet over, så skal brukeren samhandle med systemet gjennom bruk av fire knapper på tastaturet og musepekeren.

Brukergrensesnittet

Ettersom oppgaven spesifiserer at man skal ta inspirasjon i Lunar Lander av Atari så ønsker jeg å benytte noen skjermbilder fra dette spillet til å vise mine ideer om brukergrensesnittet.

Skjermbilde fra Lunar Lander Her ser vi et skjermbilde fra Lunar Lander. I spillet jeg lager ønsker jeg å ha et liknende brukergrensesnitt, men med en mer moderne følelse. Altså en annen font og en litt annerledes framvisning.

Testing av systemdesign


Programdesign

Detaljert design av systemet/spillet

Merknad: Alle klassene og metodene er nøyere beskrevet i koden ved hjelp av kommentarer og i egen dokumentasjon.

Klasser:

Se testing av klassene.

Spilløkken:

Spillet skal kjøres ved hjelp av requestAnimationFrame() som er bakgrunnen for spilløkken. Denne funksjonen kalles med en funksjon som inneholder spilløkkaen, og på slutten av spilløkken så kalles requestAnimationFrame() igjen. Slik fortsetter løkken så hurtig som mulig, uten å kjøre synkront, slik en while løkke hadde gjort. Dette gjør at selv om spilløkka aldri slutter å gå, så kan det skje eventer i javascript. Spilløkka skal gjøre fire ting som er som følger:

  1. Sjekke om det har skjedd noen eventer, og håndtere disse (altså håndtere inngangsverdier)
  2. Oppdatere alle elementer i spillet, som for eksempel månefartøyet, ved hjelp av eventuell inngangsverdier fra forrige punkt, deretter så sjekker man etter kollisjoner.
  3. Tegne alle elementer som skal tegnes på canvas.
  4. Kalle requestAnimationFrame() med seg selv som parameter.

Disse fire punktene er forklart næremere her.

  1. I spillet skal man ta inngangsverdier gjennom eventer, altså for eksempel et onclick event kan kalles når som helst under game løkken, men hvis man prøver å for eksempel endre på hastigheten til månelandere mens variablen brukes til å oppdatere hastigheten, så kan det skape problemer. Derfor samler jeg opp alle eventene som skjer hver gang løkken kjører og behandler de i starten av spilløkken. Altså er det første punktet i løkken å behandle en oppsamling av eventer som har skjedd under den forrige spilløkken.
  2. Etter at eventene er behandlet, så oppdateres alle objekter i spillet. Altså for eksempel flyttes månelanderen. I tillegg til å oppdatere objekter sjekker også denne delen av spillet for kollisjoner og oppdaterer variabler som tid og hastighet. En annen viktig del av oppdateringen er tiden fra forrige oppdatering, altså delta tid. Se klokke og tider for en nærmere forklaring. Denne delta-tid vil derfor være en parameter i alle oppdateringsfunksjoner.
  3. Når alle objektene er oppdatert så tegnes de på canvaset i den tredje delen. Spillet skal ha ulike canvaser slik at man kan velge hvilket canvas man vil tegne de på, dette gjør at man kan få en lagdeling og at man for eksempel kan få en bakgrunn som ikke overlapper med noen av spillobjektene.
  4. Nå er spilløkken ferdig, men spillet er ikke over. Derfor kaller man løkken på nytt i punkt fire, slik at spillet fortsetter å kjøre. Som nevnt over så gjøres dette ved hjelp av requestAnimationFrame().

Se testing av spilløkken.

Ulike tilstander

Spillet kan være i ulike tilstander, i den form av at man starter på menyen. Når man så starter selve spillet så begynner man å spille, og da er spillet i en annen tilstand. En lett måte å skille mellom ulike tilstander er å lage en individuell spilløkke for hver tilstand og kjøre disse istedenfor å sjekke tilstanden før hver endring i spillet. Dette gjør man ved å ha en Array med ulike tilstander spillet kan være i og i spilløkken så kaller man de tre første punktene på den nåværende tilstanden.

Siden dette er et relativt lite spill så skal jeg bruke hovedsakelig bruke 3 ulike tilstander som er som følger:

  1. "Menu" Spillet starter i denne tilstanden, det er hovedmenyen der man kan starte spillet, se på instrukser eller endre instillinger.
  2. "In-game" Her spilles selve spillet, altså det er her man prøver å lande månelanderen.
  3. "Post-game" Når spillet er over så vises denne skjermen med informasjon om poeng, tips og videre valg om hva man vil gjøre.

I tillegg til disse tre så skal jeg bruke en tilstand som heter "Test". Denne er egentlig ikke en del av sluttproduktet men under produksjon så brukes denne tilstanden til å teste ulike deler av koden for å sjekke at koden fungere slik som den er spesifisert.

Se testing av de ulike tilstandene.

Klokke og tider

Ettersom spilløkken repeteres basert på requestAnimationFrame() så kan løkken gå så fort som klienten klarer å kjøre spillet, derfor er det viktig at bevegelser skjer basert på tid og ikke basert på antall oppdateringer. Dette gjør at det er viktig å ha en klokke som holder orden på tiden.

Grunnen til at dette er viktig er fordi hvis spillet oppdateres 60 ganger i sekundet, og hver gang månelanderen oppdateres så beveger den seg en piksel. Hvis det er en klient som ikke klarer å opprettholde denne oppdateringsfrekvensen og spillet bare oppdaterers 30 ganger i sekundet, så vil også månelanderen bare flytte seg 30 piksler på et sekund istedenfor 60 piksler. Derfor ganger man forskjellen i tid med forflyttningen slik at hvis oppdateringsfrekvensen synker, så øker delta og da øker avstanden som objektet flyttes. Dermed forflytter månelanderen seg like langt uansett om spillet oppdateres 30 eller 60 ganger per sekund.

Se testing av klokka.

Justering og balansering av spillmekanikker

For at spillet skal kunne bli finjustert slik at alle mekanikkene fungerer optimalt og at det både er gøy og utfordrende, så lager jeg et objekt som heter CONST helt i starten av koden. Denne kan evt. flyttes ut til en JSON-fil. Dette objektet skal inneholde mange ulike variabler som endrer på spillet. For eksempel kan det være en variabel for tygdekraften. Dette objektet gjør at man etter å ha skrevet ferdig koden lett kan endre på mekanikkene slik at de fungerer slik man ønsker det.

Testing av programdesign

For å sørge for at spillet fungerer slik som spesifisert så er det vikitg å teste hver enkelt del av programmet som er definert i programdesignet, slik at når man setter sammen programmet så fungerer delene av koden slik som funksjoner og mekanikker.

Testing av klassene
Testing av spilløkken
Testing av de ulike tilstandene
Testing av klokka

Implementasjon

Se dokumentasjon av javascript for å få et nærmere innblikk i implementasjonen. Et viktig fokus under implementasjonen har vært å skrive kode som lett kan utvides. Et eksempel på dette er hvordan baner lastes inn til spillet. Alle banene ligger i en fil som heter maps.json og her kan man endre på banene og verdiene utenfor spillet. Når man starter spillet så leser spillmotoren av denne filen og dataene blir brukt i framstillingen av banene. Ved å bare legge til en bane med nødvendig informasjon i maps.json så er banen allerede en del av spillet.

Testfaser

Enhetstesting

Det er blitt gjennomført enhetstesting i tråd med det som ble oppgitt i Testing av programdesign. Alle testene er ikke dokumentert, og bakgrunnen for dette er at innenfor tidsperspektivet vi fikk til rådighet så fikk jeg ikke tid til å dokumentere alt av tester. Noen tester som er dokumenter er:

Integrasjonstesting

Ved hjelp av en utenforstående person har spillet blitt testet på punktene oppgitt i systemdesignet.

Akseptansetesting

Kravspesifikasjonen som ble presenter i starten av utviklingsprosessen var i hovedsak en oppgave, og utifra denne laget jeg meg en liste med krav. Punktene som er strøket ut mener jeg at jeg har utført.

Merknad: Siden akseptansetesting egentlig skal gjennomføres med klienten, så blir denne delen noe annerledes enn en ordentlig akseptansetest.

Oprasjonelle krav:

Funksjonelle krav:

Utifra tid som var til disposisjon så er jeg fornøyd med spillet jeg har produsert. Jeg ser helt klart områder som kunne vært bedre, men de delene som er lagt til så langt fungerer dugelig.

Tilbake til spillet