Download projekt "Edutainment" som PDF - Informatiker.DK
Download projekt "Edutainment" som PDF - Informatiker.DK
Download projekt "Edutainment" som PDF - Informatiker.DK
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
Titel Edutainment – Proces til model<br />
Tema Udvikling af IT-system<br />
Projektperiode P2 - 1. februar – 29. maj 2007<br />
Projektgruppe Informatik - Gruppe B331<br />
Deltagere Synopsis<br />
- Tobias Bornakke<br />
- Jonas Urth Olsen<br />
- Rahuvaran Pathmanathan<br />
- Daniel Nielsen<br />
Vejleder Gitte Tjørnehøj<br />
Bi-Vejleder Pirkko Raudaskosi<br />
Oplagstal 10<br />
Sideantal 92 sider inkl. forside<br />
Bilagsantal 7, (22 sider inkl. forside)<br />
Afsluttet den Tirsdag den 29. Maj 2007<br />
Det Ingeniør-, Natur- &<br />
Sundhedsvidenskabelige Basisår -<br />
Informatik<br />
Strandvejen 12-14<br />
9000 Aalborg<br />
Tlf. 96 35 97 33<br />
Fax 98 13 63 93<br />
http://tnb.aau.dk<br />
Hovedemnet for dette <strong>projekt</strong> er<br />
edutainment. Projektet berettiges af en<br />
opfattelse, at der eksisterer uudnyttede<br />
muligheder for at anvende<br />
computermediet edutainment særligt i<br />
folkeskolesammenhænge.<br />
Der redegøres for edutainment samt<br />
teorierne leg, spil og læring der er<br />
grundelementerne i den gængse<br />
forståelse af edutainment, hvorefter der<br />
foretages en analyse af<br />
edutainmentspillets interessenter,<br />
herunder målgruppen.<br />
Ud fra teoristudierne og<br />
interessentanalysen udarbejdes et sæt<br />
kriterier for udvikling af et<br />
edutainmentspil specifikt til målgruppen.<br />
For at inddrage leg, spil og læring<br />
balanceret i systemudviklingen, gøres<br />
kriterierne afgørende for designet af<br />
spillet, og der gennemføres en<br />
koncepttest med henblik på at sikre<br />
spillets overordnede linier.<br />
Projektet kan blandt andet konkludere at<br />
den anvendte systemudviklingsmodel på<br />
en effektiv måde kobler kriterier fra<br />
analyse og litteratur med en<br />
spiludviklingsproces.<br />
Rapportens indhold er frit tilgængeligt, men offentliggørelse (med kildeangivelse) må kun ske efter aftale med forfatterne.
Forord<br />
Udvikling af et IT-system - Informatik P2 - Projekt – Feb. - Maj. 2007<br />
Denne <strong>projekt</strong>rapport er udarbejdet i P2-<strong>projekt</strong>perioden, 2.semester på den teknisk<br />
naturvidenskabelige basisuddannelse Aalborg Universitet.<br />
I forbindelse med udarbejdelse af rapporten vil vi gerne takke følgende personer: Vores<br />
fokusgruppe på Stolepedalsskolen i Aalborg, <strong>som</strong> har fundet tid til at hjælpe os med <strong>projekt</strong>et.<br />
Cand.mag. Kirsten Jørgensen for assistance til læringsforståelse. Derudover vil vi gerne takke<br />
Mikkel Andersen, <strong>som</strong> på trods af planlagt studieskift, til det sidste har været til rådighed i<br />
udarbejdelsen af denne rapport. Sidst, men bestemt ikke mindst vil vi gerne takke Lars Konzack,<br />
<strong>som</strong> har været til rådighed under vores <strong>projekt</strong>.<br />
Aalborg, 29. maj 2007<br />
Side 5 / 92
Læsevejledning<br />
Udvikling af et IT-system - Informatik P2 - Projekt – Feb. - Maj. 2007<br />
Vi har i vores opbygning af rapporten, så vidt muligt forsøgt at lade denne afspejle det forløb<br />
<strong>som</strong> <strong>projekt</strong>et har gennemgået.<br />
Rapporten er skrevet således, at der forekommer både kildehenvisninger og fodnoter.<br />
Kildehenvisninger vil i teksten være noteret <strong>som</strong> [kildebogstav], <strong>som</strong> henviser til den brugte<br />
kilde, <strong>som</strong> er at finde i kapitlet referencer. Fodnoterne vil indeholde uddybende eller<br />
forklarende information om emnet og vil være tilgængelig i bunden af den pågældende side, og<br />
betegnes med nummereringer. I rapporten er der desuden henvisninger til en række opstillede<br />
kriterier. Disse henvisninger, eksempelvis til kriterium 16, er noteret <strong>som</strong> (K. 16).<br />
En stor del af dette <strong>projekt</strong> beskæftiger sig med læringsfeltet, der begrebsmæssigt ofte ikke er<br />
eksplicit defineret. Vi har derfor vurderet det <strong>som</strong> væsentligt at fastlægge hvad vi i det følgende<br />
forstår ved centrale begreber 1 .<br />
I forhold til de læringsmæssige begreber arbejdes der med begreberne træning, læring,<br />
indlæring, undervisning samt uddannelse. Vi definerer træning <strong>som</strong> en aktivitet med stor fokus<br />
på færdigheder, hvor procedurer indarbejdes gennem gentagelse af konkrete øvelser over tid.<br />
Med læring er der fokus på den studerende, hvor information og oplysning ikke rækker, og den<br />
studerende selv deltager aktivt i sin læring.<br />
I modsætning til læring sætter indlæring et mere specifikt fokus på stof og viden. Med<br />
undervisningsbegrebet fokuseres der på læreren, <strong>som</strong> fremviser viden <strong>som</strong> de skal tilegne sig, på<br />
samme måde <strong>som</strong> uddannelsen sætter fokus på uddannelsesinstitutionen.<br />
Flyttes fokus til modtageren af læringen, støder vi på begreberne elev, studerende, og den<br />
lærende. Med elev forstås en person <strong>som</strong> er tilknyttet en uddannelsesinstitution under en<br />
underviser (lærer). I modsætning til eleven er den studerende en person der aktivt deltager i sin<br />
læringsproces. Den studerende undersøger selv sit emne, og får sin viden gennem boglige<br />
færdigheder på højt niveau (ofte universitetsstuderende). Afslutningsvis er den lærende, et<br />
begreb der dækker over en studerende der blot ikke nødvendigvis er tilknyttet bestemt<br />
studiemiljø.<br />
1 Følgende afsnit bygger på Lars Konzacks Edutainment [a, s15-23]<br />
side 6 / 92
Indholdsfortegnelse<br />
Udvikling af et IT-system - Informatik P2 - Projekt – Feb. - Maj. 2007<br />
1.0 Indledning..........................................................................................................................................................................................8<br />
1.1 Indledning............................................................................................................................................................................................................8<br />
1.2 Problemanalyse...............................................................................................................................................................................................9<br />
1.3 Problemformulering...................................................................................................................................................................................10<br />
1.4 Projektafgrænsning....................................................................................................................................................................................11<br />
2.0 Systemudviklingsmodel.............................................................................................................................................................13<br />
2.1 Indledning.........................................................................................................................................................................................................13<br />
2.2 Systemudviklingsparadigmer.................................................................................................................................................................14<br />
2.3 Faktorer for systemudvikling..................................................................................................................................................................16<br />
2.4 Projektets systemudviklingsmodel......................................................................................................................................................17<br />
3.0 Edutainment..................................................................................................................................................................................21<br />
3.1 Indledning.........................................................................................................................................................................................................21<br />
3.2 Leg.......................................................................................................................................................................................................................22<br />
3.3 Spilteori.............................................................................................................................................................................................................25<br />
3.4 Læring................................................................................................................................................................................................................27<br />
4.0 Interessentanalyse.....................................................................................................................................................................36<br />
4.1 Indledning.........................................................................................................................................................................................................36<br />
4.2 Fokusgruppeinterview...............................................................................................................................................................................37<br />
4.3 Analyse af målgruppen.............................................................................................................................................................................41<br />
5.0 Kriterier for edutainment........................................................................................................................................................44<br />
5.1 Indledning.........................................................................................................................................................................................................44<br />
5.2 Integration af leg, læring og spil...........................................................................................................................................................44<br />
5.3 Kriterier for god edutainment...............................................................................................................................................................48<br />
6.0 Spiludvikling...................................................................................................................................................................................50<br />
6.1 Indledning.........................................................................................................................................................................................................50<br />
6.2 De 7 trin............................................................................................................................................................................................................51<br />
7.0 Idéudvikling og Designproces.................................................................................................................................................60<br />
7.1 Indledning.........................................................................................................................................................................................................60<br />
7.2 Ide og Koncept..............................................................................................................................................................................................60<br />
7.3 Spilverden........................................................................................................................................................................................................62<br />
7.4 Karakterer.......................................................................................................................................................................................................63<br />
7.5 Historie..............................................................................................................................................................................................................65<br />
7.6 Gameplay..........................................................................................................................................................................................................67<br />
7.7 Brugerinterface............................................................................................................................................................................................70<br />
8.0 Designtest.....................................................................................................................................................................................73<br />
8.1 Indledning.........................................................................................................................................................................................................73<br />
9.0 Implementering............................................................................................................................................................................75<br />
9.1 Arbejdsgang...................................................................................................................................................................................................75<br />
9.2 Kodestruktur og eksempler...................................................................................................................................................................75<br />
9.4 Konklusion på implementering.............................................................................................................................................................80<br />
10.0 Diskussion og Konklusion......................................................................................................................................................81<br />
10.1 Indledning......................................................................................................................................................................................................81<br />
11.0 Pædagogiske Perspektiveringer........................................................................................................................................87<br />
11.1 Indledning...................................................................................................................................................................................................87<br />
11.2 Evaluering af eleven..............................................................................................................................................................................87<br />
11.3 Undervisningsdifferentiering............................................................................................................................................................87<br />
11.4 Kollaboration og multiplayer...............................................................................................................................................................88<br />
11.5 Læringstest................................................................................................................................................................................................89<br />
12.0 Afrunding.....................................................................................................................................................................................90<br />
Litteratur...............................................................................................................................................................................................91<br />
Side 7 / 92
1.1 Indledning<br />
Udvikling af et IT-system - Informatik P2 - Projekt – Feb. - Maj. 2007<br />
1.0 Indledning<br />
Undervisning med computeren <strong>som</strong> medie har de sidste år for alvor haft sit indtog i folkeskolen.<br />
Motiveret af især folkeskolelovgivningen, er computeren blevet prioriteret <strong>som</strong> et værktøj på lige fod<br />
med skolebøger. Dog adskiller computeren sig fra de andre redskaber, eleverne bruger, ved at være<br />
et interaktivt digitalt medie, <strong>som</strong> giver mulighed for at formidle viden og understøtte læring på en ny<br />
og ressourceøkonomisk måde.<br />
Den nye folkeskolelov fremstiller desuden et klart krav om undervisningsdifferentiering, hvilket<br />
vil sige en tilpasning af undervisningens faglige niveau til den enkelte elevs forudsætninger.<br />
Manglende tid og ressourcer kan imidlertid gøre det svært at imødekomme de nye krav om<br />
personligt tilrettelagt undervisning. Her kan computeren anvendes <strong>som</strong> alternativ og<br />
supplement til den udifferentierede klasseundervisning, idet den computermedierede<br />
undervisning kan målrettes den enkelte elev ved justeringer af indholdsmængden, det faglige<br />
niveau og lignende læringskriterier.<br />
Læreren fungerer ofte <strong>som</strong> en af de motiverende kræfter for elevens modtagelse af undervisning<br />
– engagerede lærere vil så vidt muligt forsøge at aktivere sine elever i deres egen lærings- og<br />
udviklingsproces. Interaktive medier <strong>som</strong> for eksempel computerspil kan skabe lignende<br />
rammer for undervisning, idet spillets gennemførelse beror på spillerens interaktion med spillet.<br />
Netop computerspil tilfører ofte også et fortællende element, der <strong>som</strong> i andre medier altid har<br />
været afgørende for mediets underholdningsværdi.<br />
Kombinationen af computerspil og undervisning sker i computermedieret edutainment. Her<br />
udnytter man computerspillets virkemidler til at formidle information, og de udfordringer <strong>som</strong><br />
forekommer i spillet, vil besidde både et læringsaspekt og en underholdningsværdi.<br />
Edutainment beskrives i dag af International Game Developers Association (IGDA) således:<br />
Edutainment: Combining educational information in a gaming environment to make<br />
the presentation more entertaining [dd].<br />
Selve ordet edutainment er en sammensætning af to engelske ord, education og entertainment.<br />
Om end begge dele i de fleste sammenhænge er positive begreber, er edutainment blevet og<br />
bliver stadig mødt med skepsis af mange inden for undervisningsverdenen. I dag er der dog flere<br />
forskellige gode grunde til at inddrage edutainment i undervisningen, heriblandt de<br />
ovennævnte. En række undersøgelser [bbb] viser tilmed at langt de fleste børn fra 1. - til 9.<br />
klassetrin i dag, har bekendtskab med computerspil, drenge <strong>som</strong> piger. Computerspil kan derfor<br />
opfattes <strong>som</strong> et på forhånd fortroligt medie hos børn og unge i aldersgruppen 7 – 16 år.<br />
Edutainment udvikles og bruges sjældent målrettet i undervisningssammenhæng, og endnu<br />
sjældnere efter folkeskolens 7. klassetrin. Vores udforskningsfelt vil derfor kredse om<br />
udviklingen af et edutainmentspil for en udvalgt målgruppe, <strong>som</strong> ligger over denne grænse.<br />
Projektet berettiges af en opfattelse, at der (stadig) eksisterer uudnyttede muligheder for at<br />
anvende computermediet edutainment særligt i folkeskolesammenhæng. Det initierende<br />
problem kan derfor udtrykkes i følgende sætning:<br />
side 8 / 92<br />
Hvordan udvikles et edutainmentspil til brug i folkeskolens 8. klasser?
1.2 Problemanalyse<br />
Udvikling af et IT-system - Informatik P2 - Projekt – Feb. - Maj. 2007<br />
Projektgruppens kontakt med personer indenfor undervisning<strong>som</strong>rådet, og personlig erfaring<br />
med edutainment har ledt til den klare opfattelse, at edutainment lider under et dårligt ry. Og<br />
med rette. Efter lidt research i Aalborg hovedbiblioteks spilsamling kan konkluderes at<br />
edutainment kan bruges <strong>som</strong> fællesnævner for noget, hvor der ganske rigtigt både indgår læring<br />
og underholdning, men der er ingen konvention for hvilken balance der skal eksistere mellem de<br />
to ting. For en lærer vil det derfor være svært at bedømme om et givet edutainmentspil primært<br />
er bygget på et solidt læringsfundament, eller under påvirkning af en kommerciel<br />
underholdningsbranche. Ifølge adjunkt i multimedier Lars Konzack, er den største og<br />
væsentligste udfordring i forbindelse med udvikling af læringsfunderet edutainment, at sikre at<br />
de tre hovedpæle ”Leg, læring og computermediet” går op i en højere enhed.<br />
Det største krav for at inddrage edutainment i undervisningsøjemed, må til alle tider være<br />
læring, mens motivationen for at vælge et edutainmentspil over andre undervisningsformer må<br />
være den stærke underholdnings- og stimulationsfaktor, <strong>som</strong> mediet tilbyder. Et computerspil<br />
med et synligt underholdningselement, men dårligt repræsenteret læringsindhold, vil<br />
sandsynligvis blive diskvalificeret af enhver folkeskolelærer. På den måde vil dette marked altid<br />
stille strenge krav til relevant skolefaglighed og niveau i edutainment, da lærere og skoler selv<br />
mødes af strenge krav med henblik på undervisningens faglighed og progression fra både<br />
forældre og det offentlige.<br />
Der ligger i forvejen en stor udfordring blot ved at udvikle et computerspil, og der må siges at<br />
være rigtig mange faktorer, der skal forenes. Målgruppens ultimative krav til spillet vil <strong>som</strong><br />
oftest være, at spillets gameplay og grafik skal være af højeste kvalitet og originalitet. Dette krav<br />
vil sandsynligvis stadig gælde for edutainmentspil, da det er heraf motivationen for at spille<br />
skabes. Ved at se endnu et ultimativt krav blive stillet, nemlig målrettet og velovervejet<br />
læringsindhold, kan man udmærket forstå hvis spilbranchen giver fortabt på forhånd. Det sker<br />
ikke hver gang, men bemærkelsesværdigt er det, at de (i hvert fald fra vores syn) mest succesrige<br />
edutainmentspil overvejende henvender sig til folkeskolens mindre klassetrin.<br />
Årsagen kunne tænkes at være, <strong>som</strong> for undervisning generelt, at der eksisterer en antagelse om,<br />
at mindre børn er lettere påvirkelige og ikke stiller sig kritiske overfor det lærte. Et lignende<br />
billede tegnes for spildesignet. Mindre børn har lettere ved at lade sig underholde af simple<br />
historier og simple grafiske virkemidler. Dette afspejler sig konkret i edutainmentspilmarkedet,<br />
hvor indskolingen og til dels mellemskolen er målgruppen for det, spilbranchen skaber. Måske<br />
også fordi disse spils aftagere også er ambitiøse forældre, der vil ”træne” med deres børn i<br />
førskole- eller fritiden. De større klasser er åbenbart et for krævende marked at satse på. Og hvis<br />
der stilles for store krav fra et for lille marked, er det helt konkret et spørgsmål om manglende<br />
økonomisk udbytte af produktet.<br />
Hvis det antages at markedets købekraft er til stede, hvad skal der så til for at lave et produkt<br />
<strong>som</strong> anerkendes af skoler og lærere? Udover at der er et klart krav til fagligheden, skal et<br />
edutainmentspil, der bruges seriøst, også kunne indgå i lærerens didaktiske og pædagogiske<br />
strategier. Det vil derfor være nødvendigt at få et indblik i lærerens undervisningsplanlægning.<br />
Indtænkning af lærerens interesser i edutainmentudvikling skaber flere udfordringer. Hvis<br />
spillet skal bruges <strong>som</strong> et professionelt undervisningsværktøj, er det oplagt at tænke spillet <strong>som</strong><br />
en del af et IT-system, der afspejler lærerens behov.<br />
Igennem de seneste 10 til 20 år er fokus indenfor softwareudvikling flyttet fra maskinorienteret<br />
til brugerorienteret udvikling[aaa].<br />
Side 9 / 92
Udvikling af et IT-system - Informatik P2 - Projekt – Feb. - Maj. 2007<br />
Hvor udviklingsfasen tidligere var forbeholdt udvikleren, inddrages produktets slutbruger og<br />
andre interessenter nu oftere og oftere. Fordelen med en sådan tilgang er bla. at der skabes en<br />
større konsistens imellem brugere og interessenters krav og udviklerens produkt. Specielt er<br />
inddragelsen af slutbrugere interessant i forbindelse med udviklings<strong>projekt</strong>er, hvor <strong>projekt</strong>ets<br />
mål er løst defineret, hvilket vi netop anser spil- og i særdeleshed edutainmentudvikling for at<br />
være.<br />
En stor mængde viden vil forhåbentlig fremkomme af kontakten med slutbrugeren. Al<br />
brugerens, såvel lærerens <strong>som</strong> elevens, erfaring med skoleundervisning lader sig imidlertid ikke<br />
uden videre overføre til leg og læring i relation til computermediet[a]. Derfor vurderer vi det til<br />
at være væsentligt at undersøge, hvorledes resultaterne fra <strong>projekt</strong>ets vidensindsamling kan<br />
inddrages aktivt i den efterfølgende design- og produktudviklingsfase. For at sikre at balancen<br />
mellem læring og underholdning opnås, bør en efterprøvning af spildesignet også gennemføres.<br />
I forlængelse af dette forventer vi at kunne opstille nogle specifikke krav til <strong>projekt</strong>ets<br />
systemudviklingsmodel.<br />
Som nævnt ovenfor anses inddragelsen af brugeren <strong>som</strong> særlig væsentlig i forbindelse med<br />
udviklings<strong>projekt</strong>er med meget løst definerede mål. Vi anser det derfor <strong>som</strong> væsentligt, at<br />
brugeren inddrages til afprøvning af produktet inden afslutningen af realiseringsfasen. I<br />
forbindelse med læring ligger der imidlertid en stor udfordring forbundet med aftestningen.<br />
Hvor kriterier for spil kan opsummeres i underholdning, vil edutainment vurderes på både<br />
læringsindhold og underholdningsværdi, hvilket skaber flere faktorer i forhold til evalueringen.<br />
1.3 Problemformulering<br />
For at udvikle et edutainmentspil til 8.klassetrin, er det afgørende at fokusere på inddragelsen af<br />
brugeren under udviklingen. For at kunne skabe et lærerigt computerspil på et tilfredsstillende<br />
niveau, er det nødvendigt at foretage analyser samt test og evaluering af målgruppen, og studere<br />
den teori, der bliver benyttet i forbindelse med edutainment og systemudvikling. Derfor ønsker<br />
vi følgende hovedspørgsmål besvaret.<br />
Hvordan udvikles et edutainmentspil således at teorier for leg, læring, spildesign og de<br />
forskellige interessenters krav indgår balanceret?<br />
Der er i problemanalysen fremsatte problemstillinger, motiverer os til at opstille følgende<br />
underspørgsmål, <strong>som</strong> søges besvaret igennem <strong>projekt</strong>et.<br />
side 10 / 92<br />
● Hvordan kan et edutainmentspil indgå <strong>som</strong> en integreret del af undervisningen i en 8. klasse?<br />
● Hvorledes kan slutbruger og andre interessenter inddrages i udviklingsprocessen?<br />
● Hvilke læringsteorier kan med fordel inddrages i udviklingen af et edutainment produkt?<br />
● Hvordan kan en teoretisk forståelse for leg og spil udnyttes i forbindelse med edutainment?<br />
● Hvordan kan balancen imellem leg/spil og læring fastlægges i udviklingen af edutainment?<br />
● Hvordan kan man sikre at resultaterne af første analysefase indgår aktivt i de efterfølende faser?<br />
● Hvilke særlige krav til systemudviklingsmodellen opstår i en edutainment udviklingsproces?<br />
● Hvordan kan en test af læringsindhold i prototypen gennemføres?
Udvikling af et IT-system - Informatik P2 - Projekt – Feb. - Maj. 2007<br />
Omdrejningspunktet for dette <strong>projekt</strong> er udviklingen af et edutainmentspil. Computerspil er et<br />
komplekst stykke software, der <strong>som</strong> de fleste andre IT-systemer involverer aktiviteter indenfor<br />
områderne analyse, design, implementering og tests. Projektets indhold skal derfor dels være et<br />
studie<strong>projekt</strong>, hvor studiets og personlige læringsmål forfølges, dels et systemudviklings<strong>projekt</strong><br />
der munder ud i en fungerende spilprototype. En del af <strong>projekt</strong>et vil gå ud på at definere en<br />
systemudviklingdmodel inspireret af overordnede system- og spiludviklingsparadigmer, og<br />
moduleret i forhold til edutainment genren særlige krav om integration af læringselementet.<br />
Projektet vil i starten indebære en afsøgning af edutainment feltet for gængse teorier, hvorefter<br />
feltets delområder, læringsteorier samt teorier for leg og spil, undersøges. Denne<br />
vidensindsamling skal sikre en teoretisk forståelse af de begreber, <strong>som</strong> <strong>projekt</strong>et omkredser. I<br />
relation til eksempelvis læring, giver dette en væsentlig forståelse af den terminologi, der<br />
anvendes af lærere eller edutainmenteksperter.<br />
I <strong>projekt</strong>et implementeres edutainment med henblik på en konkret målgruppe, repræsenteret<br />
ved 8. klasses elever. Målgruppen er imidlertid langt fra områdets eneste interessent. For at<br />
undersøge de mulige interessenter for et edutainmentspil til 8. klasser foretages en<br />
interessentanalyse. På den måde findes faktorer for de mennesker og institutioner, der har en<br />
afgørende stemme i forhold til produktet. Blandt interessenterne anses slutbrugeren <strong>som</strong> særlig<br />
vigtig, og vil derfor blive genstand for særlig analyse med formålet at finde ud af, hvordan spillet<br />
skal fange disses interesser og motiverer til læring.<br />
Med de opstillede krav fra målgruppen og andre interessenter samt fra teorier for leg, læring og<br />
spildesign, fås et sammensurium af forskellige konsistente såvel <strong>som</strong> modstridende anbefalinger<br />
for god edutainment. Disse anbefalinger fortolkes og vægtes efterfølgende til en liste af kriterier<br />
relevant i forhold til vores specifikke edutainment udvikling. Med udgangspunkt i disse kriterier<br />
og vores modulerede edutainmentsudviklingsmodel skabes en kravspecifikation, ud fra hvilken,<br />
en implementering gennemføres.<br />
1.4 Projektafgrænsning<br />
Ovenstående problemanalyse og -formulering efterlader os med en meget bred række af<br />
spørgsmål. I følgende afsnit vil vi derfor forsøge at indskrænke og afgrænse <strong>projekt</strong>ets<br />
undersøgelsesfelt.<br />
På grund af den brede et edutainmentudviklings<strong>projekt</strong> afkræver vil væsentlige teoretiske<br />
områder kun blive behandlet overfladisk. Teori for leg og spil vil på den baggrund blive<br />
behandlet fra to vinkler, hvorimod læringen, der i dette <strong>projekt</strong> anses <strong>som</strong> edutainment genrens<br />
bærende element, vil blive anskuet fra en mængde forskellige vinkler uden dog at være alt<br />
omfattende for området.<br />
Da vi på grund af vores valgte målgruppe, 8.klassetrin, arbejder med en specifik og overordnet<br />
homogen aldersgruppe, vil vi i dette <strong>projekt</strong> ikke benytte os af aldersorienterede læringsteorier.<br />
Desuden vil vi arbejde med matematikfag <strong>som</strong> mål for edutainment spillet. Dette skyldes fagets<br />
meget formelle, og relativt simple opgave form, <strong>som</strong> vi mener, ville sikre at en masse ressourcer<br />
ikke forsvinder på opgaveformulering. I forhold til den senere læringstest, er det også en fordel<br />
at vi relativt nemt, i modsætning til f.eks. danskfaget, kan udarbejde ensartede opgaver.<br />
Indsamling af empiri gennem interessentanalyse og målgruppeanalyse vil også blive genstand<br />
for afgrænsning. Af de interessenter, der findes for <strong>projekt</strong>ets produkt, anses spillets målgruppe<br />
samt acceptgiver, for dette <strong>projekt</strong>s mest interessante, hvorfor nærmere undersøgelse bør<br />
gennemføres.<br />
Side 11 / 92
Udvikling af et IT-system - Informatik P2 - Projekt – Feb. - Maj. 2007<br />
Spørgsmålet, der rejses om hvordan et edutainmentspil kan indgå integreret i<br />
undervisningsøjemed besvares kun implicit igennem <strong>projekt</strong>ets analyse aktiviteter. Hovedfokus<br />
for disse aktiviteter er i stedet bygget op omkring målgruppen, og hvordan denne aktivt kan<br />
integreres i udviklingen. Overordnet kan man sige at det spil vi udvikler er elevens spil, hvor<br />
lærerens kun inddrages før spillets start, men ikke under spillet. Dermed menes ikke, at læreren<br />
ikke findes interessant i udviklingsfasen af spillet, men da vi i vores <strong>projekt</strong>, ressourcemæssigt<br />
ikke har haft overskud til at inddrage alle parter i udviklingen af spillets design, arbejdes der<br />
kun indirekte lærerens rolle.<br />
Kravspecifikationen dokumenterer designfasen for <strong>projekt</strong>ets edutainmentspil, og vil ikke<br />
indebære teknisk specifikke krav til produktimplementeringen. Da der er tale om et studie<br />
<strong>projekt</strong> har de værktøjs- og procesmæssige aspekter frem for <strong>projekt</strong>et produkt haft en<br />
fremtrædende rolle. Dette har resulteret i en produktimplementering af mere illustrativ og<br />
undersøgende karakter. Helt konkret har det medført at designidéer af ensartede funktionalitet<br />
ikke er blevet udført. Hovedkravet til produktet har været en fungerende prototype hvilket har<br />
været det bærende element i udvælgelsen af hvilke design idéer, der har skulle implementeres<br />
og hvilke der ikke skulle.<br />
Et eksempel kan ses på figur 1 og figur 2, <strong>som</strong> illustrerer vores overordnede afgrænsning i<br />
forhold til en klassisk systemudviklingsproces.<br />
side 12 / 92<br />
Figur 1: Klassisk model Figur 2: Afgrænset model
2.1 Indledning<br />
Udvikling af et IT-system - Informatik P2 - Projekt – Feb. - Maj. 2007<br />
2.0 Systemudviklingsmodel<br />
Når man skal udvikle et IT-system benyttes forskellige udviklingsmodeller <strong>som</strong> foreskriver,<br />
hvorledes en systemudviklingsprocessen koordineres. Vi har i dette <strong>projekt</strong> ikke været i stand til at<br />
finde anvisninger på systemudviklingsmodeller tilpasset udviklingen af edutainments applikationer.<br />
Vi har derfor sat os <strong>som</strong> mål at sammensætte vores egen model. Udvikling af edutainment<br />
applikationer er en meget sammensat størrelse hvor mange forskellige fagfelter, teoretiske tilgange<br />
og forståelser mødes.<br />
Det vil derfor være vigtigt at vores udarbejdede systemudviklingsmodel tager højde for følgende<br />
væsentlige aspekter:<br />
Faglige læringsmål.<br />
Teorier for leg.<br />
Teorier for spil.<br />
Teorier for læring.<br />
Teorier for edutainment.<br />
Systemudviklingsteorier.<br />
Spiludviklingsteorier.<br />
Multimedieudviklingsteorier.<br />
Vores egne udviklingskompetencer.<br />
Interessenterne.<br />
Udviklingsprocessen vil tage sit afsæt i de gængse overordnede systemudviklingsparadigmer. I<br />
forhold til udvikling af multimedier anser Marie Christensen og Louise Harder i bogen udvikling<br />
af multimedier[c, kp2] de 6 kriterier udgangspunkt, risikovillighed, verifikation, validering,<br />
dokumentation og tid, <strong>som</strong> centrale i forhold til at sammensætte sin systemudviklingsmodel. Da<br />
vi anser multimedier <strong>som</strong> værende edutainment genren tæt, har vi valgt at undersøge de to<br />
typisk brugte systemudviklingsparadigmer nærmere på disse områder. Resultatet af disse<br />
undersøgelser vil være en systemudviklingsmodel <strong>som</strong> efterfølgende videre-formidles. I den<br />
forbindelse vil vi desuden gennemgå udviklingsmodellens forskellige faser og væsentligste<br />
metoder.<br />
Side 13 / 92
Udvikling af et IT-system - Informatik P2 - Projekt – Feb. - Maj. 2007<br />
2.2 Systemudviklingsparadigmer<br />
2.2.1 Vandfaldsparadigmet<br />
I vandfaldsparadigmet gennemgås udviklingsprocessens faser én for én, så hvert trin er<br />
fuldstændigt afsluttet, inden man går videre i processen. Når man er gået videre til et nyt trin,<br />
bør man ifølge modellen ikke gå tilbage i processen. Imod slutningen af hver fase verificerer og<br />
validerer man ens resultater før man går videre.<br />
I verifikationen fokuseres der på selve systemets opbygning, mens valideringen fokuserer på, om<br />
det er det rigtige system, der er under opbygning.<br />
De 7 faser<br />
Som det ses på figur 3 består vandfaldsparadigmet af 7 faser <strong>som</strong> gennemgås nedenfor.<br />
side 14 / 92<br />
● Kravspecifikation: Systemet og kravene til systemet defineres så præcist og detaljeret <strong>som</strong> muligt.<br />
Først efter at alle krav er opstillet afsluttes fasen.<br />
● Design: Blok diagrammer over programmets funktioner, de designmæssige principper, samt<br />
funktioner opstilles.<br />
● Konstruktion: Systemet implementeres og den programmeringsmæssige udvikling gennemføres.<br />
● Integration: Eventuelle programelementer sammensættes og integreres.<br />
● Test: Systemet afprøves, og tidligere opstået fejl findes og rettes.<br />
● Installation: Systemet installeres.<br />
Figur 3: Vandfaldsparadigmet<br />
● Vedligeholdelse: Det færdige system vedligeholdes periodisk.
2.2.2 Prototyping<br />
Udvikling af et IT-system - Informatik P2 - Projekt – Feb. - Maj. 2007<br />
I forhold til vandfaldsparadigmet er der i prototypingparadigmet[jj] ikke klare skel imellem de<br />
forskellige udviklingsfaser. I starten af modellen defineres <strong>som</strong> i vandfaldsmodellen<br />
kravspecifikationen, dog ikke i samme detaljegrad <strong>som</strong> vandfaldsparadigmet hvilket gør det<br />
nemmere senere at ændre og skrive nye krav til systemet.<br />
Allerede fra starten udvikles en prototype, <strong>som</strong> ikke behøver bestå i andet end en enkelt<br />
blyantstegning. Denne testes for fejl og funktioner, før man igen går tilbage til design- og<br />
kravspecifikationsfasen. Denne iterative udviklingsproces gentages derefter indtil man står med<br />
et færdigudviklet system 2 .<br />
En prototype kan altså således strække sig helt fra ”mock-ups” til næsten færdigudviklede<br />
systemer.<br />
Tidligt i et udviklings<strong>projekt</strong> der benytter prototyping, produceres ofte såkaldte ”Throw-away”<br />
prototyper, <strong>som</strong> er hurtige og billige at lave. Disse danner ikke basis for senere prototyper, men<br />
smides væk efter brug.<br />
Figur 4: Prototyping<br />
2 Ofte vil man dog i praksis opleve at den sidste iteration programmeringsmæssigt starter helt fra bunden af, for at sikre et<br />
bedre programdesign.<br />
Side 15 / 92
Udvikling af et IT-system - Informatik P2 - Projekt – Feb. - Maj. 2007<br />
2.3 Faktorer for systemudvikling<br />
I hvert underafsnit er der en kort beskrivelse af hvordan vandfaldsparadigmet og prototyping<br />
forholder sig til faktorerne. Efterfølgende beskrives hvordan vi anskuer faktorerne.<br />
2.3.1 Udgangspunktet<br />
Vandfaldsparadigmet kræver et klart udgangspunkt, det ligger implicit i paradigmet, at man fra<br />
starten kan skrive en detaljeret kravspecifikation, før man går videre i udviklingsarbejdet. Med<br />
prototyping kan man arbejde med et mere diffust udgangspunkt grundet de mindre krav til<br />
kravspecifikationen.<br />
Udgangspunktet er rimeligt diffust i dette <strong>projekt</strong>. Der er ikke at klart billede af hvordan<br />
slutproduktet kommer til at se ud, og ikke klare mål for hvilket funktionalitetsniveau<br />
slutprogrammet vil få. Dette gør det oplagt at benytte en prototype tilgang. Vi anser det også for<br />
nemmere at starte udviklingen efter prototypeparadigmet frem for vandfaldsparadigmet, da der<br />
ikke er så klare retningslinjer for hvornår hvad skal gøres. Dette må ses <strong>som</strong> en fordel for et<br />
uerfarent udviklingsteam, da dette giver mere plads til at begå fejl.<br />
2.3.2 Risikovillighed<br />
Vandfaldsparadigmet opererer med meget lille risikovillighed, hvilket er begrundelsen for at mål<br />
og krav skal være meget klart defineret ved dets start. Paradigmets klare skel imellem de<br />
forskellige udviklingstrin, og deraf krav om at hvert skridt i processen er gennemarbejdet før<br />
man går videre til næste fase, giver ikke meget plads til at ændre fokus og krav midt i processen.<br />
Der er derfor stor risiko forbundet med at skulle fastlægge <strong>projekt</strong>ets mål tidligt i<br />
udviklingsfasen, hvis der ikke kan dannes klarhed om disse mål. Til <strong>projekt</strong>er der har klare mål<br />
er vandfaldsparadigmet derimod velegnet. I prototyping kan man operere med en meget større<br />
risikovillighed, da man ikke skal fastlægge sig på det endelige mål tidligt i processen.<br />
I vores <strong>projekt</strong> er der brug for stor risikovillighed, da mange faktorer gør <strong>projekt</strong>et risikofyldt.<br />
Vores gruppe er tidligt i vores uddannelsesforløb og har derfor stort set ikke nogen erfaring med<br />
udvikling af software, hvor der er flere udviklere involvere. De der har erfaring med<br />
softwareudvikling, har arbejdet med en-mands <strong>projekt</strong>er, og har derfor ikke de kompetencer der<br />
skal bruges i et sådant <strong>projekt</strong>. En anden risiko i <strong>projekt</strong>et er, at vi arbejder med ikke-kendte<br />
værktøjer i udviklingen. Mange at de udviklingsværktøjer vi kommer til at benytte, har vi ikke<br />
erfaring med, og har derfor vanskeligt ved at vurdere hvad der er muligt med dem, og hvor lang<br />
tid de forskellige elementer tager at udvikle.<br />
Der er mange andre risikofyldte faktorer i <strong>projekt</strong>et. Leg, læring og spil elementer er ukendte<br />
områder for os, og derfor områder der kræver, vi tilegner os ny viden. Risikoområderne gør det<br />
vanskeligt for os at lave den detaljerede beskrivelse imellem de forskellige udviklingstrin <strong>som</strong><br />
vandfaldsparadigmet kræver.<br />
2.3.3 Verifikation<br />
Verifikation er et vigtigt punkt i vandfaldsparadigmet, da man her sikrer, at programmet lever<br />
op til den kravspecifikation, man har udviklet ud fra. Ved prototyping træder verifikationen<br />
mere i baggrunden i forhold til validering, da en gennemarbejdet kravspecifikation betyder<br />
mindre, og accept fra brugerne betyder mere. Det betyder at vores fokus vil ligge i validering<br />
frem for verifikation.<br />
side 16 / 92
2.3.4 Validering<br />
Udvikling af et IT-system - Informatik P2 - Projekt – Feb. - Maj. 2007<br />
Med vandfaldsparadigmet har man ikke tradition for at involvere brugeren i udviklingen. Det<br />
kan være vanskeligt at gøre, da man først meget sent i processen har noget, man kan fremvise<br />
for brugerne, og dermed få tilbagemeldinger man kan bruge. Alternativet er det muligt at<br />
involvere personer med kendskab til software udvikling, da de kender værktøjerne man<br />
benytter. Denne ”ekspert” hjælp kan bruges igennem hele udviklingsprocessen. Prototyping<br />
bygger på test af prototyper på forskellige stadier gennem hele udviklingsprocessen. Validering<br />
er et vigtigt punkt set for vores synsvinkel, da vi arbejder inden for et område, vi ikke har<br />
forudgående kendskab til. Desuden er programmet direkte brugerorienteret, hvilket vil sige at<br />
brugeren er i kontakt med programmet under afviklingen, så brugervalidering er vigtig.<br />
2.3.5 Dokumentation og vidensdeling<br />
Dokumentation og vidensdeling er grundlæggende i vandfaldsparadigmet. De klare skel mellem<br />
de forskellige faser og modstanden mod at gå en fase tilbage, betyder at gennemarbejdet<br />
dokumentation er påkrævet.<br />
I prototyping er der traditionelt ikke krav til meget dokumentation og vidensdeling. Projektet er<br />
først og fremmest et studie<strong>projekt</strong>, og det er derfor vigtigt at alle opnår en viden om alle dele af<br />
udviklingsprocessen. Af den grund, vil der være et øget fokus på vidensdelingen og<br />
dokumentation. Dels for at vi forbedre det interne samarbejde, samt dels for at vi efterfølgende<br />
bedre kan dokumentere vores proces.<br />
Udviklingstiden ligger fast i dette <strong>projekt</strong> - vi har et afleveringstidspunkt <strong>som</strong> skal overholdes,<br />
hvilket umiddelbart gør vandfaldsparadigmet med en stramt styret tidsplan oplagt. Selv om<br />
afslutningstidspunktet ligger fast i dette <strong>projekt</strong>, er der ikke klare definerede krav, om hvilket<br />
funktionalitetsniveau programmet skal have, til afleveringen, hvilket igen lægger op til<br />
prototyping paradigmet.<br />
2.4 Projektets systemudviklingsmodel<br />
Det er åbenlyst at det mest oplagte udviklingsparadigme i dette <strong>projekt</strong>, er prototypeparadigmet. I det<br />
følgende afsnit vil den kommende udviklingsproces blive beskrevet og diskuteret. Desuden vil der<br />
systemudviklingsmodellens udviklingsfaser blive beskrevet i detaljer.<br />
2.4.1 Udviklingsfaser<br />
Udviklingsprocessen inddeles i forskellige faser. Ved starten af hver fase beskrives produktet,<br />
kravene dertil samt en dato for afslutning af fasen. Vi vil bestræbe os på at afslutte alle faser med<br />
et produkt der opfylder de for fasen fastsatte krav/mål. Tidsplaner i software<strong>projekt</strong>er har det<br />
med at skride, hvilket er argumentet for at afslutningstidspunktet fastlægges fra fase til fase.<br />
Imidlertid vil vi sandsynligvis alligevel opleve faser, hvor alle kravene ikke er opfyldt. Efter<br />
afslutning på en fase, evalueres produktet i henhold til kravene. Resultatet af evalueringen<br />
danner grundlag for målene i den næste fase. Produktet, <strong>som</strong> skal færdiggøres i næste fase, og<br />
kravene dertil beskrives, og der fastsættes et sluttidspunkt for fasen.<br />
Side 17 / 92
2.4.2 Fasebeskrivelse<br />
Udvikling af et IT-system - Informatik P2 - Projekt – Feb. - Maj. 2007<br />
Vi har valgt at benytte en delvis interaktiv udviklingsmodel hvor vidensindsamlings- og<br />
analysefasen gennemløbes en enkelt gang, hvorefter 2 iterationer af de efterfølgende<br />
udviklingsfaser gennemløbes. At vi har valgt ikke at lade den første faser være en del af<br />
iterationen skyldes vores målet om at få leg, læring og computermediet til at blive en samlet<br />
enhed[a, s280]. Ville vi efterfølgende vende tilbage til vidensindsamlings- og analysefasen, ville<br />
vi enten løbe en risiko for ikke at kunne skabe denne større enhed, fordi den tidligere læsning<br />
var glemt, eller vi vil være tvunget til på ny at sætte os grundigt ind i teorierne, hvilket vil tage<br />
unødvendigt mange ressourcer fra <strong>projekt</strong>et.<br />
Projektets faser:<br />
1. Vidensindsamling og analyse<br />
2. Idé-udvikling og design<br />
3. Implementering<br />
4. Test<br />
5. Evalueringen<br />
Hvor meget arbejde der vil ligger i hvert trin afhænger i høj grad af evaluering af den foregående<br />
fases. F.eks. kan man forestille sig at idéudviklingstrinnet være mindre i sidste fase end i første<br />
fase. Mens der sandsynligvis vil blive brugt mere energi i implementeringstrinnet sidste fase<br />
frem for den første.<br />
2.4.2.1Vidensindsamling og analyse<br />
Vidensindsamling og analyse placeres almindeligvis i to forskellige faser. Vi vurderer imidlertid<br />
at det, grundet de for os mange ukendte områder, vil være ugunstigt at holde de 2 punkter<br />
adskilt. I praksis vil der derfor mere være tale om et iterativt forløb, hvor teori læses og<br />
efterfølgende udnyttes hvorefter et nyt felt inddrages 3 .<br />
I analysefasen agter vi blandt andet at inddrage allerede eksisterende analyser og statistikker,<br />
samt at gennemføre vores egne teoretiske og empiriske analyser - blandt andet i form af en<br />
fokusgruppe analysen.<br />
2.4.2.2Idé-udvikling og Design<br />
I idéudviklingen udvikles idéerne til produktet. Den viden der er indsamlet i analysefasen<br />
benyttes til at skabe et spilkoncept. F.eks. vil teorierne for leg, læring og spildesign samt andre<br />
konklusioner fra analysetrinnet kunne inddrages. Vi har valgt at slå idé-udvikling og designfasen<br />
sammen, da en stor del af første trin i designfasen, spilkoncept, afdækkes i idéudviklingsfasen.<br />
Da det er vores overbevisning, at et stærkt koncept væsentlig forsimpler den efterfølgende<br />
designproces, har vi dog valgt at supplere idé-udviklings produkt med aspekter fra spilkoncept<br />
trinnet 4 .<br />
Vi anser designprocessen <strong>som</strong> en meget stor del af udfordringen der ligger i at få leg, læring,<br />
spildesign samt interessenternes krav til at indgå balanceret i udviklingsprocessen. I vores<br />
arbejde med <strong>projekt</strong>ets overordnede problemstilling anser vi specielt designfasen <strong>som</strong> central.<br />
Vores designproces er domineret af udviklingen af en kravspecifikation. En kravspecifikation<br />
beskriver <strong>som</strong> oftest alle opgaver, der indgår i udviklingen af et nyt IT-system.<br />
3 Bemærk at dokumentationen for valg af vidensindsamlingsmetoder, på grund af basis årets struktur, befinde sig i<br />
<strong>projekt</strong>ets procesanalyse.<br />
4 Vores valgte idéudviklingsteknik er udviklet med inspiration fra bogen Udvikling af multimedier og er tilgængelig i bilag 4.<br />
side 18 / 92
Udvikling af et IT-system - Informatik P2 - Projekt – Feb. - Maj. 2007<br />
Det skyldes, at målet er at give udvikleren indblik i alle behov og krav for produktet, så denne<br />
bliver i stand til at designe en løsning <strong>som</strong> matcher behovene. Det er altså en vidensoverførsel<br />
fra den ene fase til den anden.<br />
Til dette <strong>projekt</strong> vurderes at en sådan tilgang bliver for stram og unødvendig. Grunden er<br />
primært, at <strong>projekt</strong>gruppen både foretager analyse, design og implementering, og på den måde<br />
vil være til stede i alle systemudviklingens faser. Det vil også sige, at der ikke sker nogen<br />
vidensoverførsel fra ”designer” til ”udvikler”, <strong>som</strong> i de fleste andre IT-<strong>projekt</strong>er. Der er valgt en<br />
ikke fastlåst tilgang, hvor der selvom <strong>projekt</strong>et er i implementeringsfasen, er mulighed for at<br />
foretage løbende designovervejelser med hensyn til spillet og læringens integration med det.<br />
Derfor vil man heller ikke kunne se en kravspecifikation, <strong>som</strong> den forventes med krav til<br />
systemet opstillet punkt efter punkt, men i stedet en mere sproglig opsummering af de valg der<br />
er truffet. Vores udgangspunkt for kravspecifikationen er Andrew Rollings og Ernest Adams<br />
(R&A) 6 faser for spiludvikling i et efterfølgende kapitel [f]. Disse faser afdækker fra vores<br />
synspunkt de vigtigste aspekter af en spiludvikling.<br />
Samtidig afsluttes R&A gennemgangen af hver fase, med en lang række spørgsmål <strong>som</strong><br />
afdækker de væsentligste aspekter i kapitlet. Da arbejdsgruppens tidligere erfaring med design<br />
af spil er meget begrænset, anser vi disse spørgsmål <strong>som</strong> en oplagt teknik til at sikre at<br />
væsentlige aspekter af designfasen ikke glemmes. R&As udviklingsmetode er imidlertid en<br />
spiludviklingsmetode. Vores design proces vil derfor bestå af en gennemarbejdning af<br />
ovenfornævnte spørgeark integreret med produktet af analysefasen. Produktet vil helt konkret<br />
materialisere sig i en udarbejdet liste af kriterier for udvikling af edutainment. Denne liste vil<br />
under hele designfasen være ophængt i forstørret udgave i vores arbejdslokales, så vi under<br />
arbejdet hurtigt kan inddrage vores analysearbejde i processen. Ligeledes vil den 6. fase,<br />
balanceringen, almindeligvis først for alvor blive inddraget i de afsluttende iterationer af en<br />
udvikling, da der under de første udviklings iterationer løbende vil skabes ubalance i spillet når<br />
nye spilelementer tilføjes. På grund af <strong>projekt</strong>ets korte forløb er det derfor muligt, at denne fase<br />
ikke eksplicit vil blive berørt.<br />
2.4.2.3Implementering<br />
I Implementeringsfasen realiseres det foregående design. Vi vil benytte et problemorienteret<br />
udgangspunkt, hvorfor vores implementering hele tiden vil tage udgangspunkt i en afgrænset og<br />
konkret programmeringsmæssig problemstilling oplevet i designfasen. Med jævne mellemrum<br />
vil vi samle disse forskellige kodestumper i builds for at sikre, at de forskellige kodestumper<br />
også fungerer sammen. Udover den kodemæssige implementering vil udarbejdelsen af de<br />
grafiske elementer også finde sted i denne fase. Fasen afsluttes med, at fokuset for den<br />
efterfølgende prototypetest fastsættes.<br />
2.4.2.4Prototyperne<br />
Vi vil udvikle 2 prototyper med tilhørende prototypetest, hvor af den sidste bliver <strong>projekt</strong>ets<br />
slutprodukt. I de 2 tests vi ønsker at gennemføre, vil vi fokusere på forskellige aspekter af<br />
programmet. Første prototypetest vil i vores <strong>projekt</strong> lægge sig i forbindelse med<br />
statusseminaret, hvilket gør det nemt for os at samle eksperter (vejledere) samt andre grupper<br />
til testen. Testen vil bestå i en designtest, hvor en simpel prototypetilstand præsenteres<br />
hvorefter evaluatorerne giver feedback på det grundlæggende koncept af de udefrakommende<br />
deltagere. Begrundelsen for at teste konceptet er at vi vurderer, et stærkt og gennemarbejdet<br />
koncept, til at kunne spare os for mange efterfølgende diskussioner. Desuden er området relativt<br />
overordnet og klart afgrænset så det er nemt for udefrakommende at sætte sig ind i det. Anden<br />
prototype test fokus vil blive spillets funktionalitet samt læringspotentialet. Prototypen vil bestå<br />
af en ”final” build <strong>som</strong> en gruppe elever vil få mulighed for at prøve kræfter med.<br />
Side 19 / 92
2.4.2.5Evalueringen<br />
Udvikling af et IT-system - Informatik P2 - Projekt – Feb. - Maj. 2007<br />
I afslutningen af hver iteration gennemføres en evaluering af de opnåede resultater. Disse<br />
evalueringer har til formål både at kigge tilbage, og evaluere resultaterne i forhold til de krav<br />
<strong>som</strong> blev defineret i starten af iteration, samt kigge fremad og inddrage resultaterne i<br />
planlægningen af næste fase.<br />
side 20 / 92
3.1 Indledning<br />
Udvikling af et IT-system - Informatik P2 - Projekt – Feb. - Maj. 2007<br />
3.0 Edutainment<br />
En af de problemstillinger der ønskes belyst med <strong>projekt</strong>et er, hvordan en hensigtsmæssig balance<br />
mellem leg, spil og læring opnås. For at komme nærmere et svar på om hvordan og det overhovedet<br />
kan lade sig gøre, må der ses på hver af de komponenter, <strong>som</strong> balancen skal finde sted imellem.<br />
Begrebernes opståen og deres anvendelse må nødvendigvis gennemgås, for at en forbindelse kan<br />
skabes mellem dem.<br />
Mødet imellem forskellige teoretiske retninger er traditionelt fører til dogmatisme. Sociolog og<br />
videnskabsteoretisk systemteoretiker Niklas Luhmann[kk], præsenterer os for et alternativ til<br />
dette. Luhmanns påstand er, at benyttelsen af overlappende teorier ikke blot skaber en større<br />
forståelse af emnet <strong>som</strong> når sideløbende teorier benyttes. Ydermere skabes der også en form for<br />
synergi i teoriernes ”brænding”. Teoriernes forskelligartede tilgang til emnet ”irriterer”<br />
hinanden og tvinger dermed forskeren til at skaffe sig en større forståelse af emnet. Ved at<br />
belyse emnet fra 2 forskellige vinkler tvinges vi til at skabe en 3. og større forståelse af emnet.<br />
Figur 6: Klassisk tilgang<br />
Figur 5: Luhmannsk tilgang<br />
Edutainmentspillet er i sin natur et meget sammensat felt der både består af mange forskellige<br />
teoretiske retninger. Vi anser derfor Luhmannsk tilgang <strong>som</strong> værende ekstra interessant i netop<br />
vores tilfælde, hvorfor vi i det følgende afsnit vil benytte en Luhmannsk tilgang. Et eksempel på<br />
en Luhmannsk tilgang ser vi på figur 6, <strong>som</strong> viser overlapningen af diverse teori, der tilsammen<br />
danner grundlag for en større forståelse.<br />
Side 21 / 92
3.2 Leg<br />
Udvikling af et IT-system - Informatik P2 - Projekt – Feb. - Maj. 2007<br />
Leg er en fundamental del af den menneskelige udvikling, idet legen forbereder os til udfordringer i<br />
det virkelige liv.<br />
Når vi leger, lærer vi hvordan vores verden er sammenbundet, og opnår dermed en forståelse af den<br />
verden omkring os. En hollandsk historiker, Johan Huizinga definerede allerede i 1930’erne leg <strong>som</strong><br />
et centralt element i den menneskelige kultur, hvor alt fra kunst til naturvidenskab har sin<br />
oprindelse. Sammen med den franske sociolog Roger Caillois, etablerede de teorier for leg, <strong>som</strong> vil<br />
blive gennemgået i det følgende. En simpel definition får vi dog fra Jørn Møller, <strong>som</strong> i sit arbejde<br />
<strong>som</strong> forsker for institut for Forskning i Idræt og Folkelig Oplysning (IFO), har udarbejdet følgende<br />
definition [lm].<br />
Proces / resultat > 1 = Leg<br />
Ovenstående ”matematiske” definition, udtrykker at processen, selve legen, skal være vigtigere<br />
end resultatet eller produktet for at vi taler om leg.<br />
En mere detaljeret forståelse af legens væsen opnås ved indragelse af Caillois' 6 krav for leg [dp]:<br />
Fri Leg skal være fri, idet den er tilbøjelig for at tabe værdi, når den baseres på<br />
tvang.<br />
Separeret Leg skal være defineret ud fra dens egen verden og tid, uafhængigt af den<br />
virkelige verden.<br />
Usikker Leg skal ikke have noget specificeret forløb, samt resultatet skal være<br />
uforudsigelig.<br />
Samtidig skal spillere have mulighed for at komme med nye tiltag, <strong>som</strong><br />
ændrer spillets udvikling.<br />
Uproduktiv Legen skal ikke producere produkter, <strong>som</strong> har værdi udenfor legens verden<br />
Regelstyret Leg skal være styret af egne regler. Ordinære regler er afskaffet og kun regler<br />
for legen er gældende.<br />
Fiktiv Leg skal foregå i en sekundær fri virkelighed, der accepteres af alle legens<br />
deltagere.<br />
3.2.1 Ludus og Paidia<br />
Caillois definerer i forlængelse af ovenstående legens frihedsgrad ved hjælp af to ekstremer –<br />
Ludus og Paidia[a, s71-78].<br />
3.2.1.1Ludus<br />
Denne form er leg styret af klare retningslinjer og regler, der ofte er prædefinerede områder <strong>som</strong><br />
skaber spillets opbygning. Ludus leg, er ofte de vi betegner <strong>som</strong> spil, idet det udover at følge<br />
legens regler, er styret af nogle klart definerede mål <strong>som</strong> skal løses. Eksempler på leg <strong>som</strong> går<br />
mod ekstremet Ludus, er håndbold, fodbold eller basket, hvor sidstnævnte mål er at få bolden i<br />
kurven for derved at score point. Ved spillet slutning tælles pointene sammen og det hold <strong>som</strong><br />
har flest point vinder kampen.<br />
side 22 / 92
3.2.1.2Paidia<br />
Udvikling af et IT-system - Informatik P2 - Projekt – Feb. - Maj. 2007<br />
Denne form er den mest frie form for leg, hvor der er meget få retningslinier for legen. Det er<br />
ustruktureret og improviseret leg. Eksempler på leg <strong>som</strong> går mod ekstremet Paidia er rollespil,<br />
hvor den narrative historie er fri af prædefinerede regler.<br />
I realiteten er ekstremerne Ludus og Paidia hypotetiske, ingen spil kan eksistere fuldstændig<br />
regelsat eller regelløst. Derfor mikses der imellem de to ekstremer når leg og spil beskrives. I<br />
computerspillets verden befinder de fleste spil sig til ludus-siden, dog opstår Paidia-muligheder,<br />
når spilleren har mulighed for at skabe sit eget spil, for eksempel ved hjælp af ”map-editors”, der<br />
tillader spilleren at bygge sine egene baner.<br />
3.2.2 Legetyper ifølge Caillois<br />
På baggrund af de to ekstremer har Caillois defineret nogle legetyper[dp]:<br />
3.2.2.1Agôn<br />
Denne type af leg, er baseret på konkurrence med målet at vinde. Agön er ofte fysiske med klare<br />
regler og retningslinier der er med for at gøre det ligeligt for alle deltagere. Et eksempel kan<br />
være fodbold, hvor reglerne er lige for begge hold, og forskellen imellem spillerne dermed bliver<br />
deres færdigheder. Læringspotentialet i Agön er her, opøvelse af konkrete færdigheder <strong>som</strong><br />
f.eks. indkast, skud på mål og hjørnespark og ofte defineret <strong>som</strong> træning.<br />
3.2.2.2Alea<br />
I Alea afgøres vinderne og taberne ikke af deltagerne, men af tilfældigheder. Denne type leg,<br />
fokuserer modsat Agön, ikke på deltagernes fysik og psyke, men på sandsynlighed og held. Et<br />
eksempel på Alea-typen er spil <strong>som</strong> roulette, blackjack og spillemaskiner, hvor det er umuligt<br />
selv at påvirke resultatet. Læringspotentialet indenfor Alea er spekulationer og<br />
risikoberegninger.<br />
3.2.2.3Mimicry<br />
Denne type leg, omhandler skuespil og simulation. Idet man skaber fiktive realiteter skabes der<br />
en mulighed for at spille rollespil, og træde ind i en anden persons virkelighed. Reglerne har ofte<br />
til formål at sikre at illusionen bibeholdes.<br />
Et eksempel på mimicry leg er ”Politi og Røvere”, hvor deltagerne påtager sig en rolle og<br />
foregiver at opføre <strong>som</strong> denne indenfor nogle givne regler. Læringspotentialet er socialitet,<br />
psykologi og fantasi.<br />
3.2.2.4Ilinx<br />
Ilinx, i daglig tale også kaldet rusleg, er en leg hvis mål er at skabe et ”sus” for deltagerne i legen.<br />
Ekstreme oplevelser, <strong>som</strong> bongy-jumping, faldskærmsudspring og ture i store karruseller og<br />
rutsjebaner er alle eksempler på Ilinx-leg. Læringspotentialet i Ilinx er selvkontrol samt<br />
overskridelse af grænser.<br />
Side 23 / 92
Udvikling af et IT-system - Informatik P2 - Projekt – Feb. - Maj. 2007<br />
Genre Typer Eksempel Læringspotentiale<br />
Agôn Konkurrence Fodbold Opøvelse af konkrete færdigheder<br />
Alea Chance Væddemål og lotteri Spekulationer og risikoberegning<br />
Mimicry Rolleleg Rolleleg og teater Socialitet, psykologi og fantasi<br />
Ilinx Rusleg Bongijump og skating Selvkontrol og overskridelse<br />
3.2.3 Legetyper ifølge Knud Rasmussen<br />
Tabel 1: Legetyper ifølge Knud Rasmussen<br />
Danske Knud Rasmussen [b, s40] har ligeledes defineret leg i forhold til forskellige stadier i de<br />
tidligere år af barndommen, se tabel 1.<br />
3.2.3.1 Sanseleg<br />
Sanselegen er barnets manipulation med genstande i løbet af de første 2 leveår. Det kan være<br />
svært at fortolke hvornår noget er leg, men det er tydeligt, at barnets adfærd er engageret og<br />
vedholdende.<br />
3.2.3.2 Funktionsleg<br />
Funktionslegen påbegyndes efter de 2 leveår er barnet, hvor barnet har mulighed og er udviklet<br />
til at bruge legegenstande frem for hidtil at føle og mærk genstandene. Her mødes andre børn og<br />
leger sammen med samme genstande, men ikke i samarbejde, og stadig i en egocentreret<br />
verden.<br />
3.2.3.3 Rolleleg<br />
Fra 3. Til 5. leveår udvikles rollelegen, hvor forestillinger og fantasi udvikles og indlæres. Dette<br />
sker på baggrund af at sprogligheden får vigtigere placering i legen samtidig med at socialiteten<br />
øver indflydelse. Fra 5. til 7. leveår udvikles rollelegen videre i kønsopdelte roller, og barnet får<br />
mulighed for at anskue sin verden <strong>som</strong> fiktion. Et eksempel på dette er legetøjet, <strong>som</strong> i<br />
fiktionsverdenen bliver en realitet.<br />
3.2.3.4 Konstruktionsleg<br />
Konstruktionslegen udvikles samtidigt med rollelegen, hvor det at skabe noget, giver glæde til<br />
barnet. Til denne form for leg hører al kombinatorik <strong>som</strong> f.eks. til Lego, hvor små dele bliver til<br />
en større helhed.<br />
3.2.4 Knud Rasmussen og Roger Caillois<br />
Sammenlignes de to ovenstående legetyper ses det at rollelegen og mimicry afspejler samme<br />
type leg hvor fiktion og indtagelse af roller er det bærende. Derudover ses det at de to forskellige<br />
definitioner af legetyper ikke uden videre lader sig sammenligne. Grunden til dette kan skyldes<br />
at Rasmussen benytter en pædagogisk synsvinkel, der sætter en sammenhæng imellem<br />
udvikling og alderstrin, hvor Caillois i modsætning fuldstændig undlader at inddrage disse [b,<br />
s41]. Man kan argumentere for at Rasmussens udviklingsperspektiv er irrelevant i forhold til<br />
<strong>projekt</strong>et, da målgruppen for spillet befinder sig væsentligt over disse alderstrin. Rasmussens<br />
tilgang viser dog at vi mennesker også finder underholdning ved at konstruere ting.<br />
side 24 / 92
3.3 Spilteori<br />
Udvikling af et IT-system - Informatik P2 - Projekt – Feb. - Maj. 2007<br />
Spil er ifølge Chris Crawford [e, s5] en fundamental del af menneskets eksistens. Han belyser denne<br />
forankring ved at give eksempler på talemåder hvor spil optages i det amerikanske sprog. Noget<br />
lignende er at finde i den danske sprogbrug. Det spiller en vigtig rolle... sådan er spillets regler...<br />
spillet er slut for ham... politisk spil... det var aftalt spil er bare nogle få udtryk. Crawford<br />
karakteriserer et spil med begreberne repræsentation, interaktion, konflikt og sikkerhed, <strong>som</strong><br />
gennemgås i det følgende.<br />
3.3.1 Repræsentation<br />
Begrebet repræsentation, dækker over den måde vi opfatter spil på. Først og fremmest er et spil<br />
et lukket formelt system der på en subjektiv måde repræsenterer en afgrænset del af<br />
virkeligheden udenfor spillet[e, s7]. Repræsentationen giver sig udslag i formaliteter, altså et<br />
regelsæt, og systematik i den forstand at spillet består af dele der kan interagere med og påvirke<br />
hinanden. Et spil er ofte en subjektiv repræsentation, i modsætning til en simulation der<br />
forsøger at skabe en så vidt mulig virkelighedstro afbildning. Et spil er præget af et bestemt<br />
fokus og en bestemt stil, <strong>som</strong> understøtter spillerens egen fantasi indenfor spillets rammer.<br />
”Spillerens fantasi er en nøglefaktor til at gøre spillet psykologisk virkeligt” [e, s9]<br />
Endelig er et spil en afgrænset del af virkeligheden. Til dette giver Crawford to grunde, dels at<br />
intet spil vil kunne udgøre hele virkeligheden uden at være virkeligheden selv, dels at en<br />
afgrænsning af virkeligheden skaber fokus på det væsentlige. Hvis et spil repræsenterer en for<br />
stor del af virkeligheden, kan spil og virkelighed i sidste ende blive svære at adskillelige, og<br />
spillet vil miste den appel der ligger i fokuseringen og karikeringen af virkelighedsbilledet.<br />
3.3.2 Interaktion<br />
Interaktion omhandler brugerens mulighed for at påvirke en handling eller proces. Modsat film<br />
<strong>som</strong> er sekventiel og kontinuert, er spil et hypertekstueltmedie hvor fortællingen kan gå i<br />
forskellige retninger, på baggrund af spillerens valg. Disse valg kan herefter udløse forskellige<br />
mekanismer, <strong>som</strong> gør at spillet kan synes at rumme et interpersonelt element på trods af at<br />
mange computerspil spilles alene.<br />
”Interaktion tilføjer et socialt eller interpersonelt element til handlingen. Den<br />
forvandler udfordringen fra at være teknisk til at være interpersonel [...] Interaktion<br />
forvandler udfordringens natur fra at være passiv til at være en aktiv udfordring.” [e,<br />
s12]<br />
Med en aktiv udfordring menes en modstand i spillet <strong>som</strong> kan have nogle af de samme<br />
egenskaber <strong>som</strong> spilleren selv. Denne modstand kan repræsenteres ved medspillere eller<br />
computere.<br />
3.3.3 Konflikt<br />
I processen hvor en eller flere spillere søger at gennemføre et spil og dermed interagerer med<br />
spillet, vil der i et vellykket spil opstå en større eller mindre konflikt. Konflikten skal fungere<br />
<strong>som</strong> forhindring for spilleren i at nå spillets mål. Konflikterne i den virkelige verden er indirekte<br />
og <strong>som</strong> oftest spredt over tid. De mangler ofte en løsning, og man oplever sjældent en direkte<br />
sejr over hverdagens konflikter.<br />
”Vi opnår små successer på nogle områder, men problemerne fortsætter uden rigtigt at<br />
blive løst. Da et spil er en subjektiv repræsentation af virkelighedens verden, retter de<br />
vores opmærk<strong>som</strong>hed på et særligt aspekt af verden, ved at fremhæve dette aspekt.”[e,<br />
s 13]<br />
Side 25 / 92
Udvikling af et IT-system - Informatik P2 - Projekt – Feb. - Maj. 2007<br />
Crawford nævner endvidere at disse særligt fremhævede aspekter ofte giver sig til kende i vold.<br />
Grunden til at vold ofte anvendes i spil, er at det er det mest synlige og naturlige udtryk for en<br />
konflikt. Set i lyset af spilgrafikkens og lydsidens øgede kvalitet siden denne konklusion blev<br />
draget, vil man i dag bedre kunne udvikle et spil, hvor konflikten kommer til udtryk på andre<br />
måder. Spillet The Sims [gg], <strong>som</strong> handler om det at få en familie til at fungere på godt og ondt,<br />
er et godt eksempel herpå.<br />
3.3.4 Sikkerhed<br />
Den sidste ting der kendetegner spil er sikkerhed. Da spillet kun skildrer en del af virkeligheden,<br />
går de fleste spillere ind i en mission eller opgave med større mod og entusiasme. Man ved at<br />
man i spillet ikke risikerer noget tab i virkelighedens verden, andet end den brugte tid eller<br />
indsats. Spilleren sætter ikke alt over styr, når han indvilliger i spillets rammer. Omvendt er der<br />
heller ikke nogen belønning for at vinde spillet udover æren.<br />
”I næsten alle spil er belønning og straf systemet positivt. Det vil sige, at taberen ikke<br />
straffes for at at tabe, men vinderen belønnes for at vinde. Det eneste taberen mister, er<br />
den indsats han gjorde for at komme til at spille spillet, så<strong>som</strong> et væddemål eller en<br />
betaling.” [e, s14]<br />
De spil hvor belønningen ved at vinde og konsekvensen ved at tabe, gør en væsentlig forskel i det<br />
virkelige liv, placerer sig selv i en gråzone i forhold til legebegrebet. I gambling, eller førnævnte<br />
legetype ”Alea” 5 hvor motivet for at spille ikke kun er den rus man kan føle når man tager en stor<br />
risiko eller chance, men også ofte et håb om at blive rig.<br />
3.3.5 Hvorfor spiller vi?<br />
Der synes at være mange forskellige grunde til at vi giver os i kast med et spil. Nogle af grundene<br />
er anskueliggjort i de fire begreber, der ifølge Crawford, til sammen manifesterer et spil. Spillet<br />
er en subjektiv repræsentation, der understøtter spillerens fantasi. Interaktion tilføjer et<br />
interpersonelt – eller om man vil – socialt element. Spillet kendetegnes ved sikkerhed, og med<br />
andre ord er spillet et virtuelt rum hvor mennesket kan udfolde sig uden at det har konsekvenser<br />
i virkeligheden.<br />
Alligevel argumenterer Crawford at der eksisterer en grundlæggende årsag til menneskets brug<br />
af spil.<br />
”Spil er det ældste og mest anvendte værktøj til uddannelse. Det er den originale<br />
uddannelsesteori, den mest naturlige, blåstemplet af naturens egen udvælgelsesproces.<br />
Vi ser ikke løvemødre undervise løveunger med tavle og kridt... Set i det lys bliver<br />
spørgsmålet, ”Kan spil have undervisningspotentiale?” ganske absurd. Det er ikke spil<br />
men skolen der er et nymodens begreb, den uprøvede dille, et brud på traditionen. At<br />
spille spil er en kraftfuld uddannelsesfunktion for ethvert væsen der er i stand til at<br />
lære.”[e, s16]<br />
At vi først og fremmest spiller spil for at lære, bekræfter at spil er en del af legebegrebet. Med<br />
denne ”ur-årsag” for spillets berettigelse er andre motiver imidlertid ikke afskrevet. På samme<br />
måde <strong>som</strong> man i madkulturen i høj grad dyrker det æstetiske i selve tilberedningen og det<br />
sociale ved spisningen, ændrer dette ikke på hovedårsagen til at vi spiser, nemlig kroppens<br />
behov for næring.<br />
5 Se kapitel om Leg<br />
side 26 / 92
3.4 Læring<br />
Udvikling af et IT-system - Informatik P2 - Projekt – Feb. - Maj. 2007<br />
Edutainment er <strong>som</strong> nævnt i indledningen en kobling af computerspil, leg og læring. Vi vil i det<br />
følgende afsnit forsøge at belyse læringsdelen. Der forelægger stadig meget begrænset forskning om<br />
læring i sammenhæng med edutainment[b, s77]. Vi vil derfor i det følgende, ved hjælp af en bred<br />
tilgang til læringsfeltet undersøge de gængse læringsteoriers potentiale i edutainment øjemed.<br />
I nyere tid benyttes ofte triadeforståelsen af læring repræsenteret ved den kognitivistiske,<br />
psykodynamiske samt sociale og samfundsmæssige forståelse af læring. Den tredimensionelle<br />
tilgang kan desuden retfærdiggøres, idet forståelsen ikke kun knytter sig til læring, men også til<br />
andre nærliggende områder. Som eksempel kan nævnes udviklingspsykologien, hvor man<br />
arbejder med mennesket <strong>som</strong> et biologisk, et psykologisk og et socialt væsen[nn].<br />
Vi vil i det følgende, for overskuelighedens skyld, forsøge at sondre i mellem disse læringspoler.<br />
Af disse tre er kognitivismen den, <strong>som</strong> har været genstand for mest forskning, og det er derfor<br />
også den retning, <strong>som</strong> bringer os flest læringsteorier og metoder[b, s77]. Hvad angår de andre<br />
poler, <strong>som</strong> findes, er læringsteorierne mere specifikke i relation til edutainment.<br />
Knud Illeris, der er forfatter og forsker ved Roskilde Universitet, betragtes <strong>som</strong> en anerkendt<br />
stemme inden for dette felt. Han illustrerer det tredimensionelle læringsbegreb ved hjælp af<br />
følgende figur.<br />
Figur 7: Læringstrekanten<br />
De to øverste poler er begge psykologiske og<br />
udgør sammen den psykiske tilegnelsesproces.<br />
Den underliggende modpol er det sociale og<br />
samfundsmæssige, <strong>som</strong> dækker over læringens<br />
sociale samspilsproces. Idet mennesket er et<br />
individ, der er udviklet i en samfundsmæssig<br />
kontekst, vil der dog altid være et<br />
samfundsmæssigt element repræsenteret i de to<br />
øverste poler[d, s18-19]. Illustrationen skal ikke<br />
blot forstås <strong>som</strong> en bekræftelse på at læring er<br />
præget af forskellige filosofier eller teorier, men<br />
<strong>som</strong> en grundlæggende og samlet opfattelse, hvis<br />
komponenter ikke kan adskilles.<br />
”Læring er altid på en gang en kognitiv, psykodynamisk og en social, samfundsmæssig proces<br />
[...] Det er vigtigt her at understrege at de tre dimensioner indgår på en integreret måde i al<br />
læring, og at dimensionerne ikke i praksis forekommer <strong>som</strong> separate funktioner.”[d, s19]<br />
Læring vil i praksis dog sjældent være så komplet <strong>som</strong> den tager sig ud her. Afhængig af<br />
læringssituationen, læringsstoffet og den lærende, varier trekantens siders længde.<br />
3.4.1 Psykodynamikken 6<br />
Psykodynamikken omhandler bevæggrunde eller motivationer for menneskets handlinger.<br />
Motivation er eksistentiel i læring, og endnu mere væsentlig i edutainment <strong>som</strong> netop er et<br />
forsøg på at kombinere læringen med motiverende leg og spil. For at kunne definere det mere<br />
specifikt har vi taget udgangspunkt i Thomas Ziehes psykodynamiske teorier for læring.<br />
6 Det følgende afsnit bygger på D&A gennemgang af Ziehe[b, s89-94]<br />
Side 27 / 92
Udvikling af et IT-system - Informatik P2 - Projekt – Feb. - Maj. 2007<br />
Ifølge Ziehe indeholder et hvert menneske til enhver tid to modsatrettede psykologiske behov:<br />
1. Regression: Et behov for at slappe af hvor det handler om blandt andet søgen efter tryghed,<br />
uforandrethed og gentagelse, altså en søgen efter sikkerhed.<br />
2. Progression: Et behov, hvor man er fremadrettet og udviklingssøgende. Progression tilstanden<br />
betegnes også <strong>som</strong> den risikofyldte tilstand fordi det er i denne tilstand man bevæger sid uden for<br />
sin sikkerhedszone.<br />
De to behov er lige væsentlige og underbygger hinanden, da det for at motivere læring er<br />
væsentligt, at individet oplever regressive perioder præget af sikkerhed og nydelse af de oplærte<br />
egenskaber. Derigennem opnås ny energi, <strong>som</strong> er nødvendig for den videre læring. Regressionen<br />
ses derfor f.eks. ofte i repetitionen, hvad enten denne består af gentagelse eller opgaveregning,<br />
der begge lader eleven bevæge sig indenfor allerede lært stof.<br />
Tages Ziehes teorier for pålydende, vil det i opbygningen af et edutainment spil være væsentligt<br />
at indbygge regressive perioder, hvor den nytillærte viden nydes og afprøves. Samtidig bør man i<br />
designet forsøge at overbevise eleven om at målet er opnåeligt. Dog kan man, pga. af vores<br />
samfundsopbygning, argumentere for, at en stor del af menneskelige regression normalvis<br />
foregår udenfor skolen.<br />
3.4.2 Kognition<br />
Det anden pol i Illeris trekant er kognitivismen, <strong>som</strong> de sidste 50 år har haft en stor<br />
forskningsmæssig bevågenhed. Det omhandler intellektuelle processer i den menneskelige<br />
hjerne, det vil sige alt fra f.eks. sansning samt behandling af sanseindtryk til mere avanceret<br />
tænkning og planlægning. Kognitivisme opstod <strong>som</strong> en reaktion imod den behavioristiske<br />
tilgang, <strong>som</strong> siden psykologiens barndom havde været den dominerende pol. I dag betragtes<br />
behaviorismen imidlertid principielt <strong>som</strong> en del af den kognitive pol i Illeris' triadeforståelse[a,<br />
s27].<br />
I det følgende afsnit vil vi forsøge at belyse de overordnede indre læringsprocesser <strong>som</strong><br />
kognitionsforskningen har arbejdet med. Vi vil dernæst belyse nogle af de individuelle<br />
påvirkninger <strong>som</strong> skal passeres før læringsprocessen påbegyndes, samt eksempler på hvordan<br />
disse kan passeres. Før vi når så langt vil det imidlertid været væsentligt at undersøge<br />
behaviorismen nærmere, for derigennem at give os et mere klart billede af, hvilke tanker der<br />
ligger til grund for kognitivismen og måske vigtigere hvilke fordele og ulemper, der er forbundet<br />
med denne tilgang.<br />
3.4.2.1Behaviorisme 7<br />
Det behavioristiske paradigme blev oprindeligt formuleret af John B. Watson. For<br />
behavioristerne er den ydre menneskelige adfærd (eng. behave) det væsentlige studie for<br />
psykologien, hvilket ligger til grund for det danske navn adfærdspsykologi. Ifølge<br />
behavioristerne kan alt adfærd forklares ud fra stimuli-respons modellen8 . I modsætning til<br />
andre kognitive studier, betragter behavioristerne menneskets<br />
kognitive processer <strong>som</strong> en utilgængelig sort boks imellem<br />
stimuli og respons9 . Boksen <strong>som</strong> i sin natur er utilgængelig, er<br />
derfor uinteressant for psykologien. Kun implicit igennem<br />
Figur 8: Stimuli-respons modellen<br />
stimuli/respons studier kan den menneskelige adfærd studeres[n, s23].<br />
7 Det følgende afsnit bygger på Tia Hansens mfl. Kognitionspsykologi – en introduktion[n s13-43] samt Konzacks<br />
Edutainment[a s25-28]<br />
8 De første behaviorister f.eks. John B. Watson (1878-1958) betvivlede at der overhovedet foregik en kognitive processer<br />
imellem stimuli og respons. Vi har imidlertid valgt at benytte den mere moderate (og accepterede) anskuelse hvor de<br />
kognitive processer accepteres, men i stedet ses <strong>som</strong> en utilgængelig sort bokse uden interesse.<br />
9 Se figur 8<br />
side 28 / 92
Udvikling af et IT-system - Informatik P2 - Projekt – Feb. - Maj. 2007<br />
Ifølge behavioristerne kan en adfærd styrkes eller svækkes vha. positiv/negativ forstærkning af<br />
en given stimulus igennem belønning/ikke belønning. At behavioristerne anser en så enkel<br />
forståelsesramme til at være generelt gældende skyldes deres bagvedliggende menneskesyn.<br />
Ifølge behaviorismens menneskesyn, er alle mennesker ved deres fødsel udstyret med et næsten<br />
identisk psykologisk udgangspunkt. Igennem positiv og negativ forstærkning tilpasses og rettes<br />
dette til, blandt andet af læreren, <strong>som</strong> igennem undervisningen <strong>som</strong> en skulptør tilskærer<br />
eleverne. Læreren er altså, i en behavioristisk tilgang, den aktive formidler mens eleven passivt<br />
modtager - altså den traditionelle ”undervisning fra tavlen”.<br />
Fordelene <strong>som</strong> ligger i den behavioristiske tilgang, er at de meget snævre konklusioner kan<br />
bruges i mere generelle slutninger, idet der er færre faktorer, <strong>som</strong> kan spille ind <strong>som</strong><br />
forsøgspersonens indre kognitive verden, fjernes information fra forsøget fordi man <strong>som</strong> en<br />
matematisk funktionsmaskine undersøger hvad der kommer ind (stimuli) og hvad dette<br />
genererer (respons). Det gør den meget brugbar til træning, hvor man netop er interesseret i<br />
indøvning af førbevidste reaktioner.<br />
Som eksempel kan nævnes regnestykket og rimet 7*17=119, <strong>som</strong> tidligere er benyttet <strong>som</strong><br />
udenadslære, hvor læringsformen har været udformet uden refleksion.<br />
3.4.2.2Konstruktivistisk kognitivisme 10<br />
Konstruktivismen har de sidste 30 år været en af de bærende psykologiske retninger på<br />
læring<strong>som</strong>rådet. Konstruktivismen er en meget bred retning, der dog udgår fra en fælles<br />
opfattelse at den lærende selv konstruerer sit verdensbillede. Viden overføres således ikke fra et<br />
menneske til et andet, men formidles og ”genskabes” hos modtageren <strong>som</strong> ny viden. En af de<br />
store fortalere for konstruktivismen er den schweiziske psykolog Jean Piaget[a, s29-33]. Piaget<br />
har skabt en teoretisk tilgang til kognitivisme igennem sit adaptationsbegreb.<br />
Adaptation beskrives <strong>som</strong> en form for tilpasning. Det forudsætter, at den lærende har dannet sig<br />
nogle psykologiske strukturer, et skema, <strong>som</strong> han kan sætte ny viden i forbindelse med. Herefter<br />
kan adaptationen, afhængig af den nye videns karakter og individets livsstadie[a, s29],<br />
gennemføres <strong>som</strong> en assimilativ eller akkomodativ proces.<br />
Figur 9 & Figur 10: Assimilation & Akkomodation illustreres.<br />
10 Afsnittet bygger blandt andet på Knud Illeris' Læring[d, s25-33]<br />
Assimilation foregår, idet individet forsøger at tilføje nye<br />
indtryk fra omgivelserne, ved at tilpasse ny viden i det<br />
allerede eksisterende skema. Nye erfaringer behandles<br />
<strong>som</strong> et tilfælde af noget allerede kendt.<br />
Akkommodation derimod kan betegnes <strong>som</strong> individets<br />
omstrukturering eller nedbrydning af egne psykologiske<br />
strukturer, så skemaet passer til den nye erfaring.<br />
Da akkommodativ læring synes at være den mest radikale<br />
proces for individet, kunne man fristes til at sige, at den<br />
læring, man opnår ved akkommodation, er bedre end den,<br />
der finder sted ved assimilation eller kumulation 11 . En<br />
overdreven mængde akkommodative processer risikerer<br />
imidlertid at føre til desorganisering eller forvirring. Illeris<br />
argumenter:<br />
11 Piaget behandler ikke åbenlyst situationer, hvor individdet hverken tilpasser erfaringer til eksisterende skemaer eller<br />
omstrukturerer et skema til ny erfaring. Her tænkes på situationer hvor der er behov for at individet opstiller nye<br />
skemaer, fordi den nye viden ikke knytter sig til eller udfordrer de eksisterende psykologiske strukturer. Senere har denne<br />
proces fået navnet kumulation af danskeren Thomas Nissen.<br />
Side 29 / 92
Udvikling af et IT-system - Informatik P2 - Projekt – Feb. - Maj. 2007<br />
”En sådan opfattelse er imidlertid misforstået, dels fordi akkommodationer<br />
nødvendigvis forudsætter at der gennem kumulation og assimilation er opbygget<br />
relevante strukturer der kan akkommoderes på”[d, s33]<br />
3.4.3 Samfundsmæssighed<br />
I nyere tid er konstruktivisternes megen fokus på læring på det individuelle plan blevet<br />
kritiseret, hvilket har ført til socialkonstruktivismen. Læring foregår altid i en social og<br />
samfundsmæssig kontekst[d, s19]. På det sociale plan skal samspilssituation på det<br />
indholdsmæssige og følelsesmæssige plan synes acceptabel hos den lærende for at læring kan<br />
ske. Eksempler på uhensigtsmæssige forhold kan være et negativt forhold til læreren, de andre<br />
lærende, af faget eller skolen. På det samfundsmæssige plan findes ligeledes en mængde<br />
elementer <strong>som</strong> kan virke forstyrrende for den lærende, eksempelvis hvis denne lider under<br />
eksamenspres eller frygt for karaktergivning, lige <strong>som</strong> den lærendes generelle livssituation også<br />
har betydning for evnen til at modtage nyt stof.<br />
Den sociale og samfundsmæssige dimension indvirker ikke kun negativt på læring, men er i<br />
triadeforståelsen en del af læringen, der vil kunne modelleres for at højne indlæringen[d, s20].<br />
Man taler i denne sammenhæng blandt andet om læring i samarbejdssituationer – kollaborativ<br />
og kooperativ læring.<br />
3.4.3.1 Kooperativ og Kollaborativ læring 12<br />
Kooperativ læring er en situation hvor de lærende hjælper hinanden med at forstå læringsstof og<br />
-opgaver. Kollaborativ læring kan her ses <strong>som</strong> en udvidelse af dette samarbejde, hvor de lærende<br />
arbejder sammen om et fælles <strong>projekt</strong> <strong>som</strong> vi f.eks. ser det i det <strong>projekt</strong>orienteret<br />
gruppearbejde[b, s115]. Motivet for at inddrage samarbejde i læring er, at interaktionen i form af<br />
samtaler, fælles produktion og anden social aktivitet mellem de lærende øges væsentligt. Det vil<br />
sige at ikke kun læringstoffet modtages men også sociale færdigheder opøves, og der er stor<br />
sandsynlighed for at der genereres mere viden i gruppen, da hver enkelt bidrager med sin viden.<br />
Principperne i kooperativ og kollaborativ læring har især i nyere tid fået opmærk<strong>som</strong> f.eks. i<br />
forbindelse med situeret læring.<br />
3.4.3.2 Situeret læring<br />
Situeret læring lægger sig tæt op ad mesterlære princippet, hvor den lærende (ofte en lærling)<br />
opnår læring igennem efterligning af en ”ekspert”. I situeret læring er denne ekspert imidlertid<br />
ikke nødvendigvis en mester, men blot en person der deltager i læringsfælleskabet, og er<br />
overlegen i den givne faglighed[b, s116]. Det handler altså om at drage nytte af den største<br />
erfaring eller viden tilstede i gruppen, og på den måde udvikle sine egne grundforudsætninger,<br />
på lige fod med de andre i fællesskabet. I relation til f.eks. computerspil kan det ses i den måde,<br />
en spiller lærer et multiplayerspil på. Spilleren vil, mens han prøver sig frem, iagttage de andres<br />
måde at spille på, efterligne deres manøvrer, for efterhånden at spille på samme måde <strong>som</strong> de<br />
andre spillere.<br />
3.4.3.3Differentiering<br />
Efter at have set på trekantens poler, psykodynamikken, kognitionen og det samfundsmæssige<br />
sociale aspekt, vil vi se nærmere på nogle af de forskellige teorier, der beskæftiger sig med<br />
lærings differentiering. Ovenstående teorier bringer os en glimrende overordnet forståelse af de<br />
fælles menneskelige kognitive læringsprocesser. I det følgende fokuseres på at skabe et mere<br />
nuanceret billede af menneskets forskellige måder at lære på.<br />
12 Det følgende afsnit bygger primært på D&A[b, s115-118] og Konzack [a, 43-49]<br />
side 30 / 92
3.4.3.4 Intelligenser 13<br />
Udvikling af et IT-system - Informatik P2 - Projekt – Feb. - Maj. 2007<br />
I de seneste år har Howard Gardners [ll] teorier om mange intelligenser vundet stor udbredelse<br />
i forståelsen af hjernen. Ifølge Gardners teori besidder hvert individ (mindst) de syv<br />
intelligenser Musisk, Krops-kinæstetisk, Logisk-matematisk, Sproglig, Spatial (rumforståelse),<br />
Interpersonel (social kapacitet) og Intrapersonel (forståelse indre aspekter).<br />
Ifølge Gardner bliver vi alle skabt med disse intelligenser, men af forskellige årsager udvikles de<br />
vidt forskelligt igennem livet. At Gardner i første omgang benyttede sig af 7 intelligenser<br />
skyldtes udelukkende, at han i sine første videnskabelige arbejder kun var i stand til at finde<br />
klare beviser for disse syv intelligenser. Listen har efterfølgende vokset sig længere således, at vi<br />
i dag arbejder med syv til elve intelligenser. De enkelte intelligenser er imidlertid ikke det mest<br />
interessante i Gardners teorier, men derimod introduktionen af et pluralistisk syn på<br />
intelligenserne. Ifølge Gardner stiger læringspotentialet, hvis flere intelligenser aktiveres i<br />
formidlingssituationen[a, s36].<br />
Således kan f.eks. flere medier med fordel benyttes samlet i forbindelse med formidlingen. Det<br />
er også muligt at øge læringspotentialet ved at fokusere på elevens stærkeste områder, for<br />
derved at udnytte de ekstra ressourcer der. Det har imidlertid været kritiseret da en sådan<br />
individualiseret undervisning er ressourcekrævende i de fleste praksisser. Derudover har det<br />
være pointeret at den megen fokus på logisk og sproglig intelligens, ikke udelukkende, <strong>som</strong><br />
Gardner påpeger det, er et udtryk for manglende viden omkring hjernens opbygning, men også<br />
skyldes vores samfunds generelt større behov for disse intelligenser.<br />
3.4.3.5 Flow og zonen for nærmeste udvikling 14<br />
Jævnfør vores problemafgræsning vil vi i dette <strong>projekt</strong> ikke benytte os af aldersorienterede<br />
læringsteorier 15 . Et alternativ til den aldersdifferentierede undervisning finder vi blandt andet i<br />
Vygotskys virk<strong>som</strong>hedsteoretiske overvejelser om zonen for nærmeste udvikling. Vygotsky<br />
definerer denne <strong>som</strong> ”afstanden mellem det aktuelle udviklingsniveau, <strong>som</strong> det kan konstateres<br />
ved individuel problemløsning, og niveauet for den potentielle udvikling, <strong>som</strong> det kan<br />
konstateres ud fra problemløsning med vejledning fra voksne eller i samarbejde med dygtigere<br />
jævnaldrende”.<br />
Zonen er altså forskellen imellem den viden, vi har, vurderet ud fra vores individuelle evner, og<br />
den potentielle viden, <strong>som</strong> vises efter problemløsning med assistance- fra personer <strong>som</strong> allerede<br />
har denne viden. Ifølge Vygotsky bør undervisningen altid rettes imod det næste<br />
udviklingstrin[b, s102]. Det er således væsentligt, hverken at fokusere på allerede opnået<br />
læringsniveauer eller på områder langt fra den lærendes niveau. Lidt forsimplet kan man sige at<br />
zonen for nærmeste udvikling dækker over alt den potentielle viden, <strong>som</strong> eleven umiddelbart<br />
kan opnå.<br />
13 Det følgende afsnit bygger primært på Konzack[a, 33-39] og D&A[b, 106-107]<br />
14 Afsnittet bygger blandt andet på Kognitionspsykologi – en introduktion[n, 36-39]<br />
15 Se <strong>projekt</strong>afgrænsning 1.4.<br />
Side 31 / 92
Udvikling af et IT-system - Informatik P2 - Projekt – Feb. - Maj. 2007<br />
En del af forklaringen på at det netop er i denne zone at læring opnås, kan fås ved at betragte<br />
Mihaly Csikszentmihalyis flow tilstand:<br />
”Flow er en ekstase-ligende mental tilstand – en særlig behagelig fordybelsestilstand<br />
der kan indtræde, når der er komplet harmoni mellem udfordringer og evner. Flow er<br />
en særlig fordybelsestilstand, hvor mennesket er så opslugt af en aktivitet, at tid og<br />
sted og alt uvedkommende forsvinder og erstattes af dyb koncentration.”[b, s104]<br />
Ud over enkeltvis at have relevans <strong>som</strong> læringsteori giver disse to teorier i forbindelse med<br />
hinanden en ny og større forståelse af læringsprincippet. Enhver person der har oplevet flow i en<br />
læringssituation kan tilslutte sig, at oplevelsen af et sådant flow netop ofte opstår når der<br />
eksisterer harmoni imellem udfordring og evner altså når man arbejder inden for zonen for<br />
nærmeste udvikling[b, s106]. Ovenstående er et perfekt eksempel på hvordan teorier, ved en<br />
luhmannsk videnskabsteoretisk tilgang, skaber en større og dybere forståelse af feltet.<br />
Flow teorien er i vores specifikke tilfælde ikke kun interessant i den læringsmæssige<br />
sammenhæng, men mindst ligeså relevant i forbindelse med spil og legeteorier, hvor flow må<br />
betragtes <strong>som</strong> en af hovedmotivationerne til, at mennesker finder interesse i at spille[g].<br />
3.4.3.6 Refleksion<br />
Inden for de sidste årtier er refleksionen for alvor begyndt at spille en væsentlig rolle i<br />
forståelsen af læring[b, s209], Det ses blandt andet igennem begreber <strong>som</strong> ”at lære at lære” og<br />
aktiv læring, <strong>som</strong> vil blive diskuteret senere. Professor i pædagogik Mads Hermansen giver i<br />
nedenstående citat en klar fornemmelse af refleksionens væsentlige placering i<br />
læringsprocessen:<br />
”Formuleret i kort form mener jeg nu, at refleksionsarbejdet er en nødvendig og vital<br />
del af lære- og lærerarbejdet. Uden målet om, at det skal ende i relativ syntese, er en<br />
væsentlig grundbetingelse for læreprocessen ikke til stede.”[a, s52]<br />
Det er altså centralt for os at forstå hvilket refleksionsniveau, de forskellige læringsteorier<br />
henvender sig til i udarbejdelsen af edutainment. Illeris skriver om refleksion at:<br />
”Det karakteristiske for [...] refleksion synes at være, at der ikke direkte indgår nye<br />
impulser fra samspillet med omgivelserne... noget har været ufuldendt, impulserne er<br />
ikke blevet færdigbehandlet, der er et element af kognitiv dissonans”[d, s41]<br />
Illeris beskriver refleksion <strong>som</strong> en intern lukket proces, hvilket ligger i forlængelse af blandt<br />
andet den socialkybernistiske teori om den enkelte elevs læringsprocesser <strong>som</strong> lukket område<br />
for læreren[a, s51]. Kun igennem en aktiv deltagelse fra eleven har læreren mulighed for at følge<br />
læringsprocessen og skabe differentieret læring.<br />
Illeris beskriver desuden refleksionen <strong>som</strong> en behandling af noget ufuldendt. Dette er<br />
interessant i forhold til argumenterne for refleksiv læring, <strong>som</strong> ofte bygger på et krav om ikke<br />
bare at lære stoffet, men også at forstå det.<br />
side 32 / 92
3.4.3.7 Læringsniveau<br />
Udvikling af et IT-system - Informatik P2 - Projekt – Feb. - Maj. 2007<br />
I forlængelse af refleksionens voksende rolle i læring har Gregory Bateson udviklet en model,<br />
<strong>som</strong> definerer læringen i forhold til kompleksiteten af emnet. Modellen er bygget op omkring en<br />
forestilling om feedback, <strong>som</strong> udgangspunkt for læring [a, s49]. Modellen er bygget op af trin,<br />
hvor hvert niveau kommer oven på de foregående. Batesons oprindelige model har et tydeligt<br />
teoretisk præg der gør den svært anvendelig. Som Konzack påpeger det:<br />
”Læring 0 er tvivl<strong>som</strong>, om den overhovedet kan kaldes læring, da der ikke finder nogen<br />
'trial and error' sted, mens læring 4 går ud over grænser for det menneskeligt<br />
mulige.”[a, s50]<br />
Desuden er teorien om læringsniveau blev kritiseret for at være for generel, og man arbejder<br />
derfor i praksis ofte med professor i læringspsykologi Yrjö Engeströms opdeling i 2a og 2b. Vi vil<br />
derfor i det følgende benytte Engeströms niveaudeling[a, s51], <strong>som</strong> vi anser for mere let<br />
anvendelig i forhold til dette <strong>projekt</strong>.<br />
Niveau 0-1: På niveau 0 og 1 foregår ingen refleksion. Som et dyr der forsøger at komme ud af en<br />
labyrint forsøgs hele tiden den mest oplagte løsning.<br />
Niveau 2a: Læring på niveau 2a kan til dels betragtes <strong>som</strong> læring af paratviden. I 2a er målet for<br />
læringen givet og værktøjerne til denne viden er blind ”trial and error” testning af det man<br />
allerede kender. Læring på 2a er altså en reproduktion af den givne viden.<br />
Niveau 2b: Læring på niveau 2b dækker over begrebet 'at lære at lære'. I 2b er målet også givet,<br />
mens værktøjerne til at opnå denne viden udvikles undervejs vha. eksperimentering. I 2b<br />
konstruerer den lærende altså selv sin viden.<br />
Niveau 3: Det øverste menneskelige læringsniveau, <strong>som</strong> mennesket i særlige betingelser kan<br />
opnå. På niveau 3 reflektere mennesket over sin egen refleksion, og er således frigjort fra de<br />
bindinger, der regulerer læringen på niveau 2b. I praksis kan det imidlertid være<br />
sygdomsfremkaldende at presse elever til at gennemføre refleksion på niveau 3.<br />
Niveau 0 - 1 Niveau 2a Niveau 2b Niveau 3<br />
Ubevidst læring Bevidst læring<br />
Ingen<br />
refleksion<br />
● Blind<br />
efterforskning<br />
blandt det man<br />
kender.<br />
● Reproduktiv<br />
læring.<br />
6. Eksperimentering<br />
7. Refleksion.<br />
8. Produktiv læring.<br />
9. Teori.<br />
Tabel 2: Engeströms tabel om ”reelle” læringsniveauer[b, s85]<br />
1. Refleksion over<br />
refleksion.<br />
2. Tilpasning af<br />
situation ift.<br />
kontekst.<br />
D&A har i deres bog undersøgt, hvilket refleksionsniveau, de forskellige læringsteorier lægger<br />
optil, hvilket vil være for omfattende at komme ind på her. Overordnet kan det dog konkluderes<br />
at et refleksivt edutainment spil bør aktivere spilleren så meget <strong>som</strong> muligt på læringniveauet<br />
2b.<br />
Side 33 / 92
3.4.3.8 Lagring<br />
Udvikling af et IT-system - Informatik P2 - Projekt – Feb. - Maj. 2007<br />
Alle foregående teorier har hovedsageligt beskæftiget sig med, hvordan informationerne<br />
bevæger sig fra afsender til modtager. At informationerne lagres i modtagerens hjerne er<br />
imidlertid langt fra ensbetydende med at de senere er tilgængelige <strong>som</strong> viden. F.eks. huskes kun<br />
20 % af en given læsning efter 24 timer såfremt den præsenterede viden ikke benyttes<br />
efterfølgende. I det følgende beskrives de forskellige teorier og tekniker for hvorledes<br />
undervisningen tilrettelægges på en fornuftig måde. Da disse områder er utrolig omfattende og<br />
befinder sig i periferien af dette <strong>projekt</strong>, vil vi ikke gå i dybden med dem, men blot berøre nogle<br />
af de mest alment accepterede konklusioner.<br />
3.4.3.9 Undervisningslængde<br />
Undersøgelser[du] har vist, at man husker mest fra begyndelsen og slutningen af en<br />
indlæringsperiode. Derfor bør man i stedet for en lang periode på f.eks. 3 timer, med kun én<br />
start og én slutning og dermed to såkaldte indlæringstoppe, dele de 3 timer op i fire<br />
indlæringsperioder med en pause på ca. 10 min. imellem hver. Dette giver i stedet otte<br />
indlæringstoppe i stedet for kun to med det resultat, at man husker betydeligt mere af det læste.<br />
Udover at planlægge indlæringsforløbet skal man sørge for at planlægge sin undervisning,<br />
således at indlæringsperioderne ligger på 20-50 min. Kortere end 20 min. vil betyde, at hjernen<br />
ikke når at indstille sig på det stof, der skal indlæres. Længere end 50 min. vil betyde en stærk<br />
reduktion af det, der kan huskes <strong>som</strong> er uafhængigt af flow.<br />
3.4.3.10 Repetition<br />
Den mest oplagte og brugte metode til at forstærke hukommelsen er repetition. Denne tilgang,<br />
<strong>som</strong> praktiseres inden for næsten alle læring<strong>som</strong>råder, går i alt sin enkelthed ud på, at<br />
information huskes tydeligere jo oftere den benyttes. Der findes mange meninger om hvornår og<br />
hvor ofte et givent stof skal repeteres, og det virker ligeledes sandsynligt at parametre <strong>som</strong> f.eks.<br />
stoffets art, samt modtageren og afsenderens individualiteter spiller væsentligt ind. Der<br />
eksisterer dog en generel fingreregel om at 1. repetition bør finde sted ca. 10-15 min efter<br />
indlæring [du][vd]. En anden fingerregel er at benytte repetitionen, efter én time, dag, uge, og<br />
måned. Dette sikre naturligvis en endnu bedre lagring af det lærte, til gengæld kan det<br />
diskuteres hvor mange mennesker der kan finde en motivation for at repetere lært stof op til to<br />
gange eller mere.<br />
3.4.3.11 Konnektionisme og organisering<br />
Et andet meget væsentligt aspekt ved informationernes lagring er organiseringen af de data, der<br />
ønskes formidlet. Ifølge Henning Dalgaard og Tom Nørregård Andersens (D&A) huskes<br />
information bedre hvis enten [b, s113-114]:<br />
● Den er naturligt organiseret<br />
● En organisering er pålagt den.<br />
● Eleven er opmærk<strong>som</strong> på organiseringen<br />
At den er organiseret henviser til at det er nemmere at arbejde med information <strong>som</strong> allerede<br />
forekommer naturligt. For eksempel vil informationen i en matematiktime, <strong>som</strong> omhandler<br />
trekanter være naturligt organiseret så længe stavning eller algebra ikke inddrages. Dette kan<br />
virke banalt, men det er vores opfattelse at netop edutainmentspil nogle gange forsøger at<br />
omfatte mere end ét emne. Dette skyldes muligvis, at udvikleren udnytter en, for ham, oplagt<br />
mulighed i spilforløbet for at integrere en bestemt type opgaver – til trods for at typen ligger<br />
uden for emnet.<br />
side 34 / 92
Udvikling af et IT-system - Informatik P2 - Projekt – Feb. - Maj. 2007<br />
Udover den naturlige organisering kan informationen også pålægges en organisering, <strong>som</strong> det<br />
f.eks. er tilfældet når vi forsøger at lagre noget information ved hjælp af en remse. Men det kan<br />
også være diagrammer hvor informationen er sat i forhold til andre koncepter. Ifølge Seymour<br />
Papert [a, s40] <strong>som</strong> er en af ophavsmændene for konnektionismen 16 er en organisering af stof<br />
imidlertid ikke kun væsentlig i forhold til at huske det lærte stof.<br />
Han argumenterer for, at man ved at sætte noget lært information ind i en større sammenhæng<br />
ikke udelukkende opnår viden om denne information, men samtidig også opnår en næsten lige<br />
så stor viden om de koncepter <strong>som</strong> der relateres til. Det bliver således et mål for læreren at<br />
fremme at de lærende ser disse sammenhænge.<br />
Det sidste punkt kan ligeledes virke banalt, men er væsentligt at huske fordi vi i vores rolle <strong>som</strong><br />
systemudviklere med formidlingsarbejde, selv så tydeligt ser organiseringen at vi glemmer, at<br />
den for ”udefrakommende” personer muligvis ikke fremstår lige så åbenlys.<br />
16 Indlæringsteori ift. hvilken indlæring består i dannelse af forbindelser mellem stimuli og reaktioner[o]<br />
Side 35 / 92
4.1 Indledning<br />
Udvikling af et IT-system - Informatik P2 - Projekt – Feb. - Maj. 2007<br />
4.0 Interessentanalyse<br />
I et udviklings<strong>projekt</strong> er det essentielt at skaffe sig data om interessenternes behov. For at finde ud<br />
af hvem af interessenterne der er de væsentlige, og hvad de bibringer af krav til edutainmentspillet,<br />
foretages en interessentanalyse. P. E. Christiansen[m] med flere, opstiller i bogen Organisation, en<br />
generel forskrift for interessentanalyse[m, s435].<br />
Modellen består af tre hovedproblemer:<br />
● Hvem er interessenterne?<br />
● Hvilken indstilling har de?<br />
● Målkonflikter hos de forskellige interessentgrupper.<br />
Disse problemer danner grundlag for gennemførelsen af <strong>projekt</strong>ets interessentanalyse.<br />
4.1.1 Hvem er interessenterne?<br />
Interessenterne kan ifølge modellen deles op i fire grupper der i større eller mindre grad kan<br />
skildres <strong>som</strong> produktets brugere, betalere, acceptgivere og udviklere, se tabel 3.<br />
Brugere Betalere Acceptgivere Udviklere<br />
Elever<br />
(målgruppen)<br />
Lærere<br />
Folkeskoler<br />
Privatskoler<br />
Specialskoler<br />
Materialecentraler<br />
Skoler<br />
Lærere<br />
Undervisningsministeriet<br />
Tabel 3: Interessent oversigt<br />
Projektgruppen<br />
Evt. spilvirk<strong>som</strong>hed<br />
En interessent kan være repræsenteret i flere grupper, man kunne for eksempel forestille sig at<br />
Undervisningsministeriet også gav økonomisk støtte til <strong>projekt</strong>et. Som behandlet i<br />
<strong>projekt</strong>afgrænsningen 17 , vil analysen ikke omfatte alle interessenter. Interessegrupperne<br />
betalere og udviklere vedrører i høj grad det økonomiske aspekt af edutainment, <strong>som</strong> ikke er et<br />
foku<strong>som</strong>råde for dette <strong>projekt</strong>. Der er valgt én interessent i gruppen brugere, nemlig elever,<br />
hvorfor lærerens rolle kun inddrages implicit. Derudover er der Undervisningsministeriet fra<br />
gruppen acceptgivere valgt, da denne interessent i sidste instans dikterer de faglige mål hvor ud<br />
fra skoler og lærere vurdere produktet.<br />
17 se kap 1.4<br />
side 36 / 92
4.1.2 Hvilken indstilling har de?<br />
Udvikling af et IT-system - Informatik P2 - Projekt – Feb. - Maj. 2007<br />
For at give et billede af interessenterne foretages endnu to (del)analyser, et<br />
fokusgruppeinterview af 8. klasses elever samt dataindsamling vedrørende de krav <strong>som</strong><br />
Undervisningsministeriet stiller til matematikundervisning i 8. klasse (folkeskolens fællesmål) 18 .<br />
Dernæst udvælges og begrundes vores valg af fokusgruppe <strong>som</strong> analysemetode. Resultaterne af<br />
fokusgruppen fremgår af afsnit 3.3. I henhold til analyse af Undervisningsministeriets krav, har<br />
vi medtaget matematiklærebøgerne Faktor til 8. klasse[h][i], <strong>som</strong> jo er en afspejling af de<br />
udstukne fællesmål i praktisk anvendelse, og hvilket anses <strong>som</strong> yderst relevant. Hele analysen af<br />
Undervisningsministeriets krav kan findes i bilag 6.<br />
4.1.3 Målkonflikter hos de forskellige interessentgrupper.<br />
I undersøgelsen af potentielle målkonflikter, ses på hver enkelt interessents præferencer til<br />
edutainmentspillet, det vil sige resultatet af fokusgruppeanalysen og dataindsamlingen fra<br />
Undervisningsministeriet. Den oplagte konflikt er risikoen for, at Undervisningsministeriets<br />
nøje fastlagte læringsmål er svært forenelig med elevens første krav om et underholdende spil,<br />
dernæst om frihed og styring i spillet. I opstillingen af kriterierne for edutainmentspillet samt i<br />
designfasen vil interessenternes krav indtænkes og forsøges balanceret.<br />
4.2 Fokusgruppeinterview<br />
4.2.1 Formål<br />
Formålet og inspirationen til at foretage netop et fokusgruppeinterview var en tidligere rapport<br />
udarbejdet af SAFT i 2003 [bbb], omkring børn og deres brug af Internet.<br />
Fokusgruppeundersøgelsen foretages med en udvalgt gruppe 8. klasses elever. I SAFTrapporten,<br />
beskrives de unges internetvaner, <strong>som</strong> vi i dag oplever <strong>som</strong> forældet. Fokusgruppen<br />
har udover at skaffe os en større forståelse af slutbrugerens behov og interesser i forhold til<br />
edutainmentspil til formål at be- og afkræfte SAFT-rapportens resultater.<br />
4.2.2 SAFT<br />
SAFT er en nordisk EU-støttet undersøgelse <strong>som</strong> blev foretaget i årene 2002-2004. Projektets<br />
formål var at analysere sikkerheden på internettet for børn og unge. Med en deltagelse på i alt<br />
2,5 millioner børn og unge i alderen 9-16 år fra de nordiske lande må <strong>projekt</strong>et betegnes <strong>som</strong> det<br />
hidtil størst af sin art. Det tager først og fremmest udgangspunkt i hvor meget børn spiller<br />
computerspil, færdes på internettet, hvilke favoritspil de har, samt hvor meget tid de bruger<br />
foran computeren. Fra rapporten ses et skema med de unges 5 mest benyttede computer<br />
aktiviteter:<br />
3. Spille spil (71%)<br />
4. Sende og modtage e-mail (50%)<br />
5. Lave lektier (47%)<br />
6. Surfe for sjov (39%)<br />
7. Chatte (31%)<br />
SAFT har videre ud fra dette undersøgt hvilke favoritspil de unge spiller i den valgte<br />
aldersgruppe, hvoraf de hyppigste ses på figur 11.<br />
18 I bilag 3 gennemgås udvælgelses et udvalg af de mest anvendte analyse metoder til belysning af målgruppens behov.<br />
Side 37 / 92
Udvikling af et IT-system - Informatik P2 - Projekt – Feb. - Maj. 2007<br />
Figur 11: Unges favoritspil<br />
Her ses det at action, sport, strategi er de hyppigst spillede genrer. Den hyppigste respons er<br />
imidlertid 'andre favoritspil', hvilket for en til at overveje om holdet bag SAFT har været for<br />
dårlige til at udarbejde spørgeskemaernes svarmuligheder. En anden og væsentlig mere<br />
plausibel grund er de unges store forbrug af små gratis spil <strong>som</strong> florerer i tusindvis på<br />
internettet [j9]. Med tusindvis af mulige spil, og med nye der kommer til dagligt, må det<br />
betegnes <strong>som</strong> næsten umuligt for SAFT gruppen at lave svarmuligheder <strong>som</strong> fanger disse.<br />
4.2.3 Drenge og Piger<br />
SAFT undersøgelsen havde også til formål, at undersøge forskellen imellem pigernes og<br />
drengenes spilforbrug. Undersøgelsen, vis resultat ses på figur 12 nåede viser generelle opdeling<br />
af spilgenrer mellem piger og drengene. Det ses det tydeligt, at pigerne spiller mindre<br />
”aktionsfyldte” spil end drengene.<br />
Kombineres dette med at adventuregenren er den genre, der interesserer både piger og drenge<br />
mest[bbb], anser vi det for væsentligt at medtage denne genre i den videre undersøgelse. Ud fra<br />
ovenstående har vi i vores fokusgruppe valgt at begrænse os til følgende spilgenre: Strategispil,<br />
adventurespil, gudespil og rollespil.<br />
side 38 / 92<br />
Figur 12: Pigernes og drengenes foretrukne spiltyper
4.2.4 Udarbejdelse af spørgsmål<br />
Udvikling af et IT-system - Informatik P2 - Projekt – Feb. - Maj. 2007<br />
Spillisten figur 11 må i computer sammenhæng siges at være forældet. Derfor foretog vi et<br />
”rundspørge” med to 8. klasser på Vesterkærskolen, hvor vi spurgte ind til elevernes spilforbrug.<br />
Vi medbragte også en liste med nogle af de mest solgte spil i 2006, hvoraf vi undersøgte, hvilke<br />
af disse de unge havde erfaring med. I rundspørgen havde vi lagt særligt vægt på at sikre en bred<br />
tilbagemelding fra begge køn.<br />
De 3 mest spillede spil indenfor de undersøgte genrer findes nedenfor. Det skal dog pointeres, at<br />
kun et spil uden for disse genrer, Counter Strike, opnåede samme opbakning <strong>som</strong> nedenstående<br />
3.<br />
● Adventure og Rollespil: World Of Warcraft<br />
● Gudespil: The Sims<br />
● Strategi: Rollercoaster Tycoon<br />
Det er imidlertid vigtigt at huske, at rundspørgens resultater ikke bør benyttes til andet end en<br />
pejling om, hvilke spil vi kan forvente at støde på i fokusgruppemødet. Til andet brug bør<br />
længere og bedre forberedte sessioner ligge til grund.<br />
4.2.5 Rammer for interviewet<br />
For fokusgruppen har vi opstillet følgende rammer:<br />
● 7 personer, hvor vi har 4 piger og 3 drenge i 8. klasse. Den ekstra pige er medtaget for at tage<br />
højde for at computerspil traditionelt set må betragtes <strong>som</strong> et drengedomineret felt.<br />
● Varighed af fokusgruppen bliver to 45 min moduler med 5 min. mellemliggende pause.<br />
● Et lokale <strong>som</strong> ikke bærer præg af skolen, for at sikre en større distance imellem deltager og den<br />
almindelig undervisning hvor der ofte findes et ”rigtigt” og et ”forkert” svar.<br />
● Rummet skal helst have en afslappet atmosfære, for at få deltagerne til at føle sig sikre under<br />
sessionen.<br />
● Alle fra gruppen er med til fokusgruppen, for at hele gruppen opnår et fagligt udbytte.<br />
● Video og lyd optager benyttes, til logning af fokusgruppeinterviewet.<br />
4.2.6 Roller<br />
I udførelsen af en fokusgruppe er det vigtigt at få uddelt nogle klart definerede roller før<br />
sessionen. Vi vurderer følgende roller <strong>som</strong> væsentlige:<br />
4.2.7 Moderator<br />
Moderatorens opgave er at styre fokusgruppemødet, med specielt fokus på at motivere, sikre<br />
den røde tråd i diskussionen, samt sikre at eventuelle interessante indlæg uddybes. Det er<br />
imidlertid vigtigt at moderatoren ikke påvirker samtalen med sine subjektive holdninger, men<br />
lader hele fokusgruppen til aktivt at deltage i diskussionen.<br />
Side 39 / 92
4.2.8 Backup-Moderator<br />
Udvikling af et IT-system - Informatik P2 - Projekt – Feb. - Maj. 2007<br />
Backup-moderatoren har til formål at støtte moderatoren i hans opgaver. Derudover skal han,<br />
vha. MSN Messenger modtage eventuelle relevante spørgsmål fra resten af gruppen og sikre en<br />
videre formidling til moderatoren. Som udgangspunkt skal backup moderatoren ikke deltage<br />
aktivt i samtalen, med mindre moderatoren oplever problemer med f.eks. at holde samtalen i<br />
live, eller uddybe eventuelle uklare indlæg fra moderatoren. Det er imidlertid vigtigt, at backupmoderatoren<br />
forbliver i en afventende position og ikke afbryder en eventuelle nødvendig<br />
tænkepause hos deltagerne.<br />
4.2.9 Loggere<br />
Loggernes hovedformål er at ”logge” fokusgruppeinterviewet. Derudover har de mulighed for at<br />
kontakte backup-moderatoren via. MSN med eventuelle spørgsmål, de finder væsentlige, eller<br />
iagttagelser <strong>som</strong> de ønsker viderekommunikeret uden at forstyrre resten af fokusgruppen. De 3<br />
loggere deles op, så de har 2-3 fokusgruppedeltagerer hver at logge for.<br />
4.2.10 Dataindsamling<br />
De materialer <strong>som</strong> bruges til dataindsamling er primært:<br />
● 4 bærbare computere (1 til backup-moderator og 3 til loggerne)<br />
● Videokamera.<br />
● Lydoptager.<br />
4.2.11 Forløb<br />
Fokusgruppeinterviewet første punkt er en præsentation af <strong>projekt</strong>et, af folkene bag <strong>projekt</strong>et<br />
samt formålet med fokusgruppeinterviewet. Dernæst ønskes en kombineret icebreaker /<br />
præsentation af deltagerne til fokusgruppeinterviewet.<br />
Derefter starter selve diskussionen ud fra de på forhånd stillede aktiviteter og spørgsmål. Når<br />
tiden er ved at være gået afrundes diskussionen med at opsummere de vigtigste konklusioner.<br />
Nedenfor ses den planlagte dagsorden på punktform.<br />
● Præsentation<br />
● Matematik<br />
● Internettet<br />
● Surfing på nettet<br />
● Chatting<br />
● Lektier<br />
● Spil<br />
● Evt.<br />
4.2.12 Opsummering og konklusion<br />
Efter denne dagsorden bruger vi logningsarbejdet til at analysere deltagerne, og komme med<br />
konklusioner til hvordan man udvikler et edutainmentspil til målgruppen. Dette er beskrevet i<br />
næste afsnit.<br />
side 40 / 92
Udvikling af et IT-system - Informatik P2 - Projekt – Feb. - Maj. 2007<br />
4.3 Analyse af målgruppen<br />
Ud fra vores fokusgruppe diskuterede vi forskellige emner med målgruppen. Konklusionerne på<br />
disse diskussioner vil herunder blive gennemgået:<br />
4.3.1 Lærer / undervisning<br />
Efter en kort introduktion af målgruppen under fokusgruppeinterviewet startede vi ud med at<br />
diskutere deres erfaring med matematikundervisningen i skolen. Herunder diskuterede vi hvad<br />
en god underviser er, samt hvordan en underviser skaber mere interesse for faget.<br />
En lærer skal ikke være streng, da det medfører at det kun er de kloge <strong>som</strong> er i stand til at forstå<br />
matematikken, <strong>som</strong> får noget ud af undervisning, og de ikke så dygtige elever falder helt af.<br />
Derudover nåede gruppen frem til, at en god lærer skal undervise med konkrete eksempler fra<br />
virkeligheden i hans/hendes undervisning samt være i stand til at hjælpe de elever, <strong>som</strong> ikke<br />
forstår teorien med det samme. På samme vis ønskede deltagerne at bruge et mere<br />
ungdommeligt sprog, samt at lærerne havde bedre kompetencer til at hjælpe den enkelte elev.<br />
Med gruppen diskuterede vi emner, <strong>som</strong> matematikundervisningen kunne bære præg af. Emner<br />
<strong>som</strong> SMS, fodbold, økonomi, shopping, mad og internet kunne have relevans og interesse for<br />
undervisningen<br />
4.3.2 Internet<br />
Under emnet internet hørte vi hvad de brugte deres tid på internettet til, hvordan de brugte<br />
mediet til at søge efter underholdning samt hvorledes de brugte internettet til at søge efter<br />
informationer om skolearbejde mv. Under samme emne opstod en uopfordret diskussion om<br />
vigtigheden af at kunne dele, f.eks. ting de havde videofilmet, med folk på nettet. Hovedsagelig,<br />
konkluderede de unge også, at deres tid på internettet generelt blev brugt på ”tidsfordriv” og<br />
derunder underholdning.<br />
4.3.3 Spil<br />
I diskussionen om hvad det var, <strong>som</strong> gjorde de unge interesserede i spil, var den umiddelbare<br />
konklusion at spil er sjovt og underholdende, samt at det udfordrer dem på en underholdende<br />
og ufarlig måde 19 . På samme tid var spillet også en måde til at kunne tænke på noget andet,<br />
komme væk fra dagligdagen på.<br />
De unge mente at det ikke var spild af tid at spille, når man spillede på en dag, hvor man ikke<br />
havde noget at lave. Hvis man derimod havde andre ting man skulle nå at lave, og man brugte<br />
tiden på at spille, var det spild af tid. De unge var enige om, at det at spille kunne være spild af<br />
tid, men ikke mere spild af tid end andre fritidsinteresser. Den socialisering <strong>som</strong> er en væsentlig<br />
del af mange fritidsinteresser er i dag også mulig på nettet, bekræftede de unge, og tilføjede at de<br />
har mange gode venner på nettet.<br />
19 Hvilket bekræfter dele af Chris Crawford teori om sikkerhed, jf. [e, s14].<br />
Side 41 / 92
4.3.4 Spil er fede, men hvilke?<br />
Udvikling af et IT-system - Informatik P2 - Projekt – Feb. - Maj. 2007<br />
Vi snakkede om hvilke spil <strong>som</strong> de kendte til, og havde spillet. Efter en diskussion om spillene<br />
og deres betydning for deltagerne, snakkede vi om de spil, de spillede mest og havde mest<br />
interesse i. De spil <strong>som</strong> kom op under diskussionen var <strong>som</strong> følger:<br />
● GTA<br />
● Roug Rebillon<br />
● Warcraft II<br />
● World of Warcraft<br />
● The Sims<br />
● Age of Empires<br />
● Counter Strike<br />
● Rollercoaster- og Zoo-Tycoon<br />
● Den Lyserøde Panter<br />
● Gratis spil<br />
4.3.5 Gratis spil<br />
Under diskussionen af gratis spil viste pigerne stor glæde for disse spil. Pigerne så her en fordel i<br />
at spillet hurtigt var overstået og brugt spillene <strong>som</strong> fyld og kortvarigt tidsfordriv. De korte spil<br />
gav dem mulighed for at kombinere spil med socialt samvær. Når de for eksempel spillede spil<br />
på nettet, kommunikerede de på samme tid med deres venner og veninder via messenger<br />
programmer. Drengene derimod havde et større behov for at kunne fordybe sig i spillet, og ikke<br />
blive distraheret af andet omkring sig. Dette øgede behov for at isolere sig fra den<br />
omkringliggende verden, mente de skyldtes, at de spil de spillede, også var af en mere kompleks<br />
natur end pigernes og derfor krævede deres fulde opmærk<strong>som</strong>hed. Begge parter var dog enige<br />
om, at spil <strong>som</strong> gav dem mulighed for at blive ved med at prøve, indtil de til sidst klarede<br />
opgaven var gode. Ud fra denne diskussion konkluderede vi desuden, at en eventuel integreret<br />
mulighed for kommunikation med andre spillere under spillet kunne fungere <strong>som</strong> et<br />
underholdningselement for pigerne.<br />
4.3.6 Udvalgte spil<br />
I vores fokusgruppe havde vi jf. foregående kapitel valgt 3 spil fra 3 forskellige spilgenre ud til en<br />
dybere diskussion. Spillene var World Of Warcraft, The Sims og Rollercoaster Tycoon.<br />
- World Of Warcraft<br />
I World Of Warcraft, diskuterede gruppen hvad det var <strong>som</strong> gjorde spillet så populært og dertil<br />
forekom en konklusion om at samarbejdet om at klare missioner og at spillet kunne udmunde i<br />
det <strong>som</strong> de selv havde lyst til var en interessant for drengene. Pigerne var mere inspireret af<br />
spillet i forhold til det eventyr-univers <strong>som</strong> ses i spillet. Det med at opbygge en karakter fandt<br />
begge grupper interessant, og de fleste i gruppen synes om spillet, selv de personer <strong>som</strong> endnu<br />
ikke har spillet det. Dog var de også enige om at matematik og en form for undervisning i denne<br />
type spil, ville ødelægge det univers, den verden og de karakterer <strong>som</strong> spillet var opbygget af.<br />
side 42 / 92
- The Sims<br />
Udvikling af et IT-system - Informatik P2 - Projekt – Feb. - Maj. 2007<br />
I spillet The Sims, <strong>som</strong> alle i gruppen kendte, var det fangende element i det spil at kunne<br />
konstruere noget selv. Pigerne, talte for det at kunne være ”Gud” og gøre <strong>som</strong> det passer én. Dog<br />
var detaljegraden i enkelte tilfælde i spillet for højt, hvilke besværliggjorde spillet. Dog var der<br />
enkelte ting i spillet <strong>som</strong> kunne undlades idet det kunne være for meget for den unge at holde<br />
styr på 20 .<br />
- Rollercoaster Tycoon<br />
Gruppen konkluderede at der var en generel interesse i forlystelsesparker, <strong>som</strong> de har haft<br />
oplevelser med i den virkelige verden. I Rollercoaster Tycoon skal man bygge forskellige ting for<br />
at få forlystelsesparken til at fungere, hvor det ikke bare munder ud i rutsjebaner og lignende,<br />
men også i toiletter, isboder, skraldespande mv. Interessen i spillet ligger i den genre <strong>som</strong> bliver<br />
kaldt for konstruktionsleg, hvor du er herre over din egen lille verden. Spillet vækkede både<br />
interesse hos drengene <strong>som</strong> hos pigerne. Spillet prøver at give et realistisk billede af hvad der<br />
kan ske i en rigtig forlystelsespark, hvor økonomi og budgettering spiller vigtige roller, for<br />
forlystelsens fremtid, og diskussionen om muligheden for inddragelse af matematik i et sådan<br />
spil, var kun positiv og udfordrende mente flere i gruppen.<br />
4.3.7 Spil vs. undervisning<br />
Efter at have diskuteret omkring undervisning, internet og spil, stillede vi spørgsmålet om det<br />
var muligt at indbygge læring i form af computerspil, og dertil svarede de unge at det kunne det<br />
være en rigtig god mulighed for at spille computer samtidig med at man fik noget ud af det.<br />
Flere af de unge snakkede om at andre nuværende engelsksprogede spil, lærte dem bedre<br />
engelsk, hvor de kunne genkende ordene i den engelsk undervisning de fik i skolen. På samme<br />
måde kunne det være muligt at bruge andre sprog, fag og lignende i spil <strong>som</strong> dermed kunne<br />
opbygge forståelsen af undervisningen i skolen.<br />
4.3.8 Konklusion<br />
For at konkludere på vores fokusgruppeinterview kan vi opsummere, at de unge har en interesse<br />
i at:<br />
● Skabe og konstruere, samt opnå ”gudestatus”.<br />
● Opbygge egen karakter <strong>som</strong> de selv er med til at definere.<br />
● Se en reaktion på det man selv har været med til at opbygge.<br />
Disse ovenforstående konklusioner peger alle frem mod den type konstruktions- og rollelegen,<br />
<strong>som</strong> blandt andet benyttes i gudespil genren. I forhold til matematikkens integration i spillet var<br />
netop disse legetyper anbefalingsværdige, hvilket gør dem ekstra interessante i det videre<br />
udviklingsforløb.<br />
20 Man skal i spillet sørge for personerne kommer på toilet til tiden, ellers tisser de hvor de vil,og kræver et<br />
oprydningsarbejde.<br />
Side 43 / 92
5.1 Indledning<br />
Udvikling af et IT-system - Informatik P2 - Projekt – Feb. - Maj. 2007<br />
5.0 Kriterier for edutainment<br />
I de foregående aktiviteter har vi fokuseret på at skaffe en så stor mængde viden om edutainment<br />
<strong>som</strong> muligt. Vi har opnået en teoretisk viden om leg, læring og spil, <strong>som</strong> er grundsøjlerne i<br />
edutainment, og en viden om målgruppen og Undervisningsministeriet <strong>som</strong> interessenter for<br />
edutainmentspillet gennem henholdsvis fokusgruppeinterview og research. Der er gennem<br />
litteraturstudiet og interessentanalysen fundet anbefalinger og krav <strong>som</strong> kan bruges i udviklingen af<br />
spillet. For at sikre at denne viden indgår aktivt i udviklingen af spillet er det imidlertid nødvendigt<br />
at denne viden konkretiseres. I følgende kapitel vil anbefalinger og krav derfor blive sammensat til<br />
kriterier til brug i spillets designproces.<br />
En del af de konkrete anbefalinger vil være nyt stof indhentet fra Konzack og D&A, men hoveddelen<br />
af anbefalingerne sammenbinder, opsummerer eller bygger dog på tidligere præsenteret stof.<br />
5.2 Integration af leg, læring og spil<br />
Integrationen af alle edutainments aspekter er Konzacks vigtigste konklusion: ”Læring, leg og<br />
computermediet skal fungere <strong>som</strong> en samlet enhed” [a, s280]. D&A går endnu længere og<br />
konkluderer at: ”Vi kan slutte, at det ikke er tilrådeligt at udvikle edutainment uden et solidt<br />
teoretisk kendskab til både computerspil og læring”. I forlængelse heraf fastslår D&A at ”Den<br />
måske fornemmeste opgave for edutainment udviklere er at gøre læringen til en naturlig del og<br />
konsekvens af computerspillet og legen” [b, s204]. Eleven skal altså opleve spillets læringsdele<br />
<strong>som</strong> et naturligt resultat af spillets gang. D&A foreslår blandt andet at denne naturlige<br />
konsekvens kan opnås ved brug af meget tydeligt organiseret stof [b, s211]. Veltilrettelagt<br />
information hjælper med til at eleven opnår en flowtilstand fordi elevens opmærk<strong>som</strong>hed ikke<br />
distraheres. I og med man udvikler edutainment, er det vigtigt at gøre spilleren opmærk<strong>som</strong> på<br />
et klart læringspotentiale, frem for at skjule læringen. Den mest oplagte måde at lade læringen<br />
optræde <strong>som</strong> en naturlig konsekvens af legen er dog uden tvivl den problemorienterede tilgang<br />
<strong>som</strong> D&A da også fremhæver <strong>som</strong> en ”opgavestruktur [der] resulterer i refleksion der fremmer<br />
forståelsen”. Dette stemmer også overens med elevernes udsagn i fokusgruppeinterviewet.<br />
Både D&A og Konzack beskriver sammenspillet imellem edutainments forskellige delelementer <strong>som</strong><br />
afgørende i udviklingen. I de fleste edutainment spil forsøges dette sammenspil skjult. Dette tager<br />
Konzack imidlertid afstand fra: ”I og med man udvikler edutainment, er det vigtigt at gøre spilleren<br />
opmærk<strong>som</strong> på et klart læringspotentiale, frem for at skjule læringen.” [a, s140]. Et<br />
edutainmentspil må derfor ikke forsøge at føre spilleren bag lyset – dette vil blive opdaget og spilleren vil<br />
miste tillid til spillet.<br />
D&A er enig i denne påstand, men hæfter sig ved Knud Rasmussens teori for den<br />
udspecificerede leg og mener derfor at legens vilkår skal overholdes. Så længe dette overholdes<br />
er der imidlertid ingen grænse for mængden af læring <strong>som</strong> spillet kan rumme: ”Principielt [er<br />
der] ingen øvre grænse for læringsindhold, så længe Proces / resultat > 1 overholdes” [b, s27] 21 .<br />
I modsætning til Konzacks argument om at spillet og legen skal give plads til læringen <strong>som</strong> et<br />
naturligt element, argumentere D&A for at for meget læring principielt kan fjerne spil<br />
elementet, så man ender med en applikation der ikke er et spil.<br />
21 Se kap. 3<br />
side 44 / 92
5.2.1 Intelligenser, alder og køn<br />
Udvikling af et IT-system - Informatik P2 - Projekt – Feb. - Maj. 2007<br />
D&A mener at jo flere intelligenser der kommer i spil i et edutainment spil, jo større chance er<br />
der for at en spiller formår at løse spillets opgave [a, s156]. ”Det er klart, at jo flere intelligenser<br />
der kommer i spil [...] jo større chance er der for, at brugeren forstår forholdet”[h, s210-211]. Et<br />
konkret eksempel på inddragelse af flere intelligenser er visualisering og verbalisering<br />
konceptet, hvor sideløbende tekst/tale og tilsvarende afbildning appellerer til flere af elevens<br />
intelligenser. D&A advarer dog, at stimuleringen af for mange intelligenser i et spil ofte vil gå på<br />
kompromis med spillets fokus [b, s208+212].<br />
Både Konzack og D&A er enige om at alder og køn er vigtige faktorer i oplevelsen af<br />
edutainment [a, s280]. Konzack anbefaler bl.a. at ”Applikationer skal henvende sig på den<br />
rigtige måde til det alderstrin, den har <strong>som</strong> målgruppe” [a, s283]. I vores <strong>projekt</strong> kan<br />
vigtigheden af dette dog diskuteres da vores målgruppe allerede befinder sig i teenage årene.<br />
Ifølge Piaget er hjernens abstraktionsniveau nemlig færdigudviklet og i stand til at arbejde både<br />
symbolsk og formelt logisk ved teenager årenes begyndelse [d, s170]. Derfor er alder ikke i dette<br />
<strong>projekt</strong> nær så relevant for os <strong>som</strong> for traditionel edutainment der henvender sig til de yngre<br />
elever.<br />
Hvor alderen ikke er så vigtig, er det vores opfattelse at kønsforskellen i teenagealderen er<br />
tilsvarende vigtigere. Her er det ikke læringsmetoden der specielt bør tilpasses eleven, men de<br />
legemæssige aspekter. Spillets underholdning skal således ifølge Konzack ”[...] ligge i<br />
forlængelse af henholdsvis pigers og drenges legekultur”. Det er altså vigtigt at der tages hensyn<br />
til drenge og pigers forskelligartede legepræferencer. På spil der henvender sig til et mere<br />
koncentreret segment, løses dette ofte ved hovedsageligt at lade spillet henvende sig til ét af<br />
kønnene. I vores tilfælde ser vi imidlertid ikke det <strong>som</strong> en mulighed, da målgruppen vil være<br />
skoleklasser, og dermed begge køn. Dette er med til at gøre vores fokus på kønnet endnu<br />
vigtigere, i forsøget på at lave et spil <strong>som</strong> flest mulige finder interessant.<br />
Dette fokus har vi blandt andet forsøgt at skabe igennem udførelsen af vores fokusgruppe.<br />
Fokusgruppe viste at det at kunne opbygge og konstruere ting i spil, eller den såkaldte<br />
'gudestatus', tiltalte både drengene og pigerne 22 . Mere konkret var opbygning og tilføjelse af<br />
personlige egenskaber til sin egen karakter i spillet en stor interesse hos begge grupper.<br />
I forbindelse med konstruktion kommer to af computermediets vigtigste egenskaber –<br />
simulation og interaktion. Hvor konstruktionen i legen normalt er overladt til fantasien eller<br />
modeller (f.eks. legoklodser) giver computermediet mulighed for aktivt at forme og derefter<br />
simulere denne kreation. Denne interaktive og simulationsprægede proces er vigtig for spillet<br />
ifølge D&A ”fordi applikationen reagerer på brugerens input og dermed gør udfordringen<br />
interpersonel” [b, s206][a, s282]. Igennem interaktive elementer tvinges eleven til aktivt at tage<br />
del i læringsprocessen, hvorved refleksion fordres.<br />
5.2.2 Spilgenre<br />
Et væsentligt valg i en spiludviklingsproces er genrebestemmelse. Dette valg har afgørende<br />
betydning for alle efterfølgende valg og både Konzack og D&A tillægger da også dette valg stor<br />
betydning. Konzack tager udgangspunkt i legeteorierne og vurderer konstruktionsleg, rolleleg<br />
samt konkurrenceleg til at have et stort læringspotentiale [a, s144+280]. Af spilgenrer <strong>som</strong><br />
understøtter disse legeformer og lægger op til en refleksiv læreproces, kan simulationsspil og<br />
specielt strategispil anbefales [a, s144+280].<br />
22 Se kap. 4<br />
Side 45 / 92
Udvikling af et IT-system - Informatik P2 - Projekt – Feb. - Maj. 2007<br />
D&A kritiserer i deres bog denne konklusion for at være unuanceret. D&A pointerer i stedet at<br />
de andre typer af spil blot opfordrer til læring på et lavere refleksionsniveau. Vi er imidlertid<br />
noget uforstående overfor denne kritik, da der efter vores mening så vil være tale om træning og<br />
ikke læring. D&A virker da heller ikke selv så overbevisende når de senere undergravende<br />
konkluderer at: ”Refleksion [...] altid forbedrer læringen” [b, s209] og at ”Informationer først<br />
bliver til viden gennem en aktiv bearbejdning i den enkeltes bevidsthed og en integration i hans<br />
eller hendes omverdensforståelse” [b, s134].<br />
D&A argumenterer flere gange for edutainments svære økonomiske placering. Edutainment<br />
konkurrerer både imod de traditionelle læringsmedier, der sætter høje krav til produktets<br />
læringspotentiale samt spilbranchen på den anden side, <strong>som</strong> sætter krav om æstetisk grafik og<br />
et flydende gameplay.<br />
Fra D&A er løsningen imidlertid lige til: ”Originalitet kan hjælpe en applikation til at skille sig<br />
ud fra mængden, hvilket specielt er en fordel for edutainment” [b, s212]. Spil udvikleren er altså<br />
nødt til at tænke nyt og anderledes. Originaliteten giver applikationen mulighed for at skille sig<br />
ud fra mængden af almindelig, og hjælper samtidig med at gøre spillet fængende på trods af en<br />
måske knap så overbevisende grafik [b, s208].<br />
Hvis dette skal lykkes kræver det imidlertid at spillets form (grafik, lyd og teknik) samt indhold<br />
(spillets historie, gameplay og læring mv.) er konsekvent. Kun ved en konsekvent og dermed<br />
genkendelig stil eksisterer muligheden for et originalt design [b, s212]. Derudover sikres spillets<br />
sammenhæng og genkendelighed hvilket er med til at gøre applikationen mere brugbar [k,<br />
s24,][b, s208+212].<br />
5.2.3 Feedback<br />
I forlængelse af Gregory Bateson anser både Konzack og D&A feedback <strong>som</strong> en del af en<br />
refleksiv læringsproces, der er med til at udvikle, og skabe læring hos den enkelte. Derudover<br />
peger D&A også på computermediets store potentiale for netop feedback. Igennem<br />
brugerinteraktion giver mediet mulighed for målrettet ris, ros og opmuntring, hvilket vil virke<br />
motiverende for brugeren [b, s206+209]. Hvis feedbacken afleveres på det rette øjeblik og i<br />
passende doser er den et potentiale for øget motivation til læring.<br />
5.2.4 Narrativitet og underholdning<br />
I følge Konzack er underholdningselementets vigtigste formål at motivere spilleren [a, s156]. Til<br />
dette kan narrativitet udnyttes <strong>som</strong> ifølge D&A er “en væsentlig motivations faktor, der kan<br />
fjerne ensartethed” [b, s207]. D&A nævner i øvrigt at humor er et godt narrativt virkemiddel,<br />
<strong>som</strong> også er med til at spilleren nærer sympati for spillets karakterer [b, s212]. Ved overdrevent<br />
brug af fortællende elementer i spillet, f.eks. lange filmsekvenser, er der imidlertid risiko for at<br />
interaktiviteten hindres. I en interaktiv proces vil eleven deltage aktivt og ejerskab for den<br />
udviklede historie vil opstå. D&A anbefaler derfor at man i stedet søger at udvikle det narrative<br />
<strong>som</strong> en del af interaktionen [b, s208+207]. Konzack pointerer i forlængelse af dette, at strategiog<br />
simulationsgenren, hvor brugeren har stor frihed til at skabe sin egen historie og forståelse<br />
ved at eksperimentere, er at foretrække frem for en genre funderet på konkurrenceleg eller<br />
rusleg 23 .<br />
23 Se Kap 3<br />
side 46 / 92
5.2.5 Repetition<br />
Udvikling af et IT-system - Informatik P2 - Projekt – Feb. - Maj. 2007<br />
Repetition anses almindeligvis <strong>som</strong> en kedelig og anstrengende del af undervisning.<br />
Underholdnings elementet i edutainmentspil er imidlertid med til skabe en øget motivation for<br />
aktiviteten, skriver Konzack <strong>som</strong> anser repetition <strong>som</strong> en af genrens styrker [b, s211]. Dette<br />
stemmer fint overens med at repetition ofte har mere karakter af træning end læring og derfor<br />
har mere gavn af en eventuel opnået flowtilstand – en tilstand <strong>som</strong> er kendetegnet ved et godt<br />
underholdningelement. D&A anser ligeledes repetition <strong>som</strong> en vigtig aktivitet i edutainment. På<br />
længere sigt argumenter Ingeniørhøjskolen i Århus [du], for en repetionscyklus 1 time, 1 dag, 1<br />
uge og 1 måned efter indlæring [vd][du] 24 . Samtidig med at repetionscyklussen integreres i<br />
spillet bør spilperioden ligeledes fastsættes. Med spilperioden menes ikke længden på spillet,<br />
men det sammenhængende tidsrum der hver gang bør sættes af til spillet i en<br />
undervisningssammenhæng. Spilperioden bør ifølge Ingeniørhøjskolen i Århus [du] for at have<br />
en længde på 20-50 minutter hvor læringselementer er vægtet i starten og slutningen af en<br />
periode. Denne anbefaling bliver næsten mere relevant i edutainment øjemed end en traditionel<br />
undervisningssituation, da de mange regressive ”underholdningselementer” vil skabe naturlige<br />
afbræk i læringsperioderne.<br />
5.2.6 Evaluering<br />
D&A anser <strong>som</strong> alle andre evaluering af eleven <strong>som</strong> generelt anbefalelsesværdig i spillet, idet<br />
den kan skabe motivation for brugeren, og samtidig, hvis evalueringen gøres tilgængelig for<br />
underviseren, giver denne mulighed for at tilpasse sit undervisningsniveau til eleven [b s213].<br />
Mere interessant er imidlertid D&A's efterfølgende diskussion af bagsiderne ved logning af alt<br />
data til evalueringsbrug: ”De evalueringer vi har set kan være misvisende, idet de registrerer<br />
alle input og dermed også barnets eksperimenteren med applikationen”. Konzack føjer til at vi<br />
skal være påpasselige med at registrere alle inputs, da dette vil indskrænke barnets mulighed for<br />
at eksperimentere med den givne applikation, og dermed bryde legen [x]. Evalueringen bør<br />
imidlertid ikke udelukkende benyttes men hensyn til planlægning af fremtidig undervisning.<br />
Spillet bør også aktivt forsøge at skabe balance imellem udfordringerne og elevens evner, for<br />
derved, jævnfør zonen for nærmeste udvikling, at opnå flowtilstand.<br />
5.2.7 Social kontekst<br />
I de seneste år er muligheden for social læring ved hjælp af computermediet for alvor blevet<br />
alment tilgængeligt. D&A mener derfor at spillet bør gøre brug af en kollaborativ eller<br />
kooperativ læringsproces. [b, s209]. En sådan læringsproces kan både foregå med flere spillere<br />
samlet omkring én computer, hvor de sammen kan hjælpe hinanden til at løse opgaver og<br />
lignende, samt ved hjælp af netværk mellem flere computere. Dog vedkender D&A sig at<br />
computermedieret kollaborativ læring er forbundet med de samme problematikker <strong>som</strong><br />
forbinder sig til traditionel kollaborativ læring. F.eks. er der risiko for at én elev løser alle<br />
gruppens opgaver, eller eleverne ”deler” opgaver op imellem dem og ikke sørger for at den<br />
enkelte bliver i stand til at løse alle opgaver inden for et læring<strong>som</strong>råde.<br />
24 Se kap. 3.4<br />
Side 47 / 92
5.2.8 Faglige krav<br />
Udvikling af et IT-system - Informatik P2 - Projekt – Feb. - Maj. 2007<br />
For at spillet kan passe ind i undervisningen, skal eleverne selvfølgelig arbejde med de emner de<br />
lærer om i 8. klasse. Undersøgelse af Undervisningsministeriets krav 25 , og vores studie af<br />
lærebøger affødte en liste af emner <strong>som</strong> eleverne gennemløber i 8. årgang. Konkretiseres kravene i<br />
emner for edutainmentsspillets læringsopgaver, fås en liste af matematiske begreber: Geometri, procent,<br />
statistik, algebra, negative tal, ligninger, koordinatsystemet, areal, funktioner, potens og<br />
sandsynlighedsregning.<br />
5.3 Kriterier for god edutainment<br />
# Kriterium Kilde<br />
1 Understreg et klart læringspotentiale [a, s140]<br />
2 Konstruktionsleg, rolleleg og konkurrenceleg skaber højt læringspotentiale. [a, s144+280]<br />
3 Jo flere intelligenser desto større læringspotentiale [b, s210]<br />
4 Undervisningslængde: 20-50minutter, hvor der er mest læringspotentiale i start og i slut. Kap 3.4<br />
5 Underholdning – Har til formål at være motiverende [a, s156]<br />
6 Humor er godt – Alt fra Anders And til South Park [b, s212]<br />
7 Udnyt mediets mulighed for ris, ros og opmuntring [b, s206]<br />
8 Eleven skal deltage aktivt i læringen. [a, s280]<br />
9 Strategispil medfører refleksiv læring [a, s144+280]<br />
10 Refleksion vil altid forbedre læringen. [b, s209]<br />
11 Problemorienteret opgavestruktur medfører mulighed for refleksion. [b, s210]<br />
12 Brug originale elementer [b, s208]<br />
13 Læg vægt på simulation og interaktivitet [b, s206], [a, s282]<br />
14 Brug visualisering og verbalisering på samme tid [b, s211]<br />
15 Hold en konsekvent stil i forhold til grafik og lyd. [b, s208+212]<br />
25 Se kap. 4.2 og bilag 6<br />
side 48 / 92
Udvikling af et IT-system - Informatik P2 - Projekt – Feb. - Maj. 2007<br />
# Kriterium Kilde<br />
16 Skab balance mellem udfordring og evne [b, s206]<br />
17 Organiser stoffet logisk [b, s208]<br />
18 Proces / Resultat > 1 [b, s27], kap 3.2<br />
19 Gudespil er populære i 8 klasse. Kap4.2<br />
20 Tal og algebra, geometri, matematikkens anvendelse samt kommunikation og problemløsning Kap4.0, bilag 6<br />
21 Matematik 8.klasse: Geometri, procent, statistik, algebra, negative tal, ligninger, koordinatsystemet,<br />
areal, funktioner potens og sandsynlighedsregning.<br />
Kap4.0, bilag 6<br />
22 Historie og læring skal sammen udgøre det gennemgående tema. [b, s208]<br />
23 Narrativitet kan fjerne ensartethed [b, s207]<br />
24 Spillets historie skal udvikles løbende – Helst <strong>som</strong> resultat af brugerens interaktion [b, s207]<br />
25 Læring skal være en naturlig konsekvens af spillet [b, s204]<br />
26 Regression og læring 1 medfører flow [b, s91], kap3.4<br />
27 Læring skal være progressivt og regressivt Kap3.4<br />
28 Mulighed for kollaborativ læring bør udnyttes [b, s209]<br />
29 Man bør tage hensyn til alder og køn [a, s280],<br />
kap2.1<br />
30 Piger: æstetisk pænt, hvor begge vil afprøve ekstremer og eksperimentere. [x], kap4.2<br />
31 Repetition – Mindre kedelig i edutainment [b, s211]<br />
32 Repetition: 10-15min efter – 1.time, en dag, en uge, en måned [vd], [du]<br />
33 Udnytte evaluering, dog ikke alle inputs [vd], [du]<br />
Side 49 / 92
6.1 Indledning<br />
Udvikling af et IT-system - Informatik P2 - Projekt – Feb. - Maj. 2007<br />
6.0 Spiludvikling<br />
Dette kapitel er hovedsagelig skrevet ud fra A&R bog On Game Design [f]. De definerer<br />
spildesign <strong>som</strong> processen hvor man:<br />
● Forestiller sig et spil<br />
● Definerer den måde spillet fungerer på<br />
● Beskriver de elementer der udgør spillet (konceptuelle, funktionelle, kunstneriske elementer<br />
m.v.)<br />
● Viderefører informationen til de der skal udvikle spillet<br />
Denne definition er både meget specifik og meget bred. Specifik fordi processen kun omhandler<br />
designet af et spil, og dermed ikke implementeringen samt eventuelt evaluering og afhængig af<br />
produktet. I en anden forstand er processen bred, fordi den beskæftiger sig med spil i alle<br />
genrer. Der er dog nogle gode genrespecifikke elementer i den model, der bliver beskrevet<br />
senere, men i forhold til at honorere de krav der opstår ved udviklingen af et læringsspil, vil det<br />
blive nødvendigt at indtænke nogle nye elementer i designprocessen. Det vil derfor være<br />
nødvendigt at bruge R&A i kombination med en anden udviklingsmodel, så processen samlet set<br />
dækker både alle fagligheder og alle trin i det forløb <strong>projekt</strong>et omfatter. Det vil derfor være<br />
oplagt at benytte følgende <strong>som</strong> en del af en udviklingsmodel.<br />
R&A definerer 7 hovedområder, hvor den første, spilkoncept, skilder sig ud ved at være et<br />
område der fastlægger de overordnede træk ved de 6 andre områder:<br />
1. Spilkoncept<br />
2. Spilverden og settings<br />
3. Historie<br />
4. Karakterer<br />
5. Brugerinterface<br />
6. Gameplay<br />
7. Balance<br />
Grundet produktets korte forløb, vil emnet balance ikke blive gennemgået, da det vurderes til at<br />
være vanskeligt at afstemme spillet uden intensive test af prototypen. Af samme grund vil<br />
teorien bag balanceringen heller ikke blive beskrevet. I stedet henvises til bilag 7, hvor disse<br />
teorier er tilgængelig.<br />
Indholdet af de resterende 6 spildesignområder, vil i de følgende afsnit blive behandlet ét<br />
element ad gangen. Vi har af pladshensyn valgt kun at præsentere de væsentlige overvejelser<br />
man bør foretage sig.<br />
side 50 / 92
6.2 De 7 trin<br />
6.2.1 Spilkoncept<br />
Udvikling af et IT-system - Informatik P2 - Projekt – Feb. - Maj. 2007<br />
I konceptudviklingen er det <strong>som</strong> for et hvert andet produkt. Man bør have en eller flere bærende<br />
idéer til spillet, samt et overordnet billede af, hvordan spillet skal føres ud i livet, hvilke rammer<br />
der skal være for spillet, og hvilke elementer det skal bestå af. I dette <strong>projekt</strong> er spillets rammer<br />
ikke kun defineret på baggrund af den bærende ide, men også påvirket af læringsaspektet og<br />
spillets interessenter. Rammerne, <strong>som</strong> med rette kan kalde spillets regler, beskriver de<br />
handlinger og bevægelser, <strong>som</strong> spilleren kan foretage i spillet, men også de udfordringer og<br />
forhindringer <strong>som</strong> spilleren skal møde.<br />
Ofte er der i spillet et overordnet succeskriterium, <strong>som</strong> afgør om spillet er gennemført, lige<strong>som</strong><br />
der også kan eksistere kriterier for nederlag. Indtænkningen af succes- og nederlagskriterier<br />
afhænger af i hvor høj grad spillet gør brug af et konkurrenceelement, eller om man i spillet så at<br />
sige definerer sine egne mål.<br />
Spillets settings, interaktionsmodel, perspektiv, tilstande og strukturer samt spillerens rolle er<br />
emner der bliver behandlet i de efterfølgende trin, men i udviklingen af konceptet bør man<br />
allerede have en fornemmelse af hvordan spillet skal anvende disse parametre.<br />
Konceptudviklingen vil og skal dermed også give udenforstående et klart billede af hvad det er<br />
for et spil. Helt konkret bør konceptudviklingen munde ud i det <strong>som</strong> R&A kalder ”The Game<br />
Treatment”, hvis formål netop er at præsentere spillet i store træk. Når konceptet er<br />
dokumenteret, er det tid til at se mere specifikt på spillets elementer.<br />
6.2.2 Spilverden og settings<br />
Selv de mest simple spil har en verden, hævder R&A. Det stemmer også overens med Crawfords<br />
definition af et spil, her opereres blot med begrebet (subjektiv) repræsentation 26 i stedet for<br />
verden. Der er to hovedårsag at en grafisk verden skal bygges op om spillet. Spilverden og<br />
settings er for det første afgørende for, om spillet ved første øjekast falder i brugerens interesse.<br />
”Sideløbende med væksten af moderne display-teknologi, er grafikken desto mere vigtig [...]<br />
Grafikken tiltrækker spilleren, og gameplay fastholder ham.” [f, s58]<br />
26 Se kapitel om Spilteori<br />
Side 51 / 92
Udvikling af et IT-system - Informatik P2 - Projekt – Feb. - Maj. 2007<br />
For det andet fører en succesfuldt opstillet spilverden til Suspension of disbelief - udsættelse af<br />
mistillid, der er et udtryk lånt fra litteraturen[ml], hvilket vil sige at spilleren for en afgrænset<br />
periode accepterer den fiktive verden <strong>som</strong> han møder i spillet, og så at sige regner denne verden<br />
for gældende. Det er betingelsen for at spilleren helhjertet kan fordybe sig den historie og de<br />
missioner, <strong>som</strong> han fremstilles overfor. Suspension of disbelief er skrøbeligt, og kan let spoleres<br />
af et på ét punkt uhensigtsmæssigt gameplay eller interface og har i det hele taget mange<br />
ligheder med flow, <strong>som</strong> anvendes af [g].<br />
Spillets settings, gennemføres ved at tage stilling til hvordan spilverdenen skal udformes i<br />
forskellige dimensioner. Herunder vil de blive beskrevet kort.<br />
1. Den fysiske dimension<br />
Her bestemmes spilverdenens rummelige dimensioner og størrelsen på disse. Ligeledes<br />
bestemmes størrelsesforholdet mellem elementer i spilverdenen, med henblik på om<br />
nogle elementer skal forstærkes i deres udtryk i forhold til andre elementers eller<br />
spilverdenens størrelse. Der defineres nødvendigvis nogle grænser <strong>som</strong> spilleren kan<br />
navigere indenfor.<br />
2. Den temporale dimension<br />
Her bestemmes hvordan tidsbegrebet i spillet skal behandles. Der kan være tale om<br />
variabel tid, hvor eksempelvis tiden går hurtigere om dagen end om natten, og unormal<br />
tid <strong>som</strong> kan være brugt i forhold til at fremhæve en symbolsk handling i spillet <strong>som</strong>, med<br />
den ellers anvendte tidsmålestok, ville være overstået på et øjeblik. Endelig kan man lade<br />
spilleren justere tiden, hvilket giver særlig mening i sportsspil og simulationer, <strong>som</strong><br />
ellers adopterer den virkelige verdens tidsbegreb.<br />
3. Miljø<br />
side 52 / 92<br />
Det miljø der skabes i spillet afhænger i særlig grad af den kulturelle sammenhæng, der<br />
ønskes skabt eller efterlignet i spillet. Spillet kan mere eller mindre adoptere den kultur<br />
spillet er designet i, eller det kan helt og holdent betinges af den kultur der eksisterer i<br />
spillets baggrundshistorie og narrative element. Når man så er kommet nærmere den<br />
samfundskultur man ønsker at afbilde, er man i stand til at opstille de fysiske<br />
omgivelser. Her bør også overvejes hvor højt et detaljeniveau spillet kræver – dette<br />
hænger unægtelig sammen med den grafiske og fortællemæssige stil der lægges for<br />
dagen.
Udvikling af et IT-system - Informatik P2 - Projekt – Feb. - Maj. 2007<br />
4. Den følelsesmæssige dimension<br />
Kort sagt handler dette om, hvilke følelser man <strong>som</strong> spildesigner ønsker vagt i spilleren.<br />
Følelserne vækkes ofte <strong>som</strong> et resultat af indlevelse i historien eller karaktererne deri.<br />
Det er klart at hvis for eksempel en form for sympati med spillets karakterer eksisterer<br />
hos spilleren, så vil der også komme et ønske om at hjælpe dem ud af en eventuel<br />
konflikt.<br />
5. Den etiske dimension<br />
Den etiske dimension i spillet afgør hvad der er rigtigt og forkert, og hænger dermed<br />
tydeligvis sammen med den kultur der eksisterer i spillet. Hvor spil på grund af dets<br />
fysiske begrænsninger ikke tillader alle mulige handlinger, giver den etiske dimension<br />
umiddelbart lov til mere ekstreme handlinger end i den virkelige verden. Som det før er<br />
nævnt kendetegnes spil ved at konflikter forstærkes, og dermed ses vold for eksempel<br />
ofte anvendt.<br />
6.2.3 Historie<br />
Næsten alle spil indebærer en historie. Historien kan være veldefineret og fungere <strong>som</strong><br />
introduktion til spillet, eller spillet og historien kan være integreret i hinanden, hvor spilleren<br />
får mulighed for at præge handlingen i den fortalte historie.<br />
Figur 13 forklarer og definerer hvorledes spillets kompleksitet er afgørende i vigtigheden af<br />
fortællingen af spillet.<br />
Idet man bringer en historie ind i spillet, må man også gøre sig klart hvem der er fortælleren. I<br />
modsætning til en film eller en roman, giver spillet mulighed for at gøre spilleren til historiens<br />
forfatter eller fortæller. Dette er nærliggende, da spillets udfald jo afgøres af spillerens<br />
præstation. I de spil, hvor historien spiller en vigtig rolle, er det ligeledes vigtigt at historien ikke<br />
begrænser spillets gameplay, så spilleren kommer til at tro at spillet kører på skinner i en<br />
negativ forstand.<br />
Vigtighed af historie til gameplay<br />
Arcadespil Strategispil First-person shooter Rollespil / Adventurespil<br />
Forøgelse af spillets kompleksitet<br />
Figur 13: Spils kompleksitet<br />
Side 53 / 92
Udvikling af et IT-system - Informatik P2 - Projekt – Feb. - Maj. 2007<br />
For at konstruere en historie der er god og holdbar, findes der forskellige værktøjer. En af disse<br />
er ”The Hero's Journey”, <strong>som</strong> hverken i titel eller handleplan skal forstås bogstaveligt, men i<br />
stedet <strong>som</strong> en ærketypisk fortællings form der kan guide en i udviklingen af spillets historie.<br />
Herunder vil de forskellige elementer i ”The Hero's Journey” blive opstillet og kommenteret i en<br />
spilkontekst.<br />
1. Den almindelige verden – Spilleren introduceres til ”helten”, dennes baggrund og normale<br />
eksistens.<br />
2. Invitation til eventyr – Helten bliver bevidst om den rejse der ligger foran ham. Med andre ord<br />
kan spillet begynde.<br />
3. Afslag på invitationen – Helten udviser oprørskhed eller mismod overfor den opgave han skal<br />
udføre og/eller afviser invitationen.<br />
4. Mødet med mentoren – Når helten beslutter at handle på invitationen, er det mentorens<br />
opgave at give helten den viden der skal til, for at han kan vide hvad han skal gøre herefter.<br />
5. Overskridelse af første dørtærskel – Helten må her kæmpe mod en grænsevogter, <strong>som</strong> kan<br />
være en repræsentant fra fjenden eller et symbol på heltens eller en kompagnons bekymring og<br />
bange anelser.<br />
6. Prøvelser, venner, fjender – Denne fase, <strong>som</strong> ofte er den længste i spillet, indeholder et antal<br />
kampe og udfordringer, <strong>som</strong> helten må overvinde. Her introduceres mange af spillets venlige og<br />
fjendtlige karakterer, samt skygger <strong>som</strong> ofte er onde karakterer i en forklædning.<br />
7. Tilnærmelse til den inderste grotte – Her vil helten finde den belønning <strong>som</strong> han søger<br />
efter, hvilket gør dette til historiens kerne. Spilleren ved nu at der er en stor udfordring forude.<br />
8. Den afgørende prøvelse – Spilleren kæmper mod det ultimative onde.<br />
9. Belønning – Det onde er besejret og belønningen er i hænde. Spillet kan slutte af med en<br />
sekvens der viser de sidste tre elementer af historien, eller det kan være begyndelsen til en<br />
farefuld hjemtur.<br />
10. Vejen tilbage – Helten sætter kurs mod og forbereder sig på at møde den almindelige verden<br />
igen.<br />
11. Genopstandelse – Alle historiens tråde bliver samlet. Her møder helten den sidste række<br />
udfordringer, inden han helt kan nyde sin belønning.<br />
12. Tilbagevenden med belønningen – Helten er tilbage i den almindelige verden med<br />
side 54 / 92<br />
belønningen. Historien og spillet er slut.
Udvikling af et IT-system - Informatik P2 - Projekt – Feb. - Maj. 2007<br />
I on Game Design[f], ses denne historiemodel brugt i forbindelse med den klassiske tre-akters<br />
struktur (Begyndelse – Midte – Afslutning) [f]. Det ses at den periode <strong>som</strong> hovedparten af<br />
handlingen udspiller sig i enhver historie, vil også være den mest interessante og mest<br />
interaktive del af spillet.<br />
6.2.4 Karakterer<br />
Lige<strong>som</strong> der findes en ærketypisk fortællestruktur, kan der af denne også afledes en række<br />
ærketyper eller roller, <strong>som</strong> kan udgøre spillets hovedkarakterer. R&A nævner ni roller i alt,<br />
blandt andet helten, mentoren, allierede, shape-shifter, grænsevogter, budbringer mfl. Behovet<br />
for at udvikle disse karaktertyper vil være til stede i lige så høj grad <strong>som</strong> spillet generelt<br />
anvender storytelling. Spillet karakterer skal i et spil hvor historien er af afgørende betydning,<br />
også være udviklet med en personprofil der stemmer overens med spillets handleplan og<br />
historiske kontekst. R&A opstiller desuden følgende krav for karakterer i overvejende narrative<br />
spil.<br />
● Karakteren skal interessere og fascinere spilleren.<br />
● Karakteren skal få spilleren til at lide ham (hvis karakteren er en form for helt).<br />
● Karakteren skal udvikle sig og vokse i forhold til erfaring.<br />
For alle spil må det være afgørende, at karaktererne stilmæssigt er udviklet i relation til den<br />
setting og spilverden der er fastlagt for spillet.<br />
Side 55 / 92
6.2.5 Brugerinterface<br />
Udvikling af et IT-system - Informatik P2 - Projekt – Feb. - Maj. 2007<br />
R&A deler brugeroplevelsen op i et lydelement, visuelt element og et interaktivt element. Disse<br />
tre elementer skal sammen ”stræbe efter at overbevise ham [spilleren] om at det eneste der<br />
eksisterer, er spillet” [f, s147].<br />
6.2.5.1Lydelementet og det visuelle element<br />
De fleste spil gør brug af lydeffekter, dialog og musik. Lydeffekterne anvendes <strong>som</strong><br />
understøttende real- eller incidentallyd, der gengiver handlingens naturlige lyde. Det anbefales<br />
at man underbygger lyden med et visuelt cue, hvis lyden man hører er et fænomen der ikke<br />
repræsenteres på skærmen. Eksempelvis hvis der i et first person-shooter spil lyder skud fra en<br />
fjende der befinder sig bagved hovedkarakteren.<br />
En implementering af undertekster til dialog, kan ligeledes være med til at hjælpe spillerens<br />
”hørelse” i det virtuelle rum. I forbindelse med dialog er det også vigtigt at der gøres en umage<br />
indsats for at få talelyd, mundbevægelser og mimik til at hænge sammen på en overbevisende<br />
måde. R&A nævner dette <strong>som</strong> en af faldgruberne til spillerens indlevelsesevne og dermed<br />
suspension of disbelief.<br />
Musik er ofte en stor del af spillet og bør derfor også være velvalgt og stemme overens med den<br />
spilgenre man arbejder med, samt underbygge miljøet og stemningen i den verden spilleren<br />
befinder sig i. Musikken skal ligeledes være adaptiv, dvs. hvis en konflikt optrappes,<br />
underbygges dette også med en mere intens og dyster lydside.<br />
Spilmarkedets relativt høje standarder stiller krav til spillets æstetik, om end det på mange<br />
områder ikke har stor indflydelse på gameplay-oplevelsen. Derimod er det i den grad blevet et<br />
salgsargument der ligger til grund for at mange spil kræver den nyeste hardware og software<br />
med henblik på 3D-grafik. Ikke desto mindre er spilindustrien fyldt med ikke-succesrige spil der<br />
fejlede på grund af et utilgængeligt smukt interface. Derfor bør man også netop i 2D-3D<br />
diskussionen opveje fordele og ulemper ved de forskellige teknologier.<br />
6.2.5.2Det interaktive element<br />
Igennem interaktivitet, opbygges selve kommunikationen mellem spilleren og spillet. Herved<br />
afgøres hvordan navigation, skærmlayout, kontrolelementer og information skal integreres med<br />
hinanden. Crawford bruger et velvalgt udtryk for det man ønsker afdækket, nemlig In/Out-<br />
struktur – hvad skal ind og ud af computeren, og hvordan. Resultatet af et navigationsdesign<br />
bør blandt andet være et flowchart der skildrer navigationsforløbet med hovedelementer og<br />
-menuer i spillet.<br />
side 56 / 92
Udvikling af et IT-system - Informatik P2 - Projekt – Feb. - Maj. 2007<br />
I forhold til skærmlayout giver R&A nogle væsentlige slutninger 27 .<br />
● KISS (Keep It Simple, Stupid!)<br />
● Synsfeltets center er bedst i stand til at modtage den mest komplekse visuelle information.<br />
● Den vigtigste information er ofte placeret i nedre venstre hjørne af skærmen.<br />
● Et skærmlayout kan med fordel tage sit afsæt i skabelonerne <strong>som</strong> ses på figur 14 (hvor de grå<br />
områder er status- og infopaneler og de hvide områder er ”spilområdet”.<br />
Generelt med henblik på det interaktive element er det væsentligt at man møder spillerens<br />
forventninger til navigationen, skærmlayout og kontrolmuligheder. Med mindre der eksisterer<br />
en væsentlig grund til at spillet anvender et ny opfundet interaktionsdesign, og spilleren er i<br />
stand til at gennemskue grunden, bør man holde sig til det brugeren kender.<br />
”Hvis standardmetoden til at kontrollere en first-person shooter virker fint, så brug<br />
den[...]Spilleren har meget at lære når han påbegynder et nyt spil, og kun en<br />
begrænset tidsramme han vil være villig til at ofre på det.”[f, s171]<br />
De interaktive elementer kan deles op i in-game og shell elementer, hvor sidstnævnte dækker<br />
over de menuer og skærmbilleder der blandt andet håndterer spillets instruktioner og<br />
indstillinger. Her bør det være muligt for spilleren at komme hurtigt til spildelen, med et eller to<br />
klik. In-game elementer er til for at give spilleren mulighed for status og information undervejs i<br />
spillet.<br />
Figur 14: Skabeloner for skærmlayout<br />
27 Konklusionerne er draget på baggrund af en gennemgang af omkring 2000 skærmbilleder fra forskellige spil [m].<br />
Side 57 / 92
Udvikling af et IT-system - Informatik P2 - Projekt – Feb. - Maj. 2007<br />
De er vigtige da de gør spilleren i stand til at sætte mål, samt motivere sig selv og komme videre<br />
i spillet.<br />
Formidlingen af information gennem ord og billeder bør også overvejes nøje. Man bør <strong>som</strong><br />
hovedregel lægge vægt på grafisk formidling.<br />
”Talemåden ”et billede er mere værd end tusind ord” kommer i spil her – ofte kan en<br />
visuel afbildning fortolkes og forstås meget hurtigere end det tilsvarende<br />
tekststykke.”[f, s180]<br />
Desuden kan udledes følgende retningslinjer for hensigtsmæssig tekst- og ikon-layout 28 :<br />
● Tekststørrelsen må mindst være 12 pixels.<br />
● Brug et miks af store og små bogstaver.<br />
● Begræns brugen af forskellige skrifttyper, eller bliv i den samme skrifttypefamilie.<br />
● Ikoner må ikke kunne forveksles med et andet i det samme interface.<br />
● Sørg for konceptuel forbindelse mellem ikonet og den handling ikonet repræsenterer.<br />
6.2.6 Gameplay<br />
R&A definerer gameplay <strong>som</strong> en eller flere årsagsforbundne rækker af udfordringer i et<br />
simuleret miljø. En udfordring kan være eksplicit eller med andre ord designet og intenderet af<br />
spildesigneren, og den kan være implicit og dermed ufrivilligt opstået gennem spildesignet. I det<br />
følgende gennemgås en række typer af udfordringer <strong>som</strong> de ser ud på et teoretisk plan. I praksis<br />
vil grænserne mellem disse typer være udviskede. Man taler om udfordringer baseret på:<br />
● Logisk slutning – Udtænkning af løsninger på baggrund af logisk sans / sund fornuft.<br />
● Lateral tænkning – Kvalificerede gæt og konklusioner på baggrund af enten viden i spillet og<br />
udefrakommende viden.<br />
● Hukommelse – Disciplinen hvor man eksempelvis husker en række elementer i en kategori.<br />
● Intelligens – Svarer til IQ-tests, <strong>som</strong> sjældent er aktuelt i en spilsammenhæng.<br />
● Viden – Løsninger på baggrund af enten viden i spillet og udefrakommende viden.<br />
● Mønstergenkendelse – Aflæsning af mønstre i eksempelvis en avatars adfærd.<br />
● Moral – Situationer og dilemmaer der fordrer en universel, kulturel, fællesskabs- eller personlig<br />
moral.<br />
● Rummelig fornemmelse – Ofte implicit krav om at kunne gebærde sig i et virtuel rummeligt<br />
miljø.<br />
● Koordination – Manøvrer der knytter sig til styring af flere elementer i spillet.<br />
● Refleks og reaktionsevne – Opfattelse og hurtighed i forhold til at mestre spillets<br />
kontrolelementer.<br />
● Fysik – Anvendelse af kroppen til eksempelvis at mestre et større simulationsinterface.<br />
28 Nogle generelle guidelines gør sig anvendelige i forhold til at udvikle et godt interaktionsdesign i spillet, hvorfor R&A<br />
refererer til et arbejde udført af University of Alabama, <strong>som</strong> står bag et sæt retningslinjer for design af spilinterfaces.<br />
side 58 / 92
Implementerede udfordringer<br />
Udvikling af et IT-system - Informatik P2 - Projekt – Feb. - Maj. 2007<br />
Som en konkretiseret forlængelse af definitionen består gameplay af de udfordringer spilleren<br />
møder og de handlinger han kan foretage for at overvinde dem[f, s228]. I arbejdet med at<br />
implementere en eller flere typer udfordringer, må man se på hvordan disse typisk<br />
konceptualiseres. Nedenfor er opstillet forskellige implementerede udfordringer.<br />
● Race – Tids- og konkurrencemæssige udfordringer<br />
● Puzzle – Mental udfordring<br />
● Udforskning – Forhindringer der tvinger spilleren til at søge efter en løsning.<br />
● Konflikt – Udfordringer der beror på konflikt mellem spiller og spiller/computer i større eller<br />
mindre grad afhængig af handlingens størrelse (fra individer til store grupper), konfliktens<br />
tempo (efter tur eller hektisk aktivitet), succeskriteriernes kompleksitet (fra simpel overlevelse til<br />
komplekse missioner med mål og delmål).<br />
● Økonomi – Udfordringen i at samle ressourcer (penge, point etc.) og forvalte dem på en måde<br />
der er til spillerens fordel.<br />
● Konceptuelle udfordringer – Udfordringer der kræver af spilleren at han forstår en skjult<br />
sammenhæng mellem processer (særligt anvendt i forhold til konstruktions- og managerspil).<br />
Side 59 / 92
7.1 Indledning<br />
Udvikling af et IT-system - Informatik P2 - Projekt – Feb. - Maj. 2007<br />
7.0 Idéudvikling og Designproces<br />
Vi har valgt at arbejde med faget matematik. Det skyldes hovedsagelig matematikfagets meget<br />
formelle, og relativt simple opgaveform, i hvilken svarene til et spørgsmål næsten altid kan tilskrives<br />
et rigtigt eller forkert. I forhold til den senere læringstest, ser vi dette <strong>som</strong> en fordel, da i forvejen<br />
mange faktorer spiller ind i vurderingen af om eleven har lært noget.<br />
Vores designproces er domineret af udviklingen af en kravspecifikation der tager udgangspunkt<br />
i A&Rs ”On Game Design” [f]. I denne proces inddrages analysefasens resultater - listen med de<br />
33 kriterier. Disse kriterier ophænges på tavlen i grupperummet hvor designfasen gennemføres.<br />
Konceptet eller idéen til spillet er det første der bliver beskrevet. Efter dette behandles de<br />
forskellige emner <strong>som</strong> er spilverden, historien i spillet, karakterer, gameplay, opgaver og<br />
brugerinterface.<br />
Det gribes an ved at alle i gruppen læser teorien omkring emnerne i spildesign, diskuterer dem i<br />
forhold til det edutainmentspil, der ønskes, og de 33 kriterier inddrages i beslutningerne. Det<br />
munder ud i designbeskrivelsen, <strong>som</strong> valideres i en designtest der afholdes i forbindelse med<br />
statusseminaret.<br />
7.2 Ide og Koncept<br />
Spillet handler om konstruktion af en forlystelsespark, hvor spilleren skal bygge forlystelser,<br />
boder, restauranter mv., holde parken ved lige, og skabe tilfredse besøgende. Opgaverne<br />
igennem spillet giver spilleren flere og flere muligheder efterhånden <strong>som</strong> de løses.<br />
I spillet får man derfor den rolle, at være driftsleder/ejer af forlystelsesparken. Der vil være<br />
byggeopgaver, hvilke man får brug for matematik for at løse, samtidig med at spilleren<br />
vedligeholder parken. Spillet hører til strategigenren CMS – Construction Management<br />
Simulation (K. 2 og 9).<br />
7.2.1 Formål<br />
Det vigtigste formål med spillet er at spilleren lærer noget, og får en forståelse for matematik.<br />
Opgaver skal derfor opfattes <strong>som</strong> en naturlig del af spillet, og ikke <strong>som</strong> et biprodukt (K.22).<br />
Det overordnede spilmæssige formål er at få en god velholdt forlystelsespark, <strong>som</strong> opnår en<br />
stærk økonomi. Det kan opnås på forskellige måder, blandt andet ved at skabe en anderledes<br />
forlystelsespark, hvor man udfører opgaver og forlystelser <strong>som</strong> måske er urealistiske og<br />
originale. Man får altså ikke kun succes i spillet ved at gå den ”normale” vej, men kan udforske<br />
alternative indgangsvinkler. Dette er valgt for at give spille originalitet og give mulighed for<br />
eksperimentering (K.12 og 30).<br />
Spillet opbygges på den måde, at jo længere spilleren kommer, desto større forlystelsespark får<br />
han. Dermed opstår muligheder for at lave ting <strong>som</strong> går ud over ekstremerne for en realistisk<br />
forlystelsespark, <strong>som</strong> f.eks. at få mange af gæsterne i parken til at kaste op eller vognene til at<br />
flyve. Det åbne univers giver mulighed for de skæve elementer i spillet, og er inspireret af kendte<br />
serier og film <strong>som</strong> South Park og Terkel i Knibe.<br />
side 60 / 92
Udvikling af et IT-system - Informatik P2 - Projekt – Feb. - Maj. 2007<br />
Dette er valgt for at kunne få humor med i spillet (K. 6), det er især den mere makabre slags der<br />
er fokuseret på, da dette distancerer spillet for de traditionelle edutainment spil (K. 12). Spillet<br />
er generelt inspireret af et tegneserie univers, og holdes næsten udelukkende i sort/hvid<br />
”blyantstil”, for at skabe en anderledes og originalt spil (K. 12 og 15). Desuden giver et simpelt<br />
univers bedre mulighed for at implementere mere af spillet til en prototype test.<br />
Spillet består grundlæggende af et åbent landskab, hvor spilleren er med til at opbygge hele<br />
arealet med forlystelser, entre og butikker, <strong>som</strong> indgår i en forlystelsespark. Spilleren får<br />
”gudestatus”, idet han bliver allestedsnærværende i spillet (K.19 og 24). Spillet har forskellige<br />
skaleringsniveauer, idet spilleren orienterer sig med en miniature- og en almindelig oversigt<br />
over forlystelsesparken samt oversigt over den enkelte konstruktion.<br />
7.2.2 Spiltilstande<br />
I spillet skal der være forskellige tilstande, henholdsvis oversigts-, konstruktions- og<br />
driftstilstand.<br />
● I oversigtstilstanden kan spilleren se alle sine forlystelser og placere nye, <strong>som</strong> skal bygges i<br />
konstruktions-tilstanden.<br />
● I konstruktionstilstanden, har spilleren mulighed for at konstruere eller viderebygge forlystelser.<br />
● I driftstilstanden har spilleren mulighed for at se forlystelserne i brug, og dermed kontrollere om det<br />
fungerer. Desuden har spilleren mulighed for at tilse skader eller mangler, <strong>som</strong> forlystelserne kan<br />
have fået.<br />
I både oversigtsbilledet og konstruktionstilstanden, har spilleren mulighed for at indkøbe og<br />
bruge forskellige elementer der passer til den aktuelle tilstand. I konstruktionen af en rutsjebane<br />
er elementerne forskellige former for skinner.<br />
7.2.3 Matematik opgaver<br />
De opgaver <strong>som</strong> spilleren skal løse i forbindelse med konstruktion samt vedligeholdelse af parken, skal<br />
være inde for disse emner (K. 20):<br />
● trekantsberegning<br />
● procent regning<br />
● økonomi og handel<br />
● rumfang- og arealberegning<br />
● ligninger<br />
Opgaverne stilles til spilleren forskellige steder i spillet. Det være sig ved konstruktion af en<br />
rutsjebane, hvor beregning af hastigheden for vognen spiller en rolle, eller ved udregning af<br />
priser for is i isboden så den kan løbe rundt (K. 10 og 11).<br />
7.2.4 Singleplayer / Multiplayer<br />
Spillet skal først og fremmest være singleplayer-orienteret, hvilket betyder at spilleren skal<br />
kunne løse opgaverne alene. Dette er imidlertid et spørgsmål om afgrænsning, da kollaborativ<br />
læring er vigtigt i udviklingen af et edutainmentspil (K. 28).<br />
Side 61 / 92
7.3 Spilverden<br />
Udvikling af et IT-system - Informatik P2 - Projekt – Feb. - Maj. 2007<br />
Indenfor spillets verden taler teorien om den fysiske, temporale, miljømæssige, emotionelle og<br />
etiske dimension. Nedenfor følger resultatet af vores arbejde med disse kombineret med de<br />
konkrette edutainment kriterier 29 .<br />
7.3.1 Den fysiske dimension<br />
Som tidligere beskrevet i kapitel 7.3, finder spillet sted på en græsmark, hvor en indhegning<br />
danner rammen for parken. Det vil dog være muligt at tilkøbe et større areal til parken, således<br />
at der i princippet ikke bliver nogen arealmæssig ”afslutning” på spillet. Vi vil <strong>som</strong> sagt arbejde<br />
med to niveauer af skalering, hvor den ene viser en oversigt over parken. Den anden skalering<br />
vil blive brugt under konstruktion af elementer i parken, og vil simulere opbyggelsen af en given<br />
forlystelse.<br />
7.3.2 Den temporale dimension<br />
Tid har stor betydning hvad angår hændelser <strong>som</strong> kommer både forventet og uforventet i<br />
spillet 30 . Det er centralt at spilleren har mulighed for at opleve at der sker en udvikling og en<br />
progression efterhånden <strong>som</strong> spillet skrider frem. Imidlertid har vi vurderet at jobbet med at<br />
passe parken om natten hurtigt vil blive uinteressant. Af denne grund har vi valgt at lade spillet<br />
foregå i ”evig dag”. Dette løses ved kun at gøre datoen og ikke tiden tilgængelig for spilleren. For<br />
stadig at sikre en vis afveksling (K. 23) i længerevarende spil, bør spillet også indeholde en<br />
vekslen imellem de 4 årstider og vejrforhold. Resultatet for en videreudvikling af en eventuel<br />
rutsjebane skal kunne ses umiddelbart efter, og skal fremgå af spillet i form af de besøgendes<br />
reaktion (K. 10). Få minutter efter skal en øget/mindsket generel tilfredshed indvirke på<br />
parkens besøgstal og popularitet.<br />
7.3.3 Miljø<br />
Spillet finder sted i en fiktiv nutid på et fiktivt sted. Valget af et fiktivt miljø er truffet på<br />
baggrund af vores ønske om at skabe en tegneserieagtig fri verden, <strong>som</strong> ligger op til den frie leg<br />
(K. 18). Ved ikke at definere tid og sted nærmere, lægger spillet op til at eleven skal tage<br />
verdenen til sig <strong>som</strong> sit private lege-/læringsrum (K. 18). Spillets karakterer skal ligne<br />
individuelle personer, der for eksempel kan have forskelligt humør, <strong>som</strong> et resultat af spillet.<br />
Det vil ikke være muligt at se og følge karaktererne inde i bygninger mv.<br />
7.3.4 Den emotionelle dimension<br />
Følelsesmæssigt er det centralt at spilleren helt fra starten føler et ”ejerskab” og ansvar for det<br />
han skaber, da vi vurderer dette ejerskab <strong>som</strong> en af faktorerne for motivation 31 . Spillerne skal så<br />
vidt muligt selv vælge at gennemføre en opgave fordi han føler ejerskab for parken, og ikke blot<br />
fordi spillet tvinger ham til det (K. 15 og 8). Dette skal blandt andet gøres ved at sikre mulighed<br />
for at sætte et individuelt præg på de byggede rutsjebaners former, farver og lignende. Vi anser<br />
det imidlertid her <strong>som</strong> centralt at der ikke bliver tale om en lyserød verden.<br />
29 Se kap 5.0<br />
30 Ifølge et studie af et matematikspillet ”Matematik i måneby” [bb], erfares det at stilstand i spillet er med til at passivisere<br />
spilleren, og skuffe dennes forventninger til spillets underholdningsværdi.<br />
31 Jf. Fokusgruppe se. 3.3<br />
side 62 / 92
Udvikling af et IT-system - Informatik P2 - Projekt – Feb. - Maj. 2007<br />
Målet for de fleste børn er nemlig ikke at skabe den ideelle verden, men i stedet at afprøve<br />
forskellige ekstremer (K. 30). For at skabe et mindre lyserødt spil, skal der indbygges<br />
muligheder for at gæsterne både kaster op eller mister en arm. Desuden har vi overvejet<br />
muligheder for at spilleren tager nogle forelskede i at dyrke sex på et af toiletterne eller en<br />
gruppe unge <strong>som</strong> sidder og ryger hash bag nogle bygninger, med hensyn til at inddrage humor<br />
og gøre spillet originalt (K. 6 og 12). Disse aspekter indeholder dog nogle etiske valg 32 <strong>som</strong> vi<br />
først mener vi kan træffe når produktet er længere i sin udvikling. I forbindelse med et mere<br />
længerevarende <strong>projekt</strong> ser vi også et stort potentiale i at skabe mulighed for at spilleren selv<br />
løbende bestemmer om det er de gode eller onde værdier der skal dyrkes i hans rutsjebane <strong>som</strong><br />
man f.eks. har set det gjort i det meget berømte Black and White. Tilbud fra konkurrenterne om<br />
at sabotere parken kunne f.eks. tikke ind, hvilket ville åbne op for et helt andet gameplay, hvor<br />
målet ville være at skabe så vilde og livsfarlige rutsjebaner <strong>som</strong> muligt (K. 13). Udviklingen af et<br />
sådant koncept er imidlertid for omfattende til at kunne rummes af dette <strong>projekt</strong>.<br />
Et andet væsentligt emotionelt aspekt er at give spilleren en fornemmelse af gudestatus (K. 19),<br />
for derigennem bl.a. at sikre den frie leg og eksperimenteren <strong>som</strong> er central for edutainment<br />
genren. Dette vil imidlertid altid stå i kontrast til ”kravet” om et klart læringspotentiale i<br />
edutainment genren (K. 1). Af den grund har vi valgt at inddrage det økonomiske aspekt i spillet,<br />
idet konstruktion af forlystelser ved hjælp af forkerte udregninger vil ramme spillerens økonomi<br />
og dermed muligheden for at bygge de ”sejeste” rutsjebaner.<br />
7.3.5 Den etiske dimension<br />
Vi mener at det er centralt at spillet ikke pådutter eleverne nogen specifikke etiske holdninger,<br />
hvilket vi vurderer vil få eleverne til at tage afstand fra spillet. Ikke nødvendigvis de ”rigtige”<br />
etiske holdninger vil belønne spilleren – kun de rigtigt besvarede opgaver vil med en vis<br />
tidsforskydelse øge spillerens muligheder. For at understøtte denne moralløse tilgang er<br />
tegneseriegenren blevet valgt, da denne genre, efter vores overbevisning, væsentligt dæmper de<br />
uetiske hændelser i spillets provokerende aspekter.<br />
7.4 Karakterer<br />
Da vi ikke har en narrativ fortælling <strong>som</strong> tager direkte afsæt i ”The Hero's Journey”, kan vi ikke<br />
definere alle dens forskellige karakter. Dog kan vi se spilleren <strong>som</strong> helten spillet, i og med at det<br />
er hans job at sørge for at parken fungerer. Spillets dialog med spilleren kan ligeledes have en<br />
mentoragtig tilgang 33 .<br />
De besøgende skal så vidt muligt afspejle normale mennesker, hvilket blandt andet vil sige at de<br />
hverken skal være søde eller decideret ondskabsfulde. Ved at lade figurerne så vidt muligt<br />
afspejle almindelige mennesker, håber vi at spilleren vil opleve større sympati for de besøgende,<br />
ansatte og derfor ”lytte” mere til disses behov. Alle de besøgende gæster og ansatte, kan opfattes<br />
<strong>som</strong> stereotyper der i egenskaber ikke afviger synderlig fra hinanden. De er af udseende<br />
mennesker med samme egenskaber iført lidt forskelligt tøj (K. 23).<br />
Karakteren skal under spillet afspejle forskellige mangler i parken ved at indtage en afgrænset<br />
mængde mulige ”tilstande”. Fælles for alle tilstande er at de kan løses ved at spilleren<br />
gennemfører flere opgaver. Desuden fungerer de fleste <strong>som</strong> en slags ”omvendt” belønning for at<br />
undgå det ”lyserøde edutainmentspil” 34 . I spillet benyttes følgende tilstande:<br />
32 Bl.a. også fordi programmet henvender sig til skoler og ikke blot almindelig salg i butikkerne<br />
33 Se kap7.2<br />
34 Se kap7.3<br />
Side 63 / 92
7.4.1 Opkast<br />
Udvikling af et IT-system - Informatik P2 - Projekt – Feb. - Maj. 2007<br />
Opkast skal ske på baggrund af at have kørt med for vilde forlystelser. Dette kan enten være et<br />
udtryk for en mangel på de mindre vilde forlystelser, eller omvendt at de vilde forlystelser virker<br />
efter hensigten. For at skelne imellem de to udtryk, skal der på lydsiden forekomme grine lyde<br />
hvis effekten er positiv.<br />
7.4.2 Skader<br />
Der arbejdes med to situationer med skader. Den ene form opstår når de besøgende er så<br />
begejstrede for en given forlystelse, at de ”stormer” mod forlystelsen for at komme med. Dette<br />
fører til overfyldte vogne og tilskadekomne mennesker. Som et hint vil spilleren roses for den<br />
populære forlystelse, men bliver bedt om at gennemføre nogle udregninger i forbindelse med<br />
ansættelse af mere vagtpersonel. Den anden måde karaktererne kan komme til skade er hvis<br />
forlystelsen er bygget for farligt. Karakteren falder så ud af rutsjebanen. Efter uheldet vil<br />
spilleren blive bedt om at gøre noget ved sin forlystelse.<br />
7.4.3 Toilet<br />
Hvis der ikke er nok toiletter i parken, vil karakteren begynde at tisse forskellige steder i parken,<br />
eller i bukserne.<br />
7.4.4 Sult/tørst<br />
Hvis der ikke er nok restauranter og boder, vil karaktererne i spillet optræde sultne. Bliver<br />
problemet ikke løst er der risiko for at karakteren spiser andre karakterer eller besvimer.<br />
7.4.5 Stress<br />
Hvis parkens størrelse er for lille, i forhold til menneskemængden vil karaktererne klage over<br />
størrelsen og blive stressede, hvilket fysisk udmønter sig i at karakteren tager sig til hovedet og<br />
kigger fortvivlet ud på spilleren og råber 'ARGH'.<br />
7.4.6 Diarre<br />
Hvis isboden eller budgettet er for lille, vil karaktererne får dårlig mave af maden og dermed<br />
medføre diarre. Karakterer vil konstant blokere toiletterne, tage sig til maven og uheldigvis gøre<br />
deres bukser beskidte.<br />
side 64 / 92
Udvikling af et IT-system - Informatik P2 - Projekt – Feb. - Maj. 2007<br />
Et eksempel på karaktererne og nogle af deres tilstande kan ses på figur 15:<br />
Overordnet vil en generel utilfredshed med parken resultere i færre gæster, og dermed lavere indtjening.<br />
Udover at udtrykke tilstandene visuelt skal tilstandene, for at tvinge spillerens til at forholde sig til<br />
manglerne (og dermed gennemføre yderlige matematik opgaver for løse problemerne), underbygges med<br />
lydelementer 35 (K. 3 og 14). Spillet er <strong>som</strong> udgangspunkt sort/hvid men ved tilstande skal f.eks. opkast<br />
være skrig grøn, blod være skrig rødt osv. Udover at gøre spilleren ekstra opmærk<strong>som</strong> på problemer i<br />
parken, forventer vi også at dette vil tilføje spillet et mere originalt visuelt udtryk (K. 12).<br />
Størrelsesforholdet mellem karakteren og de andre elementer i spillet, skal være tæt på realistisk. Dog<br />
anser vi det <strong>som</strong> væsentligt at karaktererne stadig har en sådan størrelse at deres ”tilstande” er aflæselige<br />
for spilleren.<br />
7.5 Historie<br />
Før spillet sættes i gang er det vigtigt at til at motivere spilleren, og derfor skal der være en forhistorie,<br />
<strong>som</strong> introducerer spillet til målet med spillet (K. 23). Historien skal virke <strong>som</strong> et anslag <strong>som</strong> vi kender i<br />
dramaturgiens verden[j]. Dog skal denne forhistorie være mulig at kunne ”skippes” hvis en spiller har<br />
læst/set hørt om forhistorien før. Derfor skal forhistorien ikke indeholde vigtige informationer omkring<br />
spillet, <strong>som</strong> gør at spilleren senere i spillet ikke har mulighed for at komme videre. Forhistorien skal være<br />
en teaser <strong>som</strong> introducerer til spillet. Selv om den narrative fortælling i forhold til strategispil ikke nær så<br />
vigtigt, <strong>som</strong> med andre genrer, er den der stadig for at skabe et underholdningsmæssigt formål (K. 5). Den<br />
berømte ”The Hero's Journey” 36 , kan ikke bruges til definitionen af historien, idet den historie <strong>som</strong> bliver<br />
skabt i spillet, er på baggrund af spillerens egne valg.<br />
I forbindelsen med udviklingen af spillet, skal der på samme måde være ting <strong>som</strong> påvirker denne<br />
udvikling for skabe en balance samt narrativitet i spillet. Derfor kan disse fremgå i en form for straf samt<br />
belønning. Vi har herunder listet de mulige hændelser <strong>som</strong> kunne påvirke spillets udfald. De er løst<br />
defineret, da de anses <strong>som</strong> perifere for <strong>projekt</strong>et. Yderligere behandling afgrænses hermed fra spildesignet<br />
og helt fra implementering.<br />
35 Se kap7.7 ”Brugerinterface”<br />
36 Se kap6.2 ”De 7 trin”<br />
Figur 15: Karakter tilstande<br />
Side 65 / 92
7.5.1 Negative hændelser<br />
Udvikling af et IT-system - Informatik P2 - Projekt – Feb. - Maj. 2007<br />
● Tilskadekomst af gæsterne i parken<br />
● Konkurrent til park påvirker forlystelsesparken<br />
● Kontrolmyndigheder (Fødevarekontrol mv.)<br />
● Guds hånd, ufo og rumvæsner<br />
● Vejrmæssige forhold (tornado, tsunami mv.)<br />
● Blokader, strejker og boycuts.<br />
● Terrorister<br />
● Epidemier (diarre, Sars, influenza)<br />
7.5.2 Positive hændelser<br />
● Bonus stjerne-ordning for en god forlystelse<br />
● Michelin-stjerne i forbindelse med restauranter, boder og lign.<br />
● Bonus-økonomi, ved at klare opgaver godt.<br />
De ovenforstående hændelser <strong>som</strong> skal kunne opstå i spillet, skal <strong>som</strong> i det klassiske SimCity tjene til<br />
balance i spillet, og dermed <strong>som</strong> en udfordrende motivation for at skabe succes for parken (K. 5 og 6).<br />
Hændelser skal alt efter graden af dramatisk indhold vises ”real-time” i oversigtsbilledet, eller <strong>som</strong><br />
briefing i tekst og billeder på et popup-vindue (K. 14).<br />
side 66 / 92
7.6 Gameplay<br />
Udvikling af et IT-system - Informatik P2 - Projekt – Feb. - Maj. 2007<br />
Gameplay kan ofte identificeres i forhold til typen af spil. CMS (Construction and Management<br />
Simulation) er en type af strategispil <strong>som</strong> besidder et relativt højt læringspotentiale, samt<br />
forbedrer koordineringsevnen hos eleven (K. 2 og 9). Igennem spillet får spilleren forskellige<br />
eksplicitte og implicitte udfordringer. De eksplicitte udfordringer er de mest centrale i dette spil,<br />
da disse opgave stilles direkte til brugeren (K. 1). Disse opgaver vil altså stort set alle have<br />
matematik <strong>som</strong> omdrejningspunkt. De implicitte opgaver er de generelle opgaver <strong>som</strong> tilføjer<br />
narrativitet til spillet (K. 23) og driver spillet frem.<br />
7.6.1 Eksplicitte udfordringer<br />
Disse udfordringer skal have et klart læringsaspekt, og ligger stort set alle i spillets<br />
konstruktionstilstand. Ved konstruktion af en rutsjebane, stilles nogle krav <strong>som</strong> skal opfyldes for<br />
at rutsjebanen kan blive færdig og vellykket. Igennem processen vil der være opgaver <strong>som</strong> er<br />
konkrete på valg af elementer. Afslutningsvis vil spilleren møde opgaver <strong>som</strong> kræver udregning<br />
på den færdige rutsjebane <strong>som</strong> er baseret på viden i spillet og udefrakommende matematikfaglig<br />
viden 37 . Kompleksiteten af opgaver skal i nogle tilfælde afhænge af spillerens valg, f.eks. således<br />
at en mængde information (eksempelvis topfart, kapacitet, egenvægt, totalvægt) allerede er<br />
tilgængeligt for en almindelig vogn til rutsjebanen, mens en stor og attraktiv vogn ikke har<br />
særlig meget information tilgængeligt, og derfor kræver mere beregning eller flere spørgsmål.<br />
Få gange, kan der forekomme hændelser, <strong>som</strong> spilleren ikke skal have mulighed at ændre på,<br />
<strong>som</strong> munder ud i nye opgaver i spillet. Der vil komme en udefrakommende faktor der påvirker<br />
elementer i spillet, og <strong>som</strong> spilleren skal reagere på. Dette vil lige<strong>som</strong> de implicitte opgaver give<br />
spillet en narrativitet. Se de beskrevne hændelser i afsnittet om spillets historie. Vores opgaver<br />
burde have taget højde for at eleverne måske ikke har lært alle de krævede discipliner i<br />
matematik. Vi mener imidlertid at variationen er central for at det ikke skal blive for kedeligt, og<br />
spillet kan derfor henvende sig til afslutningen af faget/skoleåret <strong>som</strong> repetition af stoffet (K. 7,<br />
31, 32 og 33) 38 . Konkret er der designet fire opgaver. De omhandler henholdsvis beregning af<br />
gennemsnitsfart, sammensætning af bane, beregning af længde samt beregning af<br />
malingforbrug, og kan ses i bilag 5.<br />
7.6.2 Implicitte udfordringer<br />
De implicitte udfordringer er konceptuelle og økonomiske udfordringer og har også til tider et<br />
læringsaspekt. De er vigtige da de giver spilleren en succesfølelse. De implicitte udfordringer<br />
ligger i spillet i den overordnede drift af parken, og har hovedsagelig til formål at skabe flow og<br />
oplevelser. Desuden har de til formål at sikre at spilleren ikke bare oplever spillet <strong>som</strong> en række<br />
stillede opgaver der skal besvares. Spillets statuspanel giver en indikation på hvordan spilleren<br />
klarer sig i disse udfordringer (K. 26 og 27).<br />
Et CMS spil stiller ofte to overordnede opgaver til spilleren: At bygge noget og at drive noget.<br />
Disse to udfordringer er også repræsenteret i dette spil, hvor spilleren skal bygge og drive en<br />
forlystelsespark. Herunder ses en tabel over de specifikke opgaver i spillet, der relaterer til<br />
henholdsvis konstruktion og drift.<br />
37 Se kap. 7.6<br />
38 Se kap. 7.6<br />
Side 67 / 92
Udvikling af et IT-system - Informatik P2 - Projekt – Feb. - Maj. 2007<br />
Konstruktion Drift<br />
● Rutsjebane og andre forlystelser<br />
● Isboder<br />
● Restauranter<br />
● Toiletter<br />
● Stier og veje<br />
● Indgange og udgange<br />
● Information<br />
● Kø-systemer<br />
● Dekoration<br />
● Merchandise butikker<br />
● Udvidelser<br />
● Prisstyring på den generelle<br />
entre/turkort<br />
● Styring af drift<strong>som</strong>kostninger<br />
● Reparation / Renovation / Rengøring<br />
● Markedsføring<br />
Penge er spillets eneste ressource, hvilket forenkler både konstruktion og drift. For eksempel<br />
når man bygger rutsjebaner tager man ikke stilling til enhedsprisen for et stykke træ – man<br />
tager sig heller ikke af at købe det, det vil sige pengenes transaktion sker implicit. I stedet køber<br />
man et element bestående af eksempelvis både træ, skruer og metal, <strong>som</strong> udgør understel og<br />
bane til rutsjebanens næste skinneelement. Denne forenkling er gjort af hensyn til fokusering i<br />
spillets gameplay og læringselement. Det skaber for det første et flow i processen med at bygge,<br />
hvis man ikke skal bekymre sig om detaljer <strong>som</strong> skruernes stykpris, men i et matematisk<br />
læringsøjemed kan man også se fordele ved det modsatte scenarium, at man netop skal have<br />
mange faktorer med i beregningen. Derfor ses også en opgave i spillet <strong>som</strong> går ned i et realistisk<br />
detaljeniveau. 39<br />
Parkens besøgende er, i kraft af deres entre og forbrug i restauranter og boder, den primære<br />
kilde til spillerens ressourcer. Ved spillets start vil der være noget kapital til rådighed til at bygge<br />
for. Dertil kommer bonus-elementer <strong>som</strong> er beskrevet tidligere under 'Historie', da disse i høj<br />
grad også fungerer <strong>som</strong> narrative indspark. Af disse narrativer er der for spilbalancens skyld<br />
også tilføjet ”tilfældige” hændelser <strong>som</strong> påvirker økonomien negativt. Penge spiller en central<br />
rolle, da de bliver brugt af spilleren ved al slags konstruktion og drift, og det er spilleren der i<br />
kraft af hans valg af elementer til konstruktion, påvirker økonomiens udvikling (K. 8 og 13).<br />
Dog nedtones opmærk<strong>som</strong>heden på penge, idet køb, transaktioner, opbevaring og anden<br />
pengebehandling <strong>som</strong> sagt foregår diskret, blot ved sum eller difference på totalbeholdningen,<br />
der er synlig <strong>som</strong> et af spillets forskellige statuselementer.<br />
Hvis spilleren forlader spillet mens det kører, vil simulationen i spillet fortsætte, indtil<br />
udfordringer popper op <strong>som</strong> vinduer. Spillet og simulationen vil pausere efter nogle minutter,<br />
indtil spilleren har løst opgaven. På den måde er det ikke sandsynligt at parken går konkurs på<br />
grund af spillerens manglende reaktion på afgørende hændelser (med mindre parkens økonomi<br />
er helt i bund). Da læringen er det primære mål med spillet (K. 1), er det spillerens interaktion<br />
med spillet og ikke spillet selv, der afgør spillets udfald. En helt praktisk grund gør også disse<br />
scenarier uaktuelle. Spillet skal fungere i skoleundervisningen, hvor en lektion <strong>som</strong> regel varer<br />
45 minutter. Selv hvis spillet blev brugt i en dobbeltlektion, kan man ikke forestille sig afbræk<br />
fra spillet i mere end 10-15 minutter. På samme måde er det også tidselement under<br />
konstruktionen af diverse forlystelser mm (K. 4 og 10).<br />
39 Se evt. bilag 5 med opgave eksempler.<br />
side 68 / 92
Udvikling af et IT-system - Informatik P2 - Projekt – Feb. - Maj. 2007<br />
For at give spilleren mulighed for at opleve positive vendepunkter, skal der ud over de positive<br />
hændelser der tidligere er beskrevet, også eksistere en avanceringsmulighed, der helt konkret<br />
går ud på at spilleren efter konstruktion af tre vellykkede forlystelser, bliver i stand til at bygge<br />
en rutsjebane med loop. I forlystelsesparken skal det være muligt at fjerne en konstruktion, for<br />
at give plads til noget nyt og mere spændende, eller hvis forlystelsens ikke er økonomisk<br />
rentabel (K. 7).<br />
I mange nyere CMS-spil giver spillets brugerinterface mulighed for at operere med eller opleve<br />
en simulation på flere abstraktionsniveauer. Det vil sige at man udover at drive et samfund med<br />
en slags gudestatus i SimCity, også kan få lov til at se på byen fra menneskernes egen synsvinkel.<br />
I dette spil bliver dette ikke muligt, spilleren kan for eksempel ikke komme til at ”sidde” i<br />
rutsjebanen om end han kan simulere den og se den i funktion. Konstruktionerne bliver – på<br />
grund af designets afgrænsning til en 2-dimensionel platform – stærkt forsimplede i forhold til<br />
virkeligheden, og det resulterer blandt andet i at toget på en rutsjebane kun kører op og ned i<br />
forhold til én retning (beskrevet i senere afsnit om 'Brugerinterface'). En såkaldt first-person<br />
simulation ville blive tilsvarende uinteressant, og på grund af den manglende realisme gøre at<br />
spilleren mister tillid til spillet (K. 13).<br />
En vigtig ting i CMS spil er en indikation på hvordan spilleren klarer sig i spillet. Muligheden for<br />
at analysere og gøre status med henblik på at forbedre sin indsats er altid til stede i spillet. For<br />
det første i kraft af statuspanelet i nedre venstre hjørne af skærmen. Her vil spilleren kunne se<br />
statistik over sin pengebeholdning samt udgifter og indtægter over tid, antal besøgende i parken<br />
over tid og endelig parkens popularitet set i lyset af dens placering på en hitliste over ”landets<br />
forlystelsesparker”. Denne sammenligning skal med for at motivere spilleren til at skabe den<br />
bedste park og give ham en følelse af, at parken ikke er det eneste der eksisterer i spillet (selv om<br />
det jo er tilfældet).<br />
Det andet ”analyseværktøj” spilleren kan gøre brug af i spillet er hvad R&A omtaler <strong>som</strong> mind<br />
reading (K. 14). I stedet for at ty til statistisk analyse, kan spilleren ved at klikke på en af parkens<br />
gæster se dennes forskellige parametre, for eksempel graden af sult, kvalme, stress, om han skal<br />
på wc osv. Parkens besøgende bliver på denne måde repræsentanter for spillets generelle status.<br />
En for lille park med for mange gæster vil påvirke en del af gæsternes parametre (stress, kvalme)<br />
på en negativ måde.<br />
Spillet er ikke et ”rent” CMS spil. Det at matematiklæring er så tydeligt tilstede i mange af<br />
spillets udfordringer vil gøre at simlutationsaspektet træder i baggrunden. Det vil være muligt at<br />
forsøge at løse mange udfordringer på spillerens umiddelbare fornemmelse (logisk slutning 40 ),<br />
men vil udløse nogle konsekvenser senere, for eksempel i form af en livsfarlig rutsjebane, <strong>som</strong><br />
vil få spilleren til at løse opgaven matematisk (lateral tænkning). Nogle af disse konsekvenser<br />
vil være direkte forbundet til forskellige simulationsforhold i spillet, andre vil tage skikkelse af et<br />
narrativt input, det vil sige en dialogboks <strong>som</strong> fortæller hvad der er sket og hvad der bør gøres.<br />
7.6.3 Overvejelser vedrørende. køn<br />
Hensyntagen til overvejende pigernes æstetiske sans, er tænkt ind i spillets gameplay på den<br />
måde at en æstetisk flot rutsjebane, giver ekstra gode besøgstal. Æstetik er imidlertid meget<br />
svært at måle på, så derfor måles det på banens variation (dvs. brugen af så mange forskellige<br />
elementer til banen <strong>som</strong> muligt) og om man har valgt at male den. Drenge udfordres ved at<br />
kunne lave vilde baner, og dermed øge parkens popularitet. Konkret skal brug af stejle<br />
elementer og høj hastighed i en simulation resultere i at banen ved første øjekast bliver mere<br />
attraktiv (K. 29).<br />
40 Se kap. 6.2<br />
Side 69 / 92
7.7 Brugerinterface<br />
Udvikling af et IT-system - Informatik P2 - Projekt – Feb. - Maj. 2007<br />
I vores design af spillets brugerinterface, er fokus lagt på den prototype vi vil implementere frem<br />
for det “optimale” spil, <strong>som</strong> vi behandler i de andre afsnit. Dette er gjort for at vi i<br />
validationsfasen, her designtesten, vil være i stand til at teste så meget af spillet <strong>som</strong> muligt.<br />
7.7.1 Overordnet brugerinterface<br />
Der er lavet nogle generelle retningslinjer for brugerinterfacet i spillet.<br />
Sproget er dansk, da spillet henvender sig til en dansk skoleelev. Engelsk vil give en<br />
sprogbarriere for elever <strong>som</strong> er dårlige til engelsk 41 og fokus for spille er at udvikle matematikog<br />
ikke engelskkundskaberne.<br />
Hvad angår skrifttype bruges der en karikeret tegnet skrifttype, <strong>som</strong> er med til at definere den<br />
verden <strong>som</strong> spillet omhandler. Derudover skal tekststørrelsen sat til at være over 12 pixels, da<br />
den så overholder de retningslinjer er for hensigtsmæssigt tekstlayout. Der skal i spillet skabes<br />
en balance imellem store og små bogstaver, og de forskellige ikoner må ikke kunne forveksles<br />
med andre i samme vindue.<br />
Spillets inputenheder bliver både mus og keyboard. Dette er de mest brugte input enheder i<br />
konstruktionsgenren, fordi de tilsammen giver relativt avancerede muligheder for interaktion<br />
med spilverdenen, <strong>som</strong> er krævet i et spil af denne type. Der er brug for at flytte rundt på<br />
elementer, og indtaste tal og bogstaver igennem spillet. Da de færreste skoler råder over adgang<br />
til joystick og lignende input enheder, og da spillet ikke er specielt actionpræget, har vi fravalgt<br />
understøttelse af sådanne.<br />
Musen har forskellige funktioner, hvorfor cursoren vil skifte afhængigt af hvilken operation der<br />
kan aktiveres. Når man placerer cursoren over et element man kan flytte, former den sig <strong>som</strong> en<br />
udstrakt hånd. Over elementer der kan vælges, formes den <strong>som</strong> en pegende hånd. Vi har valgt at<br />
benytte nedenstående todelte layout 42 i hele spillet (K. 15). Panelet til venstre anvendes til at<br />
hente elementer ind på in-game området, samt til at vise status for spillet. Ideelt set bør spillet<br />
have et oversigtsbillede, placeret i panelet til venstre, men afgrænses imidlertid.<br />
Spillet deles op i forskellige tilstande, hvor brugerens muligheder er defineret og afgrænset i<br />
forhold til den aktuelle tilstand. Disse tilstande vil i det følgende blive defineret.<br />
41 Specielt fordi der er tale om fagsprog <strong>som</strong> generelt <strong>som</strong> er væsentligt svære at mestre end almindelig sammentale<br />
42 Se afsnit om brugerinterface 6.2<br />
side 70 / 92<br />
Figur 16: Skærmlayout for spillet
7.7.2 Menu<br />
Udvikling af et IT-system - Informatik P2 - Projekt – Feb. - Maj. 2007<br />
Denne tilstand præsenterer spilleren for en menu, hvor spilleren har følgende muligheder:<br />
● Start spil Starter en nyt spil.<br />
● Indlæs spil Starter et tidligere gemt spil.<br />
● Instruktioner Her får spilleren en introduktion til hvordan spillet skal spilles.<br />
● Credits Lister navne på de personer der har været med i udviklingen af spillet.<br />
● Afslut Afslutter spillet.<br />
7.7.3 Oversigtstilstand<br />
Denne spiltilstand er en del af selve spillet. Oversigtsbilledet giver spilleren et overblik over<br />
forlystelsesparken, hvor spillerens forskellige forlystelser er vist. I denne tilstand bruges det<br />
todelte layout <strong>som</strong> tidligere er beskrevet. I panelet findes de forskellige elementer man kan<br />
trække ind og placere på oversigtsbilledet. Elementer er i denne sammenhæng rutsjebaner,<br />
boder mv. Der skelnes altså mellem elementer der konstrueres og drives, de <strong>som</strong> er placeret på<br />
oversigtsbilledet, og elementer <strong>som</strong> spilleren har til rådighed og kan købe, de <strong>som</strong> er placeret i<br />
panelet. Forlystelserne <strong>som</strong> spilleren kan bygge trækkes ind i oversigtsbilledet med musen, og<br />
placeres på græsarealet hvor spiller ønsker det.<br />
Forlystelserne <strong>som</strong> kører i spillet er repræsenteret med et billede på oversigtbilledet, <strong>som</strong> viser<br />
forlystelsen (f.eks. en rutsjebane), man kan klikke på billedet for at komme til<br />
konstruktions/status tilstanden for denne forlystelse. Desuden vil oversigtsbilledet, figur 17, vise<br />
de besøgende <strong>som</strong> figurer der bevæger sig mellem forlystelserne (K. 13).<br />
Figur 17: Oversigtsbilledet<br />
I panelet er der desuden statusindikatorer, <strong>som</strong> viser spillerens pengebeholdning. Desuden vil<br />
der være statusindikatorer <strong>som</strong> viser spillets status for et aktuelt valgt element. Det skal f.eks.<br />
være status for en forlystelse, <strong>som</strong> viser hvordan indtjeningen går, hvor mange personer der<br />
kommer igennem forlystelsen, om forlystelsen er ved at være slidt og derfor kræver reparation,<br />
eller hvor langt opbygningen af forlystelsen er. Dette vises med progressbars og ikoner der<br />
skifter udseende. Det samme gør sig gældende for de besøgende gæster. Både elementer og<br />
parkens gæster afslører deres forskellige parametre ved hjælp af en klik-aktiveret drop-down på<br />
musens placering.<br />
Side 71 / 92
7.7.4 Konstruktions- og drift tilstand<br />
Udvikling af et IT-system - Informatik P2 - Projekt – Feb. - Maj. 2007<br />
Denne tilstand indtræder når en forlystelse skal bygges eller ses i driftstilstand. Her benyttes det<br />
todelte layout igen, for <strong>som</strong> sagt at holde konsistens i spillets brugerinterface (K. 15).<br />
Forlystelsen opbygges af elementer. I tilfældet med en rutsjebane vil elementerne være dele af<br />
banen (blandt andet et fladt stykke, en stigning og et loop). Der kan også finde andre elementer<br />
så<strong>som</strong> maling, <strong>som</strong> giver mulighed for at male rutsjebanen. Disse elementer findes i panelet.<br />
Området til højre er byggeområdet hvor forlystelsen præsenteres i sin helhed.<br />
Hvert element har nogle egenskaber, disse egenskaber ses når man holder musen over<br />
elementerne. For at bygge en forlystelse trækkes elementerne ind i byggeområdet, og<br />
sammensættes der. Man vil herefter kunne se i statuspanelet hvordan købet af elementet har<br />
påvirket økonomien. Hvis et element kræver en udregning før det kan placeres, vil et input felt<br />
komme til syne ved siden af elementet når <strong>som</strong> skal udfyldes før det kan placeres. Elementerne<br />
kan fjernes igen ved enkeltvis at trække dem væk fra banen. Efter konstruktionen er færdiggjort,<br />
kan man sætte forlystelsen i drift, og simulere om den virker <strong>som</strong> den skal.<br />
side 72 / 92<br />
Figur 18: Drift tilstand<br />
Figur 19: Konstruktions tilstand
8.1 Indledning<br />
Udvikling af et IT-system - Informatik P2 - Projekt – Feb. - Maj. 2007<br />
8.0 Designtest<br />
Efter<strong>som</strong> enden af første designfase er nået, og et spildesign er på plads, finder vi det vigtigt at teste<br />
om spillet umiddelbart ser ud til at hænge sammen. Testen består af en mundtlig evaluering på<br />
baggrund af en mundtlig og visuel præsentation af spillets design og koncept, og bliver gennemført i<br />
forbindelse med <strong>projekt</strong>ets statusseminar den 19. april 2007, hvor hoved- og bivejleder samt 5<br />
medstuderende er til stede <strong>som</strong> evaluatorer.<br />
Det vurderes at en præsentation for en sådan gruppe, er et udmærket grundlag for feedback,<br />
både med hensyn til vejlederne, <strong>som</strong> begge har beskæftiget sig praktisk og teoretisk med læring,<br />
didaktik og pædagogik, samt i forhold til tre af de fem informatikstuderende der i en tidligere<br />
periode har gennemført eksamens<strong>projekt</strong> omhandlende spilanalyse, alle med gode resultater til<br />
følge.<br />
8.3 Planlægning<br />
Som nævnt gennemføres systemudviklingens første test, <strong>som</strong> en evaluering af det foreløbige<br />
spildesign, på baggrund af en præsentation af spillets settings, karakterer, brugerinterface og<br />
gameplay, altså mange af hovedpointerne fra kapitel 7 samt relevante skitser af spilprototypen.<br />
Grunden til at historie ikke bliver præsenteret eksplicit er at det narrative, kommer til syne<br />
gennem præsentation af de andre emner. Spilbalance skal <strong>som</strong> nævnt tidligere gennemføres i<br />
forbindelse med den tekniske implementering af spillet, hvorfor vi heller ikke ønsker feedback<br />
herom. Testen er planlagt til at tage tyve minutter ud af de fyrre minutter vi har til rådighed<br />
under statusseminaret. Der er 4 personer til at præsentere spildesignet.<br />
8.4 Spørgeskema<br />
Før præsentationen har hver evaluator modtaget en simpel liste af spørgsmål for at hjælpe dem<br />
på sporet af de problemstillinger vi ønsker belyst. Selv samme liste af spørgsmål danner også<br />
baggrund for udvælgelse af relevant information til præsentationen. Derudover har de fået<br />
udleveret tekst <strong>som</strong> omhandler spildesignet. Målet er dermed at søge efter mangler i<br />
spildesignets sammenhæng, integration mellem spil og læring, modstridende elementer samt<br />
generelle forslag til forbedringer.<br />
8.5 Dataindsamling<br />
Til dataindsamlingen under designtesten, bruges en computer til at logge hvad evaluatorerne<br />
har af kommentarer til spildesignet. Evaluatorernes hovedsynspunkter fra designtesten samt<br />
hvad der er taget til efterretning er tilgængelig i bilag 2.<br />
8.6 Konklusion<br />
Den feedback på spillet <strong>som</strong> designtesten gav anledning til var efter vores opfattelse meget<br />
brugbar. Eksempler på diskussioner i designtesten er at der i spillet ikke var indtænkt en<br />
hjælpefunktion, udover generelle instruktioner og derfor var et krav fra evaluatorerne at der<br />
skulle være en mulighed for hjælp til løsning af matematikopgaverne i spillet. En løsning til<br />
dette ville være en hint-knap, <strong>som</strong> giver en mulighed og guider eleven til at finde svaret eller<br />
metoden.<br />
Side 73 / 92
Udvikling af et IT-system - Informatik P2 - Projekt – Feb. - Maj. 2007<br />
En anden ting <strong>som</strong> kommer til diskussion under designtesten, var det etiske aspekt i spillet, <strong>som</strong><br />
er afgørende for spillet i en fremtidig skolesammenhæng. For at løse denne problematik vil et<br />
dybdegående interview med en lærer være relevant, da det er ham der står med ansvaret for<br />
undervisningen.<br />
En række af disse emner <strong>som</strong> kom til diskussion under testen, betød at spildesignet fik nye<br />
tilføjelser i det videre forløb med udviklingen af <strong>projekt</strong>ets edutainmentspil. Sidstnævnte<br />
lærerinterview er dog på baggrund af en afgrænsning blevet undladt.<br />
side 74 / 92
9.1 Arbejdsgang<br />
Udvikling af et IT-system - Informatik P2 - Projekt – Feb. - Maj. 2007<br />
9.0 Implementering<br />
Systemudvikling af denne art, med flere udviklere om et program, er nyt for alle i <strong>projekt</strong>gruppen.<br />
Helt konkret er udgangspunktet at tre ud af fire i gruppen ingen erfaring har med programmet<br />
Flash, men det er målet, at alle skal lære at udvikle ved hjælp af Flash og programmeringssproget<br />
Actionscript. Derfor vælges en tilgang, hvor alle kommer til at prøve sig frem, med mulighed for<br />
hjælp fra den erfarne i gruppen og selvfølgelig internettet. Udviklingen af spillet deles op i små<br />
opgaver, <strong>som</strong> løses i grupper af en til to personer. Den skrevne kode kan måske ikke direkte indgå i<br />
den færdige prototype, men i det tilfælde vil opgaven gå videre til en anden gruppe eller person. På<br />
den måde sikres også, at hver person kommer til at se meget af spillets kode. Et eksempel på en<br />
sådan ”miniopgave” kan være: få to grafiske objekter til ”snappe” sammen, når de nærmer sig<br />
hinanden.<br />
Da det for størstedelen var første gang Flash blev brugt <strong>som</strong> udviklingsværktøj, brugtes en del<br />
tid på at sætte sig ind i programmeringssproget ved hjælp af diverse tutorials og litterært<br />
materiale. Et gruppemedlem havde allerede erfaring med Flash. Det betyder, at han brugte en<br />
del tid på at hjælpe de resterende tre gruppemedlemmer under implementeringen. Enkelte<br />
gange, hvor vi har haft problemer med at udføre opgaverne, har vi taget pauser fra<br />
programmeringen, og haft en dialog med andre i gruppen for at kunne reflektere over opgaverne<br />
og få en anderledes forståelse af de forskellige opgaver, for bedre at kunne komme med en<br />
løsning på opgaverne.<br />
9.2 Kodestruktur og eksempler<br />
Udover målet at implementere en prototype af spillet, eksisterer der også et studiemæssigt<br />
formål med udviklingen. Det mål er at opnå en grundlæggende viden om objektorienteret<br />
programmering. Flash er grundlæggende objektorienteret, så i udviklingen er arbejdet med<br />
objekter og metoder mv. noget, der vil komme naturligt. Flash giver selvfølgelig mulighed for at<br />
lave egne klasser, hvilket er noget, vi gerne vil udnytte for at blive bedre til objektorienteret<br />
programmering.<br />
Selve vinduet, <strong>som</strong> bliver synligt for brugeren, kaldes i udviklingsprogrammet en Scene. En<br />
Scene har en tidslinje med såkaldte frames, i hvilke der kan placeres billeder, grafik, lyd samt<br />
Actions. Actions er scripts, der, <strong>som</strong> navnet antyder, er skrevet i sproget Actionscript. I Flash<br />
kan et grafisk element omdannes til et MovieClip med sin egen tidslinje. Når et MovieClip<br />
skabes, bliver det en del af et Library og kan herefter duplikeres uendeligt. Alle MovieClips kan<br />
også indeholde actions.<br />
En Action på en Scene kunne være:<br />
onEnterFrame = function() {<br />
}<br />
attachMovie(”movieClipName”, ”instanceName”, 1, {_x:200, _y:120});<br />
Side 75 / 92
Udvikling af et IT-system - Informatik P2 - Projekt – Feb. - Maj. 2007<br />
Denne Action består af en eventhandler, der eksekverer funktionen attachMovie, når<br />
programmet når til den frame, <strong>som</strong> scriptet er placeret i. Funktionen tager <strong>som</strong> standard tre<br />
parametre og placerer med den information et MovieClip med navnet: ”movieClipName” og<br />
instansnavnet: ”instanceName”. Den tredje parameter 1 kan forstås <strong>som</strong> det lag, MovieClip'et<br />
skal placeres i (1 er det underste lag), begyndende oven på alle de i forvejen placerede lag.<br />
Mulige ekstra parametre er for eksempel bestemmelsen af _x og _y attributterne, der gør, at<br />
MovieClip'et placeres i koordinatet 200,120, når det kommer frem på scenen.<br />
Under placeringen af et MovieClip tilknyttes et objekt <strong>som</strong> er en instans af MovieClip-klassen.<br />
Der er altså muligt at kalde forskellige metoder på ”movieClipName”.<br />
Denne ide med at grafiske elementer tilknyttes en klasse og deraf har nogle metoder videreføres<br />
i, hvordan spillets klasser laves.<br />
Den del af spillet, vi implementerer, er opgaven med at bygge en rutsjebane. Rutsjebanen skal<br />
bestå af nogle sammensatte skinneelementer. Under denne opbygning er der brug for en<br />
funktionalitet, der laver en kopi af et skinne element, <strong>som</strong> man <strong>som</strong> spiller kan trække det ind i<br />
scenen og placere det. Spilleren skal kunne bruge flere af den samme type element. Denne<br />
funktionalitet kunne sagtens tænkes at være brugbar andre steder i spillet. Spillets første klasse<br />
laves for at kunne oprette objekter med en metode, der kan duplikere sig selv. Denne klasse<br />
kaldes Element.<br />
9.2.1 Klassen Element<br />
Elementklassen arver fra MovieClip klassen, det vil sige, at man kan bruge de samme<br />
egenskaber og metoder på et objekt af klassen Element, <strong>som</strong> man kan med et objekt af klassen<br />
MovieClip. Dette giver kun mening hvis der til objekter af Element klassen er tilknyttet grafiske<br />
elementer, da MovieClip klassen har forskellige metoder, f.eks. til at reagere på museinteraktion<br />
med objektet. Disse arvede metoder udnyttes f.eks. ved dragging (hvor det ønskes at flytte et<br />
skinneelement med musen). Metoden onPress() <strong>som</strong> udføres når der klikkes på et MovieClip,<br />
bruges til at starte dragging hvis bestemte kriterier er opfyldt. Et sådant kriterium kunne være at<br />
elementet ikke befinder sig et sted hvor det ikke skal kunne flyttes, f.eks. midt imellem<br />
skinneelementer i en rutsjebane.<br />
Et eksempel på en ny metode <strong>som</strong> ikke er arvet fra MovieClip klassen, <strong>som</strong> bruges til<br />
duplikering er dup().<br />
9.2.2 Klassen Skinne<br />
Nogle metoder og variabler giver ikke mening i relation til andet end skinner, <strong>som</strong> bruges til<br />
opbygning af rutsjebanen. En ny klasse er oplagt, så disse metoder ikke kommer på alle<br />
instanser af Elementklassen. Denne klasse er spillets anden klasse og får navnet Skinne. Da<br />
metoderne fra Element er brugbare på skinner, arver Skinne fra Elementklassen.<br />
Nogle af metoderne på Skinneklassen er blandt andet forskellige ”get”-metoder, der afleverer<br />
værdier, eksempelvis længden af skinnen. Disse værdier bruges til beregning, når et tog på<br />
rutsjebanen skal animeres.<br />
side 76 / 92
9.2.3 Klasser <strong>som</strong> arver fra Skinne<br />
Udvikling af et IT-system - Informatik P2 - Projekt – Feb. - Maj. 2007<br />
I spillet laves der ikke instanser af Skinne, i stedet implementeres en masse subklasser, hvis<br />
forskelligheder består i forskellig tildeling af værdier for klassevariablerne (længden, retningen<br />
mv.) En sådan klasse kunne være b210:<br />
class element.b210 extends element.Skinne {<br />
}<br />
MaxSpeed:Number = 60;<br />
MinSpeed:Number = 20;<br />
SpeedChange:Number = -20;<br />
RunLength:Number = 2;<br />
Retning:Number = 1;<br />
VennerList = new Array("l0_mc", "b180_mc", "b30_mc");<br />
Klassen b210 kan for eksempel være tilknyttet et tilsvarende MovieClip ved navn b210_mc, se<br />
figur 20.<br />
9.2.4 Klassen Skinner<br />
Når spilleren ”bygger” rutsjebanen, er der brug for en ”container”, der opbevarer alle<br />
Skinneobjekterne, både for senere at kunne vide. hvilke objekter der er i den byggede<br />
rutsjebane, og for at have forskellige metoder, der er relevant for flere Skinneobjekter, der<br />
sammen udgør en rutsjebane. Skinnerklassen ser således ud:<br />
class element.Skinner {<br />
private var sListe = new Array();<br />
function Skinner (_start:MovieClip) {<br />
}<br />
sListe.push(_start);<br />
function addSkinne(lskinne:element.Skinne) {<br />
}<br />
sListe.push(lskinne);<br />
function delLastSkinne() {<br />
}<br />
sListe.pop();<br />
Figur 20: Eksempel på MovieClip<br />
skinneelement.<br />
Side 77 / 92
}<br />
Udvikling af et IT-system - Informatik P2 - Projekt – Feb. - Maj. 2007<br />
function checkIfInListe(_skinne:MovieClip) {<br />
}<br />
var iListe:Boolean = false;<br />
for (var i = 0; i
Udvikling af et IT-system - Informatik P2 - Projekt – Feb. - Maj. 2007<br />
Det samlede UML-diagram for de beskrevne klasser er ses på figur 21. Klasserne Start, b30 og<br />
b60 er blot tre af de mange klasser, der kan implementeres <strong>som</strong> forskellige skinneelementer.<br />
9.2.5 Scripts uden for klasserne<br />
on(press) {<br />
}<br />
var userMaxNumber:Number = max_fart_user.text;<br />
if (userMaxNumber == _root.topSpeed) {<br />
}<br />
Mange funktionaliteter i spillet kodes ikke til at<br />
ligge i en klasse, men ligger i stedet på en<br />
Scenen eller i MovieClips, <strong>som</strong> Actions. På<br />
figur 22 ses den grafiske repræsentation af en<br />
opgave i spillet, hvor spilleren skal finde den<br />
gennemsnitlige fart og den maksimale fart,<br />
<strong>som</strong> rutsjebanen muliggør med den<br />
sammensætning af skinneelementer, der er<br />
lavet. Kun opgaven om maksimal hastighed er<br />
implementeret. Spilleren må ud fra<br />
beregninger på de procentvise stigninger og<br />
fald, <strong>som</strong> kan aflæses på skinneelementerne<br />
(fordi de er en instans af klassen b30, b90, l30,<br />
l60 osv.), regne sig frem til, hvor toget har haft<br />
den højeste fart. Koden, der tjekker svaret og<br />
giver feedback, er implementeret på et<br />
MovieClip. Når MovieClip'et trykkes på med<br />
musen, eksekveres følgende action.<br />
attachMovie("flueben","flueben",this.getNextHighestDepth(),<br />
↪{_x:max_fart_user._x, _y:max_fart_user._y});<br />
if (userMaxNumber != _root.topSpeed) {<br />
}<br />
Figur 22: Opgave eksempel<br />
attachMovie("minus","minus", this.getNextHighestDepth(),<br />
↪{_x:max_fart_user._x, _y:max_fart_user._y});<br />
Først deklareres variablen userMaxNumber og tildeles samme værdi <strong>som</strong> tallet, der er skrevet i<br />
tekstfeltet max_fart_user. Da userMaxNumber er af datatypen number, kan det indtastede tal<br />
herefter sammenlignes med variablen topSpeed, <strong>som</strong> indeholder den rigtige talværdi. Efter<br />
sammenligningen hentes, alt efter udfaldet i de to if-konstruktioner, enten et MovieClip i form<br />
af et flueben eller et minus, ind oven på max_fart_user-tekstfeltet. Funktionen<br />
getNextHighestDepth er indbygget i Flash og er særdeles anvendelig, hvis man vil være sikker<br />
på, at den dybdeværdi, man tildeler MovieClip'et, er det højeste ledige lag.<br />
Side 79 / 92
Udvikling af et IT-system - Informatik P2 - Projekt – Feb. - Maj. 2007<br />
9.4 Konklusion på implementering<br />
Den objektorienterede tilgang til implementeringen var fordelagtig, idet koden til spillet blev<br />
genbrugt og struktureret logisk. Problemet bestod i høj grad i at implementere et genkendeligt<br />
objekt (rutsjebanen) fra virkeligheden, med de muligheder og begrænsninger dette objekt reelt<br />
besidder. Objektorienteret programmering tillader, at man kan behandle objekter i en om end<br />
abstrakt, så alligevel hierarkisk og logisk orden, der ikke viger så meget fra virkeligheden. På<br />
dette grundlag kan hele spillet ses <strong>som</strong> en opgave, der kan løses objektorienteret: En<br />
forlystelsespark består af forskellige forlystelser, nogle forlystelser er rutsjebaner, en rutsjebane<br />
består af sammensatte skinner osv.<br />
I den del af spillet, der blev implementeret, er der <strong>som</strong> beskrevet også problemer, der ikke blev<br />
løst objektorienteret. De overvejelser, der ligger bag dette, er, at koden i den sammenhæng kun<br />
skal afvikles én gang og dermed ikke skal benyttes andre steder i spillet. Der er også<br />
kodestykker, det ikke er naturligt at placere i en klasse. En tredje grund er endelig, at ikke alle<br />
<strong>projekt</strong>gruppens medlemmer havde en basal forståelse for objektorienteret programmering,<br />
men trods det var målet, at alle skulle have mulighed for at kode på spillet. Hvis spillet skulle<br />
implementeres helt, er det muligt, at flere funktionaliteter, f.eks. med hensyn til startmenuen,<br />
kunne implementeres i klasser, men dette blev nedprioriteret til fordel for <strong>projekt</strong>ets læringsmål<br />
i relation til udvikling i Macromedia Flash.<br />
side 80 / 92
10.1 Indledning<br />
Udvikling af et IT-system - Informatik P2 - Projekt – Feb. - Maj. 2007<br />
10.0 Diskussion og Konklusion<br />
Hensigten med dette afsnit er at opridse nogle generelle konklusioner på de erfaringer, <strong>projekt</strong>et<br />
gav, samt diskutere deres validitet.<br />
Problemformulerings hovedspørgsmål lød:<br />
Hvordan udvikles et edutainmentspil, således at teorier for leg, læring og spildesign samt<br />
de forskellige interessenters krav indgår balanceret?<br />
Problemanalysen stillede en række delspørgsmål. Første spørgsmål lød:<br />
Hvorledes inddrages målgruppen og andre interessenter i udviklingsprocessen?<br />
For at kunne inddrage målgruppen samt andre interessenter så meget i processen <strong>som</strong><br />
overhovedet muligt, er problemstillingen forsøgt besvaret via en interessantanalyse, herunder<br />
undersøgelse af Undervisningsministeriets fællesmål og et fokusgruppeinterview af<br />
målgruppen. Målgruppeanalysen bekræfter de antagelser, vi før analysen havde haft i<br />
forbindelse med den valgte målgruppe. Et af de mere konkrete resultater er, at målgruppen har<br />
en interesse i computerspil der muligør gudestatus. Det at kunne skabe ting, samt muligheden<br />
for at opbygge karakterer med personlige egenskaber, betyder meget for de unge.<br />
Målgruppeanalysen bekræfter, at der forskel på piger og drenges spilvaner og præferencer, dog<br />
er der enighed om, at spilgenrer der benytter sig af konstruktionsleg, er interessante for begge<br />
køn. Analysen giver en forståelse af, hvilke elementer i spil, <strong>som</strong> tiltaler de unge mere end andre.<br />
F.eks. kan man ud fra fokusgruppeinterviewet konkludere, at piger har en større interesse for<br />
det grafisk æstetiske i spil, samt at begge køn føler stor interesse i at eksperimentere og gå mod<br />
grænserne i et spils gameplay. Endelig giver målgruppeanalysen et indblik i elevernes<br />
umiddelbare holdning til læring i computerspil, og det kan konstateres, at computermediet<br />
generelt har en stor interesse hos de unge. Sammenfattet kan målgruppeanalysen tilføje nogle<br />
krav til edutainmentspillet, der hjælper det til at orientere sig mod 8. klasses-elever.<br />
Undervisningsministeriet fælles mål for faget matematik begrænser os til kun at arbejde med<br />
bestemte opgavetyper i matematik. Vi har for at kunne definere mere konkrete opgaver benyttet<br />
os af bøgerne Faktor [h][i], <strong>som</strong> bliver brugt <strong>som</strong> undervisningsmateriale i folkeskolen, og<br />
dermed sikret, at fællesmålene bliver rettet mod et 8. klasses niveau.<br />
Resultatet af fokusgruppeinterviewet giver en større forståelse af målgruppen, og formen kan<br />
anbefales, idet det har skabt synergi mellem deltagerne under interviewet. Det opleves <strong>som</strong> en<br />
ressourceøkonomisk metode, der giver kvalitativ information på en hurtig og enkel måde.<br />
Fokusgruppeinterviewet giver mulighed for, at målgruppen kan give personlige input til<br />
<strong>projekt</strong>et.<br />
Side 81 / 92
Udvikling af et IT-system - Informatik P2 - Projekt – Feb. - Maj. 2007<br />
Med målet at opnå indsigt i mulige læringspotentialer i spil kan fokusgruppeinterview med<br />
målgruppen ikke anbefales, idet test af læring ikke ressourcemæssigt kan defineres under et<br />
fokusgruppeinterview, og i dialog med eleverne, uden indblanding fra undervisere. Derimod er<br />
det en god metode til at få et detaljeret indblik i den udvalgte målgruppes præferencer for<br />
computerspil. Udvælgelsen af deltagerne har stor betydning, idet vi oplevede, at en gruppe på et<br />
til to piger fik meget taletid og stor holdningsmæssig dominans. Der blev valgt flere piger end<br />
drenge til fokusgruppeinterviewet ud fra en antagelse om, at drenge vil forsøge at dominere i de<br />
fleste sociale sammenhænge. Dog har vi fundet ud af, at overvægten af piger viste sig at være<br />
uheldig, da pigerne i denne alder er længere i udviklingen end drengene.<br />
En anden grund kan være, at vi i opstillingen til interviewet kom til at adskille et godt<br />
makkerpar, der, når de sidder sammen, ellers støtter hinanden i deres holdninger. Det bekræfter<br />
derfor, at man er nødt til at finde en hensigtsmæssig balance under udvælgelsen af deltagere til<br />
en fokusgruppe – og det være sig på flere parametre så<strong>som</strong> alder, køn, personlighed og erfaring.<br />
Derfor er det også vigtigt at få et indblik i målgruppen, inden fokusgruppen afvikles, hvilket bør<br />
tages til efterretning i tids- og ressourceplanlægning for denne aktivitet. Synergien, <strong>som</strong> blev<br />
skabt under fokusgruppeinterviewet, samt den ressourceøkonomiske metode, kan bekræftes<br />
<strong>som</strong> nytteværdi og klart brugbart <strong>som</strong> en bedst mulig inddragelse af målgruppen samt<br />
interessenterne i udviklingsprocessen.<br />
Ergo kan målgruppen og andre interessenter inddrages i udviklingsprocessen via en<br />
interessantanalyse, hvor et fokusgruppeinterview kunne være nyttigt for en større forståelse af<br />
målgruppen, og andre interessenter kunne inddrages via en specifik teoretisk tilgang for en<br />
større forståelse.<br />
Hvilke læringsteorier kan med fordel inddrages i udviklingen af et edutainmentprodukt?<br />
Arbejdet med at finde frem til de læringsteorier, der kan inddrages i udviklingen af<br />
edutainmentspillet, er gjort gennem litterært studie samt et dybdeinterview med Konzack.<br />
Ud fra de tilegnede teorier har der været teorier, <strong>som</strong> giver et fundament for forståelse af læring.<br />
Teorier <strong>som</strong> Jean Piagets om assimilation og akkumulation har leveret et fagligt grundlag for<br />
<strong>projekt</strong>et, de har dog ikke været konkret anvendelige. På samme måde har teorier for de syv<br />
intelligenser givet os et væsentlig teoretisk fundament for <strong>projekt</strong>et, men ikke været konkret<br />
anvendeligt.<br />
Hvad angår mere konkret anvendelige teorier, er teorier for lagring, undervisning samt<br />
repetition brugbare i udviklingen af spillet. Teori om progression og regression, er en hjælp i<br />
forhold til inddragelse og tilrettelæggelse af opgaver og udfordringer, samt design af spillet.<br />
Behaviorismen er anvendelig i forhold til at se læringsmuligheder og -begrænsninger i<br />
registrering af spillets input og output. Desuden giver behaviorismen en forståelse for, hvad<br />
forskellen på læring og træning er. Kognitivismen giver et indblik i, hvor komplekst det er at<br />
teste læring både før undervisningen og efter, og gør opmærk<strong>som</strong> på, hvor komplekst læring i<br />
realiteten er.<br />
Teorier for flow og zonen for nærmeste udvikling, giver en forståelse for, hvorfor det er<br />
hensigtsmæssigt at kombinere computerspil og læring, og hvor væsentlig indtænkning af<br />
differentieret undervisning er. På samme måde har det været nyttigt i forhold til at få<br />
matematikken til at være en integreret del af spillet. I relation til problemorienteret<br />
opgavestruktur hjælper konnektivismen og organiseringen til at få en større forståelse inden for<br />
dette felt.<br />
side 82 / 92
Udvikling af et IT-system - Informatik P2 - Projekt – Feb. - Maj. 2007<br />
Læringsniveauer og refleksion påpeger, hvor vigtig aktiv deltagelse i undervisning er. Teorien<br />
viser vigtigheden af at undgå kun at lægge vægt på træning, men også give mulighed for et<br />
højere refleksionsniveau. For at understøtte refleksion skal spilleren mærke, at der er en<br />
konsekvens eller belønning og lade vedkommende få ejerskab over spillet. I praksis er resultatet<br />
en integrering af ris og ros samt hjælp i spildesignet.<br />
Sammenfattet kan det nævnes at der findes visse læringsteorier <strong>som</strong> er konkret anvendelige i<br />
udviklingen af edutainmentspil, hvorfor disse teorier også kan danne baggrund for<br />
designkriterier for edutainment.<br />
For at udvikle edutainment til undervisningssammenhænge bliver man desuden nødt til at have<br />
samme forståelse af teorier for og anvendelsen af læring, <strong>som</strong> en underviser har, idet man i<br />
implementeringsfasen er nødt til at træde ud af rollen <strong>som</strong> programmør og være i stand til at få<br />
et fundamentalt samarbejde om læring for at kunne agere <strong>som</strong> ”eksperter” i udviklingen af<br />
edutainment.<br />
I forhold til designprocessen af edutainmentspillet er D&A teori anvendelig, dog kan det ikke<br />
valideres, idet der ikke er gennemført test af læringsindholdet i spillet.<br />
For at konkludere: Teorier for behaviorisme, kognitivisme, konnektivisme, refleksion,<br />
progression, regression, lagring, undervisning, læringsniveauer, repetition, organisering, flow og<br />
zone kan med fordel inddrages i udviklingen af et edutainmentprodukt.<br />
Hvordan kan en teoretisk forståelse for leg og spil udnyttes i forbindelse med<br />
edutainment?<br />
For at vi kunne besvare dette spørgsmål, undersøgte vi forskellige teorier for leg og spil.<br />
Teorierne giver, udover en forståelse for, hvad der kendetegner leg og spil, et billede af, hvor stor<br />
indflydelse legen har succesfuld edutainment. Konkret anvendelse af teorien i forhold til<br />
udvikling af edutainmentspillet er sket i bestemmelse af genren for spillet. Genren for et spil er<br />
kendetegnet ved et bestemt typisk gameplay og dermed også forskellig inddragelse af leg.<br />
Ved at opdele leg i forskellige legetyper og frihedsgrader kan der identificeres styrker og<br />
svagheder på den måde, man i spillet inddrager leg på. Spilteorien bekræfter, at spillet i kraft af<br />
dets fiktive virkelighed og sikkerhed er en mulighed for at afprøve ekstremer og gøre ting, man<br />
ikke kan i virkeligheden.<br />
Da vi har erfaret, at udviklingen af edutainmentspil på nogle områder ikke adskiller sig fra<br />
udviklingen af spil, synes det vigtigt at få en forståelse af spil inden udviklingen af<br />
edutainmentspil. Teorien for spillet er fra 1985, hvorfor dens relevans for nutidens spildesign<br />
kan diskuteres. I et interview fra 1997 [e, s88] står Chris Crawford imidlertid stadig inde for<br />
teorien, hvilket gør, at den alligevel anvendes i <strong>projekt</strong>et.<br />
Vi er under udviklingen blevet opmærk<strong>som</strong> på risikoen for, at inddragelse af læring i spil sker på<br />
bekostning af legens frihedsgrad, hvilket bekræfter, at der skal gøres et stort arbejde i vægtning<br />
af edutainmentspillets indhold, for at spilleren ikke skal føle sig dikteret gennem spillet. En<br />
anden diskussion går på, at der i teorien for leg, ifølge Knud Rasmussen, ikke findes leg<br />
defineret efter 12-årsalderen, og dermed er teorien ikke aktuel i forhold til udviklingen af vores<br />
<strong>projekt</strong>. De andre teorier, vi medtager om leg og spil, antyder dog ikke, at legen forsvinder, men<br />
måske blot får andre motiver. Derfor benytter vi en teori i forhold til udvælgelsen af legetyper,<br />
<strong>som</strong> ikke er baseret på aldersinddeling.<br />
Ved at opnå en forståelse for legetyper og frihedsgrader samt spilteorier, <strong>som</strong> definerer spillet i<br />
kraft af dets fiktive virkelighed og sikkerhed, giver det en forståelse for, hvordan leg og spil<br />
udnyttes i forbindelse med edutainment.<br />
Side 83 / 92
Udvikling af et IT-system - Informatik P2 - Projekt – Feb. - Maj. 2007<br />
Hvordan kan balancen imellem leg/spil og læring fastlægges i udviklingen af edutainment,<br />
og hvordan kan man sikre, at resultaterne af første analysefase indgår aktivt i de<br />
efterfølende faser?<br />
Én måde, hvorpå der er forsøgt at finde balancen imellem leg/spil og læring, er et studie af<br />
relevant edutainmentteori og opstilling af de 33 kriterier i forhold til udviklingen af<br />
edutainmentspil og designtesten. I opstillingen af kriterierne for edutainmentspillet er de blevet<br />
nummeret for at give et større overblik over, hvilke krav der honoreres. Det kan med teorien<br />
blandt andet sluttes, at legen i edutainmentspil generelt går mod Ludus-ekstremet frem for<br />
Paidia. Det vil sige, at edutainmentspil i dag har tendens til at være mere regelstyret frem for<br />
mere frit og styret af spilleren. Med de 33 kriterier, <strong>som</strong> er opstillet for edutainmentspillet,<br />
eksisterer en kombination af krav for leg/spil og læring, der relativt nemt kan efterleves.<br />
Der kan ses en sammenhæng mellem læringsinddragelse og legens frihedsgrad. For meget<br />
læringsindhold i et spil kan føre legen mod Ludus. Det vil da være læringen, der sætter<br />
dagsordenen for spillet. Ligeledes betyder en overvægt af Paidia-leg i spillet, at der ikke vil være<br />
plads til et læringsmål.<br />
Opstillingen af de 33 kriterier er en effektiv måde til organisering af kravene,<br />
analyseresultaterne sikres i det videre forløb i systemudviklingsprocessen og kan tilmed spores,<br />
idet deres nummer indgår under dokumentationen af designfasen. Kriterierne har været<br />
væsentlige i forhold til inddragelse af læringsopgaver og -udfordringer i spildesignet. I<br />
implementeringsfasen har de kun været relevante i det omfang, der er taget stilling til spørgsmål<br />
relateret til spildesignet.<br />
Konzack mener, at balancen imellem leg/spil, læring og computermediet skal gå op i en højere<br />
enhed, det vil sige, at man skal sørge for, at det ene ikke overstiger den anden. Blandt de<br />
opstillede kriterier for edutainment er enkelte kriterier stadig undladt i forhold til udviklingen af<br />
spillet, da de ikke vurderes <strong>som</strong> afgørende for netop dette spil. Generelt er det derfor svært at<br />
forudse, hvilke kriterier der er anvendelige i forhold til et edutainmentspil, alt efter hvordan<br />
spillet udfolder sig i design- og implementeringsfasen.<br />
Ergo findes balancen imellem leg/spil og læring ved inddragelse af en Luhmannsk tilgang, <strong>som</strong><br />
overlapper teorierne for leg/spil med teorierne for læring, For at sikre os, at resultaterne fra<br />
første analysefase indgik aktivt i de efterfølgende faser, brugte vi de opstillede kriterier for vores<br />
edutainmentspil til 8. klassetrin i faget matematik.<br />
Hvilke særlige krav til systemudviklingsmodellen opstår i en edutainmentudviklingsproces?<br />
For at kunne finde den systemudviklingsmodel, der tilgodeser edutainmentspil, blev der<br />
foretaget en teoretisk gennemgang af de hyppigt brugte systemudviklingsparadigmer,<br />
multimedieudviklingmodeller samt en fremgangsmåde til design af spil. I og med at de<br />
forskellige modeller ikke specifikt pegede på en udviklingsmetode i forhold til edutainment, blev<br />
der sammensat en systemudviklingsmodel af eksisterende paradigmer og modeller, <strong>som</strong><br />
gennem tilpasning giver en spiludviklingsmodel, der tog højde for edutainment.<br />
Efter at systemudviklingsprocessen var gennemført, var det på et praktisk erfaringsmæssigt<br />
grundlag muligt at belyse, hvordan den udviklede systemudviklingsmodel fungerede <strong>som</strong> model<br />
for edutainmentspil. Det, <strong>som</strong> gav et billede af modellens anvendelighed og validitet, var den<br />
delvise afprøvning af modellen til og med implementeringen af en prototype, samt<br />
dokumentationen for, hvordan og hvor vi i udviklingen brugte de 33 kriterier for edutainment.<br />
side 84 / 92
Udvikling af et IT-system - Informatik P2 - Projekt – Feb. - Maj. 2007<br />
Processen fra designfasen gennem en kravspecifikation til implementeringen har vist, at der ofte<br />
har været et behov for flere gange at gå tilbage i designfasen, primært fordi kravspecifikationen<br />
har været en relativt løs beskrivelse af spillet. Det kræves derfor, at det samme team, <strong>som</strong><br />
arbejder med design af edutainmentspillet, også er implementeringsteamet, fordi faserne<br />
springer fra den ene til den anden. En mere fastlagt kravspecifikation, hvor spillet er beskrevet<br />
fra ende til anden både teknisk, grafisk og lydmæssigt, kunne muliggøre brug af udviklere med<br />
mindre kendskab til leg, læring og spil.<br />
Med en sådan model vil processen minde om en vandfaldsmodel og dermed også egne sig til<br />
<strong>projekt</strong>er, hvor designteamet og implementeringsteamet er to uafhængige instanser. I vores<br />
udvikling af et edutainmentspil har vi dog fundet det oplagt til tider at lade de designmæssige og<br />
implementeringsmæssige opgaver smelte sammen, blandt andet affødt af, at<br />
udviklingsværktøjet Flash i dens sammenblanding af formgivning og programmering ofte<br />
indbyder til kreativitet. Som overvejende nybegyndere i Flash var det også svært at se<br />
mulighederne i værktøjet, før vi blev fortrolige med det.<br />
Det har vist sig at modellen kræver at udviklerne har bred viden inden for leg/læring og spil,<br />
<strong>som</strong> gør dem i stand til at give en mere konkret kravspecifikation til implementeringsfasen. Da<br />
designfasen har været i fokus frem for implementeringen, kan systemudviklingsmodellen kun<br />
ses <strong>som</strong> særlig relevant op til implementeringen.<br />
De 33 kriterier<br />
Som refleksion over en generel model for edutainment blev de inddelt i 33 kriterier for<br />
edutainment i følgende skema, efter hvordan og hvor kriterierne er blevet brugt til designet af<br />
spillet. Denne gruppering vil også være hensigtsmæssig for at udskille den information, der er<br />
relevant for udvikling af spilkoncept, gameplay osv.<br />
Kriterier, <strong>som</strong> ikke bør indgå i designfasen andet end<br />
i konceptudviklingen<br />
Kriterium 9, 2, 4, 19, 28, 29, 32 og 33<br />
Bør anvendes i udviklingen af gameplay/opgaver Kriterium 20 og 21<br />
Gruppe af kriterier, <strong>som</strong> bør være tilgængelig under<br />
hele designfasen<br />
Bagvedliggende generelle kriterier Kriterium 16 og 17<br />
Tabel 4: Kriterium kategorier<br />
Kriterium 1, 5, 6, 7, 8, 10, 11, 12, 13, 14, 15, 18,<br />
22, 23, 24, 25, 30 og 31<br />
Det er i anvendelsen af kriterierne løbende blevet klart, at nogle kriterier ikke er så konkret<br />
anvendelige, relevante eller blot bekræfter andre kriterier. Kriterium 27 (”Progression og<br />
regression”) er eksempelvis uinteressant, da progression siger sig selv, og regression er omtalt i<br />
kriterium 26 (”Regression og læringsniveau 1”). En gruppe af kriterier (K. 15 og 23) er i lige så<br />
høj grad forbundet med spildesign. Disse kriterier er således relevante for udvikling af<br />
edutainment, men da spildesign indebærer, at mange håndværksmæssige kriterier overholdes i<br />
forhold til layout, grafik mv. vil listen over kriterier blive for lang og uoverskuelig <strong>som</strong> værktøj.<br />
Det må bemærkes, at kriterierne kun påvirker designfasen. Erfaringen har været, at<br />
implementeringen ikke er påvirket af de 33 kriterier, men kun af designfasen og<br />
kravspecifikationen. Når der alligevel vendes tilbage til kriterierne, betyder det, at der foretages<br />
nye overvejelser i henhold til spildesignet.<br />
Side 85 / 92
Udvikling af et IT-system - Informatik P2 - Projekt – Feb. - Maj. 2007<br />
Sammenfattet kan man sige, at de 33 kriterier er en udmærket teknik til at inddrage tidligere<br />
analyse i designfasen. En klar forbedring af teknikken kunne dog ske, hvis kriterierne grupperes<br />
efter anvendelse i spildesignfasen og konkretiseres, så man undgår de helt generelle kriterier.<br />
Derudover kan det siges om forholdet mellem design- og implementeringsfasen, at der med<br />
fordel kan laves en mere klart defineret kravspecifikation, såfremt implementeringsholdet<br />
består af udviklere med kompetencer inden for både formgivning og programmering.<br />
Hvordan kan en prototypetest af spil såvel <strong>som</strong> læringsindhold gennemføres?<br />
Gennem litterært studie af læring og edutainment samt interview med Konzack forsøgte vi at<br />
finde frem til en måde at teste læring på. Vi stødte på enkelte testmetoder for læring, <strong>som</strong> kunne<br />
ske via multiple-choice-tests. Konzack mente, at testen skulle udføres før brugen af spillet og<br />
bagefter. På samme tid nævner teorien om repetition, at viden først tilegnes helt efter repetition<br />
op til en måned efter. Man kan altså ikke konkludere noget på en persons tilegnede viden, hvis<br />
den kun er få minutter gammel. Derfor er læringstest en lang proces, der ikke kan gennemføres i<br />
undervisningsøjeblikket for en prototypetest.<br />
side 86 / 92
Udvikling af et IT-system - Informatik P2 - Projekt – Feb. - Maj. 2007<br />
11.0 Pædagogiske Perspektiveringer<br />
11.1 Indledning<br />
I det efterfølgende diskuteres de perspektiver, <strong>som</strong> vi anser <strong>som</strong> centrale for eventuel yderlig<br />
forskning, der tager afsæt i det gennemførte <strong>projekt</strong>. Disse perspektiver vil være overvejende<br />
rettet mod en mulig pædagogisk anvendelse af edutainmentspil. Vi vil runde af med et<br />
perspektiv på test af læring.<br />
11.2 Evaluering af eleven<br />
Vi har i dette <strong>projekt</strong>, afgrænset os fra muligheden for at give feedback til læreren.<br />
Computermediet giver mange gode muligheder for at indsamle data om brugerens aktivitet, <strong>som</strong><br />
er oplagte at udnytte i udviklingen af edutainmentspil <strong>som</strong> vores [b, s206].<br />
Vores spil er tænkt <strong>som</strong> en del af den normale undervisning, og igennem spillet stilles eleven<br />
løbende over for mange sammenhængende opgaver. Disse typer opgaver er forsøgt opbygget på<br />
samme måde <strong>som</strong> matematikbøgernes typiske opbygning, hvor hver opgave er opdelt i en<br />
mængde delopgaver, hvis sværhedsgrad forøges af spørgsmål. Er opgaven stillet korrekt, er et<br />
blankt svar på delopgave 2 et udtryk for, at heller ikke delopgave 3 vil kunne besvares.<br />
Denne opgaveopbygning gør det muligt for læreren at få adgang til en del af de kognitive<br />
processer, <strong>som</strong> gennemløbes hos eleven, der almindeligvis er et lukket område. Herved danner<br />
læren sig et indtryk af elevens stærke og svage sider.<br />
I modsætning til papiropgaverne, giver computermediet imidlertid mulighed for nemt og hurtigt<br />
at give læreren et statistisk overblik over den samlede klasses svage sider, når fremtidige<br />
”indsat<strong>som</strong>råder” skal fastlægges – en unik mulighed, der bør udnyttes [b, s206].<br />
Implementering af evalueringsværktøjer vil imidlertid rejse væsentlige problemer i forhold til<br />
legens frie rum. Som vi tidligere har været inde på, er en at de helt store udfordringer for<br />
edutainmentgenren at skabe synenergi imellem leg og læring, således at et frit læringsrum<br />
skabes, hvor eleven kan eksperimentere. Dette ”frie rum”, <strong>som</strong> kræves for, at legen udmunder i<br />
succes, forsvinder imidlertid, hvis eleven har kendskab til at der evalueres [x]. Spilleren kan<br />
komme til at føle sig begrænset, når han/hun ved, at andre kan se de fejl han/hun begår under<br />
sine ”eksperimenter”, og det er derfor centralt, at en eventuel evaluering kun finder sted i<br />
afgrænsede områder af spillet, og at disse områder er tydelige for eleven.<br />
11.3 Undervisningsdifferentiering<br />
Som det ses ovenfor, har edutainment genren et stort potentiale for<br />
undervisningsdifferentiering. I udviklingen af vores spil brugte vi en del energi på at fastholde<br />
frihedsgraden i spillet, så spilleren ikke følte sig styret igennem de forskellige opgaver. En måde,<br />
vi har gjort dette på, var at give spilleren mulighed for at bygge forskellige forlystelser. Nogle af<br />
disse var forbundet med nem matematik, mens andre var ”sejere”, og udfordrede eleven mere på<br />
et matematisk niveau.<br />
Dette giver dermed mulighed for vidt forskellige spilforløb, hvor den matematiske sværhedsgrad<br />
afhænger af elevens egne valg. Imidlertid åbner computermediet for mere interaktiv<br />
differentiering proces.<br />
Side 87 / 92