26.07.2013 Views

Download projekt "Edutainment" som PDF - Informatiker.DK

Download projekt "Edutainment" som PDF - Informatiker.DK

Download projekt "Edutainment" som PDF - Informatiker.DK

SHOW MORE
SHOW LESS

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

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!