Daniel Kaasing Roskilde Tekniske Gymnasium Programmeringsjournal. Lavet af Daniel Kaasing. Lærer: Karl G Bjarnason

Transkript

1 Programmeringsjournal Lavet af Daniel Kaasing Lærer: Karl G Bjarnason 1

2 "Jeg bekræfter herved med min underskrift, at opgavebesvarelsen er udarbejdet af mig. Jeg har ikke anvendt tidligere bedømt arbejde uden henvisning hertil, og opgavebesvarelsen er udfærdiget uden anvendelse af uretmæssig hjælp og uden brug af hjælpemidler, der ikke har været tilladt under prøven." underskrift 2

3 Indhold Indledning 4 Problemformulering 4 Behov 4 Krav 5 Værktøjer 5 Produktionsfase 7 Det færdige produkt 12 Mulige opgraderinger 12 Konklusion 13 3

4 Indledning Skolen kan være kedelig nogen gange. Det er en holdning som mange børn, inklusiv undertegnede, havde da jeg gik i folkeskole, og mange børn stadig har. Jeg har personligt oplevet mindst 50 børn der talte indbyrdes om hvordan skolen var kedelig og de glædede sig til at komme hjem og spille PlayStation eller Xbox. Dette kan enten blive behandle som et stort problem, eller det kan behandles som en udfordring. Hvis der er så mange børn, der synes at gå i skole er kedeligt, er det så ikke skolen der gør noget forkert? En nem måde at gøre skolen mere underholdende for børn er ved at tage de ting som de godt kan lide, og gøre dem undervisende. På denne måde bliver det nemmere at engagere børn og derved nemmere at undervise dem. Dette kan gøres ved at udvikle spil der er undervisende. Men de findes jo allerede. Eller gør de? Et eksempel på et lærerigt spil er Alf og alfabetet, hvilket er et spil hvor en alf lærer dig om det danske sprog. Det eneste problem det spil har, er at det er kedeligere end at stirre ind i væggen. Det er et spil med sværhedsgrad der passer til 7- årige med spilstil der passer til 3-årige. Spillene der skal laves til børn, der ikke synes skolen er sjov, skal rent faktisk være sjove. Ellers er det bare mere skole, som ikke er sjov, i stedet for at være en pause fra det ikke sjove skoleliv. Det er det dette projekt skal handle om. Problemformulering Det problem som dette projekt skal løse er, at computerspil der er lavet specifikt for at undervise børn i skolefag, for det meste ikke er fokuseret på at være spil, men mere fokuseret på at være undervisende. Problemet med dette er at det for det meste fjerner al den underholdningsværdi som spillet får ved at være et spil. For det meste er undervisningsspil sat op på en måde hvor spilleren skal klikke på ting, hvilket kan være underholdene, men desværre blive denne spiltype også kedelig hurtigere end andre spiltyper på grund af at det er svært at have stor variation i spillet. Behov Jeg var nede på en folkeskole tæt på hvor jeg bor for at spørge lærerne om hvor vidt de synes at der var brug for et program der støttede børns læring imens det var underholdene så børnene ikke ville blive trætte af at sidde og lære noget, eller om de synes at der ikke var nogle problemer med at holde eleverne engageret. 4

5 De fleste af lærerne sagde at de havde nogle elever, der godt kunne trænge til lidt ekstra læring, så de derfor kunne bruge programmet derhjemme, men at det også kunne være en god idé at bruge et underholdende og undervisende spil til når lærerne ikke kunne være der og en vikar ville kunne bruge det til i det mindste at undervise eleverne. Lærerne havde erfaret at når eleverne havde en vikar, blev der for det meste ikke lavet noget fagligt. Krav Ud fra de behov som er beskrevet, kan man opstille nogle krav som undervisningsspillet skal opfylde for at programmet er effektivt. - Det skal være underholdende - Det skal være undervisende - Det skal være nemt at komme i gang med Værktøj Det værktøj som blev brugt til kreationen af dette produkt, er GameMaker: Studio. GameMaker: Studio er et program, der hovedsagligt bliver brugt til at lave computerspil. GameMaker: Studio er designet for nemt at lade brugeren udvikle computerspil uden at behøve at 5

6 lære de mere komplekse kodesprog som C++ og JavaScript ved at bruge et drag and drop system til at tilføje funktioner til de objekter man bruger. 1 Kode Selvom GameMaker: Studio bruger Drag and Drop, bliver man stadigvæk nødt til at kode en smule, fordi elementerne man kan trække ind på objekterne er en smule primitive, og for det meste kun én linje kode for eksempel er det samme som: game_restart(); Selvom GameMaker: Studio bruger kode, bruger det et sprog der hedder GML, eller Game Maker Language, som er et kodesprog, der som regel er en del langsommere end de mere kompilerede kodesprog som C++ og Delphi. 2 1 "Drag-and-drop Icons to GameMaker Language Reference" besøgt Ford, Jerry (2009). Getting Started with Game Maker. Cengage Learning. s

7 Produktionsfase Produktionen af produktet startede jeg lavede den figur der skal bevæge sig i spillet. Når man laver en figur skal man igennem to trin. Først laver man figurens udseende, eller sprite, hvorefter man laver figurens substans, eller objekt. Objektet er den del af figuren man tildeler egenskaber samt udseendet som man fremstillede tidligere. Derudover skal der også laves solide blokke som figuren kan bevæge sig rundt på. fordi alt der har noget at lave disse blokke og parent. En parent er derimod kun eksisterer objekterne de er parent Disse blokke skal ikke have nogen begivenheder, med dem at gøre, bliver fra figurens side. Ud over give dem et udseende, bliver de også givet en et objekt, der ikke har nogen fysisk form, men for at have værdier og passere dem videre til til. I dette tilfælde bruges en parent sådan så al figurens kode kan henvise til den og den så kan give sine værdier videre til flere forskellige parent, så ville man slags blokke. Hvis der ikke havde været en blive nødt til at inkludere alle de blokke som skal interageres med i koden, hvilket ikke er hensigtsmæssigt, da det hurtigt ville komme til at være mange variabler man skulle skrive til selv en simpel linje kode. Alle objekter skal bruge en sprite for at kunne være synlige inde i spillet. Parents er også objekter, men har ikke nogen sprite, fordi det ikke er meningen at de skal ses. Her står spr for sprite, og obj for objekt Derefter handlede det om at give figuren egenskaber, så den kan interagere med verden omkring den. Man kan give ens figur egenskaber ved at bruge GameMaker: Studios drag and drop system, ved at vælge en begivenhed som for eksempel: Når man trykker r. 7

8 I dette tilfælde er der valgt at når der bliver trykket r på tastaturet, genstarter spillet, hvilket gør så det er nemt og hurtigt at komme tilbage til starten og prøve igen. En anden egenskab som det er vigtigt at have på en figur i et platformspil er hvad der sker når man skal bevæge sig. Dette er en smule for komplekst til at man bare kan trække egenskaberne ind i en begivenhed, så her skulle der skrives en smule kode. Den første del af koden er et fænomen som ofte bliver brugt af kodere, fordi at det kan være irriterende at skrive hele koden for noget hver gang det skal stå der. Især hvis det er noget som man skal bruge meget. Herover kan man se hvordan koden for at tjekke efter om tastaturet bliver trykket ned er blevet forkortet så det er nemmere at skrive ind senere i koden. Den næste del af koden handler om bevægelse. En vigtig del af et platformspil er bevægelse fra platform til platform, så det er vigtigt at hastigheden ikke er for stor eller lille. Derudover skal man også sørge for at figuren ikke forbliver statisk, når man skifter retning. Denne del af koden fortæller hvad der sker når man trykker på højre og venstre piletast. Som man kan se bliver den forkortede version af inputtet fra oven over brugt i stedet for at bruge hele den lange kode hver gang. Værdien hsp står for horizontal speed. Det er defineret længere nede. Den øverste del af koden beskriver at, hvis man trykker og/eller holder venstre piletast nede, bevæger 8

9 figuren sig med en hastighed på -4 pixels per frame. Spillet kører med 30 billeder i sekundet, hvilket betyder, at figuren bevæger sig 120 pixels i sekundet. Grunden til at der står -4 er at man skal forestille sig at banen er et koordinatsystem. Når man skal bevæge sig venstre i et koordinatsystem skal man bevæge sig baglens ned af x-aksen. Samtidigt skal man også sørge for, at hvis figuren har en form eller sprite, der ikke vender begge veje på samme tid, så skal man vende figuren når man drejer den vej, den ikke vender. Dette bruges koden image_xscale til. Denne linje koden fortæller hvilken ved hen ad x-aksen figuren skal kigge. Med denne figur, som allerede vender mod højre skal man bruge image_xscale = -1 fordi det vender figuren om horisontalt, imens image_xscale = 1 vender billedet tilbage til sin originale position. Det er desuden vigtigt at pointere, at man skal have sat det punkt hvor figurens start dette virker hensigtsmæssigt. Under koden der får sig mod venstre, bruger man samme kode, bare er til midten for at figuren til at bevæge uden minusserne til at bevæge sig mod højre med. Efter koden for at bevæge sig mod højre og venstre er der koden for at sprinte mod højre og venstre. Som kan ses på billedet, er koden ikke meget anderledes end, den kode der bliver brugt til højre og venstre bevægelse. De eneste reelle forskelle er at i koden for at sprinte bliver der benyttet && som betyder og. Det vil sige at det som dette stykke kode betyder er, at hvis man holder shift og højre - eller venstre piletast nede bevæger man sig med højere hastighed i den retning man holder nede. I dette tilfælde er det 180 pixels i sekundet. Derefter kom der et problem som ikke var forudset. Når der blev trykket på en knap inde i spillet bevægede figuren sig i den retning der blev trykket på indtil der blev trykket på en anden retning, eller figuren løb ind i noget. Det blev mit fokus at lave en spike solution til dette problem da det 9

10 gjorde så en af de store dele af et platformspil, evnen til at stoppe, ikke var en funktionalitet spillet indeholdte. Løsningen på problemet blev dette stykke kode. Det dette stykke kode gør, er at det bestemmer at hvis begge - eller ingen piletaster bliver holdt inde så er hastigheden hen ad x-aksen lig med 0. Derefter skulle evnen til at få figuren til at hoppe tilføjes. Dette skete med denne kode. Denne del af koden tjekker først om figuren står på gulvet ved hjælp af en variabel som bliver beskrevet senere i koden (grounded). Hvis programmet tjekker og finder ud af at figuren står på gulvet, giver det figuren en hastighed på 210 pixels i sekundet opad, men den hastighed bliver stoppet efter lidt tid af en variabel, der i dette program er blevet kaldt grav. Det som den nederste del af koden for hop siger, vsp += grav;, gør sådan så den opadgående hastighed bliver 0,5 pixels per frame langsommere, hver frame, hvilket betyder at hastigheden i løbet af 14 frames, eller lige under et halvt sekund, har mistet al sin fart og er på vej ned igen. Dette stykke kode gør dog også sådan at, jo længere tid figuren falder, jo hurtigere falder den. Uendeligt. Det er her koden begynder at blive mere kompleks. Det dette stykke kode gør, er at tjekke efter gulvet og derefter fortæller det om vi står på gulvet, eller om der stadig er tid. Det der er specielt ved denne kode, er at i stedet for at tjekke om der er gulv pixlen under figuren, tjekker den om figuren vil kollidere med gulvet næste gang den bevæger sig én frame. Dette betyder at hvis figuren bevæger dig nedad med 6 pixels per frame, så vil den tjekke 6 pixels under sig, og hvis der ikke er gulv under, så vil den bare tjekke igen næste frame, men hvis der er gulv inden for de 6 pixels, vil figuren sænke hastigheden så den kun falder med 1 pixel per frame, sådan så der ikke er nogen risiko for at figuren kommer til at overlappe 10

11 med gulvet eller sidde fast i det. Koden siger også at så længe der er en pixel fri under figuren, vil den blive ved med at falde. Det er også denne kode der fortæller koden for hoppet, om figuren står på jorden. Den næste del af koden er en horisontal version af den vertikale kollisionskode oven over. Den eneste forskel der er mellem den ovenstående kode og denne, er at i stedet for kun at tjekke én vej så tjekker denne kode både højre og venstre. Det er det sign(hsp) er til for. Det som den del af koden gør er at den finder ud af om figuren bevæger sig i en positiv eller negativ retning og giver hhv. 1 eller -1 som værdi. Den sidste del af bevægelseskoden er. Denne del af koden er den der fortæller at vsp og hsp rent faktisk er værdier i koden de er blevet brugt i, og ikke bare volapyk som programmet ikke kan forstå. De 2 linjer betyder at hsp og vsp er ændringer der skér på hhv. x-aksen og y-aksen og derved får de to linjer kode resten af koden til at fungere. Ud over koden der bliver brugt for at få figuren til at gå er der også en smule kode der bliver genereret sammen med figuren. Denne kode giver figuren værdier, der er i spil før man disse variabler bliver ændret begynder at bevæge den. Alle sekundet du begynder at bevæge på figuren. Det er også derfor der ikke er specielt komplekse koder ved create -begivenheden. 11

12 Det færdige produkt Det færdige projekt er et platformspil hvor det gælder om at komme op til toppen af banen ved brug af logik. Der er 15 blokke med tal på. 5 af dem kan man ikke stå på uden at falde igennem dem. Det kan godt virke som en nem opgave, men det er fordi at det første bane i et spil der potentielt kunne blive massivt. Indtil videre hjælper dette spil spilleren med at få greb om 3-tabellen, hvilket er en af de essentielle ting at kunne for at kunne blive god til matematik. Selvom spillet ikke er langt og har flere baner, viser det en version af hvordan man kunne lave undervisningsspil for at gøre dem mere underholdende. Mulige opgraderinger Det er åbenlyst at spillet godt kunne bruge nogle opgraderinger, hvis det skulle være et fuldt spil, der potentielt kunne sælges til børn. Først ville det være en fordel at gøre figurens bund en smule mindre for at skabe en smule mere præcisionskrævende gameplay. En anden opgradering som spillet også mangler, er flere baner med stigende sværhedsgrad, flere udfordringer, som for eksempel modstandere eller lava som dræber når man falder ned i det. Spillet kunne også bruge en del bedre design, hvilket kunne gøre så det var mere attraktivt og dermed, at børn ville gå mere åbensindet i gang med at spille det. Dette inkluderer at lave en lille forklaring i starten af spillet, der fortæller én hvad knapperne gør, og hvad pointen med spillet er. 12

13 Konklusion Konkluderende er produktet der er blevet fremstillet i dette projekt, ikke blevet helt færdigt, men det har potentiale til at blive en god måde at undervise børn på. Indtil videre er det eneste af kravene som produktet opfylder at det er nemt at gå i gang. Det er dog ikke svært at se, hvordan produktet potentielt kunne udfolde sig og blive til en rollemodel for andre mennesker, der laver undervisende spil. Den vigtigste del af spillet er underholdningsværdien. I denne kategori har spillet ikke svært ved at komme langt. Det kræver bare at der bliver arbejdet videre på det. Det som ultimativt lykkedes med dette projekt er idéen. Nu handler det bare om at udfolde spillet. 13