Computerspil - Kappa

Transkript

1 Computerspil - Kappa

2 Indledende aktivitet Kommunikationsplanlægning: Ressourceplanlægning: Iterationsplanlægning Brugerhistorier Kravspecifikation og testspecifikation Krav som skal opfyldes for at passe med brugerhistorier: De krav vi havde at gøre med fra brugerhistorierne var: Testprocedure til test af krav: Design Implementering af funktionalitet Design af brugerflade Implementering Realisering af design Dokumentation af design Test Gennemførelse af testprocedurer: Dokumentation af testprocedurer: Afsluttende aktiviteter Resultatopgørelse: Registreringer af erfaringer:

3 Indledende aktivitet Kommunikationsplanlægning: Da vi har problemet at der er mange som har problemer især fordi at de finder det kedeligt at gøre. Derfor er vores mål 8 10 år, hvor at matematikken er relevant, og hvor at mange kan have svært ved at koncentrere sig om normal matematik. Vi er afsendere med stor vision inden for at matematik og regning vil være mere sjovt for unge, sådan så at stereotypen omkring at matematik er kedeligt og svært, til at det er sjovt. Vi kan sende programmet ud gennem lærere der har med 2 4. klasse at gøre, sådan så de kan få deres elever i gang med at benytte sig af vores spil. Ressourceplanlægning: Til udviklingen af spillet bruges et gratis programmeringsværktøj designet til at lave 2D spil, på en nem og ikke kompliceret måde. 4 unge arbejder gratis for at planlægge og afvikle; programmering af spillet og udarbejdning af rapport. Første 3 uger, er planlagt til brug af spiludvikling, hvorefter den resterende tid benyttes til rapport og dokumentation skrivning. Iterationsplanlægning Brugerhistorier Da første version var færdig delte vi den med nogle brugere, for at se hvad de ville synes om det. Det er for nemt var det der blev sagt mest selv af brugere yngre end målgruppen. Derfor gjorde vi spillet sværere, hvorefter vi lod brugerne prøve det igen. Men igen fik vi de samme svar, om at de kedede sig med det da det var så simpelt. Derfor tog vi et sidste hop i sværhedsgrad hvorefter vi lod dem prøve en sidste gang. Denne gang var svarene mere forskellige, og brugerne mente at de nogle gang faktisk havde udfordring ved at løse spørgsmålene. Til sidst var der nogle brugere der sagde det var kedeligt, derfor mente vi at vi skulle prøve at gemme matematikken sådan så at det ikke føltes så skoleagtigt. Kravspecifikation og testspecifikation Krav som skal opfyldes for at passe med brugerhistorier: De krav vi havde at gøre med fra brugerhistorierne var: Gør spillet sværere, men ikke for svært.

4 Gør spillet sjovt, sådan så det bliver matematik i forklædning. Testprocedure til test af krav: Vi tester om vi har har opfyldt kravene ved at give det udviklede produkt tilbage til brugerne sådan så vi kunne få deres nye mening, derved kunne de sige hvad deres nye mening var om det, hvis de stadig mente at det var kedeligt så var det tilbage til tegnebordet, hvorved vi nu kunne gentage processen igen. Design Implementering af funktionalitet Da vi bruger Scratch som er et rimeligt simpelt program at få ting til at ske i, laver vi vores baggrund ved tegne den og derefter bare at trække den hen. Vi trækker de codeblocks hen som vi skulle bruge. Vores objekter som fx chilien er såkaldte sprites der kan have deres egne codeblocks trukket hen på, fx kan chilien tale hvis vi trækker den codeblock på, men hvis vi gerne ville have den til at dreje 90 grader kunne vi gøre det ved at trække den codeblock hen. Design af brugerflade Spillet foregår sådan at en tekst popper op, hvori et matematisk spørgsmål bliver stillet. Svaret angives på svar bjælken som dukker op nederst på skærmen i takt med det tekstboksen. Eventuelt kunne vi have indsat forskellige svarmuligheder frem for at bede brugeren skrive resultatet, som kræver at at svaret angives på en speciel måde, i.e med % eller ord som år. Vi har valgt at bruge et kostume skift til at informere brugeren om svaret er korrekt eller forkert, billede demonstration kan findes på side 6. Efter svaret er blevet givet trykkes der Enter hvorefter Spriten (cartoon karakteren) skifter kostume matchende til det givne resultat.

5 Implementering Realisering af design Med scratch er der i forvejen begrænsninger, det bliver altså ikke et nyt 3d Call of Duty spil vi får lavet, end ikke et simpelt Mario er særligt nemt at opnå, derudover har vi i gruppen det man kan kalde svært begrænsede tegneegenskaber, og derfor ved vi at designet ikke kan blive noget stort. Men vi er nødt til at gøre brug af det vi har at gøre godt med og se hvad vi kan gøre, derfor falder spil ideen på et simpelt matematikspil hvor der ikke er brug for meget mere end nogle popups med tekst, og nogle simple if statements for at checke om svaret er rigtigt. Så vi får tegnet en chili der kan stille spørgsmål, der befinder sig i sit naturlige habitat, nemlig et spækbræt. Dette er simple tegninger der ikke har taget særligt meget mere end 5 minutter. Dokumentation af design Vi har et spækbræt som gør sig ud for selve scenen for vores spil, det er her det hele foregår. Ellers har vi en sprite som er vores chili, men der er 3 udgaver, en normal chili, en hvor den er hakket over til når man svarer forkert, og en hvor den er glad til når man svarer rigtigt. Normal:

6 Rigtigt svar: Forkert svar: Disse 2 anderledes billeder er med til at skabe to effekter, en hvor du er glad for at chilien også er det, og en hvor du er trist fordi chilien græder.

7 Test Gennemførelse af testprocedurer: For at teste har vi brug for nogen med så lidt bias som muligt, derfor udelukker det os selv til rigtigt mange ting, da vi vil vise lidt kærlighed mod vores spil da det er os der har lavet det. Af denne grund er vi nødt til at få andre til at kigge på det, og hvad er bedre end vores målgruppe til dette? Vi giver brugerne spillet og spørger hvad de mener der er godt og hvad de mener der er dårligt, det de siger der er godt noterer vi og sørger for at beholde, det de mener er dårligt begynder vi at fase ud sådan så at der ikke er så mange folk der har problemer med spillet. Dokumentation af testprocedurer: Vi har egentlig ikke nogen dokumentation for vores testprocedurer, da det egentlig bare har været en aktiv samtale med vores brugere, hvor vi har sørget for at de informationer de havde der var noget værd, kom ud til os. Afsluttende aktiviteter Resultatopgørelse: Vores brugere mener at vi har fundet en sjovere måde at få indlært matematik, da adskillige af dem har sagt at det var klart at foretrække i forhold til den matematik de er vant til i skolen. Af denne grund mener vi at vores resultaterne er at vores problemformulering er hjulpet væk af vores produkt, vi kan konkludere at spillet kan være med til at gøre indlæring sjovere for mange elever, men at det også er en mere kompliceret og svær metode at lave til brugerne i forhold til et stykke papir med opgaver. Registreringer af erfaringer: Vi har: lært at benytte os af gratisværktøjet Scratch lært at kommunikere med vores brugere og sørge for at deres behov er opfyldt.

8 lært at tegne flottere modeller og sørge for at selvom vi ikke er gode til at tegne at få noget simpelt der ser okay ud. lært at brugeren er vigtigere end os selv. lært at fordele opgaver og opretholde en deadline.