Informationsteknologi Ligningespillet Nicklas Jacobsen og Jonas Christoffersen
Indholdsfortegnelse Problembeskrivelse i korte rids... 3 Kommunikationsplanlægning... 3 Jan Krag Jacobsens 25 spørgsmål... 3 Udviklingsovervejelser... 6 Udviklingsteknologier... 6 Clientside teknologivalg... 6 Serverside teknologivalg... 7 Produktdesign... 7 Overordnet design... 7 Brugergrænseflade... 8 Gennemgang af spilforløb... 8 Overordnet tekniske forløb mellem server og klient... 9 Implementering... 10 Implementering af serverside koden... 10 Version 1... 10 Version 2... 11 Implementeringen af clientside kode... 13 InitStudent... 14 InitGame()... 15 rungame()... 16 animateequation()... 18 sendresult()... 20 Test af produkt... 20 Revidering af produktet... 21 Retning af fejl med generede ligninger... 21 Konklusion... 22 Bilag... 23 Krav specifikationer... 23 Test Specifikationer... 23
Problembeskrivelse i korte rids I dette projekt vil vi lave et produkt, som har til formål at hjælpe folkeskoleelever med at lære at løse simple ligninger. Da vi mener at mange børn/unge muligvis lære bedre via spil og leg, har vi valgt programmere et spil som skal give børn/unge mulighed for at lege sig til at lære at løse simple ligninger. Kommunikationsplanlægning For at definere vores målgruppe og planlægge kommunikationen dertil, har vi valgt at bruge Jan Krag Jacobsens 25 spørgsmål til kommunikationsplanlægning. Jan Krag Jacobsens 25 spørgsmål 1. Hvem er målgruppen? a. Vores målgruppe er 7. Til 9. klasses elever, som har svært ved at lære matematik på traditionel vis. 2. Hvad er budskabet? a. Budskabet er praktiske øvelser i at løse simple (førstegradsligninger), på en overskuelig og simpel måde. 3. Hvad er mediet? a. Mediet er et web computerspil, forstået på den måde at spillet skal kunne køres i en browser. 4. Hvilken effekt skal produktet have hos målgruppen? a. Målgruppen skal via brug af produktet få øvelse i at løse ligninger i matematik. 5. Hvad er formålet med effekten hos målgruppen? a. Formålet er at de elever som normalt ikke får øvelse i ligningløsning, vil få det. Og derudover forhåbentlig få en generel bedre forståelse for matematik. 6. Hvem er afsender?
a. Det er vi. Men derudover, hvis produktet (og metoden med at lære igennem leg) blev taget i brug, være hele vores uddannelsessektor og samfund. 7. Hvilken effekt skal produktet have hos afsenderen? a. Hvis vi antager det er hele samfundet som er afsenderen, er hensigten at samfundet får færre mennesker som tabes på gulvet under den grundlæggende uddannelse. 8. Hvad er formålet med effekten hos afsenderen? a. Ved at sørger for at mindske gruppen som tabes på gulvet under den grundlæggende uddannelse (eller nogen af de andre uddannelse), kan samfundet spare mange penge, da disse mennesker ikke skal hjælpes i lige så høj grad af staten. Derudover set med humanitær øjne, vil det forhåbentlig forhøje levestandarden hos de mennesker som programmet vil hjælpe igennem uddannelsen, hvilke vi som velfærdsstat er interesseret i. 9. Hvordan påvirkes målgruppen ellers med lignende budskaber? a. Som vi kan se det bliver de kun påvirket af den undervisning som de får i skolen. Men hvis dette ikke har en direkte positiv påvirkning (forstået på den måde at de lære emnet) på dem, vil det muligvis resultere i en negativ påvirkning. Denne negative påvirkning kan være at de bliver frustreret og mister modet til at lære matematik, eller i værste tilfælde måske mister modet helt til at lære noget i skolen overhovedet. 10. Er produktet lavet før? a. Det tror vi ikke, vi har i hvert fald ikke selv støt på det eller hørt om det.. 11. Hvor, hvornår og hvordan skal målgruppen opleve produktet? a. Det vil være smart at introducere spillet for eleverne når de har haft grundlæggende undervisning i ligning løsning i matematik. Dette skulle ske i skolen, men spillet skal også kunne tages i brug af eleverne derhjemme. Produktet skal virke som en mindre tør måde at lære matematik på, og helst direkte være sjovt.
12. Hvordan skal produktet distribueres? a. Da spillet skal være et web spil, er distributionen meget nem. Spillet kan ligge på en af statens servere hvor man altid kan tilgå det ved at klikke sig ind på en hjemmeside. 13. Hvilke genrer skal bruges? a. Spil genren. 14. Hvilke fortællemåder skal bruges? a. Da der ikke direkte er en historie giver dette spørgsmål ikke mening at besvare. 15. Hvilke færdigheder skal producenten have? a. Medium kendskab til clientside kode (f. eks. javascript) og en form for serverside kode (php, asp e.l.) 16. Hvilken viden skal producenten have? a. Viden om hvordan man løser ligninger b. Niveauet for målgruppens matematiske evner. 17. Hvor meget skal der tages med? a. Dette spørgsmål giver ikke mening i denne sammenhæng. 18. Hvilket apparatur er nødvendigt? a. En internetforbindelse og en computer med browser. 19. Hvad må produktet koste? a. Det er svært at vurdere, det kommer i høj grad an på om man kan overbevise uddannelsessektoren at produktet vil være en hjælp. Hvis man kan det, vil det være muligt at sætte en rimelig høj pris per licens per skole/kommune. 20. Hvilke juridiske problemer kan opstå? a. Så vidt vi kan se, er der ikke nogle juridiske problemer. 21. Hvilke etiske problemer kan opstå? a. Hvis der stadig eksistere lære eller lgn. som mener at skole ikke må være sjovt, og derved at læring ikke skal forgå igennem leg, kunne dette være et problem. Dog mener vi ikke at det er et særlig seriøst problem. 22. Hvad skal produktet hedde? a. NemMat (Nem matematik)
23. Hvordan ser tidsplanen ud? 24. Hvordan laver man nemmest produktet? 25. Hvordan skal produktet afprøves? De sidste tre spørgsmål bliver besvaret senere i rapporten. Udviklingsovervejelser Udviklingsteknologier Da spillet skal kunne køres i en browser (helst alle browsere), begrænser dette allerede mange teknologier. Da alle webapplikationer har en serverside del (den del der køre på serveren) og en clientside del (den del som køre på brugerens computer). Kan teknologierne som vi skal bruge, deles op i to kategorier serverside teknologier og clientsite teknologier. Clientside teknologivalg Det er efterhånden rimelig indskrænket hvilke teknologier der kan bruges på clientside. De to typer af teknologier der er tilgængelige er script kodning eller kodning til en lukket platform såsom Flash eller Microsoft Silverlight. Af disse to kategorier har vi valgt at det skal være en form for script kodning som bliver fortolket af browseren. Grunden til at vi har valgt at bygge det på en form for scriptkodning er af tre grunde: 1. Vi har ikke særlig meget erfaring inde for de andre platforme, 2. af etiske årsager er vi ikke særlig begejstret for at udvikle til en lukket platform og 3. ved at bruge scriptkodning er det nemmere at gøre det platformsuafhængigt. Inde for scriptkodning er der efterhånden kun en reel valgmulighed, som er javascript. Der findes andre såsom vb-script, men disse bliver ikke brugt i særlig høj grad mere, hvilke betyder at mange browsere har ringe eller slet ingen support af dem. Vi har derfor valgt at bruge javascript til at programmere clientside koden med.
For at give noget visuelt til brugeren skal der selvfølgelig bruges noget html som browseren kan fortolke og vise. Men da der reelt ikke skal være noget udover spillet på det site vi vil lave, har vi valgt at alle elementer i body delen af html dokumentet, skal blive generet via javascript med DOM teknologien, så vi har styr på de elementer der bliver generet. Serverside teknologivalg Modsat clientside teknologierne er serverside teknologierne bestemt ikke blevet indskrænket her på det sidste, tværtimod. Der er rigtig mange teknologier der kan tages i brug, her kan f. eks. nævnes; ruby, ruby on rail, asp, asp.net, php, perl, cgi (hvor der yderligere mange programmeringssprog) og mange andre. Dog er vi her begrænset af hvilke former for teknologier vi kan bruge på skolens servere, til at udvikle koden. Da skolen servere køre *nix er alle microsoft teknologier (asp og asp.net) om end ikke umulige, men ikke særlig indlysende at bruge. Vi har valgt at bruge php, ikke fordi det er det stærkeste sprog eller fordi det er bedst, men fordi vi mener det passer bedst til den opgave som vi skal bruge det til. Da vi serverside delen ikke skal udføre særlig kompliceret ting, er php et udmærket sprog da man kan få det til at gøre meget med relative simple og korte linjer kode. Produktdesign Overordnet design Overordnet skal spillet give spilleren mulighed for at løse en ligning og give sit svar. Derudover vil vi gerne give en evt. lære mulighed for at holde statistik på om eleverne bliver bedre. Dette skal gøres ved at spillernes svar gemmes et sted på serveren således at det muligt at gå tilbage og se spillernes/elevernes resultater.
Brugergrænseflade For at give spilleren mulighed for de ønskede ting, skal spilleren have en brugergrænseflade som han kan interagere med. Men inden selve grænsefladen skal defineres er det vigtigt at huske på at vi gerne vil differentier i mellem de forskellige spillere for at kunne gemme deres svar, til evt. senere analyse. For at gøre dette skal spilleren tvinges til at identificere ham/hende selv. For at gøre dette skal spilleren indtaste sit navn e.l. for at komme videre. Når spilleren har identificeret ham/hende selv, kan spillet begynde. Vi forstiller os at der skal blive vidst en ligning og at spilleren så skal havde mulighed for at vælge den rigtige løsning ud fra nogle forslag, af ca. 5 6 stk. For at spillet ikke skal blive for kedeligt vil vi gerne have at der er noget bevægelse i brugergrænsefladen, dette kunne f. eks. være når der blive vist en ligning. Gennemgang af spilforløb For at beskrive hvordan vi forstiller os at spilleren skal bruge spillet og hvordan det tekniske forløb skal forgå, har vi valgt at beskrive det via en trinvis list over muligheder og et overordnet flowchart der beskriver det overordnede tekniske forløb mellem server og klient.
Brugerforløb 1. Spilleren får vidst en tekstboks a. Spilleren taster sit navn 2. Spilleren for vist en ligning og 5 6 svarmuligheder a. Spilleren afgiver sit svar 3. Spilleren for vist en ny ligning og 5 6 nye svarmuligheder a. Spilleren afgiver sit svar 4. Forsætter fra trin 2 Som det kan ses er det et relativt simpelt brugerforløb. Overordnet tekniske forløb mellem server og klient klient visuelt Angivelse af navn Side Navn Navn visuelt Server Resultat Spil 1. Serveren sender web siden til klienten (brugerens computer). 2. Klienten viser så en side hvor brugeren skal angive sit navn. 3. Klienten gemme så navnet lokalt på klienten. 4. Klienten viser så en ny side, hvor spillet er. 5. Når brugeren har spillet en omgang af spillet, sender klienten resultatet sammen med navnet til serveren. 6. Spillet startes på ny.
Implementering Ved implementeringen valgte vi at dele arbejdet op således at Jonas Christoffersen tog sig af serverside koden og Nicklas Jacobsen tog sig af clientside koden. Dette virkede som en logisk arbejdsfordeling, da vi var to i gruppen og det er en meget lige, skarp og klar opdeling af arbejdet. For at kunne dele arbejdet op således, skulle vi blive enige om hvordan vi sendte data frem og tilbage mellem server og client. Reelt set går kommunikationen kun en vej under hele spillet, hvilket er spil resultat fra klient til server. Derfor blev vi enige om at sende navn og resultat (1 for rigtig og 0 for forkert) via GET metoden, for hver gang en spiller angiver et svar. Implementering af serverside koden Version 1 Her jeg forklare hvordan vores backend virker, og hvorfor den er bygget op som den er. Vores første funktion havde kun en funktion, og det var at gemme de data der blev tilsendt fra frontend. Det viste sig at rumme en del problemer, og derfor lavede vi det ret massive tjek på variablerne: If-statementet tjekker om $_GET[ Student ] og $_GET[ Result ] begge er satte, og IKKE tomme.
Hvis de er gode nok, gemmer den data i 2 variable, hvis skriver den til brugeren der var en fejl, og afslutter. Version 2 Her i version 2 er vi nået til at gemme brugere og data Her starter den med at loade vores xml-fil, som vi bruger til at gemme data i. Her laver den et array af alle elever i xml-filen, som den nu kan loope igennem.
Det første der sker her er at den looper gennem array'et af elever. Dernæst sammenligner den navnet på eleven i array'et med det navn vi fik i starten. Hvis det passer, går den videre ned i koden. Den gør det, at den laver et nyt element der hedder Svar, der indeholder resultatet. Dernæst sætter den en attribute der hedder Time, som indeholder det tidspunkt, denne kode bliver kørt. Til sidst sætter den det nye element til filen, og sætter variablen Found til sandt.
Variablen Found blev kun sat til true hvis der blev fundet en elev. Hvis der ikke bliver fundet en elev med det navn, skal han oprettes. Det gøres i denne kode. Det første er, at der bliver lavet et element til eleven, der får en attribute med hans navn. Derefter sker faktisk det samme som før, med at hans data bliver sat ind. Til sidst bliver eleven tilføjet den store gruppe af elever. Der sidste der sker her, er at vi gemmer xml-filen. Implementeringen af clientside kode Jeg valgte at følge en relativ kronologisk udviklingsplan. Da det første som brugeren skal møde er en side hvor brugeren skal skrive sit navn ind valgte jeg at lave det som det første. Denne opgave er ret simpel at løse og der opstod sådan set ikke nogle fejl overhovedet i denne delopgave. Jeg startede ud med at lave en html fil, med standard tags; html, head, og body. Herefter inkluderede jeg to javascript filer, jquery.js og matspil.js, i head sektionen.
Javascriptfilen jquery.js er et javascript bibliotek, som giver en masse præskrevet funktioner, som gør udviklingsarbejdet meget nemmere og hurtigere. Mens javascriptfilen matspil.js er det som det er tiltænk at selve spillet skal skrives i. Næste skridt var således at skrive noget i matspil.js for at lave en side hvor brugeren kan skrive sit navn ind. Den eneste globale variable er studentname, hvilke er den variable som skal holde elevens/spillerens navn under hele spillet. Herefter startede jeg hvor jeg altid starte, med en ready funktion. Hvad denne funktion gør er at kalde en anden funktion initstudent() (ikke skrevet i nu), når siden er loadet færdig. Dette gør vi for at sikre os at alt koden er loadet før den begynder at køre. InitStudent InitStudent funktionen er den funktion som skal bede om spillerens navn og gemme det i den globale variabel. Funktionen er opdelt således at først deklarer den alle de ting som den skal bruge, så giver den alle elementerne deres korrekte værdier (fx style værdier). Når alle elementer er sat, bliver de så appended til body tagget i html dokumentet, således at de bliver vist for brugeren.
Hvis man åbne index.html (forsiden) vil man nu blive mødt af dette billede: Dette er meget fint, vi har nu en beskrivelse af hvad brugeren skal gøre. Vi har en tekstboks hvor brugeren kan skrive sit navn og en knap som brugeren kan trykke på. Dog gør knappen ingenting i nu. Koden for hvad knappen skal gøre når knappen bliver trykket på er det sidste som initstudent definere, koden ser således ud: Når knappen bliver trykket på, tjekker den først om brugeren har skrevet et navn ind. Hvis dette ikke er tilfældet vil den vise en alertbox som siger at det er et obligatorisk felt. Men hvis brugeren har skrevet sit navn ind, bliver navnet gemt og derudover fjerner den alt på siden og kalde funktionen initgame() (ikke lavet i nu). InitGame() InitGame funktionen er den funktion som skal tegne alt til selve spillet. Det som den skal tegne er en velkomst besked hvor der står Velkommen og så spillerens navn. Koden for dette ser således ud:
Det næste tegner så rammerne for spillet. Den laver en div som bliver kaldt frame hvor spillet skal forgå, dette er bare simpel indsættelse af elementer i dokumentet DOM metoden: Det sidste der bliver gjort i funktionen, er at kalde en anden funktion som hedder rungame() (ikke skrevet i nu). rungame() rungame() er funktionen hvor selve spillet køre. Det første denne funktion gør er at lave to arrays, som henholdsvis hedder lefteq og solve. lefteq indeholder fem forskellige generelle (dvs. de indeholder ikke tal) kombinationer af ligninger, mens solve indeholder 5 funktioner der er i stand til at løse ligningerne i lefteq. Herefter laver funktionen et (pseudo) tilfældig til mellem 1 og 5, som skal bruges til at vælge en af de defineret ligninger (og dertil løsnings funktion). Nu hvor en af de generelle ligninger er valgt, fylder funktionen så den generelle ligning med tal. Dette gør den ved at sende den valgte ligning til en funktion der hedder equationcontext. equationcontext Vælge to eller tre tal, kommer an på
den valgte ligning mellem 0 og 20. Derefter returnere den et array med 3 index keys der hedder a, b og c med tilhørende tal. Disse tal skal bruges som koefficienter til ligningen. De generede koefficienter bliver derefter gemt i en variable der hedder equationdata. Herefter lave funktionen et nyt array der hedder equationsuggests med plads til 4 elementer. Dette array skal indeholde løsningsforslag, hvor et af dem er det rigtige som bliver vist for spilleren. Så finder den et tilfældigt sted i array og putter den rigtige løsning ind der. Det vigtigt at det rigtige løsningsforslag ikke ligger det samme sted altid, da spilleren så vil kunne regne ud at det rigtige svar altid ligger det samme sted.
Herefter udfyldes resten af arrayet med tilfældige tal som udgøre forkerte løsningsforslag Dette gøres ved at loope igennem array og give det tilfældige værdier. Dog tjekker den om det element den er nået til indeholder den rigtige løsning, hvis den gør springer den det element over. Dette tjekke vi på for at sørger for at vi ikke overskriver den rigtige løsning. Funktionen genrer så en menneskelig version af ligningen på formen 0=ax+b. Dette gøres ved at tage den valgte generelle ligning og bytte konstanterne ud med de tilfældige generede tal som ligger i variablen equationdata. Den menneskelig version af ligningen gemmes så i variablen equationstring. Herefter sende equationstring, equationsuggests (løsningsforslagene) og equationholder (den variable der siger hvilken af løsningerne i equationsuggests der er den rigtige) til funktionen animateequation (ikke skrevet i nu). animateequation() animateequation er funktion som har to funktioner, 1. den skal lave noget animation således at ligningerne og løsningerne flyver ind fra siden, 2. den skal fremstille ligningen og løsningsforslagene for spilleren.
Den laver en boks som indeholder ligningen og en liste med løsningsforslagene. Derudover sætter den en html klasse på alle løsningsforslagene som hedder forkert undtagen på den rigtige hvor den laver en html klasse der hedder rigtig. Dette gør den for at holde styr på senere hen om brugeren har trykket på den rigtige eller forkerte løsning. Herefter definere den så en funktion på samtlige løsningsforslag som bliver kørt hvis man trykker på en af løsningsforslagene. Hvad denne funktion gør, er at tjekke om den løsning som spilleren klikkede på har klassen rigtig, hvis den har så har brugeren trykket på den rigtige løsning og den kalder funktion sendresult (ikke skrevet i nu) med parameteren 1. Hvis den ikke har denne klasse kaldes samme funktion bare med parameteren 0. Når dette er gjort, rydder den hvad funktionen rungame() tegnede på skærmen og kalder rungame() igen. Og spillet startes på ny.
sendresult() sendresult er den funktion som sender data til serveren om hvorvidt spilleren har givet et rigtig eller forkert svar, og derudover også sender spillerens navn således at serveren kan differentier mellem de forskellige spillere. Funktionen er meget simpel. Den modtager som parameter om den skal sende rigtig i form af 1 eller forkert i form af 0 til serveren. Den sender dataene via ajax. Hvor den sende navnet på spilleren og resultatet. Hvis sendingen af dataene fejler af en eller anden grund, laver den en alertboks med en fejlmeddelelse. Test af produkt 1. Spillet skal kunne generer ligninger og deres løsninger, det vil sige de må ikke være hardcoded. a. Dette gør spillet tilfredsstillende. b. Dog kan man være ude for at løsningen bliver undefined eller infinity, hvilket ikke er tilfredsstillende. Denne test er derfor ikke bestået 2. Spillet skal kunne generer løsningsforslag. a. Dette gør spillet tilfredsstillende. b. Bestået 3. Spillet skal være i stand til at differentier mellem forskellige spillere a. Dette kan spillet også. b. bestået 4. Spillet skal kunne opsamle resultater til senere brug. a. Dataene bliver gemt i en xml fil på korrekt vis. b. bestået 5. Spillet skal passe spiludfordringsmæssigt til målgruppen. a. Vi testede det af på Jonas Christoffersens lillebror. Spillede er muligvis en smule for svært.
b. Ikke bestået 6. Spillet skal kunne køre i alle gængse browsere. a. Alle browser kørte spillet fint. b. bestået 7. Spillet skal være hurtigt at loade. a. Man kan stort set ikke mærke nogen loade tid b. bestået 8. Spillet må ikke være platformsafhængigt. a. Spillet virker fint på alle testet platforme b. Bestået Revidering af produktet Det vi mente var mest kritisk i form af fejl i spillet, var at den generede ligninger der ikke havde en logisk løsning (i hvert fald ikke i forhold til det matematiske niveau hos vores målgruppe). Retning af fejl med generede ligninger For a sørger for at spillet ikke fremviser en ligning med en underlig løsning laver vi et tjek på hvorvidt den generede løsning har en rigtig løsning inden vi fremviser den for spilleren. Hvis ligningen har løsningen undefined, infinity eller -infinity, laver spillet en ny ligning. Og denne ny ligning tjekke så igen. Hvis den nye ligning også har en af de tre forkerte løsninger generes en ny igen. Dette forsætte indtil den har generede en ligning med en logisk løsning. Dette løste problemet.
Konklusion Vi mener vi faktisk at vi har skabt en god prototype til et læringsprogram. Spillet har tydeligvis nogle visuelle mangler og de automatisk generede løsninger og ligninger kunne muligvis godt trænge til nogle justeringer. Dog har der ikke ligget særlig meget arbejde i at skabe et ellers udmærket læringsspil, hvilke beviser at man med ikke særlig mange ressource vil være i stand til at kunne effektivisere undervisningen i folkeskolen.
Bilag Krav specifikationer 9. Spillet skal kunne generer ligninger og deres løsninger, det vil sige de må ikke være hardcoded. 10. Spillet skal kunne generer løsningsforslag. 11. Spillet skal være i stand til at differentier mellem forskellige spillere 12. Spillet skal kunne opsamle resultater til senere brug. 13. Spillet skal passe spiludfordringsmæssigt til målgruppen. 14. Spillet skal kunne køre i alle gængse browsere. 15. Spillet skal være hurtigt at loade. 16. Spillet må ikke være platformsafhængigt. Test Specifikationer 1. Spillet startes op, og den fremstillede ligning skrives ned. a. Dette gøres 6 gange. b. Ligningerne sammenlignes for at tjekke at der ikke er nogle bestemte kombinationer, der optræde meget ofte. 2. Spillet startes op, og de fremstillede løsningsforslag skrives ned. a. Dette gøres 4 gange. b. Løsningsforslagene sammenlignes for at tjekke at der ikke er nogle bestemte løsningsforslag der optræder meget ofte 3. Spillet startes op og et navn skrives ind, derefter sættes følgende kode ind i adresselinjen på browseren: javascript: alert(variable); hvor variable skiftes ud med navnet på variablen der skal holde navnet. a. Hvis der kommer en boks op med det angivet navn er testen bestået. 4. Spillet startes, et testnavn angives. a. Spillets spilles og følgende kombinationer af rigtige og forkerte svar angives: 2x forkert, 1x rigtig, 1x forkert og 3 gange rigtig. b. Hvis serveren har gemt den rigtige kombination af svar under testnavnet, er testen bestået. 5. Spillet afprøves på nogle personer i den bestemte målgruppe.
a. Hvis de er stand til at spille spillet men stadig føler udfordring er testen bestået 6. Spillet startes og spilles i følgende browsere a. Firefox b. Internet explore c. Opera d. Safari e. Chrome f. Hvis spillet kan spilles i alle overnævnte browsere, er testen bestået. 7. Hvis spillet kan loades på under 20 sekunder er testen bestået 8. Spillet startes og spilles på følgende platforme a. Mac b. Windows c. Linux d. Hvis spillet kan spilles på alle overnævnte platforme er testen bestået.