Computerspil kom/it Elever: Nicky Lund, Lukas H. Christophersen, Oliver K. Sewohl, Peter S. Salomonsen, Sebastian S. Sørensen og Ludvig V. K. G. Sørensen Lærer: Karl Bjarnason Skole: HTX Roskilde Klasse: 1.6 Fag: Kom/it Dato: 18/3 2016 Side 1 af 10
Indledning til projektet Formål Formålet med denne opgave er at eksperimentere med at lave et computerspil. Vi fik til mulighed at vælge en række forskellige programmer til at lave spillet, programmer såsom Gamemaker, Scratch, Etoys og Unity. Vi valgte GameMaker da vi syntes at det var det mest spændende program, og det program vi havde mest lyst til at lære om. Vi følte også at dette program var egnet bedst som udviklingsmiljø til det spil vi ville lave. Problemstilling Mange yngre børn mangler koncentration og motivation, til at begynde på at lære matematik, og vil gerne have et kreativt hjælpemiddel til at lære. Målgruppe definition Vores målgruppe er børn fra 6 10 års alderen, hovedsageligt målrettet mod begge køn, men muligvis mere mod drenge. vores målgruppe kommer til at blive målrettet mod flere forskellige etniciteter, da produktet ikke indebærer nogen former for sprog, men kun tal og regnestykker. Budskabet Vi vil gerne hjælpe børn med at lære matematik, på en ny, kreativ og sjov måde. Mediet Mediet er er en form for mindre computerspil eller telefon spil, med et læremæssigt formål. produktets effekt Effekten af produktet er at lære mindre børn at regne ved at der kommer nogle regnestykker som personen der spiller spillet skal løse, og så skyde det rigtige resultat. Formålet med effekten Formålet med effekten er at lære børnene at regne både uden for skoletiden, og i skolen. det kan også være et hjælperedskab til lærere i indskolingen. Side 2 af 10
Krav til vores spil Spillet skal være muligt at spille for skolebørn i alderen 6 10 år. Spillet skal være nemt, og brugervenligt at anvende. Spillet skal kunne spilles på computer eller telefonen. Spillet skal have et læremæssigt grundlag. Spillet skal kunne bruges i samarbejde med faglig /undervisning i folkeskolen. User stories for eleverne Som en bruger på 6 10 år, skal jeg kunne navigere og anvende produktet nemt og hurtigt, så jeg kan lære matematik uden at få hjælp til navigationen. Som en bruger på 6 10 år vil jeg havde muligheden for at lære matematik, på min egen tidsplan, uden hjælp fra voksne, så jeg kan lære mig selv matematik. User stories for Lærerne Som en indskoling matematiklærer vil jeg give mine elever muligheden for at arbejde selvstændigt, med et nemt og brugervenligt brugerflade. Løsningsforslag Før vi kunne begynde at udvikle spillet, har vi brug for nogle forskellige løsningsforslag, vi fandt to forskellige: Løsningsforslag 1 Det første løsningsforslag vi tænke på, var at lave en form for matematisk labyrint spil. Ideen var at en dreng inde i spillet løb rundt i en labyrint og skulle løse matematiske problemer/regnestykker for at komme videre i labyrinten. På den måde bliver ens matematiske evner og problemløsningsevner forbedret, samtidig med at det har en underholdende effekt. Løsningsforslag 2 I vores andet løsningsforslag havde vi den samme ide med at vi gerne ville have lidt af det samme med at man så spillet oppefra, men i denne løsning skulle man være en figur som skulle rende rundt i et rum hvor der kom runder af fjender som havde en eller anden værdi. man fik så et regnestykke som man hurtigt skulle løse, for at skyde den rigtige fjende, og få point for det. Side 3 af 10
Valg af løsningsforslag Vi valgte at bruge det første løsningsforslag med labyrinten, siden vi syntes at denne løsning passede bedst til den målgruppe som vi ønskede at ramme (6 10 år). Afgrænsning Efter valget af spillet var blevet diskuteret, fandt vi frem til at løsningen med labyrinten var bedre egnet til vores målgruppe og til de mål vi ønskede at opnå. Selvom et skydespil ville være mere actionfyldt ville det tage den matematiske læring væk fra spillet. Formål med spillet formål med spillet er at 6 10 årig børn, skal blive motiveret til at lære mere. ved hjælp af det her spil, bliver det sjovere at lære. vi vil hjælpe børn som har svære ved at lære ved fx. at bare lave almindelige opgaver. så bliver det meget sjovere for dem at spille vores spil. dermed får de rigtig meget ud af det. Valg af vores værktøjer Vi har brugt en række forskellige værktøjer til at åbne de resultater vi ledte efter, her er en række af de værktøjer samt hvad det har gjort for os. GameMaker Siden vi ville bygge et matematikspil som blev set oppefra, valgte vi at bruge det program, som vi syntes var mest oplagt til det formål, altså GameMaker. GameMaker er en platform, der er udviklet af YoYoGames som er en simpel platform at lære at kende. vi havde prøvet at bruge unity som er en anden game engine der kan bruges til at lave 3D spil med. dette program var dog for komplekst til at vi kunne nå at lave et egentligt produkt på den tid som vi havde. dette var den største grund til at vi valgte gamemaker da det var simpelt at lære og bruge til at lave et 2D spil med. Om musik Side 4 af 10
Vi besluttede at lave musikken i Sonic Pi. Et program lavet af en musiker ved navn Sam Aaron. Imens vi prøvede at lære at bruge programmet, blev der arbejdet på at lave selve noderne og takten til musikken. Der blev lavet en lille melodi, med et lidt hurtigt beat, og med fire noder. Alt sammen på en bass. Melodien blev skrevet efter ti minutters kedsomhed og tyve minutter med at teste noder og sammenhænge. Derefter blev der arbejdet på at få det ind i Sonic Pi, men vi har ikke kunnet få det til at fungere. Vi kunne muligvis havde lavet en mere succesfuld indspilning på LMMS, hvilket er et andet musik programmerings program som var anbefalet til brug. En tredje mulighed var at optage musikken, imens at den blev spillet live. Det musik der blev brugt i spillet er en version som blev optaget live. Der er dog et problem ved live versionen som bør siges. Den oprindelige melodi var over to strenge på en bass, og der var ikke behov for at rykke op og ned på bassen. Men under testning af optagelse, knækkede en af strengene, så den skulle omskrives til at virke på en enkelt streng. Hvilket medførte at der kan høres en svag node i baggrunden. Og optageenheden var af dårlig kvalitet. Yderligere problemer var baggrundsstøj fra en computer og interferens på højtaleren. Musikken blev skrevet af Nicky. Tidsplan (ressourceplan) For at dele hele projektet op i mindre bider, som var nemmere at arbejde med og få hele projektet delt op i tidsperioder, brugte vi open source programmet Ganntt project. Herunder er den tidsplan vi har lavet: Side 5 af 10
Læringsproces til brug af game maker studios har vi brugt youtube til at få en lille indsigt i hvordan programmet bruges der efter har det været at prøve sig frem og spørge andre der har arbejdet med game maker studios. Teori For at kunne lave et spil af samme stil som vores, har man brug for noget basisviden i programmet GameMaker, og dets kommandoer. Man skal bruge noget tid på at lære hvordan alle elementerne i programmet spiller sammen, men når man har fået et godt greb på programmet bliver det lettere at betjene. Indledende krav fangst Testprocedurer I testen ville vi gerne teste de elementer som vi havde lavet i spillet. vi ville gerne teste spillet på en klasse for at se hvordan det virkede, men det nåede vi ikke, og derfor testede vi bare selv spillet. Overordnet design Hvad er designet? Vores spil er 2D, og foregår i en labyrint som ses fra oven. Man bevæger sig hen ad veje der føre til forskellige spørgsmål. Der er brugt tydelige farver (grøn, blå, rød og gul), som bedre appellere til børnenes fantasi og interesse i spillet. Bogstaverne i spillet er simple og tydelige så børnene kan se hvilke tal og tegn der står i de forskellige regnestykker, dermed er de sorte for så at tydeliggøre hvad der er regnestykker og scenarie. Svarmulighederne er formet som små bolde der indeholder et tal, som enten er forkert eller rigtigt i forhold til regnestykket. Hvorfor har vi valgt dette? For at tage hensyn til vores målgruppe har vi valgt et tema der er simpelt og med tydelige farver. Vi ville også gøre de veje og bevægelser man kommet til at tage Side 6 af 10
enkelte, så det ikke bliver for svært og kompliceret at spille for de børn der skal komme til at spille. Iterationer af systemudviklings aktiviteterne Første prototype Planlægning Efter at have fundet vores krav til vores spil, begyndte vi at planlægge vores første prototype. Her blev vi enige om at vores spiller (personen som man gør rundt som) skulle laves først, og derefter vores omgivelser for at få størrelsesforholdene i orden. Design Spilleren skulle være godt synlig, og nem at kunne genkende i de forskellige omgivelser. Her valgte vi at give ham gult hår og en grøn kappe, så der ville være kontrast mellem ham, vejene og svarmulighederne. I prototypen havde vi også lavet de veje som man skal bevæge sig hen ad, her var farverne gr, med en mørkegrøn hæk ude i siden. Rundt omkring vejene lavede vi gras som havde små blomster på, for at bryde den grønne farve op i andre farver. Implementering Hvordan vi satte det ind (hvilke værktøjer vi har brugt). Vi lavede en sprite som alle genstandene i spillet hedder. Den første sprite som vi lavede var vores spiller som vi tegnede op som en cirkel og derfra tegnede gult hår, en næse og en grøn kappe. Anden Iteration Hvad er det? Vi har lavet nogle vejspærringer som skulle forhindre vores spiller i at gå den forkerte retning. Dette er lavet som nogle sprites som vi satte ovenpå de veje der skulle blokeres. Hvorfor er det vigtigt? Side 7 af 10
Deres formål er at blokere de veje som ikke føre nogle veje hen. Dette er vigtigt siden at spilleren kunne gå den forkerte vej og derfor fare vild udenfor skærmen. Planlægning vi planlagde at lave disse vejspærringer for at kunne lave nogle begrænsninger/forhindringer i vores labyrint for at sørge for at der kom noget mere med i spillet og så der ikke var en masse blinde veje, eller nogle rum som simpelthen kun ville have en enkelt vej man kunne benytte sig af uden at designet kom til at være ensartet i dets design. Kontrol af krav og testprocedurer Skiltene skulle kunne opfylde de krav at skulle spærre de blinde veje, og det har de opfyldt. Design Designet på den anden iteration er det samme som på den første prototype, som vi bare havde forbedret for at få lidt mere design med i vores spil. Vi havde i den første prototype kun veje, græs og hække som var opbygget som en labyrint, uden noget andet stort set. det vi gjorde var så at designe nogle røde og hvide vejspærringer som kunne være med til at give endnu et lag på vores spil, og fungere som forhindringer i vores labyrint. Implementering Vi lavede spriten med barrieren der efter har vi lavet et objekt og gået ind under den visuelle del og sat collisen på så når den ramte playeren satte vi moment speeden til 0. Test Vi startede vores spil op og begyndte at gå mod vores vejspærringer, her skulle de så forhindre spilleren i at fortsætte og dette gjorde de. Vi prøvede også at gå mod dem fra den anden side, for at teste om begge sider at vejspærringen virkede som det skulle. Side 8 af 10
Resultatopgørelse Hvad har vi opnået? Gennem spil udviklingsprocessen har vi udover at lære at lave et spil i GameMaker, har vi undersøgt konceptet med user stories og vi har lært at beskrive dem, og se hele bruger oplevelsens fra en anden synsvinkel. Vi var tilfredse med vores spil, selvom der selvfølgelig er massere af forbedringer der kunne blive lavet i fremtiden, syntes vi at vores spil er ret godt, og vi syntes at vi har ramt vores formål ret godt. Evaluerende tanker refleksion Hvordan gik det? Vi syntes at hele processen gik forholdsvist godt, der var selvfølgelig nogle få bump igennem forløbet. Vi havde selvfølgelig nogle fejl som skulle fikses i spillet, men det var ikke noget vi ikke havde forventet, siden at det næsten er umuligt at gå igennem en spiludviklings process uden fejl. Hvad har vi lært? Vi har lært at bruge nogle forskellige værktøjer og hjælpemidler, som vi kunne bruge til at udvikle spil. Vi brugte hovedsageligt gamemaker, men vi stiftede også bekendtskab med andre programmer som unity. Vi prøvede også forskellige måder at lave musikken på, blandt andet ved hjælp af audacity med en optagelse, et program der hed bfxr som kan bruges til at lave musik. vi lærte noget af at prøve at bruge flere forskellige programmer så vi indså de store forskelle som der er mellem programmerne, samt deres styrker og svagheder. vi har lært at anvende disse værktøjer og hjælpemidler til vores fordel til at lave vores spil. Hvad var sværest i processen? Det sværeste gennem dette forløb, har klart været at bygge selve spillet. Ingen af os havde arbejdet med programmet før, så det var helt nyt for os alle sammen. Det var en sjov og udfordrende opgave at bygge spillet fra bunden, og lære et helt nyt program fra bunden af. Side 9 af 10
Konklusion I vores problemstilling skrev vi at vi ville hjælpe yngre børn der mangler koncentration og motivation, til at begynde på at lære matematik. Vi syntes at vi har lavet et produkt som kunne løse dette problem. Vores produkt er ikke perfekt, men hvis man gik igennem nogle flere iterationer og fik nogle flere brugere til at teste produktet og give noget feedback på det. Hvad kunne forbedres i fremtiden? I fremtiden er der en del fejl som der skal rettes, ud over det er der også en hel masse forskellige forskellige funktioner som bør implementeres i spillet, f.eks. kunne vi lave flere niveauer og dermed gøre labyrinten større, eller vi kunne lave flere forskellige sværhedsgrader så spillet ville være brugbart for større klasser. Bilag YouTube video link: https://www.youtube.com/watch?v=ukhrvdju0gw Side 10 af 10