Computerspil. Hangman. Stefan Harding, Thomas Bork, Bertram Olsen, Nicklas Thyssen og Ulrik Larsen Roskilde Tekniske Gymnasium.

Transkript

1 Computerspil Hangman Stefan Harding, Thomas Bork, Bertram Olsen, Nicklas Thyssen og Ulrik Larsen Roskilde Tekniske Gymnasium. Kom/it c

2 Indhold Intro... 2 Indledende aktivitet... 2 Kommunikations planlægning... 2 Lowells 5 spørgsmål... 2 jan Kraghs 25 spørgsmål... 2 Resurseplanlægning for projektet... 3 Definer delopgaver... 3 Underopgaver... 3 Iterationsplanlægning... 3 Revision af Kommunikations planlægning... 3 Kravspecifikation og testspecifikation... 4 Design/implementering... 4 Afprøvning... 5 Afsluttende aktiviteter... 6 Bilag... 7 Side 1 af 8

3 Intro I dette forløb har vi arbejdet med at lave en video spil ved brug af en systems udviklingsmetode. Indledende aktivitet Kommunikations planlægning Lowells 5 spørgsmål I det indledende aktivitet har vi svaret på Lowells 5 spørgsmål og de svar vi har kommet frem til er at afsenderen er spillet, at buskabet er at man burde forbedre sin viden om sproget, modtageren er den casual bruger, mediet er spil og effekten hos modtageren som vi prøver at opnå er at forbedre deres dansk ordforåd. jan Kraghs 25 spørgsmål Vi har også svaret på nogle af jan Kraghs 25 spørgsmål, vores svar er 1. Målgruppen kan være hvem som helst som har et middel - godt ordforråd, altså teenagere og ældre. 2. Vi har det budskab med vores spil at spillerne kan øge deres ordforråd. 3. Mediet er et spil vi selv har programmeret. Spillet præsenteres via computer. 4. Vores formål med dette er at danskere skal blive bekendt med flere ord som de kan støde på i deres hverdag, for at kunne håndtere situationer bedre. 5. Formålet med effekten er at få folk til at udvide deres sprog og kunne udtrykke sig selv klarere. 6. Afsenderen starter med vores lærer som giver os opgaven og derefter os som har programmeret spillet. Efter at spillet er produceret vil det være vores afsender. 7. Produktet skal underholde brugeren og samtidig ubevidst udvide deres ordforråd imens de prøver at gætte de svære ord. 8. Vi tænkte at hvis vi lavede et ekstremt simpelt spil ville vi blive meget hurtige færdige og kunne komme i gang med vores rapport med det samme. Hvis vi brugte for meget tid og ressourcer på vores spil ville det både blive svært at forklare for de mindre erfarne målgrupper og det ville tage alt for lang tid at sende 9. Dem der spiller spilet bliver påvirket af alle andre medier som inkluderer ord. Bøger, tv, radio, internettet, skolen, tale med andre mennesker, andre spil med det samme budskab osv. Vores spil er ikke unikt i forhold til disse andre medier Side 2 af 8

4 10. Produktet er lavet før både som spil og som fysisk fællesskabsleg. Det er ikke originalt. Resurseplanlægning for projektet Definer delopgaver I dette del af det indlederne aktivitet har vi lavet en resurseplanlægning og i resurseplanlægningen har vi skullet definer delopgaverne. De delopgaver som vi har defineret er programmering af spillet, testning af spillet og dokumentation. Underopgaver I ressourceplanlægningen skulle vi også lave bestemme hvad underopgaverne til delopgaverne var. De underopgaverne til delopgaverne er: Dokumentation De delopgaver som vi har lavet til dokumentation er planlægningen af dokumentationen, skrivning af dokumentationen og opstillingen af dokumentationen. Programmering af spillet De delopgaver som vi har lavet til programmering af spillet er konstruktionen af mechanics, konstruktionen af grafikerne og debugging af spillet. Testning af spillet De delopgaver som vi har lavet til testning af spillet er finde test personer, lave testen og vurdering af resultater. Iterationsplanlægning I dette forløb havde vi ikke resurserne eller tiden til at iterate. Men her er en eksempel på en mulig iteration på vores produkt. Revision af Kommunikations planlægning Der er ikke noget revision som vi vil gøre til vores svar til Lowells 5 spørgsmål, der var også ikke nogle ændringer som vi vil lave til vores svar af jan Kraghs 25 spørgsmål. Nogle af de brugerhistorier som vi kunne have implementerede er en restart knap, valg af sprog og at ordene bliver inddelt i forskellige sværhedsgrader som man kan vælge imellem. Vi har ikke haft mulighed for at kunne implementer nye brugerhistorier da dem som testede spillet havde ikke nogle ting som de vil have tilføjet. Side 3 af 8

5 Kravspecifikation og testspecifikation De krav som vi har lavet for at implementer de valgte user storys er: At HCI (Human computer interface) skal være visuel At HCI skal være nemt at bruge af kunden At programmet skal være i stand til at vælge en tilfældig ord At kunden kan vinde og tabe spillet Den testprocedure som vi vil bruge til at teste vores implementering af user storys er at først få brugeren til at prøve vores spil 5 gange, imens brugeren spiller spillet observer vi hvad de laver og holder øje efter hvor langt tid det tager dem at lære HCIen, hvor brugervenlig vores produkt er og de ting som irriterer brugeren. Når brugeren er færdig med at spille spillet spørger vi om hvis i deres mening spillet opfyldte de krav som vi have lavet, hvad de synes var godt og dårligt og om hvor de vil stille spillet i en skala fra 1 til 10. Design/implementering Vi bruger visual python til at lave scenen. I scenen startede vi ud med at designe manden og galgen som ses til vendstre på billedet. Der efter lavede vi et array som vi satte en masse tilfældige ord ind i. Så lavede vi et for loop som køre så mange gange som ordet er lang. I loopet bliver stregerne under bogstaverne lavet. Da vi havde gjort det skulle vi havde den til at sætte de bogstaver ind som vi klikker på hvis det er i ordet. Der fandt vi en fejl at hvis man blev ved med at klikke på den samme bogstav hele tiden vandt man så vi var nød til at inden bogstavet blev sat ind på scenen skulle vi først tjekke hvis det var blevet brugt og om det var i ordet. Der efter skulle vi så finde ud af om man havde vunder eller tabt. Det gjorde vi ved hver gang den satte et bogstav ind på scenen ville den ligge en til ens points. Når ens points var samme værdig som ordet er langt vil man vinder. Derefter fik vi den til at skrive you won. Så skulle vi havde den til at finde ud af om man har vundet. Det gjorde vi ved at hver gang man klikker på et bogstav og dette ikke er i ordet vil den lægge en til dine fejl og sætte en kropsdel mere ind på figuren til venstre. Du kan se selve koden under bilag. Side 4 af 8

6 Afprøvning Prototype 1.0 Her begynder testen af vores produkt. Indtil videre har vi har stillede nogle krav til produktet som vi gerne have vil have overholdt og det lyder - Man skal kunne integrere med computeren (det vil sige man skal kunne trykke på en knap eller trykke med musen). - Man skal kunne vinde spillet - Det skal være visuelt, i form af 3d. Under testen blev alle disse krav opfyldt. Når man trykker på et bogstav kommer det op på skærmen. De lykkedes at vinde spillet og spillet skriver når man har fundet You won Det sidste krav var også opfyldt, der var en figur i 3d, bogstaverne var i 3d og hele spillet var i 3d Men selvom det alt sammen lyder meget godt, så er der en del fejl i spillet indtil videre. Når man klikker på knappen enter skriver den enter, og de sammen med backspace og esc. Produktet er færdigt i form at kravmatrixen. Og dette var testen er prototype 1.0 Side 5 af 8

7 Prototype 1.1 Produktet er der nu blevet kigget på endnu en gang og lavet er par justeringer. Produktet opfylder stadig alle kravene og nu kan man heller ikke trykker på enter, backspace osv. Ud fra testen ser produktet færdigt ud, der er ikke flere fejl og alle krav er opfyldt. Spiller er også så venligt at når man har tabt skriver den ordet færdigt for en. Afsluttende aktiviteter Vi er blevet bedre til at kode ved hjælp af Python. Vi har generelt lært at bruge systemudviklingsmetoden til at fremstille et produkt. Selvfølgelig er vi blevet bedre til at samarbejde og organisere os, så vi kunne nå deadline. Side 6 af 8

8 Bilag Bilag 1: Side 7 af 8

9 Side 8 af 8