Spil Rapport Spil lavet i GameMaker Kevin, Mads og Thor 03-02-2011
Indholdsfortegnelse Indledning... 2 HCI... 2 Planlægning / Elementær systemudvikling... 2 Kravspecifikationer... 4 Spil beskrivelse... 5 GameMaker forklaring... 5 Implementering... 6 Brugertest... 7 1
Indledning Internettet har gennemgået en fantastisk udvikling de sidste par år, og derfor er der også kommet langt større fokus på brugervenlighed, både på hjemmesider men også i programmer og spil. Hvis brugervenligheden ikke er i top, så vil brugeren bare gå videre og finde et bedre alternativ, da der er så meget at vælge i mellem på internettet. HCI HCI står for Human Computer Interaction, oversat til dansk Menneske Maskine interaktion. Det er altså sammenspillet mellem brugeren og computeren. Det er her hvor brugervenligheden kommer ind i billedet, for her er brugervenligheden enten med til at skabe en barriere for afsenderens budskab, eller så er brugervenligheden i top, og derved får modtageren nemmer ved at forstå budskabet. Human Computer Interaction kan være altså også et sammenspil mellem hardware og software. Men i netop vores produkt vil vi ligge vægt på interaktionen mellem forbrugeren og vores spil. Vores målgruppe er gymnasie- og folkeskoleelever, og derfor så er det vigtig for vores program, at man ikke behøver at sætte sig alt for meget ind i det tekniske, hvorimod vi vil fokuserer på, at det skal være så enkelt og logisk for vores målgruppe. Planlægning / Elementær systemudvikling Først startede vi fælles i vores gruppe med at lave forskellige mindmaps dette gjorde vi for at spore os ind på hvilken slags spil vi ville lave, og hvordan vi ville lave det. Derfor startede vi altså med at brainstorme om forskellige typer spil som vi kendte til. Brainstormen kan ses herunder. Det som er markeret med fed, det blev vores endelig valg. 2
Efter at vi i gruppen havde valgt os ind på genretypen klassisk spil, så valgte vi herefter at lave endnu en brainstorm hvor her fokuserede på klassiske spil. I denne brainstorm fandt vi frem til at vi ville lave singleplayer spil, som skulle være level baseret, hvor det gælder om at undgå fjenderne og gennemføre banen. I spillet skulle der også være en scorelist hvor man selvfølgelig kunne se den tid som man havde brugt på banen. Styringen skulle være ekstrem simpel, og derfor valgte vi piltasterne. Vi lagde også i vores gruppe stor vægt på, at vi ville lave alle spillets elementer selv, grafik, spillet og selv lyden havde vi i tankerne at vi ville fremstille selv. 3
Til sidst valgte vi at lave endnu en brainstorm over vores spil elementer, hvor vi ville gøre 100 % rede for hvordan spillet skulle være opbygget. Kravspecifikationer Det skal være nemt, altså let at lære. Det skal være underholdende og udfordrende. Det skal være brugervenligt og nemt at betjene. Vi lagde vægt på disse ting, for ellers ville brugeren hurtigt finde alternativ til vores spil hvis, vores spil er for kompliceret og svært at betjene. Samme gælder hvis spillet ikke er underholdene eller udfordrende nok, og hvis det er for svært for brugeren at komme i gang med spillet, så ville personen bare lukke vores spil og hente et nyt, og derfor har vi især lagt vægt på disse 3 ting. 4
Spil beskrivelse Vi har valgt at fremstille et klassisk spil. I vores spil kaldet Mission VissenGrød gælder det om at indsamle risengrød, hvorefter man kan komme videre til det næste level. Undervejs vil man møde forhindringer fra de i alt 5 verdner, og disse forhindringer skal man så undgå for at kunne gennemføre spillet og komme tilbage til julemanden, som er bortrejst til sydpolen da nordpolen er smeltet. Vores målgruppe i spillet var at ramme gymnasie- og folkeskole elever, som har brug for et hurtigt sjovt spil i frikvarteret for at få tiden til gå. Derfor har vi valgt denne simple måde at lave spillet på, da man så hurtigt kan komme i gang med spillet. GameMaker forklaring GameMaker er et meget simpelt program til at lave spil. I GameMaker har man nogle objekter, som man giver et billede, også kaldet sprite i GameMaker. Derefter giver man dette objekt en række indstillinger og events. Disse indstillinger på objekterne bestemmer, hvordan de forskellige objekter opføre sig. Når man så indsætter objekterne i et room. Så kan man få en sprite vha. et objekt til at bevæge sig, ved hjælp af disse events. De forskellige rooms er spillets forskellige universer og baner. Her kan man indstille banens bagrund og størrelse, samt hvilke sprites og objekter som skal indgå Alt dette tilsammen danner et meget simpelt spil, der kan spiller, når man har debugget det, hvilket bygger spillet. Til sidst exportes spillet så til en.exe fil, så alle kan spille spillet, selv uden GameMaker installeret. GameMaker kan downloades her http://www.yoyogames.com/make 5
Implementering For at kunne overskue opgaven, så valgte vi at dele os op hver for sig i gruppen. Én person stod for alt det grafiske, en anden stod for selve programmeringen af spillet, og den sidst stod så for teorien. Vi har valgt at programmere vores spil i GameMaker, og her startede vi alle 3 med at gennemgå den indbyggede tutorial, for at få et indblik i hvilke muligheder GameMaker gav os, og derved kunne vi så alle 3 hjælpe hinanden med programmeringen, men der var stadig kun én som var ansvarlig. Derefter startede vi så med selve implementeringen af spillet. Alle vores grafiske materialer blev implementeret i spillet og spillet begyndte stille og roligt at tage form. Vi startede først med at sætte alle vores sprites ind, derefter sat vi alle de dertilhørende objekter til, hvor efter vi tilføjede en masse indstillinger, altså events. Når disse events var tilpasset, så lavede vi vores rooms, og satte derefter objekterne ind. Derefter testede vi så spillet stille og roligt, vi startede med, at sætte de kun nødvendige ting ind, altså risengrød, wall og nissen, hvor vi så kunne få det til at fungere 100 %, og derefter så tilføjede vi så flere og flere ting til vores spil. Så på den måde testede vi hele tiden under vores implementering spillet, for at sikre os at alt var 100 % i orden. 6
Brugertest Vores plan var at vi hurtigst muligt i vores implementering ville lave nogle brugertest. Men da vi kom sent i gang med implementeringen af det endelige spil, så kunne vi desværre ikke nå at teste programmet mere end 2 gange. I den første test valgte vi at give vores spil til testpersonen uden at sige noget om hvad personen kunne forvente eller hvordan spillet virkede. Dette gjorde vi for at gøre det så realistisk som muligt, hvis nu personen selv have hentet det på nettet. Da personen så have testet vores spil, så valgte vi først at få ren feedback fra testpersonen, vi spurgte altså ikke ind til nogen elementer i spillet el.lign. Da vi så havde fået denne feedback fra testpersonen, så valgte vi derefter at sende et vurderingsskema som testpersonen derefter skulle udfylde. Vi valgte at bruge en person fra klassen til at vurdere vores spil, da personen passede godt på vores målgruppe, nemlig folkeskole- og gymnasieelever. Skemaet så således ud: Krav til: Beskrivelse af selve kravet: Beta #1 Endelig Jo højere jo bedre Funktionalitet Fungere programmet godt? 3 4 Brugervenlighed Er det nemt eller svært at styre? Hvor højere tal er sværere 2 2 Udfordring Er det udfordrende? 3 4 Underholdene Er spillet underholdende? 3 4 Pointsum: 11 14 Vi tog selvfølgelig denne feedback til eftertanke, og vi gjorde bl.a. spillet langt mere ufordrende ved at tilføje flere fjender, samt gøre dem hurtigere. Derved blev vores spil også mere underholdende end før. Funktionaliteten, den forbedrede vi ved at tilføje en start menu og slut menu. 7