Matematik i spil

Du skal lave et spil

• som indeholder mindst én bold eller anden genstand, som bevæger sig naturligt.
• hvor vandret bevægelse er lineær (dvs. uden tyngdekraft), og al anden bevægelse påvirkes af tyngdekraften.
• hvor mindst én ting opfører sig tilfældigt, f.eks. hvor og/eller hvornår en genstand dukker op, eller hvordan genstanden ser ud.
• som overholder modellen gameplay.
• som indeholder mindst ét motiverende element, som er tilpasset den valgte spillertype.
• som indeholder mindst ét element, som passer til den valgte spilgenre.
• hvor du kan vælge at inkludere luftmodstand, men det er ikke et krav.

Du kan læse om modellerne gameplay, spillertyper og spilgenre i dette modul.

Krav til spillets kode

Spillets kode skal indeholde

• mindst én variabel
• mindst én funktion/procedure – ”min brik” i Scratch
• mindst ét skift af kostume eller baggrund
• mindst én løkke
• mindst én betinget sætning
• mindst én hændelse ud over

Krav til arbejdsprocessen

Du skal arbejde systematisk med udviklingsprocessen. Du skal bruge og dokumentere, at du 

• bruger modellen trinvis forbedring.
• vælger en målgruppe og udvikler en persona, som I inddrager, når du skal foretage valg i løbet af udviklingsprocessen.
• inddrager mulige brugere i test af protyper ved at lave 5-sekunderstest, usabilitytest og userexperiencetest.

Det er svært at være kreativ på kommando. Hvis du får besked på, at du lige nu skal finde på en idé til et spil, virker det sjældent. Måske vil du gå i stå og føle, at der ingen idéer kommer, eller du foreslå en løsning, som minder meget om et spil, du allerede kender.
 

Men der findes nogle teknikker, som kan hjælpe dig til at blive mere kreativ.

Ro og tid

• Bloker alle forstyrrelser – ingen notifikationer – læg mobil og computer langt væk.
• Afsæt et fast tidsrum. Lang tid nok til at du begynder at “kede dig”, og tankerne kan vandre – kort tid nok til at du føler et pres på at få nogle idéer.
• Laver du brainstorm sammen i en gruppe, skal I veksle mellem at fortælle om jeres idéer og være stille, så i hver især kan tænke selv uden at blive forstyrret

Benspænd

Et benspænd er et krav, som din idé skal opfylde. Det viser sig, at det er meget nemmere at få idéer, hvis man fokuserer på noget, frem for helt frit at skulle få idéer. I dette projekt skal du lave et spil med en “bold”. Et benspænd kunne være, at du skal finde på idéer, hvor “bolden er noget som normalt ikke flyver”.

Når du laver brainstorm i en gruppe, kan I skiftes til at finde på et benspænd. Benspændene må meget gerne være lidt fjollede eller svære at opfylde. F.eks. Find på en idé til et spil, som spilles af 2 personer, men kun styres med én knap. Efter hvert nyt benspænd skal alle have ro til at tænke og skrive/tegne egne idéer, før I snakker om idéerne.

Skriv eller tegn jeres idéer på små stykker af papir eller post-its, så I kan flytte rundt på idéerne og snakke om, hvilke idéer som kan supplere hinanden og tilsammen blive en bedre idé.

Vær positiv

Når I præsenterer idéer for hinanden i gruppen, må I ikke sige “nej” eller på andre måder være negativ overfor en idé. I skal gerne opnå en legende stemning, hvor I tør præsentere skøre idéer, som måske ender med at udvikle sig til en rigtig god idé.

Det er forbudt at sige “det er en dårlig idé”. I skal i stedet foreslå tilføjelser eller ændringer, som bygger videre på idéen. Svaret til “Vores bold kan være en flyvende hund” kunne være “Det er en god idé, så kunne hunden undgå at ramme flyvende katte, mens den samler flyvende kødben”.

Tilfældige ord og sætninger

Man kan bruge tilfældige ord til at lave gode benspænd. Enten kan man bruge enkelte ord som man trækker tilfældigt og derefter bruger I benspændet, eller man kan have flere bunker med ord, som man trækker fra og laver tilfældige sætninger.

Du skal bruge 4 ark papir. Skriv 20 ord på hvert ark og klip de enkelte ord ud. På de forskellige ark, skal der være forskellige kategorier af ord, så de kan sammensættes til sætninger.

1. Navneord f.eks. hund, kat, cykel, bil, rumskib
2. Udsagnsord f.eks. løber, hopper, svømmer, flyver
3. Forholdsord f.eks. på, i, ovenpå, under
4. Flere navneord f.eks. vand, is, bjerg

Læg de fire kategorier af ord i hver sin bunke og træk tilfældigt ét ord fra hver bunke. Nu kan de tilfældige ord sammensættes til sætningerne, som bruges som benspænd i gruppens benspænd. F.eks. “Cykel flyver under et bjerg”. 

Samle idéer til et helt spil

Når I har lavet mindst 40 idéer – gerne flere – skal I sortere idéerne i gruppen, som kan bruges sammen. I skal gerne have nogle idéer til:

• hvordan skal spillet se ud?
• hvilke figurer/sprites skal der være i spillet?
• hvordan skal man styre spillet?
• hvordan vinder eller taber man spillet?
• ting som skal motivere spilleren til at blive ved med at spille

Når I har samlet én eller flere spilkoncepter, kan I gå i gang med at lave prototyper.

Det er vigtigt at lave prototyper, så du får konkretiseret og afprøvet dine idéer, inden du bruger lang tid på at programmere dit spil.

Papirprototyper

De tidlige prototyper er ofte tegninger. Lav skitser af alle skærmbilleder (baner) i spillet og af alle sprites. Du kan også bruge storyboards, hvor man tegner forløbet i spillet som en tegneserie. Her kan man lave et eller flere billeder, som f.eks. viser, hvad der sker, når spilleren trykker på en knap.

Fordele ved papirprototyper

• de er hurtige at lave
• det behøver ikke være pænt eller præcist
• du kan lave flere og hurtigt opdage, hvis der er noget, som måske er meget svært at lave.

Du kan lave prototyper i f.eks. et tegneprogram, men fordelen ved papirprototyper er, at det går hurtigere at tegne en ny, og du kan lave mange forskellige, så du kan vise forskellige prototyper til mulige brugere og teste IT-systemet, allerede inden du begynder at programmere.

Fysisk prototyper

Det kan være en fordel at klippe alle sprites ud, så du kan flytte rundt på sprites og undersøge om interaktionen mellem spiller og spillet, kan laves på den måde, du forestiller sig.

Når man laver større IT-systemer, såsom Rejsekortet, har man brug for fysiske prototyper, f.eks. en model af en checkin-stander. På den måde kan man teste, om brugerne vil kunne forstå, hvordan udstyret skal bruges og hvordan IT-systemet kommer til at fungere.

Kørende prototyper

Undervejs i programmeringen af spillet kan du sagtens have forskellige udgaver af det delvist færdige spil. Det kan du bruge som kørende prototyper og dermed lade mulige brugere teste dele af spillet.

Da du ikke har meget tid til at programme jeres spil, kan dit spil være en kørende prototype, hvor du f.eks. har lavet én eller to baner, men har skitser til flere baner eller idéer til andre udvidelser, som du gerne ville have tilføjet, hvis der var tid nok.

Målgruppe

En målgruppe er en afgrænset grupper af personer, som du forestiller dig vil bruge det spil eller IT-system, du er ved at udvikle. Beskrivelsen af målgruppen kan indeholde:

• aldersgruppe, f.eks. unge mellem 16 og 20 år.
• specielle interesser, f.eks. fodboldfans.
• et specielt formål, f.eks. personer som vil lære sprog ved at spille et spil.
• spillertype – f.eks. stræbere som motiveres af at sample point og slå en highscore.

Der et vigtigt at få beskrevet målgruppen præcist, så du kan lave gode designvalg, når du skal designe og programmere dit IT-produkt.

Persona

En persona er en beskrivelse af en konkret person på en form, som skal forestille en virkelig person. Idéen med at bruge personas er at tvinge designere af IT-systemer til at tænke på rigtige brugere, når de beskriver kravene til systemet, så de ikke kun fokuserer på de tekniske krav.

Det hjælper også at tænke med en bestemt persona, når du skal træffe valg, mens du programmerer dit spil. Hvis du har lavet en beskrivelse af en persona kaldet Nikolaj, kan du spørge sig selv: “Ville Nikolaj foretrække, at denne knap er blå eller grøn?”.

Beskrivelsen af en persona indeholder:

• et navn, f.eks. Nikolaj.
• en præcis alder, f.eks. 17 år.
• en beskrivelse af hvad personaen kan lide og ikke lide, f.eks. Nikolaj kan lide spil, hvor han kan konkurrere med andre om at få flest point.
• en beskrivelse af personaens formål med at bruge den type IT-produkt, du designer. F.eks. Nikolaj gider ikke øve sig på tyske gloser, men synes, at det ok at øve sig, hvis det er i et spil, hvor han kan konkurrere om at slå sin egen highscore.

Beskrivelsen kan også indeholde:

• hvor og hvordan personaen typisk bruger IT-systemer.
• personaens behov for et IT-system af denne type.
• hvilke krav og forventninger personaen kan have til IT-systemer af denne type.

En beskrivelse af en persona må gerne minde om en personbeskrivelse i faget dansk. Du må til gengæld ikke fortælle om, hvordan personaen bruger netop dit IT-produkt, da det er ikke designet færdigt, når du laver personaen. Persona er altså et redskab, som skal hjælpe dig med at designe dit IT-produkt.

Scenarier og storyboards

Et scenarie er en beskrivelse af et menneskes aktivitet. Den beskriver kort, hvordan IT-systemet kan bruges, f.eks. hvad man gør trin for trin, når man bruger IT-systemet. Det beskriver også den sammenhæng, brugeren er i, når systemet anvendes.

Storyboards egner sig godt til spil, hvor der fortælles en historie, som udvikler sig f.eks. med flere scener eller spillebaner. Et storyboard svarer til, at du vil lave en film og tegner eller beskriver filmens scener: hvordan ser det ud og hvad sker der i en scene.

Vandfaldsmodel

Nogle IT-produkter kan vi forestille os meget præcist. Vi kan lave en liste med ting, som systemet skal kunne, og vi ved på forhånd, hvordan det skal virke. Til den slags IT-produkter virker vandfaldsmodellen godt.

Modellen hedder vandfaldsmodellen, fordi vand altid løber én vej, nedad. Du kan altså ikke gå tilbage til en tidligere fase i denne udviklingsmodel. Vandfaldsmodellens faser kan være:

1. Kravspecifikation: Udvikler og kunde bliver enige om en liste af krav, som IT-produktet skal opfylde.  
2. Design: Udvikleren laver et design af skærmbilleder og interaktion, som passer til kravspecifikationen, dvs. beskriver de enkelte dele mere detaljeret.
3. Implementering: Udvikleren programmerer én ting ad gangen, indtil hele kravspecifikationen er opfyldt.
4. Test: IT-produktet testes, og udvikleren dokumenterer, at IT-produktet virker og ser ud som aftalt.
5. Aflevering: IT-produktet afleveres til kunden.

Hvis du allerede nu kan lave en præcis kravspecifikation til dit spil, hvor alt kan tegnes i papirprototyper og beskrives, så kan du bruge vandfaldsmodellen som udviklingsmodel. 

Agile udviklingsmodeller

Desværre er det sjældent, at man kan beskrive alle krav til IT-produktet på forhånd, som er et krav for at bruge vandfaldsmodellen. Derfor bruger man ofte en agil udviklingsmodel, hvor man kan gå frem og tilbage mellem faserne. Agil betyder en bevægelse som er hurtig og fleksibel.

Når du skifter hurtigt frem og tilbage mellem udviklingsprocessens faser og kræver det god projektledelse, især i større projekter. Der findes mange forskellige agile udviklingsmodeller, som alle fokuserer på forskellige måder at styre udviklingsprocessen.

Når du arbejder på et mindre projekt i en lille projektgruppe, er det vigtigt, at alle gruppens medlemmer er beviste om, hvilken fase I er igang med, så I ikke blander det hele sammen. Især implementering (programmering) og design kan meget vel blive blandet sammen, hvilket gør, at man mister overblikket og bruger for meget tid på programmering.

“Trinvis forbedring” er en måde at styre udviklingsprocessen. Du arbejder på én del af projektet og går igennem faserne design, implementering og test én eller flere gange, så du trinvist forbedrer denne del. Derefter kan du gå videre til nye dele af projektet. 

Interaktion kan defineres bredt som alt samspil mellem en bruger og et IT-system. Interaktionen går to veje:

1. Brugeren aktiverer IT-systemet med input. Input kan f.eks. ske via tastatur, mus eller skærmen på en mobiltelefon.
2. IT-systemet laver et output som ofte afhænger af brugerens input.

Samlet beskrives input- og outputmulighederne ofte som systemets brugergrænseflade, dvs. grænsen mellem menneske og IT-system. Med et godt interaktionsdesign er IT-systemet designet, så det virker godt for brugeren af IT-systemet.

Usability

IT-systemer med høj usability er lette af anvende for brugeren. I et spil med høj usability vil brugeren have let ved at forstå, hvordan spillets regler fungerer, hvordan man styrer spillet og hvad målet med spillet er.

IT-systemer som virker som andre tilsvarende IT-systemer har ofte høj usability. Hvis brugeren gør, som vedkommende plejer, er outputtet som forventet. Mange computerspil kan styres med pile-tasterne, hvor man også hopper med mellemrumstasten, og derfor forventer brugerne, at et nyt spil gør det samme.

IT-systemer med høj usability er:

• lette at lære at bruge – intuitive.
• lette at huske, hvordan man bruger.
• effektive at bruge.
• forventelige – man får det output, man forventer.
• sikre at bruge – man kan ikke lave fejl ved et tilfælde/uheld.

Userexperience

Brugerens oplevelse af IT-systemet kaldes ofte userexperience. Et spil med god userexperience er sjovt og brugeren bliver motiveret til at fortsætte med at spille spillet. God usability er ofte forudsætningen for, at et spil også kan have en god userexperience. Kort sagt er usability det tekniske i interaktionen, og userexperience er de følelser brugeren oplever ved interaktionen med IT-systemet.

IT-systemer med god userexperience er:

• tilfredsstillende – opfylder et behov.
• æstetisk behagelige – pænt design og behagelige farver.

Desuden kan IT-systemer være:

• underholdende
• sjove
• motiverende
• belønnende

Især spil skal opfylde de sidste krav for at få en høj userexperience.

Der findes forskellige typer test, som egner sig til at teste forskellige dele af et IT-produkt og bruges på forskellige tidspunkter i udviklingsprocessen. Det er vigtigt at teste ofte i udviklingsprocessen, så man hurtigt kan ændre designet, hvis det virker dårligt.

Jo flere testpersoner du bruger, jo bedre kan du regne med dine testresultater. Når du laver en test skal du planlægge testen, udføre den og til sidst konkludere, hvad du vil ændre i IT-systemet.

5-sekunders-test

Da det er vigtigt, at brugere hurtigt kan se, hvad et spil, en webside eller et andet IT-produkt kan bruges til, er det vigtigt at teste brugernes førstehåndsindtryk af et IT-produkt. I en 5-sekunderstest ser testpersonerne kort (fem sekunder) IT-produktet og skal derefter fortælle om, hvad de lagde mærke til.

En 5-sekunders-test er god til at teste det umiddelbare indtryk, f.eks. om de valgte farver signalerer, at IT-systemet henvender til den valgte målgruppe.

Planlægning af 5-sekunders-testen

• Vælg, hvilken del af IT-produktet du vil teste, f.eks. startsiden på dit spil.
• Vælg, hvem testpersonerne skal være, f.eks. personer i målgruppen, måske andre elever på skolen.
• Vælg, hvilke spørgsmål du vil stille testpersonerne. Typiske spørgsmål kan være “Hvad lagde du mærke til?”, “Hvem tror du IT-produktet henvender sig til?”, “Hvad er dit indtryk af designet?”.

Spørgsmålene skal være åbne spørgsmål, så testpersonerne ikke kan gætte, hvad du gerne vil have de skal svare. Husk, at testpersonerne ikke må kunne se IT-produktet, når de svarer på spørgsmålene.

Udførelsen af 5-sekunders-testen

Det er vigtigt, at du fortæller testpersonerne, at de kun har fem sekunder til at kigge på IT-produktet, og at de derefter skal fortælle om det uden at kunne se på det. Derefter vises IT-produktet eller prototypen i fem sekunder (tag tid). Når fremvisningen er overstået, stiller du dine forberedte spørgsmål og noterer testpersonernes svar.

Fortolkning og konklusion

Ud fra de svar, du har fået, skal du konkludere og prioritere de ændringer, du vil lave. Det kan f.eks. være, at du vil ændre farver på eller placering af de vigtigste elementer i spillet, så brugerne opdager de vigtigste elementer med det samme.

Tænke-højt-test – usabilitytest

I en tænke-højt-test afprøver testpersonerne dit IT-system, mens de fortæller, hvad de tænker undervejs. Denne type test kan være god til at forstå, hvilke dele af designet, der virker ulogisk, fordi testpersonerne f.eks. vil sige “Jeg kan ikke finde …” eller “hvordan kommer jeg videre?”.

Planlægning af usabilitytest

Hvis det er et spil, du tester, vil du ofte bede testpersonerne afprøve dit spil uden at give flere instruktioner. Hvis det er en tænke-højt-test, skal testpersonerne instrueres i at fortælle alt, de tænker undervejs.

Du skal vælge fokus for din test, f.eks. at du vil observere:

• hvor lang tid går der, før testpersonerne finder ud af spillets regler og målet med spillet.
• går spillet for hurtigt eller langsomt.
• er der tidspunkter i spillet, hvor testpersonen ikke kan komme videre. Her bliver du nødt til at hjælpe.

Du kan eventuelt afslutte usabilitytesten med nogle spørgsmål om det tekniske i spillet. 

Udførelsen af usabilitytesten

Hvis I er to til at udføre testen, er det bedst, hvis den ene taler med testpersonerne, og den anden observerer og noterer reaktioner og svar på spørgsmål. 

Fortolkning og konklusion

Når du har lavet testen, laver du en liste, hvor du prioriterer de forbedringer, du bør lave. Notér gerne alle mulige forbedringer og vurdér herefter, om de er ”lette”/”svære” at lave, samt om de er ”meget vigtige” eller ”mindre vigtige”. På den måde kan du lave de lette og vigtige ændringer først.

Userexperiencetest

Denne test kan ofte kombineres med usabilitytesten. Du kan tilføje nogle spørgsmål til testpersonerne, som du stiller, efter testpersonerne har lavet usabilitytesten. Husk, at det skal være åbne spørgsmål, så testpersonerne ikke kommer med ja/nej eller høflige svar.

• hvad er det sjoveste i dette spil?
• hvad skal vi ændre i spillet, for at det bliver sjovere?
• hvem passer spillet til?

A/B-test

I A/B-test afprøver du to forskellige muligheder og ser, hvad brugerne bedst kan lide. Det er meget udbredt i udviklingen af webbaserede IT-systemer, hvor du let kan ændre IT-systemet, så nogle af brugerne ser version A og andre version B. Derefter kan du undersøge om brugerne reagerer forskelligt, f.eks. om flest brugere køber en vare i en webshop, når de ser version A eller B.

Spilgenre

Spil kan opdeles i forskellige typer kaldet spilgenre. Nogle spil har elementer fra flere spilgenre, så de kan henvende sig til en bred målgruppe. Der findes mange forskellige spilgenre og måder at kategorisere spil.

Aktionspil

Dette er en meget bred spilgenre, hvor det vigtige er, at man er hurtig og har gode reflekser. Tempoet og tidspresset er en vigtig del af disse spil. Mange skydespil, hvor du enten spiller mod computeren, andre eller sammen i hold, har elementer af aktionspil.

Platformsspil, hvor du skal fange eller undgå genstande, hører også til denne spilgenre. Tempoet i denne type spil går ofte hurtigere og hurtigere, så spilleren oplever et tidspres og bliver bedre til spillet ved at spille det mange gange.

I aktionspil skal du ofte score point og undgå at miste liv eller blive skudt. En del aktionspil er korte og simple, men kan spilles mange gange for at opnå flere point.

Adventure

I adventurespil skal du f.eks. løse gåder for at komme videre i spillet. Du kan gå på opdagelse og blive ved med at finde nye ting og steder i spillet. Denne spilgenre behøver ikke at have en slutning eller et mål.

Strategi

I strategispil handler det om at vinde ved at lægge en god plan, kunne analysere mulighederne og træffe gode valg, f.eks. vælge den rigtige taktik. Den rigtige strategi eller taktik kan afhænge af modstanders valg, og derfor skal du måske tilpasse din taktik i løbet af spillet.

Strategispil kan både spilles i grupper eller mod enkelte modstandere. I nogle spiltyper skiftes modstanderne til at lave et træk, i andre spiller man mod hinanden real-time, og denne genre handler derfor både om taktik, koordination i gruppen og hurtighed.

Processpil

Processpil kaldes sandbox games på engelsk og minder mere om leg end et egentlig spil. Der er ikke et bestemt mål i spillet, og spilleren opbygger ofte sin egen verden i spillet. Det er en spilgenre, hvor der er mange muligheder og valgmuligheder, og hvor spilleren delvist kan lave sit eget spil i spillet.

Du kan læse om flere forskellige spilgenre og kombinationer af spilgenre her:

https://en.wikipedia.org/wiki/List_of_video_game_genres

Spil er forskellige og ikke alle kan lide de samme spil. Forskellige spillertyper motiveres af forskellige elementer i spil, og derfor designes spil, så det passer til en eller flere spillertyper.

Stræbere (achievers)

Stræbere vil gerne konkurrere og være bedst. Enten konkurrerer stræbere mod sig selv og vil f.eks. forbedre sin egen high score, ellers konkurrerer stræbere mod andre spillere og vil gerne kunne sammenligne sig med dem, f.eks. om at have den bedste high score.

Stræbere motiveres ved at kunne vise egne resultater frem og kunne sammenligne sig med andre. Selv simple spil kan motivere stræbere, hvis man skal øve sig for at blive god til at spille spillet. Men også spil med mange niveau kan motivere stræbere, hvis man skal være dygtig og nå langt i spillet.

Udforskere (explorers)

For en udforsker er spillets verden og historie vigtig. Spillet skal udvikle sig og man skal gerne blive ved med at kunne opdage nye ting i spillet. Der må gerne være skjulte elementer i spillet, som ikke alle opdager, eller som først bliver tilgængelige, når man løst bestemte opgaver.

Dræbere (killers)

I spil kan man lege med at gøre ting, man aldrig ville gøre i det virkelige liv, f.eks. slå ihjel eller være destruktiv og ødelægge ting. Dræbere fokuserer ofte på magt og muligheden for at bryde med normal etik og moral. Spil, som henvender sig til dræbere, kan opleves grænseforskridende for andre spillertyper.

Sociale (socializers)

Sociale spillere vil gerne være sammen med andre om at spille og opbygge et netværk med andre spillere inden i spillet. Muligheder for at kunne kommunikere om spillet og i spillet er vigtigt for sociale. Det er vigtigere for sociale at deltage og være sammen med andre om spillet end at nå et bestemt mål. 

Flere spillertyper

De fleste motiveres af forskellige elementer i spil og tilhører derfor flere spillertyper. Modellen med de 4 spillertyper kan dog hjælpe i designfasen, så du ved, hvilke elementer du skal have med i spillet for at motivere den spillertype, du udvikler spillet til.

Et spils gameplay er de rammer, der er for spillet og den oplevelse en spiller får, når spillet spilles. Et godt gameplay er tæt knyttet til begrebet userexperience.

Man kan designe et godt spil ved at arbejde med forskellige elementer i spillets gameplay, f.eks. regler, motivation, læring og identifikation.

Regler

Spillets regler dækker over, hvordan spilleren interagerer med spillet og målet med spillet, f.eks. hvordan spilleren vinder spillet. Regler skal være: 

• logiske – f.eks. spilleren går til højre, når man trykker på højre piletast.
• genkendelige – spilleren gør det samme som i andre spil.
• forståelige – f.eks. bevægelser i spillet svarer til bevægelser i den rigtige verden.

Er du nødt til at forklare sine regler for spilleren, skal du overveje, om du kan forbedre spillet, så det bliver lettere for spilleren at komme i gang med spillet selv.

Motivation

Spilleren skal gerne have lyst til at fortsætte med spillet. Forskellige spillertyper motiveres forskelligt, og du skal derfor tilpasse dit spil til den spillertype, som er målgruppe for spillet.

En stræber (achiever) vil gerne slå sin egen og andre spilleres high score. Derfor kan man forbedre motivationen for denne spillertype ved at vise egen og andres high score, som den aktuelle pointscore kan sammenlignes med.

En udforsker (explorer) motiveres af at opdage nye ting i spillet. Hvis spilleren kan få adgang til flere baner eller nye områder i spillet, eventuelt ved at løse gåder eller opgaver, kan det motivere spilleren til at gå på jagt efter de nye elementer i spillet.

Læring

Læring drejer sig om følelsen af at blive bedre til at spille et spil. Når man føler, at man bliver dygtigere og opnår nye kompetencer, motiveres spilleren til at blive ved med at spille spillet. Det er vigtigt, at udfordringerne tilpasses spilleren, f.eks. tempoet i spillet eller sværhedsgraden af gåder, som skal løses.

I mange spil sættes tempoet op, jo længere spilleren når. Hvis det bliver for svært for hurtigt, er spillet demotiverende, da spilleren dermed taber hele tiden og aldrig når langt. Hvis spillet udvikler sig for langsomt, bliver det kedeligt og ensformigt. Det gode spil udvikler sig, så spilleren oplever, at man hele tiden udfordres, uden at det bliver for svært.

Læring betyder ikke, at man skal lære noget bestemt, som i skolen. Det er vigtigt, at spilleren lidt efter lidt klarer sig bedre i spillet.

Identifikation

For nogle spillere er det vigtigt, at man føler sig som en figur i spillet. Identifikation kan opnås ved at spilleren:

• ser spillet fra en sprites synsvinkel, f.eks. i skydespil.
• kan vælge sin figurs/sprites udseende.
• kan udbygge sin sprites egenskaber, f.eks. får flere muligheder jo længere man kommer i spillet.

I dette projekt skal du bruge det simple blokprogrammeringssprog “Scratch”. Fordele ved Scratch:

• Det er simpelt at programmere med blokke bl.a. fordi du har blokke, som klarer svære opgaver, som f.eks. registrering af om to sprites rør hinanden.
• Du har adgang til mange sprites/figurer.
• Spilplanen opfører sig som et koordinatsystem i matematik, så du kan bruge den matematik, du kender. I andre systemer vender y-aksen modsat.

Ulemper:

• Du er begrænset til 2D-spil. Det er svært at lave noget, som bevæger sig i 3 dimensioner.
• Du skal selv programmere bevægelsen. I nogle systemer er tyngdekraften indbygget, så bevægelsen sker automatisk.

Større spil udvikles i et avanceret udviklingsmiljø, hvor det er let at arbejde sammen, og det færdige spil kan afvikles på mange forskellige platforme, både computere, spilkonsoller og mobile enheder. Et populært udviklingsmiljø er Unity, som oprindelig var dansk.