Untitled - puffin

Titel: ”1984” 

Tema: Designing from both sides of the screen 

Projektperiode: 01/2 - 2007 – 29/5 - 2007 

Det Ingeniør-, Natur- og Sundhedsvidenskabelige Basisår 

Medialogi 

Strandvejen 12-14 

9000 Aalborg 

Tlf. 9635 9731 

Fax 98 13 63 93 

http://tnb.aau.dk 

Projektgruppe: C213 Synopsis: 

Deltagere: Dette er en P2-rapport, udarbejdet af 

gruppe C213 på Medialogistudiet ved 

Dennis Kokholm Risborg 

Aalborg Universitet. 

Temarammen er ”Designing from both 

_______________________ 

Jacob Boesen Madsen 

sides from the screen”. 

Rapporten forsøger at give et indblik i 

det at omsætte en bog til et spil. 

_______________________ 

Mads Pilegaard Baadsmand 

Produktet er baseret på og har taget 

udgangspunkt i bogen 1984 af George 

Orwell, og spilplatformen er Adventure 

_______________________ 

Mie Feldborg Johansen 

_______________________ 

Thomas Mygind Jensen 

_______________________ 

Vashanth Selvadurai 

_______________________ 

spil, udviklet i flash. 

Implementeringen er ikke fuldstændig. 

Vejledere: 

Hans Jørgen Andersen 

Palle Qvist 

Oplagstal: 10 

Sideantal: 83 

Bilagsantal og -art: 0 

Afsluttet den 29. maj, 2007 

Rapportens indhold er frit tilgængeligt, men offentliggørelse (med kildeangivelse) må kun ske efter aftale med forfatterne.

FORORD 

Denne rapport er lavet under andet semester på Medialogistudiet, ved Aalborg Universitet. 

Semestertemaet for denne rapport er ”Designing from both sides of the screen”. Projektet går ud på 

at omdanne bogen 1984 af George Orwell, til et adventure computerspil. Rapporten forsøger at skabe 

indblik i at omdanne en bog til et computerspil. Dette indblik i, og tilgang til projektet udspringer fra 

research af teori og egne erfaringer med computerspil. 

Gennem projektforløbet har vi modtaget hjælp fra en række mennesker. Vi vil gerne takke de 

medstuderende, der deltog i pilottesten og kom med konstruktiv kritik til, hvorledes testen 

fungerede, og hvad der burde ændres. Ligeledes vil vi gerne takke alle testpersonerne, der var villige 

til at bruge deres tid og energi på at hjælpe os med at teste prototypen. Yderligere vil vi gerne takke 

Thessa Jensen for alle hendes gode råd og vejledning under spiludviklingsfasen, og sidst men ikke 

mindst, vores to vejledere, Hans Jørgen Andersen og Palle Quist for deres hjælp og vejledning 

gennem semesteret. 

1 of 83

Forord ............................................................................................................................................... 1 

Indledning ......................................................................................................................................... 4 

Læsevejledning .................................................................................................................................. 4 

Initierende problem ........................................................................................................................... 5 

Problemanalyse ............................................................................................................................. 6 

Overvågning ...................................................................................................................................... 6 

Anti-terror pakken ......................................................................................................................... 6 

TV Overvågning ............................................................................................................................. 7 

Refleksion .................................................................................................................................... 12 

Adventurespil .................................................................................................................................. 12 

Macromedia Flash ........................................................................................................................... 14 

Fordele ved Flash ........................................................................................................................ 14 

Begrænsninger i flash .................................................................................................................. 15 

Målgruppe ...................................................................................................................................... 15 

Segmentering .............................................................................................................................. 15 

Spillets målgruppe ....................................................................................................................... 17 

Problemformulering ........................................................................................................................ 18 

Design ........................................................................................................................................... 19 

Bogen .............................................................................................................................................. 19 

Resumé ....................................................................................................................................... 19 

Analyse af bogen 1984 ................................................................................................................ 20 

Konklusion og afgrænsning af bogen ud fra analysen .................................................................. 22 

Gameplay ........................................................................................................................................ 22 

Spil skal være sikre ...................................................................................................................... 23 

Udfordringer og konflikter ........................................................................................................... 23 

Narrativer I computerspil og dets formål ......................................................................................... 25 

Indlevelse .................................................................................................................................... 25 

Belønning .................................................................................................................................... 26 

Identificering ............................................................................................................................... 26 

Narrative Triggering .................................................................................................................... 27 

Narrativ overlevering i computerspil ............................................................................................... 27 

Tekst ........................................................................................................................................... 28 

Optaget Dialog ............................................................................................................................ 28 

Statiske Billeder ........................................................................................................................... 29 

Camera Cases .............................................................................................................................. 29 

Mellemsekvenser (i spilmotoren) ................................................................................................ 29 

Scripted Events ............................................................................................................................ 30 

Cut Scenes ................................................................................................................................... 30 

Story line ......................................................................................................................................... 30 

Udviklingen af et spil ....................................................................................................................... 33 

Spiludvikling – Prototypen ........................................................................................................... 34 

Brugertests .................................................................................................................................. 35 

Implementering ............................................................................................................................ 37 

1984 – Det visuelle .......................................................................................................................... 37 

Ikoner .......................................................................................................................................... 37 

Test ................................................................................................................................................. 39 

Brugervenlighed .......................................................................................................................... 40 

2 of 83

Overvejelser og erfaringer ........................................................................................................... 40 

Testpersonernes forkundskaber .................................................................................................. 46 

Metoder ...................................................................................................................................... 47 

Delkonklusion .............................................................................................................................. 47 

De basale Flash funktioner .............................................................................................................. 48 

Navigering ................................................................................................................................... 48 

Event Handlers ............................................................................................................................ 48 

Variabler ...................................................................................................................................... 48 

If-sætninger ................................................................................................................................. 48 

Loops ........................................................................................................................................... 49 

Funktioner ................................................................................................................................... 49 

XML navigation i ActionScript .......................................................................................................... 49 

Spilmotor ......................................................................................................................................... 53 

Spilmotorens struktur ................................................................................................................. 53 

Diverse spilmotor overvejelser .................................................................................................... 60 

Moduler i detaljer ....................................................................................................................... 63 

Videreudvikling ............................................................................................................................... 74 

Diskussion ..................................................................................................................................... 76 

Kildefortegnelse ............................................................................................................................ 77 

Bøger: ............................................................................................................................................. 77 

Hjemmesider ................................................................................................................................... 77 

Appendix A : Projektbeskrivelse .................................................................................................... 80 

Indledning ....................................................................................................................................... 80 

Formål ......................................................................................................................................... 80 

Baggrund ..................................................................................................................................... 80 

Mål .............................................................................................................................................. 81 

Projektplanlægning ..................................................................................................................... 81 

Vidensindsamling ........................................................................................................................ 82 

3 of 83

INDLEDNING 

Computerspilindustrien er markant voksende og spillene varierer fra ren underholdning, til 

edutainment- og infotainmentspil. I denne rapport undersøges spil primært som ren 

underholdningsform, hvorfra et spil vil udvikles. Sekundært vil der igennem bl.a. narrativet tages 

temaer op som overvågning og det totalitære styre. 

Igennem rapporten og produktudviklingen besvares, hvorledes en historie opbygges, formidles og 

sættes sammen. Herefter hvordan selve produktet udvikles og testes for brugernes opfattelse og 

holdning til selve den interaktive del, såsom brugerinterface. 

Centrum for produktet er at brugeren kan finde rundt, uden at føle sig forvirret, og føler sig 

underholdt og samtidig får noget nyttigt ud af denne underholdning. Gennem rapporten er det 

tiltænkt at gøre rede for dagens teknologiske samfund, samt hovedpunkterne omkring romanen 

1984. Derfra designes og udvikles et computerspil, der skildrer overvågningen negativt og samfundet 

som totalitært. Der oplyses om hvad der allerede er muligt i dagens samfund og sætter fokus på, 

hvorvidt mere overvågning virkeligt vil forbedre samfundet. 

Med udbredelse af ny teknologi er det blevet lettere end nogensinde at overvåge befolkningen i 

hverdagen. Med forøget lyd og billede overvågning i det offentlige rum, såvel som hos private 

virksomheder, kan det i teorien medføre et overvågningssamfund beskrevet i George Orwells roman, 

1984. 

Hvor overvågning i sig selv ikke er en slem ting, må man indse at muligheden for at andre kan styre 

ens liv og ens personlige frihed indskrænkes, kan blive en realitet. I tider med frygt for terror mange 

steder i verden kan det risikeres at netop den personlige frihed må opgives for at befolkningen kan 

føle sig mere sikker. 

LÆSEVEJLEDNING 

Rapporten er struktureret vha. Tek-Nat basis modellen. Problemstillingen i rapporten er beskrevet i 

det initierende problem. Den kontekstuelle del uddyber omstændighederne, for problemstillingen og 

indskærper dem til en konkret problemformulering. 

Temaet for projektet er ”Designing from both sides of the screen.”, og går ud på at skabe et 

interaktivt produkt. 

For projektet er den interessante problematik, hvorledes en bog omsættes til et computerspil. Der 

gives gennem rapporten et indblik i, hvorledes denne transformation fra bog til spil finder sted. 

Rapporten er sammensat af følgende hovedafsnit, foruden problemstillingen, problemformuleringen 

samt diskussionen: 

• Problemanalyse 

• Game Design 

• Test 

• Produktet 

De fire afsnit omhandler følgende: 

4 of 83

PROBLEMANALYSE 

Dette er rapportens kontekstuelle del. Afsnittet omhandler overvågning, der allerede i dag findes i 

samfundet. Efterfølgende kommer der et kort afsnit omhandlende overvågning. Herefter bliver 

Adventurespil og Flash beskrevet, førstnævnte som hvad der snakkes om samt historie, og for 

sidstnævnte nævnes der fordele og ulemper ved at vælge Flash som værktøj til udvikling. 

Sidst snakkes der om målgruppen og hvordan en sådan vælges/defineres. 

GAME DESIGN 

Afsnittet starter med en analyse af bogen 1984, der afgrænses og bruges til at skabe et spil fra bogen. 

Herefter følger de narrative teorier omhandlende historie og spil, hvorudfra spillet designes. 

TEST 

Afsnittet omhandler selve testen der blev foretaget af produktet. Testpersonerne og produktet 

nævnes. Sidst gives en vurdering af testen og hvorledes det forløb, samt hvordan det kan bruges til 

videreudvikling og fejlrettelser. 

PRODUKTET 

Gennem denne del forklares hvorledes spillet er kommet til live og hvordan koden er opbygget, samt 

hvorfor. Den visuelle del forklares først, hvorefter den mere tekniske del, koden, følger. Efterfølgende 

kommer forskellen på test modellen og den endelige model, samt mulig videreudvikling. 

For yderligere information om hvert afsnit kan underafsnittene ses i indholdsfortegnelsen 

INITIERENDE PROBLEM 

Vores initierende problem er som følger: 

- Hvordan omsætter man en bog til et adventurespil? 

5 of 83

PROBLEMANALYSE 

Følgende kapitel gennemgår viden omkring overvågning i samfundet som det er i dag, og hvad det 

muliggør. Denne viden danner grundlag for projektet, da der tages stilling til hvorvidt overvågning 

udgør en trussel for den personlige frihed. Viden om overvågning bruges som inspiration til spillet. 

Macromedia Flash (nu Adobe Flash) bruges som medie, hvilket uddybes senere. Adventurespilgenren 

er valgt for spillet og vil også blive begrundet senere i et afsnit. 

OVERVÅGNING 

I følgende afsnit undersøges hvilke typer overvågning der findes i dag, og hvordan denne overvågning 

bruges. Det gennemgås hvordan overvågningen bliver brugt i udlandet, samt den effekt denne 

overvågning har haft. Efterfølgende vendes blikket mod Danmark og der ses på den øgede 

overvågning der bliver lagt op til her i landet for tiden. 

I 1984 har borgerne ingen frihed pga. overvågning. Det diskuteres hvorvidt anti-terrorpakken krænker 

menneskerettighederne, hvilket er grunden til at dette er relevant for rapporten. 

ANTI-TERROR PAKKEN 

Terrorangrebet i New York d. 11. september 2001 har sat et stort præg på det fokus, der har været 

omkring terrorisme. Efter terrorangrebet på World Trade Center, blev der i USA vedtaget en række 

nye love under navnet USA PATRIOT Act. Disse love blev lavet kort tid efter terrorangrebet og flere 

andre vestlige lande gjorde dette efter (Frandsen, 2007). Denne Patriot Act, hvilket den også bliver 

kaldt, indeholder en stor udvidelse af USA’s efterretningsbureauers autoritet, indenfor 

efterforskningen af terrorisme. Derudover omhandler den blandt mange emner en lov om, hvorvidt 

det bliver lettere for efterretningsbureauerne, at undersøge elektroniske 

kommunikationsmuligheder, som f.eks. telefonopkald og e-mails. Udover disse 

kommunikationsmuligheder gjorde denne Patriot Act, det også lettere at undersøge civiles medicinale 

og finansielle journaler (http://en.wikipedia.org/wiki/USA_PATRIOT_Act, 2007). 

I Danmark vedtog folketinget en anti-terrorpakke i år 2002, som følge af terrorangrebet i New York d. 

11. september 2001. Denne anti-terrorpakke indeholder bl.a. en bred definition på terrorisme. Her 

nævnes groft hærværk og frihedsberøvelse, hvilket defineres som terrorisme, hvis de har hensigt med 

at ødelægge politiske forfatningsmæssige eller samfundsmæssige strukturer. Er dette tilfældet kan 

fængsel på livstid være straffen. Efter denne nye lovgivning er det også blevet kriminelt, at give 

humanitær støtte til organisationer, der benytter militante midler til at ændre de samfundsmæssige 

strukturer, og dette er uanset hvor i verden det er. 

På mange områder er ytringsfriheden efter denne lovgivning blevet påvirket. Det er nu blevet 

strafbart offentligt at anerkende eller værdsætte en oprørsbevægelse, som laver sabotage mod 

samfundets virkemidler, såsom kraftværker, kommunikationsnet osv.. 

I tilføjelse til ændringerne af straffeloven blev der ændret i retsplejeloven. Disse ændringer, som 

Folketinget vedtog, kan stærkt sammenlignes med den ovenstående lov, der blev dannet i USA år 

2001, vedrørende kommunikation. I Danmark er der ligeledes blevet generel registrering af 

elektronisk kommunikation. Her er der dermed givet politiet og efterretningstjenesten nye 

overvågningsmidler. Det vil sige at internetudbydere og teleudbydere nu er forpligtigede til at gemme 

disse oplysninger i minimum ét år. Det er ikke blot hvem der har kommunikeret med hvem, men også 

hvornår og i hvor lang tid. Dette står beskrevet i retsplejeloven §786 stk. 4-7 (Justitsministeriet, 2002). 

Som en udvikling indenfor efterretningsvæsener, er det nu ikke kun muligt via retskendelse, at aflytte 

eller læse indholdet i kommunikationen, når der er en mistænkt involveret. Efter den danske antiterrorpakke 

er det blevet muligt for politiet, at overvåge computere i hemmelighed, ved hjælp af 

6 of 83

såkaldte ”snifferprogrammer”. Disse programmer kan kopiere alle indtastninger på en computer og 

derefter sende alt materialet til politiet (retsplejeloven §791b). Dette vil sige, at ved hjælp af disse 

programmer kan politiet komme ind i den enkelte computer, og dermed overvære alle handlinger, 

der bliver foretaget og ransagningen vil derfor have bedre mulighed for at være skjult (Jørgensen, 

2002). 

Det ses at terrorangrebet d. 11. september 2001 har medført en række indskrænkelser i den 

personlige frihed pga. ny lovgivning. Denne nye lovgivning giver statens efterretningsbureauer større 

beføjelser til at overvåge samfundets enkelte individer, hvilket er et skridt tættere på 

overvågningssamfundet beskrevet i 1984. Lovgivningen giver også mulighed for at benytte 

overvågning i det offentlige rum. 

TV OVERVÅGNING 

TV-overvågning bliver mere og mere almindeligt i dag, og nye metoder til at overvåge og generelt 

bruge denne teknik, er under konstant udvikling. Dette afsnit går i dybden med, hvorledes 

overvågning kan anvendes i samfundet og de måder det bliver brugt. 

CLOSED CIRCUIT TELEVISION (CCTV) 

Dette afsnit er hovedsageligt baseret på http://en.wikipedia.org/wiki/Closed-circuit_television, 2007, 

hvis modsatte ikke er nævnt. 

CCTV er et lukket system af kameraer, monitorer og/eller lydoptagere. Forskellen på et åbent eller et 

lukket system er, at i et lukket system bliver kameraets output sendt til et afgrænset og bestemt antal 

af modtagere. Et åbent system er, hvor TV-signalet bliver lagt ud på f.eks. Internet- eller 

satellitnetværk. 

HVOR BRUGES CCTV? 

CCTV bruges til overvågning. Det kunne være overvågning på et kasino, i en bank eller et 

indkøbscenter. Dette bruges også til at overvåge steder, hvor mennesker ikke kan komme, såsom en 

nuklear reaktor, hvor kameraer med varmefiltre kan overvåge reaktorens varmeudvikling. 

CCTV bruges også på nogle togstationer, hvor TV-skærme forrest på perronen, gør det muligt for 

togføreren at sikre sig, at han kan lukke dørene og starte toget uden tilskadekomne. Dertil bruges 

CCTV også til overvågning af gader og offentlige steder i f.eks. England. 

TEKNISKE MULIGHEDER 

Dette afsnit viser hvilke tekniske fremskridt der er gjort indenfor overvågning. Da bogen blev skrevet 

for snart 60 år siden, er den teknologi den illustrerer som nyskabene for sin tid, forældet. Som 

inspiration for hvor nutidens samfund er på vej hen, er dette afsnit med nyere overvågningsteknologi 

taget med. 

ANSIGTSGENKENDELSE 

Det er muligt, ved hjælp af software, at registrere et ansigt og derefter scanne databaser efter samme 

ansigt. Dette kan f.eks. bruges i lufthavne eller ved havne for at screene passagerer for kendte 

terrorister. Denne metode er dog endnu ikke præcis nok til, med 100% sikkerhed, at genkende 

ansigter. 

7 of 83

NUMMERPLADEGENKENDELSE 

Nummerpladegenkendelse er brugt til at registrere fartsyndere, i bl.a. England, og automatisk sende 

dem en bøde. Der er dog mulighed for at nummerpladen bliver fejllæst og bøden sendt til en uskyldig 

bilejer. 

Efter samme princip er det muligt, at overvåge biler i trafikken efter stjålne biler, hvor 

nummerpladerne bliver tjekket med stjålne bilers nummerplade i en database. 

ADFÆRDSGENKENDELSE 

Software er under en udvikling, der gør det muligt at genkende, hvordan personer bevæger sig på 

kameraet. Teorien bag udviklingen er at mennesker opfører sig på bestemte måder, når de befinder 

sig på offentlige steder, og derfor vil det være muligt, at alarmere en vagthavende, hvis der 

forekommer uregelmæssige bevægelser. 

MIKROFONER 

Det er muligt for kameraer med mikrofoner og den rette software, automatisk at zoome ind på en 

person der råber på en aggressiv måde. Et eksempel kunne være en person, som prøver at påbegynde 

et slagsmål. 

OVERVÅGNING I ENGLAND 

CCTV bliver i nogle lande brugt til gadeovervågning. Gadeovervågning kan bruges med præventiv 

virkning, med opklarende virkning, med dokumenterende virkning, til observation og mere. 

Gadeovervågning kan også misbruges, ved krænkelse af privatlivets fred, vouyerisme eller spionage. 

I det følgende kommer en redegørelse, af hvorledes TV-overvågning bliver brugt i England, og hvor 

effektivt det har vist sig at være. 

Det anslås at der er over 4.000.000 kameraer i England, også svarende til et kamera pr. 14. indbygger. 

Dette er et kvalificeret gæt der stammer fra Urbaneye, working paper no. 6 (McCahill & Norris, 2002). 

Urbaneye er et projekt støttet af Europa kommissionen, og koordineret af Centre of Technology and 

Society ved Technical University i Berlin. 

EFFEKTIVITET AF OVERVÅGNING I ENGLAND 

Der er foretaget mindst to undersøgelser på foranledning af det britiske Home Office, der bl.a. skulle 

belyse, hvorvidt kameraovervågning har en effekt på kriminalitetsniveauet i de områder der benytter 

overvågning. Home Office Research Study 252 (HORS 252) blev afsluttet i år 2002, og Home Office 

Research Study 292 (HORS 292) blev afsluttet i år 2005. 

HORS 252 er en undersøgelse baseret på tidligere evalueringer af CCTV systemer, der levede op til 

skarpe krav om indhold, formål og metoder. Evalueringerne skulle vurdere, hvilken effekt kameraer, 

som overvågning, havde på kriminaliteten. De fandt 22 evalueringer der levede op til kravene, hvor 

halvdelen viste en lille, men positiv, påvirkning på kriminaliteten. Analysen af evalueringerne gav det 

resultat, at CCTV bør støttes op af andre interventioner. Fem af evalueringerne foregik på 

parkeringspladser og de viste en nedsættelse af biltyverier, som var den eneste forbrydelse der blev 

begået på parkeringspladserne. Ved samtlige systemer havde der også været andre interventioner, 

som forøget belysning, eller skiltning der gjorde opmærksom på kamerarene. Alt i alt, bør 

overvågning med kameraer ledsages af andre tiltag og evalueres grundigt, konkluderer rapporten 

(Welsh & Farrington, 2002). 

HORS 292 er en undersøgelse, der evaluerer 13 systemer i England, ud fra tal om kriminalitet før og 

efter installation af CCTV kameraer. Derudover evaluerer undersøgelsen også befolkningens skræk for 

kriminalitet før og efter opsætningen af kameraer. Undersøgelsen konkluderer at ud af de 13 

systemer, var der nedsat kriminalitet i seks systemer, og ud af disse seks var der kun to systemer, hvor 

8 of 83

nedsættelsen statistisk betød noget. I et af disse kunne nedsættelsen af kriminaliteten forklares med 

andre omstændigheder. Kriminalitet steg i syv systemer, men det var ikke på grund af kameraerne. 

Det skete også i nogle tilfælde, at kriminaliteten blev flyttet til rundt omliggende områder, og i 

hullerne mellem kameraerne i et system. Systemerne virkede bedst på parkeringspladser. 

Undersøgelsen fandt at CCTV overvågningssystemerne ikke var specielt effektive og hjalp mest mod 

planlagte forbrydelser og biltyverier, især på parkeringspladser. I de tilfælde hvor kriminaliteten steg, 

kan der også være tale om at politiet har opdaget flere forbrydelser end normalt. Rapporten 

konkluderer at de kan støtte op om HORS 252, og at kameraer ikke sænker kriminalitetsniveauet (Gill 

& Spriggs, 2005). 

Rapporterne bestilt af det britiske Home Office repræsenterer ikke Home Offices holdninger og 

synspunkter. Tilbage i år 1994 udgav Home Office en rapport ved navn ”CCTV: Looking out for you”, 

der bedømte CCTV overvågning, som en success og banede vejen for det massive antal systemer i 

England i dag (http://en.wikipedia.org/wiki/Closed-circuit_television, 2007). 

TALENDE CCTV KAMERAER 

I Middlesbrough er der blevet installeret syv kameraer der er monteret med højtalere. På den 

måde kan ordensmagten fra et kontrolrum påtale dem, som er i færd med at begå kriminalitet 

eller uorden (http://news.bbc.co.uk/2/hi/uk_news/england/tees/5353538.stm, 2006). Det 

britiske Home Office melder at de talende CCTV kameraer er en success. 

Efter at Middlesbrough har haft talende kameraer, med stor success, mod anti-social adfærd, 

såsom smidning af affald på åben gade, har 20 kommuner søgt og fået støtte fra Home Office 

til at installere talende kameraer (http://www.homeoffice.gov.uk/about-us/news/talkingcctv?version=1, 

2007). 

OVERVÅGNING I DANMARK 

I Danmark er der strammere love vedrørende overvågning, end der er i de fleste andre lande. 

Størstedelen af danskerne er positivt stemte overfor overvågning, da de mener at det har en 

kriminalpræventiv virkning. Derudover bliver en stor del, især kvinder, trygge af at vide, at de bliver 

overvåget. 

9 of 83

Figur 1 

Som ovenstående graf viser, gives der udtryk for at mange mennesker tror kameraer virker 

kriminalpræventivt (Nickelsen, 2005, s. 15). 

Når man ser på danskernes holdning til overvågning, er det tydeligt at desto tættere det kommer på 

den private sfære, desto mere kritiske bliver danskerne. Den primære årsag til at danskerne er 

negativt stemte, er krænkelse af privatlivets fred, som det kan ses på figur 2 og 3. 

Figur 2 

Som set på dette billede, frygter hovedparten af de adspurgte at det vil krænke deres privatliv eller 

frygter det kan misbruges (Nickelsen, 2005, s. 14). 

10 of 83

Figur 3 

På figuren ses det tydeligt hvordan de adspurgte forholder sig til overvågning i forskellige omgivelser 

(Nickelsen, 2005, s. 13). 

FLERTAL FOR TV-OVERVÅGNING UDENDØRS 

I sommeren år 2007 bliver det i Danmark muligt, for både butikker, hoteller natklubber og banker, at 

filmovervåge både gaden og facaden foran deres bygninger. I midten af april måned år 2007 viste det 

sig, at der var politisk flertal for et lovforslag, som ville gøre dette lettere for ovennævnte steder at 

benytte udendørs overvågning (Justitsministeriets nyhedsbrev nr. 80 - 2 marts 2007, 2007). 

Det er nu besluttet at dette lovforslag træder i kraft d. 1 juli 2007 (Forslag til lov om ændring af lov om 

forbud mod tv-overvågning mv. - 28 februar 2007, 2007). 

Den præventive virkning, over tid, vil måske ikke blive stor ved denne nye lovgivning, men i 

modsætning til tidligere, kan det give politiet en ny række oplysninger om mulige gerningsmænd i 

forbindelse med disse ulovligheder. 

Overvågning i forbindelse med natklubber og hoteller kan være med til at opklare uheldige episoder, 

der kan opstå mellem gæster. For butikker og banker kan det muligvis hjælpe til at identificere mulige 

gerningsmænd eller øjenvidner på stedet. 

MISBRUG AF OVERVÅGNING 

CCTV er et nyttigt og sikkert redskab til prævention, dokumentation og opklaring, hvis det bruges 

rigtigt, men med brug følger også muligheden for misbrug. Hvad der præcist er misbrug, er et 

holdningsspørgsmål. Følgende belyser vi emner der muligvis kan anses som misbrug. Det kræver 

ekstra refleksion at vælge, at udøve overvågning, når man ser på de måder det kan misbruges på. I de 

følgende afsnit forklares nogle kendte og potentielle muligheder for misbrug af overvågning. 

11 of 83

REFLEKSION 

Det er til stadig diskution hvorvidt overvågning gavner samfundet mere end det skader. Erfaringerne 

fra England og Danmark, viser at tv-overvågning ikke nødvendigvis nedsætter kriminalitet. Øget 

overvågning er velanset af den danske befolkning, blandt andet fordi det giver en tryghed hos 

borgerne. Dette kan opfattes som en falsk tryghed. Både fordi tv-overvågning ikke har vist sig så 

prævensivt som det kan opfattes, men også fordi at det kan misbruges og udnyttes. 1984 er et 

skræmme-eksempel på konsekvenserne af den øgede overvågning. 

Kapitlet tog fat i elementerne omkring overvågning i dag, hvordan det er muligt og hvordan det bliver 

gjort forskellige steder i verden. Denne generelle viden om overvågning, der er indsamlet og formidlet 

her, giver inspiration til, hvordan et overvågningssamfund kan illustreres i et spil. Disse illustrationer 

kan give brugeren af det endelige produkt en følelse af, at der ikke er langt fra fiktion og historie til 

den virkelige verden. Teknologi venter blot på at blive misbrugt. 

ADVENTURESPIL 

Information om adventurespilgenren er nyttig, da denne genre er en velegnet til at lave spillet efter, 

for at kunne fortælle 1984, som en interaktiv historie for brugeren. 

I de følgende afsnit vil der blive givet en kort gennemgang af, hvad et adventurespil er, og hvilke 

fordele denne genre har, i forhold til andre genrer, samt hvilke svagheder der er. Ydermere, for at 

skabe en overordnet forståelse for hvad adventurespil er, vil der blive beskrevet en kort gennemgang 

af dets historie. Således kan der skabes en forståelse af, hvilken udvikling genren er gået igennem de 

sidste 30 år, og en idé om hvor den er på vej hen. Denne generelle viden kan samtidig være med til, at 

give en idé om, hvordan adventurespil har taget sig ud og er opbygget, og hvordan det kan bidrage til 

spillet der forsøges udviklet. 

HVAD ER ADVENTURESPIL 

Adventurespil er en genre af computerspil, hvor gameplay’et bedst kan karakteriseres, som en 

kombination af udforskning, gådeløsning, interaktion med spilkarakterer (NPC’er – Non Player 

Characters) og fokus på narrativ, i stedet for refleksbaserede udfordringer. De fleste adventurespil er 

lavet til computere, dog findes der nogle konsol adventurespil. Modsat andre computerspilgenrer, 

ligger adventurespils fokus på historie, hvilket har påvirket at genren igennem tiden, er blevet stærkt 

inspireret af andre narrative medier, såsom film og litteratur. 

Adventurespil bliver i nogle tilfælde beskrevet, som interaktiv fiktion. Interaktiv fiktion er en bred 

betegnelse, der for det meste bliver brugt til at beskrive den type medier, der lader brugeren have 

indflydelse på historien. Af andre medier der hører under denne betegnelse kan nævnes ”Vælg dit 

Eget Eventyr” bøger, med deres forgrenede historier. 

ADVENTURESPILGENRENS HISTORIE 

TEKSTBASERET ADVENTURESPIL 

Moderen til alle adventurespil, ”Colossal Cave Adventure”, blev skrevet i år 1975 af Will Crowther. 

Han kombinerede sine oplevelser, at udforske bjerghuler i Kentucky og hans hobby, at spille 

”Dungeons & Dragons”, til ét computerspil. ”Colossal Cave Adventure”, eller bare ”Adventure”, som 

det blev kendt som i eftertiden, blev en protype for en helt ny kategori af spil: text-based adventures, 

eller som det senere blev kendt, interaktiv fiktion (Dillon, 2007 & 

http://search.eb.com.zorac.aub.aau.dk/eb/article-233729, 2007). Denne type spil havde en helt ny 

form for narrativ struktur. Spiloplevelsen blev formet af beskrivelser af rum, karakterer og forskellige 

12 of 83

genstande, som spilleren kunne samle op og bruge til at løse gåder, på et senere tidspunkt i 

spilforløbet. Derudover blev spillet formet af en historie, der udviklede sig i forhold til de valg 

spilleren foretog sig. Interaktionen med programmet foregik igennem tekst, hvor spilleren fik 

beskrevet sin nuværende situation på skærmen. Bagefter gav programmet input ved hjælp af en 

”verb-noun parser”. Dette betyder at spillet ikke forstod hele sætninger, men kun kunne forstå små 

sætninger, sat sammen af et navne- og et udsagnsord, som f.eks. ”release Bird” og ”Down Steps”. 

Der gik ikke lang tid før, der blev udviklet en ”parser”, som kunne tolke hele sætninger, såfremt de var 

programmeret forud ind i spillet. Andre populære spil i denne genre og tidsperiode kan nævnes, 

”Zork” triologien (1981 og 1982) og ”Hitchhikers Guide to the Galaxy” (1984). 

GRAFISKE ADVENTURESPIL 

I midten af firserne blev adventurespil mere grafiske. Ron Gilbert, en grafisk designer, som arbejdede 

for ”Lucasfilm Games” (nuværende ”LucasArts”), lavede et scripting system kaldet ”Script Creation 

Utility for Maniac Mansion” (SCUMM). Han lavede også den første point-and-click brugerflade til et 

adventurespil. Det var nu ikke nødvendig at indtaste kommandoer, for at interagere med systemet, 

men i stedet brugte man musen til at interagere med ikoner, der repræsenterede forskellige 

handlinger i spillet. Det første spil til at anvende denne teknologi, var spillet ”Maniac Mansion”, der 

blev udgivet i år 1987. Denne nye måde at spille på, hvor det var det grafiske, der nu var drivkraften 

bag fordybelsen, hurtigt blev velmodtaget af de fleste spillere. Dog var der nogle få der mente, at det 

visuelle udtryk, som ikke var til stede i de originale tekstbaserede adventurespil, begrænsende 

spillerens fantasi. Den nye grafiske overflade, betød at de generelle scenarier, blev mindre end de var 

i de tekstbaserede spil, samt at plotudviklingen i spillet blev reduceret (Dillon, 2007). Dette kunne dog 

ikke forhindre den hurtige død, de tekstbaserede adventurespil gik i møde. Denne nye inkarnation af 

adventurespilgenren var, for det meste, domineret af ”LucasArts”, som udgav de populære ”Monkey 

Island” spil (år 1990 -2000), dog havde andre firmaer også succes med spilserier som ”Gabriel Knight” 

(år 1993 – 1999). 

Figur 4 

LucasArts’ Monkey Island 

13 of 83

ADVENTURESPILGENREN I DAG 

Selvom adventurespillenes indvirkning på spilkulturen er indiskutabel, er adventurespil i den 

traditionelle forstand, ikke ligeså kommercielt succesfulde, som de var tilbage i deres storhedstid i 

slutningen af 1980’erne og starten af 1990’erne. Det er en skarp kontrast til nutiden, hvor kun nogle 

få adventurespil bliver udgivet om året. De gamle udviklere, som f.eks. Sierra og LucasArts er begyndt 

at fokusere på andre spilgenrer, der har større markedsandele. Der er forskellige teorier om, hvorfor 

udviklingen er gået denne vej, bl.a. udviklingen inden for 3D modellering, computergrafik, ændring i 

spillernes smag, såsom mere fokus på multiplayer og online kompatibilitet, har medvirket til 

ændringerne i spilkulturen (Dillon, 2007 & http://game-research.com/index.php/info-pages/historyand-genre/adventure-games/, 

2006). Ydermere har fremgangen og udviklingen inden for computere 

medført, at de gamle adventurespil ikke kan spilles på nutidige PC’er. Dog har gamle fans udviklet 

open source emulatorer, såsom ”ScummVM1”, der gør det muligt at køre de gamle spil på nuværende 

computere. 

De gamle tekstbaserede adventurespil har oplevet en mindre renæssance på håndholdte PC’er, da 

disse har vist sig meget brugbare til denne type adventurespil. Selvom de traditionelle adventurespil 

er sjældne i dag, så lever hybriderne i bedste velgående. Action adventurespil, RPG’er (Role Playing 

Games), som f.eks. ”Final Fantasy” serien, og andre der har kombineret adventuregenren med andre 

spilgenrer. 

Som konklusion på det ovenstående afsnit, kan det bemærkes at adventurespil er i fær med at tage 

en ny retning: Et stigende antal af adventurespil bliver udviklet til Flash, kommercielt sålvel som 

amatør lavede. 

MACROMEDIA FLASH 

Valget af Flash som platform for spillet kommer efter semesterets kurser, hvor der var 

programmering i flash, så muligheden for at kombinere kursus med projektarbejde lå lige for. Flash er 

desuden valgt at arbejde i, fordi mange af internettets brugere har mulighed for at afspille flash 

(http://www.adobe.com/products/player_census/flashplayer/,2007). Flash er et nemt og fleksibelt 

program at lave visuelle produkter i. 

Flash kan benyttes til at lave interaktive medier, som bl.a. kan vises på hjemmesider. Flash 

understøtter næsten alle slags medieformer, og da flash er vektorbaseret er det let at skalere. Flash 

er en mellemting mellem at programmere og arbejde grafisk. 

Flash bruges generelt til grafiske elementer, webbaserede spil og reklamebannere bl.a. på websider. 

Indførelsen af ActionScript i nyere versioner af Flash, har muliggjort produktionen af hele 

hjemmesider, og mange andre muligheder. En stor fordel ved flash er, at det er muligt at genbruge 

det samme objekt flere gange, og derved formindskes filstørrelsen en del. Flash kan ikke klassificeres, 

som en åben standard, da det kompileres i SWF-format, der har en restriktiv brugerlicens. 

FORDELE VED FLASH 

• Flash er skræddersyet til Internettet. Med et enkelt plug-in til browseren, kan der ses flashvideoer, 

animationer og spilles spil online. 

• SWF-formatet er ikke særlig pladskrævende, da det, som nævnt, gør brug af vektor baseret grafik og 

komprimerer næsten alt uden kvalitetstab. 

• Der er en lang række muligheder for at integrere flash med andre applikationer, som f.eks. at 

kommunikerer med en server til eksempelvis chat eller multiplayer spil. 

14 of 83

BEGRÆNSNINGER I FLASH 

• Flash er platform-uafhængig, hvilket medfører at sproget skal fortolkes af en Flashfortolker, et plugin. 

På grund af dens uafhængighed er afviklingshastigheden baseret på filstørrelsen. Derfor vil et spil, 

programmeret i flash, ikke yde så godt som samme spil programmeret i f.eks. c++ e.lign. 

Udfra det ovenstående afsnit kan det bekræftes at flash er velegnet til webbaserede spil, hvilket øger 

tilgængeligheden af spillet. 

MÅLGRUPPE 

Dette afsnit indeholder bl.a. nogle eksempler på teorier vedrørende segmentering af målgrupper, da 

det er meget brugt at inddele befolkningen i mindre grupper, for lettere at kunne præcisere 

produktets målgruppe, hvilket sidste del af dette afsnit omhandler. 

SEGMENTERING 

Som skrevet ovenfor er segmentering af stor betydning, når der skal findes en målgruppe og er derfor 

ofte brugt. Dog er det i dag mere problematisk at benytte segmentering, da befolkningen i stigende 

grad bliver individualister (se evt. bilag 1). Dette betyder at segmentgrupperne bliver mindre, og 

dermed også mere homogene, da der ellers ville være flere personer, som ville passe til mere end én 

segmentgruppe på en gang og dermed ville befinde sig i ”den grå gruppe”, hvilket der kommes 

yderligere ind på senere. 

Segmenteringsprocessen kan illustreres på følgende måde, som vist på figur 5: 

Segmentering 

Inddeling af markedet i 

segmenter 

( homogene grupper) 

Beskriv de enkelte 

segmenter 

Målgruppevalg 

Segmentvurdering i 

forhold til 

salgspotentiale 

Valg af målgruppe(r) 

Figur 5 

Segmenteringsprocessen (Søndersted-Olsen, 2003, s. 115) 

Produkt-positionering 

Vurdering af 

produktpositioneringer 

Fastlæg marketing-miks 

til målgruppen 

Hvis ovenstående figur følges, skal markedet inddeles i segmenter. Befolkningen kan inddeles i 

segmentgrupper efter bl.a. demografi, beskæftigelse, geografi og livsstil alt efter, hvilket marked 

produktet tilhører. Det kan enten være Business-to-consumer (BTC-markedet), også kaldt 

konsumentmarkedet, som er det marked hvor produktet er til eget brug, eller Business-to-business 

(BTB-markedet), også kaldt producentvaremarkedet, hvor produktet er til f.eks. videresalg eller 

forarbejdning. Dette er de to mest brugte, men herudover er der også markedet Business-toinstitution 

(BTI-markedet), hvilket er det marked, hvor det offentlige køber produktet til deres 

services. Ud fra de to førstnævnte markeder kan segmenterne defineres ud fra følgende 

segmenteringsvariable, se figur 6: 

15 of 83

(BTB) 

Business-to-consumer (BTC ) Business-to-business 

- Demografi (køn, alder, uddannelse, 

indkomst, husstandens sammensætning 

osv. 

- Geografi 

- Beskæftigelse (arbejder, funktionær, 

selvstændig osv.) 

Figur 6 

Segmenteringsvariablerne som ses under henholdsvis BTC- og BTB-markedet er de kriterier man, som 

kommunikator, vælger at definere sine segmenter efter 

(Søndersted-Olsen, 2003, s. 116-117). 

Da vores produkt er til eget brug, og at det ikke har til formål at blive videresolgt, vil det dermed 

tilhøre Business-to-consumer, altså (BTC)-markedet. Dette betyder, at for at kunne definere 

segmenterne, skal man som kommunikator, efter denne fremgangsmåde, benytte sig af de 

segmenteringsvariabler, der står i ovenstående figur (6) under BTC-markedet. 

MINERVA-MODELLEN 

Der er i dag mange former for segmenteringsmodeller. En af dem, er den kendte Minerva-model, der 

fokuserer på personers livsværdier og dermed inddeler konsumentenhederne op i fem grupper. Ved 

brug af denne model er det ikke længere kun eksempelvis demografi og geografi der bestemmer 

købsadfærden, men også livsværdierne. 

De fem segmenter kan defineres ved disse nøgleord: 

Det blå segment (moderne og pragmatisk) 

- selvtillid 

- forbrug 

- teknologi 

Det grønne segment (moderne og idealistisk) 

- Engageret aktivitet 

- Kultur 

- Natur 

- Miljø 

Det rosa segment (idealistisk og traditionel) 

- Tradition 

- Familien 

- Det nære miljø 

16 of 83 

- Demografi (kundetype, -størrelse, 

omsætning osv.) 

- Geografi (beliggenhed, og geografisk 

spredning (f.eks. filialer) 

- Beskæftigelse (branche, 

produktteknologi osv.) 

Det violette segment (traditionel og 

pragmatisk) 

- Stabilitet 

- Tradition 

- Gør-det-selv 

Den grå segmentgruppe 

- Rådvildhed 

- Nydelse 

Det er de personer der bl.a. er så 

individualistiske, at de tilhører flere af de 

andre fire segmentgrupper på samme tid, og 

dermed ikke kan placeres i en bestemt 

gruppe. Herved bliver de således placeret i 

den grå gruppe.

Ved brug af Minerva-modellen deles befolkningen op i fem grupper, hvilket som tidligere nævnt, ikke 

rammer særlig mange mennesker, da der er få segmentgrupper og befolkningen bliver større 

individualister (Søndersted-Olsen, 2003, s. 126-128). 

Det skal nævnes at der udover Minerva-modellen, er et såkaldt Gallup Kompas, som analyseinstituttet 

Gallup benytter (http://www.gallup.dk/test/kompas_segmenter.asp, 2007). Denne 

segmenteringsmodel deler, ligesom Minerva-modellen, befolkningen op efter deres livsstil, men blot i 

ni segmentgrupper. Dette gør segmenteringen mere præciseret, da der her er flere grupper, som 

befolkningen inddeles i. ”IndexDanmark” er interviewbaseret markedsinformation og er uundværligt 

for mange producenter. Her kan producenten få meget præcise oplysninger om, hvilke personer der 

køber de forskellige mærker osv. (Søndersted-Olsen, 2003, s. 128-130). 

BUDSKABSSEGMENTERING 

Budskabssegmentering er en speciel form for segmentering, der bruges indenfor Direct Marketing og 

kommunikation på Internettet. 

Princippet med denne segmenteringsform er at respondenterne segmenteres efter, hvilket budskab 

de reagerer på. Her testes der personer, hvor formålet er at se, hvem der reagerer på hvad. Ulempen 

ved denne form for segmentering er, at det er nødvendigt med mange testpersoner for at få de mest 

præcise resultater. Igen spiller individualisme ind, da alle folk reagerer på forskellige måder, men 

denne segmenteringsform kan evt. også bruges, som et godt supplement til andre. 

SPILLETS MÅLGRUPPE 

Normalt ved brug af segmentering, undersøges der hvilket slags spil målgruppen ønsker og spillet 

produceres med baggrund på dette. Derimod er det valgt at gøre det anderledes. Der vil først blive 

produceret et spil, for bagefter at blive testet på den målgruppe der ønskes at ramme, og se hvordan 

de modtager det. Valget af dette produkts målgruppe er derfor hovedsageligt baseret på 

budskabssegmentering. Dvs. at der før testforløbet vil blive valgt en gruppe mennesker, som alle er 

mellem 18 og 25 år, er studerende, er interesserede i computere og er vant til at spille computerspil. 

Disse mennesker vil blive testet og derefter vil det vise sig om disse mennesker kunne tilhøre 

produktets primære målgruppe. Grunden til at denne metode er valgt er at der er valgt, at lægge 

vægt på disse kriterier til segmentet og derfor ingen grund er til at benytte andre former for 

segmenteringsmodeller. 

Der er både fordele og ulemper ved denne metode. En ulempe kan være at man som producent har 

en ide, som man gerne vil fuldføre. Ved ikke at finde en målgruppe, som kan være med til at udvikle 

dette produkt, må man blot håbe på at det færdige produkt har en målgruppe, der finder produktet 

attraktivt. Det er en meget kunstnerisk tilgang til produktudvikling, men set på verden så er alt ikke 

kommet til fordi forbrugerne har bedt om det, men den kreative innovation baseret på designerens 

valg, hvorefter dette er blevet testet. Hvis målgruppen ikke finder produktet attraktivt og det viser sig 

efter testen, at den ønskede målgruppe ikke bryder sig om produktet, er der flere muligheder. Det 

kan enten smides ud eller også kan målgruppen forsøges at ændre mening vha. reklamation. En 

anden mulighed er at målgruppen godt kan lide produktet, men derimod ikke vil købe det. Dette kan 

f.eks. løses ved at produktet ligges på Internettet og kan spilles gratis. Hvis der vises interesse for 

spillet er der potentiale for forretning. 

17 of 83

PROBLEMFORMULERING 

Vores problemformulering er som følger: 

- Hvorledes kan konsekvenserne af overvågning illustreres gennem et adventurspil, baseret på 

George Orwells roman 1984? 

18 of 83

DESIGN 

Følgende kapitel omhandler hele designfasen omkring det at skabe et computerspil. Starten 

omhandler bogen, spillet baseres på, 1984, og analyse af denne for at undersøge forskellige 

elementer af bogen der kan bruges i spillet. Efterfølgende kommes der ind på Chris Crawfords syn på 

Game Play, leg, konflikter mm. og der undersøges hvad et narrativ er og hvordan det evt. kan 

opbygges. Sidst i kapitlet ses der på hvordan brugertests kan udføres på det endelige produkt, baseret 

på læring fra HCI kurset. 

BOGEN 

1984, skrevet af George Orwell, danner grundlag for spillet, hvilket hele rapporten omhandler. 

Resume er givet for de der endnu ikke har stiftet bekendtskab med bogen, og efterfølgende trækkes 

de vigtige elementer mht. overvågning og et totalitært samfund ud, i en simplificeret analyse. Disse 

elementer bruges som grundlag for den tankegang der ligger forud for spillets udvikling. 

RESUMÉ 

Winston Smith er medlem af ”Yderpartiet”, der er en af de 

dårligst stillede i det ledende ”Partiet” i London, der befinder 

sig i Oceania. 

Partiet overvåger Winston og alle andre igennem storskærme. 

Storskærmene er installeret overalt og derpå kan ses ansigtet 

på den ledende fører "Big Brother". Det er næsten umuligt at 

undgå, at blive overvåget, selv i ens eget hjem. Partiet 

kontrollerer alt i Oceania, selv menneskets historie og sprog. 

Partiet er i gang med at lave og indføre det nye sprog, der 

kaldes "Newspeak". I dette sprog er ordforrådet mindsket en 

del og ord der kan vække modstand, mod Partiet, er fjernet. 

Selv tanken om modstand er ulovlig, det er endda den største 

kriminalitet der findes. 

Winston er frustreret over den undertrykkelse og den strenge 

kontrol af Partiet, hvilket udelukker tankefrihed, sex og enhver 

form for individuel/selvstændig tankegang. Winston hader 

Partiet, trods dette også er ulovligt. Han har anskaffet sig en 

bog, hvori han beretter om hans kriminelle tanker. Winston er interesseret i et magtfuldt 

partimedlem O'Brien, han tror, er et hemmeligt medlem af "The Brotherhood" 

(modstandsbevægelsen). 

En aften går han en tur gennem de fattiges kvarterer, hvor Proletarerne lever et elendigt liv, dog 

uden svær overvågning. En dag modtager han en seddel, hvorpå der står "I love you" af en mørkhåret 

pige ved navn Julia. Der påbegyndes en hemmelig affære mellem dem. De mødes ude i naturen, hvor 

der ikke er overvågningsskærme og senere lejer de endelig et værelse i proletarernes kvarter. 

De mødes og bruger deres tid i værelset, når de kan, men Winston er overbevist om at de før eller 

senere vil blive fanget og straffet, mens Julia er mere optimistisk. Som tiden går, gror Wintons had 

mod Partiet betydeligt. 

Winston og Julia møder O'Brien en dag og får bekræftet at, som dem, han selv er imod Partiet. Han 

påstår at han kæmper imod Partiet i samarbejde med modstandsbevægelsen. 

Han indoktrinerer Winston og Julia ind i modstandsbevægelsen og giver Winston, Goldsteins bog, 

som er skrevet af lederen for modstandsbevægelsen. 

En dag i det lejede værelse indtræder ”Tankepolitiet” og anholder dem begge for tankeforbrydelse. 

19 of 83

Winston finder ud af at O'Brien også er en spion af Partiet. Han er en fælde for dem, som vil gøre 

modstand mod Partiet. 

I fængslet bliver Winston udsat for tortur og hjernevaskelse af O'Brien. Til sidst bliver han sendt til 

det berygtede torturværelse 101, som også bliver kaldt "The final destination for anyone who 

opposes the Party". Her fortæller O’Brien, Winston at han vil blive tvunget til at konfrontere hans 

værste frygt. Winston har altid haft mareridt om rotter, så derfor fastsætter O’Brien et bur med 

rotter til Winstons hoved og åbner buret, så rotterne kan æde hans ansigt. Winston skriger og siger; " 

Gør det mod Julia, lad mig være". O'Briens hensigt var nu opfyldt, at Winston skulle opgive Julia og 

derfor er Winston nu ”frigivet”. 

Senere møder Winston Julia igen, men der er nu ingen følelser for hende, da han nu har accepteret 

Partiet fuldstændigt og har lært at elske "Big Brother". 

ANALYSE AF BOGEN 1984 

I dette afsnit gennemgås en simplificeret analyse af 1984. Denne analyse klarlægger de forskellige 

temaer; hvorledes Orwell visualiserede sin dystopiske fremtidsvision, samt den teknololgi han havde 

forestilt sig for at gøre dette muligt. Udfra dette kapitel vælges hvilket temaer fra bogen der skal 

omsættes til vores adventurespil. Selve analysen er baseret på Spark Publishings analyse af 1984, af 

samme navn. 

WAR IS PEACE 

FREEDOM IS SLAVERY 

IGNORANCE IS STRENGTH 

Partiets slogan, også beskrevet i analysen, beskriver Partiets syn, og giver et godt indblik i, hvordan 

”Doublethink” (forklaring i afsnit om Doublethink) virker. 

Folk informeres konstant om at Oceania er i krig med enten Eastasia eller Eurasia, skaber et 

sammenhold i befolkningen og folk har noget at tænke på, andet end arbejde og Partiet. Dermed 

skaber Partiet en kunstig tilstand, hvori de slipper for at stå til regnskab for befolkningen. 

Efter Partiets mening er den frie mand, dømt til at fejle. I sammenholdet med arbejde og styrkelse af 

Partiet gennem ”slaveri” har befolkningen sin frihed. Partiet mener dermed ikke at der er plads til 

individualister, men derimod skal folk være ens og alle arbejde, for at få skandaløse tanker ud af 

hovedet. 

Ved at ignorere al ”sund fornuft” og godtage Partiets holdninger og information de får fortalt af 

Partiet, er de styrket i deres sammenhold, og Partiet har/får styrke til at gøre som de ønsker. 

DET POLITISKE SYSTEM 

Gennem hele historien, beskrives det politiske system gennem hovedpersonen, Winston’s, øjne. Hans 

syn på samfundet og Partiet, er det der gennem hele bogen skinner igennem. Det giver læseren 

indtrykket af den magt Partiet bruger for at underkue befolkningen, og hvor hensynsløs Partiet virker. 

Noget der ofte bliver beskrevet af Winston er ”Telescreens”, hvilket er TV-skærme der så at sige, går 

begge veje. Partiet kan se alt og høre alt gennem disse og dette giver Partiet mulighed for konstant 

overvågning af befolkningen, samtidig med at de uafbrudt sender propaganda. 

Partiet lever ved at stoppe alle former for selvstændig tankegang hos den ydre del af Partiet, hvilket 

muliggør manipulation og løgne. Dette gøres endnu lettere for Partiet, eftersom de fungerer, som den 

eneste nyhedstjeneste i landet. Intet af den information Partiet sender ud, kan derfor verificeres, og 

langsomt er befolkningen blevet vænnet til at hvad Partiet siger, er sandt. 

Måden hvorpå partiet stopper alle former for selvstændig tænkning er ved ændring af historien, 

splittelse af familier og Doublethink 

20 of 83

ÆNDRING AF HISTORIEN 

Partiet er i stand til at ændre fortiden til deres fordel, hvilket de gør i høj grad. Som George Orwell 

skriver: 

“Who controls the past controls the future.” 

“Who controls the present controls the past.” 

Da Partiet kontrollerer alle medier, har de fuld kontrol over nutiden. Dermed muliggøres det, at 

historien kan ændres til deres fordel uden at folk stiller spørgsmål, og kun den ældste generation i 

befolkningen kan huske, hvordan tiden, før Partiet, var. 

Derved, ved at ændre fortiden, har Partiet mulighed for at forme fremtiden derefter og ændre 

sproget til at umuliggøre partifjendske tanker: 

“Don’t you see that the whole aim of Newspeak is to narrow the range of thought? In the end we shall 

make thoughtcrime literally impossible, because there will be no way to express it.” 

(Orwell, George, 1998, s. 55) 

Dette gør også, at Partiet kan lyve for befolkning og skabe en illusion af at verdenen aldrig har været 

bedre, trods de miserable forhold, der leves i. 

Alt litteratur afskaffes, hvorved befolkningens kreative evner og tanker forsvinder og derfor er der 

ingen andre tanker tilbage, end dem der er positivt stemte omkring Big Brother og Partiet. 

SPLITTELSE AF FAMILIER 

Splittelse af familier sker ved at fjerne følelserne mellem de voksne og få dem til at tro deres 

ægteskab kun er til for, at hjælpe Partiet med at få nye medlemmer. Fremmedgørelse af sex og 

kropslige lyster sker, da Partiet ikke ønsker følelser der overgår medlemmets kærlighed til Big 

Brother. Sex bliver hermed udstillet som noget væmmeligt der bare skal overstås. 

Børn oplæres i ”daginstitutioner”, mens forældrene er på arbejde, med formålet at lære at spionere 

på deres forældre og rapportere enhver unormal opførsel. Dette er endnu en slags overvågning af 

befolkningen, samtidig med at allerede i en tidlig alder, udsættes børnene for hjernevaskelse, så de 

kan blive ”perfekte” medlemmer. En utryg følelse skabes internt i familien, og følelsen af tillid og 

familiefølelsen fjernes. 

Som tidligere nævnt påvirker Partiet alle sammen, ved at oversvømme menneskets hjerne med 

propaganda, krig og om den kommende sejr, via storskærmene. Disse storskærme bliver også brugt 

til overvågning og alle bliver hele tiden mindet om at de bliver overvåget. 

”BIG BROTHER IS WATCHING YOU” 

Samtidig overvåges menneskets kropsprog og ansigtsudtryk, hvis en person bare i en lille grad viser 

modvilje for Partiet bliver han/hun anholdt. Partiet har lavet en arbejdsdag for alle, så de bliver 

psykisk og fysisk udmattet, og dermed ikke har overskud til, at skabe tanker om Partiet, andet end 

hvad man bliver bombarderet med i forvejen. 

DOUBLETHINK 

Doublethink er måden, hvorved Partiet kan ændre begivenheder og befolkningen ikke bare 

accepterer det som sandt, men også selv tror på det, og tror det har været sådan altid. Det er med til 

at give partiet mere kontrol over befolkningen og derved blive i magten. 

21 of 83

TEKNOLOGI 

George Orwell beskriver den teknologi, Partiet benytter gennem hele bogen, og om hvorvidt alle 

midler tages i brug, lige fra kamera, skærme, mikrofoner, tankekontrol, og alt hvad der i år 1948-49 

fandtes sandsynligt for fremtiden. 

Storskærme hvor billede og lyd går begge veje, hvilket vil sige et fjernsyn, hvor personen der sender, 

samtidig har mulighed, for at se og høre alt hvad der foregår på den anden side. Denne teknologi og 

form for overvågning, er den mest omtalte i bogen. Det fremgår, hvordan disse skærme er i alle hjem 

og de fleste offentlige steder, i de bydele, hvor Partiets medlemmer begår sig. Disse skærme kan 

hverken slukkes eller skrues helt ned for, så på alle tider af døgnet kan befolkningen overvåges og få 

information fra Partiet uden personlig indvirkning. 

Skjulte mikrofoner nævnes også, da disse, som de mere diskrete former for overvågning, menes at 

kunne findes alle steder der ikke er skærme. Populationen kan derfor aldrig vide sig sikker, og alt hvad 

man siger, kan opfanges af disse mikrofoner og ens stemme genkendes. 

Sidste bemærkelsesværdige, men samtidig delvist uforklarlige, teknologi er tankekontrol. Det 

hemmelighedsfulde tankepoliti står bag dette og det menes muligt, at alle menneskets private tanker 

kan opfanges, og er disse imod Partiet, er det naturligvis ulovligt. Winston hentyder til at det kan 

hænge sammen med skærmene, der opfatter ens væremåde og ansigtsudtryk, samt stemmeføring, 

og derved kan ens tanker udledes, værende positive eller negative. 

KONKLUSION OG AFGRÆNSNING AF BOGEN UD FRA ANALYSEN 

Ud fra analysen af bogen er det tydeligt, at George Orwell’s mening med 1984 har været at oplyse 

faren ved overvågning og det totalitære samfund. Dette totalitære styre ses gennem øjnene på 

hovedpersonen Winston. Dette er grunden til, at hovedpersonen i spillet ligeledes vil være Winston 

og hovedtemaet vil være belysning af de konsekvenser, der kan være ved udviklingen af 

overvågningssamfundet og det totalitære styre. 

Bogen 1984 indeholder også et kærlighedstema, hvor Winston fører et hemmeligt og ulovligt 

kærlighedsforhold. Dette kærlighedsforhold er endnu et bevis på, at samfundet styrer selv 

befolkningens følelser, dog er dette forhold fravalgt, som scene i spillet, da spillets hovedtema er 

overvågning og det totalitære styre og spillet er derfor afgrænset til at omhandle dette. 

GAMEPLAY 

Dette afsnit vil omhandle en beskrivelse af ordet leg og hvordan det bruges i computerspil og andre 

underholdningsmetoder. Derudover vil afsnittet omhandle emnet sikkerhed, hvilket er en vigtig faktor 

i underholdning, da mennesker har brug for en vis sikkerhed. 

Der kommes videre ind på hvordan ordene leg og sikkerhed bruges i forbindelse med underholdning 

og spil generelt og om hvordan det skal være sikkert for spilleren at træffe sine valg, uden at skulle 

føle sig frustreret efterfølgende. 

”You can't design games if you don't understand play” 

(Crawford, 2003, s. 28) 

Ordet ”leg” er et ord, der kan defineres som det modsatte af arbejde og alvor. Det bliver dermed ofte 

forbundet med børn. Da legen har en så stor dominans i barndommen, er den svær at komme af med 

i det voksne liv. Derfor fortsætter legen i det voksne liv i en vis grad, nogle mere diskrete end andre. 

Legekonceptet har integreret sig i nutidens kultur og på en måde kan leg findes i næsten alt, hvad vi 

foretager os. Børns lege er med til, at fremme deres sociale adfærd og mange lege går netop ud på at 

efterligne de voksnes handlinger (Crawford, 2003, s. 28 & www.gyldendalsleksikon.dk under opslaget 

leg). 

22 of 83

Overdrivelse fremmer forståelsen er et ordsprog mange har hørt før, og i denne sammenhæng passer 

det godt til forståelsen om leg og spil. Spiludviklere generelt får gjort den virkelige verden fordrejet og 

interessant, i stedet for at få spillet til at ligne virkeligheden. 

Et eksempel på dette er ”Microsoft’s Flysimulator”. Her er det vigtigt den ligner virkeligheden, da det 

er en simulator og skal simulere et virkeligt scenarie. I et andet eksempel er ”Rockstar Games: Grand 

Theft Auto” (GTA), der tager en virkelighed og forskruer den, overdriver den og fremhæver de 

unaturlige elementer (i hvert fald kan de betegnes sjældne), således spillet fremstår sjovt og 

interessant. 

Chris Crawford betegner her denne overdrivelse, som den mentale relation, man som spiller, har til 

virkelige hændelser. Set på ovenstående eksempel med GTA, kan det illustreres ved at overveje, hvor 

underholdende GTA ville være, hvis der ikke var ondsindede missioner at fuldføre. Det ville være en 

simulation af bylivet, hvor man kun kan gå rundt, og ikke meget andet. Netop den overdrivelse der 

beskrives, er hvad der fanger spilleren. 

SPIL SKAL VÆRE SIKRE 

Et meget væsentligt eksempel for Chris Crawford er, hvorledes brugeren skal være sikker i sin leg. 

Hele meningen, eller hele ideen, med leg, er at brugeren skal være i sikkerhed for farer, men samtidig 

drage erfaringer i spillet. Dermed intet der kan bevirke negativt direkte på spilleren, kun dennes 

tilstedeværelse i spillet. 

Spilleren skal have muligheden for at hoppe tilbage og ændre en handling i spillet, således spilleren 

føler sig sikker. Kun en sjælden gang skal spilleren støde på tab eller nederlag, for at bevare illusionen 

af risiko. Vi har som mennesker brug for sikkerhed, samtidig med at fare er en spændende faktor. 

Dette ses ved mange forskellige typer underholdning. En af de typiske er film, hvor helten overlever 

flere livstruende situationer, og som seer ved man, at det er utroligt sjældent indenfor filmgenren, at 

helten dør. Dermed er der skabt spændende fare, samtidig med en vis sikkerhed om at der ikke sker 

helten noget. Derudover er seeren jo udmærket klar over, at det bare er en skuespiller, så trods at 

personen dør i filmen, sker det ikke i virkeligheden. Dette er en stærk faktor, som kunne overføres til 

spil og dermed ville et godt spil, lade spilleren bevare illusionen af fare, men kun sjældent egentligt 

være i fare (Crawford, 2003, s. 31-33). 

Computerspil behøver dog nødvendigvis ikke, at være sjove for at være underholdende. Et 

computerspil kan give brugeren mange andre følelser og stadig være et godt computerspil. Det vigtige 

ved computerspil er, at det på en eller anden måde, giver brugeren en form for god følelse når 

han/hun spiller det (Crawford, 2003, s. 34-35). 

UDFORDRINGER OG KONFLIKTER 

Dette afsnit vil omhandle, hvordan vi mennesker har det med udfordringer, hvor stor en vigtighed 

udfordringer har i et computerspil og hvordan disse kan være med til at udvikle menneskers evner. 

UDFORDRINGER 

Vi som mennesker, er altid på jagt efter nye udfordringer. Dette er en del af den menneskelige 

udvikling og mennesket søger derfor udfordringer i næsten alt: socialt, kunstnerisk, arbejde, viden 

osv.. Hvis en udfordring fejler sættes standarden ned og når en udfordring giver succes, leder vi blot 

efter en ny og større udfordring. Udfordringer er derfor en vigtig faktor i livet, da disse er med til at 

udvikle et menneskes identitet. 

Ved enhver form for udfordring hører der regler til. 

23 of 83

“The water skier cannot change the nature of water, nor can the rock climber defy gravity.“ 

(Crawford, 2003, s. 37-38) 

De regler der hører med til en udfordring er vigtige, og hvis de ikke er der, er der ingen udfordring. 

Som Chris Crawford skriver, kunne en bjergbestiger blot bruge en helikopter, hvis der ikke var en 

regel, der sagde at man som bjergbestiger skal klatre (Crawford, 2003, s. 37-38). 

I et computerspil er det udfordringen, der er det vigtige og ikke målet. Et problem der helst skal 

undgås i et spil er, at spilleren ikke slutter spillet med en følelse af utilfredshed. Mange mennesker 

har en tendens til at springe over, hvor gærdet er lavest, hvilket vil sige at hvis en spiller kommer til en 

udfordring i et spil vil han/hun, så vidt muligt prøve at snyde systemet, via de uskrevne regler, til at 

undgå denne udfordring. Dette vil medføre at spilleren kommer forholdsvis let igennem spillet og 

dermed ikke føler at have fået noget ud af det, pga. de manglende udfordringer. Dette er grunden til 

at det er vigtigt, når der laves et spil, at undgå et sådant problem ved eksempelvis, at gøre 

smutvejene umulig for spilleren at tage. Dette er forholdsvis nemt at undgå ved computerspil, da 

programmøren her kan bestemme, hvad der skal være muligt at gøre i spillet, og hvad der ikke skal 

være muligt. 

“Eliminate loopholes that allow the player to evade the challenge of the game” 

(Crawford, 2003, s. 40) 

Ovenstående citat betyder, at for at udfordringen bliver tilfredsstilende for spilleren, skal 

udfordringen defineres og gøres så klar og præcis som muligt, så den ikke kan undgås (Crawford, 

2003, s. 38-40). 

HURTIGE OG SEKVENTIELLE UDFORDRINGER 

En udfordring i sig selv, kan være hurtighed. Mange spil indeholder disse udfordringer, hvor det 

gælder om at være hurtig. Dette kan være en stor udfordring for nye spillere, der ikke er vant til at 

spille mange computerspil. De mere vante spillere har opbygget en hurtigere reaktion. De mange 

forskellige typer og størrelser af udfordringer er afhængige af, hvor meget spillerens hjerne er vant til 

at benytte de evner der skal til for at fuldføre udfordringen. Det betyder at dette derfor også skal 

tages hensyn til, når der laves et spil. Des mere vante målgruppen er til at spille des større skal 

udfordringerne være. 

En type udfordring der kan være risikabel at bruge i computerspil er sekventielle udfordringer, såsom 

lange udregninger, hukommelse eller handlinger der skal fuldføres i en bestemt orden. Dette kan 

nemt få spilleren til at føle at spillet er ensformigt og kedeligt. 

RESSOURCE MANAGEMENT 

Mange computerspil indeholder udfordringer indenfor kategorien ressource management, hvilket 

betyder at spilleren skal, som en af udfordringerne, administrere de forskellige ressourcer. Dette har 

både fordele og ulemper. Det er en god måde for spilleren, at kunne forhandle sig frem til elementer 

eller handlinger fra de andre karakterer i spillet. Hvis der dog kommer for mange ressourcer ind i 

spillet, kan det hurtigt blive ligesom de sekventielle udfordringer, for ensformigt og der vil dermed 

være manglende handlinger i spillet. 

24 of 83

KONFLIKTER 

”Conflict enlivens and animates challenge; without conflict, challenge is limp and passive. Narrative 

operates under the same constraint; conflict puts the protagonist under stress, forcing choices that 

reveal character.” 

(Crawford, 2003, s. 55) 

Dette citat fortæller at uden konflikter i et spil, er udfordringerne i spillet passive og derfor ikke vil 

have, den effekt de burde have i et spil. Derudover bliver det nævnt at der mht. det narrative i et spil, 

er de samme begrænsninger. Konflikter stiller hovedkarakteren i spillet i en stresssituation og dermed 

bliver tvunget til at tage beslutninger. 

Der er stor forskel på mænd og kvinder når det gælder konflikter. Mænd har en tendens til at gå efter 

fysiske konflikter, hvor kvinder er større fans af sociale konflikter. Mænd har ofte en tendens til at slå 

først og derefter stille spørgsmål, hvor det er modsat ved kvinder. Dette gør det ofte svært at designe 

et computerspil, da det pga. de store konfliktforskelle, er svært at ramme en målgruppe, der både 

indeholder mænd og kvinder (Crawford, 2003, s. 56). 

NARRATIVER I COMPUTERSPIL OG DETS FORMÅL 

I dette kapitel bliver der gjort rede for de tre tekniker hvorpå et narrativ tjener sit formål samt bruges 

til emner som indlevelse og belønning for brugeren. Derefter gås der videre med former for narrativ 

udtrykkelse, dette i form af forskellige metoder, så som tekst, visuelt osv. 

INDLEVELSE 

Indlevelse, eller immersion, henfører til den sindstilstand, hvor en person er komplet optaget af hvad 

vedkommende laver. Det er blevet beskrevet som den psykologiske tilstand af ”flow” og opfattelsen 

af at enhver form for mistro og adskillelse fra mediet er blevet afbrudt (Bateman, 2007 s. 5). Når en 

spiller er fuldt indlevet i spillet, holder den virkelige verden op med eksistere og spilverdenen bliver 

spillerens virkelighed. Narrativ er med til at skabe en kontekst for et spils hændelser, samt et 

tilstrækkeligt troværdigt narrativ, er med til at skabe indlevelse hos spilleren. 

”First Person Shooter” (FPS) genrens spil kører generelt efter det samme koncept: flyt sigtekornet 

over fjenderne og skyd. Selvom det basale spilkoncept er det samme, har genren alligevel præsteret 

at lave meget afvigende spiltitler, som rangerer fra alt imellem historisk korrekt og dyster ”2. verdens 

krigs” temaer til ”fremtids-horror-shooter”, til ”lejemorder simulation”. Det der adskiller disse spil fra 

hinanden, er både spilmekanikken og det narrative indhold. Det narrative indhold er med til at give 

spilmekanikken troværdighed og motivere spilleren til at tage del i den, og udføre de handlinger som 

er påkrævet. 

Et eksempel på dette ses i spillet ”Tom Clancy’s Ghost Recon” (Red Storm 2001). Her nedkæmper 

spilleren utallige af fjender i spilforløbet. Her er spilnarrativet med til at give det troværdighed, i form 

af en forklaring af, hvem disse fjender er, hvem spilleren er, og hvad deres formål er, hvilket er 

soldater, der forsvarer de uskyldige mod et uretmæssigt angreb. Yderligere giver det en forklaring til 

hvad spillerens mål er for spillet, hvilket er at skyde fjenden. Dette er med til at forklare spilleren, at i 

spilverdenen er det acceptabelt at eliminere den computerstyrede fjende. Narrativet giver 

spilmekanikken dybde ved at omformulere ”bevæg dig og skyd fjenden i dette område” til ”sikre det 

styrtede fly fra fjenden” og det meget anvendte scenarie ”Bliv i dette område i et bestemt stykke tid, 

25 of 83

uden at blive skudt” bliver til ”Beskyt (Den Røde Plads) mod det sidste desperate forsøg fra fjendens 

soldater”. 

Da spilforløbet nu er tilknyttet et narrativ, bliver spil målene nu mere appellerende og motiverende 

for spilleren at opnå. 

BELØNNING 

Narrativ kan også virke som en belønning for spilleren. Historien i spillet kan blive afsløret gradvist, 

hvor forskellige segmenter af historien bliver givet som belønning for at have løst nogle spillets 

udfordringer og mål. Hvis man gør dette flere gange i sit spil, er det vigtigt at man husker, at spilleren 

kommer til at forvente, at dette er en gentagende hændelse og at en del af narrativet bliver givet, 

efter hver større udfordring som en bosskamp, eller andre svære udfordringer. I spillet ”God of War” 

(SCE Studio Santa Monica, 2005), bliver forhistorien i spillet langsomt fortalt, som spillet fremskrider. 

Efter spillets forskellige baner, bliver en lille del af hovedpersonens fortid vist, der gradvist forklarer 

om, hvorfor man er i den givne situation. Disse ”in-game cutscenes” giver ikke spilleren nogen fordel 

spilmæssigt. Derudover giver de ikke spilleren nogen decideret spilrelateret viden, såsom fjendernes 

svagheder, eller hvor der er gemte skatte eller hvordan man skal aktivere hemmelige funktioner i 

spillet. I stedet er deres formål blot at give spilleren narrativ information, såsom hvorfor 

hovedpersonen er så opsat på at få hævn over skurken, hvorfor han er i hans nuværende situation 

osv. (Bateman, 2007, s. 6). Helt simpelt er det belønning, hvis eneste formål er, at stoppe med en 

”cliff-hanger” 1 , der tjener det formål, at trække spilleren igennem gameplay’et, til det næste punkt, 

hvor der er endnu en belønning. Disse cliff-hangers er med til at motivere spillerne, til at finde ud af, 

hvad der sker i historien og få dem til at blive ved spillet. 

IDENTIFICERING 

Det tredje formål med et solidt narrativ i computerspil, er identificering. Identificering er med til at 

forklare spillerne hvad der er hvad, hvem der er hvem, og hvordan spilverdenen rundt omkring ham 

er skruet sammen. Identificering giver spilleren kontekst for sine handlinger, og samtidig 

retfærdiggøre spillets handlinger, såsom når spillet fortæller brugeren at han skal gå ud og skyde 

objekter, er det godt at forklare, hvorfor disse skal skydes (Bateman, 2007, s. 6). At gøre det klart for 

spilleren, hvorledes spilverdenen han befinder sig i er skruet sammen, gør narrativet det klart for 

spilleren, hvad hans position i den er og hvorledes det er forventet at spilleren skal handle. Dette 

giver spillerne en form for tryghed og selvsikkerhed, velvidnede hvorledes de skal handle i spillet, og 

hvorfor det er nødvendigt for dem at gøre det, i stedet for de stopper op og spørger sig selv ”Hvorfor 

gør jeg det her?” 

Identificering virker også på en anden måde. Identificeringen er med til at virke således at spilleren 

kommer til at føle sig nært knyttet til hovedpersonen, samt en lyst til at være denne (Bateman, 2007, 

s. 7). Spillerne bliver motiveret til at identificere sig med hovedpersonen. I computerspil er denne 

identificering meget stærkere end i f.eks. film, bøger eller andre medier, fordi de har direkte 

indflydelse på hovedpersonens handlinger. Derfor burde et spilnarrativ altid blive designet med den 

hensigt at gøre karakteren i hovedrollen så sympatisk og vellidt så muligt, således at spilleren 

identificerer sig mest muligt med karakteren, således at spilleren for lyst til at spille denne karakter og 

dermed også spillet. 

1 Kan bedst beskrives som en brat afslutning på et kapitel, hvor handlingen er i et spændende punkt, 

hvor læseren/publikum/spilleren venter spændt på en slutning og konklusion. 

26 of 83

Spillerens indvirkning på narrativ beskriver, hvorledes spilleren har en meningsfuld indvirkning på 

spilverdenen, eller i det mindste en illusion af indflydelse. Det er vigtigt, at det meste af et spilnarrativ 

bliver leveret i forhold til spillerens handling. Det er derfor vigtigt at spilleren, så vidt muligt, svarer 

tilbage på spillerens handlinger i spilrummet. Det er derfor vigtigt at man tager i betragtning, hvilke 

muligheder spilleren har mht. at interagere med spillet. 

NARRATIVE TRIGGERING 

Der er forskellige måder, hvorpå man kan inkorporere interaktion med et spils narrativ. En af dem er 

ved hjælp af narrative triggering. 

Narrative triggering, eller narrativ udløsning, er en hændelse i spilverdenen der skaber en 

håndgribelig effekt på spillet (Bateman, 2007, s. 63). F.eks. hvis spilleren låser en dør op i et spil, bliver 

der aktiveret et ”flag” i spillets kode, der fortæller at døren er blevet låst op og at spilleren nu kan gå 

igennem den. Her, ved dette flag, kunne der således også sættes narrativt materiale, sådan at der 

bliver aktiveret en dialog eller man støder på en NPC (karakter i computerspil, som ikke er styret af 

spilleren), etc. 

Der er mange forskellige måder hvorpå at narrativ udløsning kan benyttes. En af de mest anvendte 

metoder er at registrere, hvorvidt en spiller er i et givent område eller lokalisation i spillet, hvorefter 

spillet udfører en given hændelse. En hændelsesbaseret trigger, kunne f.eks. være, efter spilleren har 

løst en ”puzzle” eller udfordring, og således bliver belønnet med narrativt materiale. Et andet er 

tidsaktiverede udløsere, hvor f.eks. i et givent tidsinterval kan blive givet beskeder, som små 

hjælpebeskeder. Dette er specielt godt at bruge i starten af spil, hvor spilleren stadig er ny, og måske 

har svært ved at forstå et spils funktioner. Dog kan man risikere, hvis disse er i form af lyd, at lyden 

kommer til at overlappe en allerede igangværende dialog og det kan være generende for spilleren. 

NPC’ere bliver også brugt på denne vis, dog her igen, med forskellige metoder. I nogle spil er det 

nødvendigt for spilleren, at aktivere karakteren ved hjælp af at trykke på en bestemt knap, i andre 

spil, skal spilleren blot være i nærvær af karakteren, hvorefter den starter med at tale med spilleren. 

Kontrol af tale, er en variation af den ovenstående, hvor spilleren har valg, i form af forskellige linjer 

dialog, hvor spilleren kan vælge hvilke spørgsmål og svar han vil give NPC’en, og på den vis give 

spilleren en følelse af interaktion med et andet menneske. 

Den sidste er en kombination af en række spilhændelser, såsom en række ens objekter er blevet 

samlet op, eller et vist antal udfordringer løst. Her kunne man forestille sig, at en spillers forhold til 

spillet vil blive stærkere, hvis spillet på en eller anden vis kommenterede det gode arbejde. Et 

eksempel på dette kunne være spil, hvor spilleren er i gang med at gennemgå en træningsmission. 

Her skal han eventuelt nedkæmpe en række fjender, og er ledsaget af en NPC der hjælper ham 

igennem denne mission. Der kommenteres løbende om hans fremgang i udfordringen, såsom hvor 

mange fjender han har nedkæmpet, samt hvor godt han klarer det. 

NARRATIV OVERLEVERING I COMPUTERSPIL 

En række basale metoder til overlevering af narrativer i computerspil er blevet udviklet igennem 

tidernes løb. Hver især har de forskellige stærke og svage sider, samt de kan anvendes på en række 

forskellige måder og yderligere, kan de kombineres på kryds og tværs. 

27 of 83

TEKST 

Tekst er en af de mest simple former for narrativ overlevering. Her læser spilleren historiens udvikling 

på skærmen, mens vedkommende spiller spillet. 

I mainstream computerspil bliver tekst, som regel, set i tre forskellige områder (udover 

undertekstning af optaget dialog). Det første er i computerspil, hvor der er mange linjer af dialog, 

hvor det enten vil være urealistisk at lægge stemme til dem alle, på grund af deres overvældende 

antal, eller fordi spillet har et begrænset budget. Man ser dette for det meste i ”Role Playing Game” 

(RPG) genren, hvor genrens publikum ikke bliver generet af denne type narrativ overlevering 

(Bateman, 2007, s. 49). 

Det andet område hvor tekst optræder, er i action adventurespil, såsom ”Resident Evil” (Capcom 

1996) eller i ”Fear” (Vivendi 2005), hvor teksten optræder i in-game artefakter såsom dagbøger man 

finder, eller tekstfiler der læses på computeren osv.. I ældre spil indeholdte disse sommetider vital 

information, der var nødvendig for spilleren at gennemlæse og forstå før, at vedkommende kunne 

fortsætte til næste segment af spillet. Dette er udviklerne begyndt at gå væk fra, og i stedet bruge 

tekst til ekstra dybde og farve på historien, så spilleren selv kan vælge om han/hun vil fordybe sig i 

heri (Bateman, 2007, s. 49). Disse artefakter kan også bruges til at nedsætte fremdriften på 

handlingen i spillet, f.eks. efter en action sekvens eller plotpointe, hvor spilleren har brug for et hvil. 

Den sidste måde, er mest set i Japanske konsol spil, hvor lydeffekter bliver brugt til at illustrere 

vokalisering af spilkaraktererne og tekst kommer frem på skærmen og viser hvad de siger (Bateman, 

2007, s. 50). 

OPTAGET DIALOG 

Optaget dialog er mere fleksibelt end skrevet tekst. Det er dog dyrere at inkorporere i sit spil. Af de 

mange fordele der er ved optaget dialog, kan nævnes blandt andet, muligheden for spilleren at høre 

dialogen og spille samtidig, hvilket er lettere end at spille og læse samtidig. Dette medfører en mere 

flydende spiloplevelse for brugeren (Bateman, 2007, s. 51). Spilleren bliver ligeså fordybet yderligere, 

ved brug af talentfulde skuespillere til at lægge stemme til de forskellige karakterer i spillet. 

Som regel er det godt at anvende optaget dialog gennem spillet. Dog er det vigtigt at tage sig visse 

forbehold, såsom når man videregiver vigtig information som det er absolut nødvendigt at spilleren 

forstår. Dette burde man kun gøre når man er sikker på man har spillerens fulde koncentration, 

såsom i en animeret mellemsekvens i spillet, eller i det mindste gøre det muligt at få den optagede 

dialog gentaget. At spille en lang vigtig dialog midt i en lang action sekvens i et spil, hvor spillerens 

koncentration er fokuseret på overlevelse og kamp, er ikke så smart, i forhold til at spille en dialog 

mens spilleren kører i elevator eller på andre måder venter passivt. Ikke essentiel dialog, som er med 

for at give spillet farve, kan dog spilles på alle tidspunkter. 

Dog er der visse problemstillinger der skal tages højde for. Såsom to linjer af dialog der overlapper 

hinanden, som f.eks. kan ske, hvis man har linjer af dialog der udløses i bestemte områder. Her kan 

det ske at spilleren bevæger sig for hurtigt igennem spillet og starter to linjer af optaget dialog så en 

kollision af de to sker. Der er forskellige løsningsmetoder, f.eks. ved at lave en prioritet af de 

forskellige linjer af dialog, så den første bliver spillet og den anden bliver stoppet, og lige så at det er 

den første dialog der bliver afbrudt og den anden bliver spillet. Ingen af de to muligheder er 

tilfredsstillende men, af de to er det nok den anden der er at foretrække. En anden problemstilling er 

ved gentagelse. Et spil hvor den samme linje bliver brugt igen og igen, som f.eks. ved et skrig, eller en 

bekræftelse fra spilkarakteren, kan hurtig blive træls og forstyrrende for spillerens indlevelse. Her vil 

det bedste nok være at indspille flere forskellige linjer af dialog af den samme sætning og variation af 

den. En anden mulighed af dette er at visse ord kan blive anset af udgiveren eller målgruppen som 

28 of 83

stødende, så det er altid godt at optage forskellige variationer af en replik, hvis der mistanke om 

stødende ord. 

STATISKE BILLEDER 

Computerspil er et audiovisuelt medium, og billeder levende eller stillestående, kan være et stærkt 

narrativt virkemiddel (Bateman, 2007, s. 53). Den billigste form for dette er at bruge stillestående 

billeder, eksempelvis en tegning, maleri eller computerskabte billeder. Gamle computerspil havde et 

afgrænset narrativ på grund af den begrænsede hukommelse, som datidens floppydisks og kassetter 

havde. Disse brugte stillbilleder eller meget basale animationer, der ofte var to stillbilleder 

bevægende på hinanden, til at fremme historien. Spil i dag bruger stadig stillbilleder, såsom ”Katamari 

Damacy” (Namco 2004) der bruger animerede storyboards til at fremme historien. Dog er det ikke en 

almen gældende regel, da det førnævnte spil skiller sig meget ud fra mængden og er yderst 

ukonventionelt, så det er tænkeligt at samme løsning ikke gør sig gældende ved mere konventionelle 

spil. 

Et andet sted at bruge statiske billeder er ved loadscreens. Her kan disse bruges mens næste del af 

spillet indlæses til at give spilleren en ny del af historien, eller tips omkring, hvorledes spillet skal 

anvendes. Dette er et godt virkemiddel at bruge til, at fremme historien, såsom det er gjort i 

”Warcraft 3” (Blizzard 2002), hvor spilleren bliver informeret om hændelser i spilverdenen der er sket 

pga. spillerens tidligere handlinger (Bateman, 2007, s. 53). Dette er muligt fordi spillet har en lineær 

historie, som gør det muligt at bestemme spillerens eksakte position i spillets historie. Et andet sted 

hvor stillbillederne også bliver brugt, er i mellemsekvenser til at fremme den narrative fremdrift i 

spillet. Dette ses ofte brugt i RPG genren, hvor der ofte er store mængder af narrativt materiale. Her 

bruges de statiske billeder til historiefortælling. Billederne bliver for det meste brugt dynamisk, med 

voice-over, pans, zooms, fades osv. som det blev gjort i ”Neverwinter Nights” (Bioware 2002). En 

variation af dette er at lave det i tegneserieform. Dette er blandt andet gjort i ”Max Payne” spillene 

(Remedy 2001 og 2003) og i ”XIII” (UbiSoft 2003), det sidste nævnte brugt i kombination med ingame 

engine. 

CAMERA CASES 

Camera cases er en engelsk betegnelse der bliver brugt til at beskrive en ændring i 

synsvinkelen/kameravinklen i spilverdenen. Som regel bruges det til ændre synsvinklen fra spillerens 

synsvinkel til et frit bevægende kamera, som viser et område uden for spillerens synsfelt, som 

eksempelvis en advarsel, vejviser eller anden form for hjælp. Til tider bliver det også brugt som et 

narrativt virkemiddel til at fremme historien i et spil. Her bliver ofte anvendt animationer der allerede 

er i spillet, såsom ”gang-animationer”, ”skyde-animationer”, osv. Det gør dem meget billige at 

producere, da der er ikke meget decideret nyt materiale der skal laves. 

MELLEMSEKVENSER (I SPILMOTOREN) 

”Cut-scenes”, eller mellemsekvenser, er små sekvenser af film, lavet inde i selve spilmotoren. Det vil 

sige at det er små scener fra spillet, præsenteret som små film, mellem spildelene af spillet. Disse 

bliver ofte brugt efter store nøgleudfordringer, som en belønning, hvor spilleren har spillet intenst og 

har brug for et hvil (Bateman, 2007, s. 55). Alt for mange mellemsekvenser er ikke nødvendigvis godt 

for spilnarrativet, da dette kan nedsænke farten på et spil drastisk, og man kan risikere at tabe 

spillerens opmærksomhed. Mellemsekvenser burde aldrig være længere end to minutters længde 

(Bateman, 2007, s. 55). Dog kan dette variere alt efter hvilket slags spil det er, og alt efter hvilket sted 

i spillet det er, såsom i starten og slutningen af et spil, samt ved nøglepunkter i midten, hvor vigtige 

plotpunkter afsløres. Det der adskiller cut-scenes og cameracases er, at ved mellemsekvenserne, skal 

29 of 83

der bruges nye animationer, hvilket gør dem dyrere at producere, men til gengæld flottere og mere 

troværdig for spilleren. 

SCRIPTED EVENTS 

Scripted events, er på sin vis relateret til mellemsekvenser. Det der adskiller dem er, i scripted events 

har spilleren stadig kontrol over sin karakter, modsætningsvis mellemsekvenser (Bateman, 2007, s. 

56). Her i scripted events, udspiller handlingen sig foran spilleren, hvor han har det frie valg om han vil 

blive og kigge på det der udspiller sig foran ham, eller om han vil foresætte videre på sin færd. Ved 

brug af denne type narrative virkemiddel til at videregive vigtig information, er det vigtigt at man sikre 

sig spillerens opmærksomhed. Dette kan gøres ved hjælp af de såkaldte ”flaskehalssituationer”, hvor 

man sikrer sig spilleren ikke har andre steder at bevæge sig hen. Det kan f.eks. gøres ved en gang, 

eller lukke spilleren ind i et forseglet rum, mens handlingen udspiller sig. 

CUT SCENES 

FMV, eller ”full motion video”, dækker over brugen af rigtige skuespillere i decideret filmsekvenser, 

der bliver afspillet på forskellige punker i spillet. Termen er dog begyndt at dække over en bredere 

række medietyper, som f.eks. ”Computer generated imagery” (CGI). Brugen af decideret 

filmsekvenser var meget brugt i midten af 1990’erne, i spil som ”Red Alert” og ”Command And 

Conquer”. Dog gik trenden senere hen på de førnævnte prerendered CGI film. CGI bliver ofte brugt i 

computerspilsintroer, hvor det er vigtigt at have højbevægelige billeder. Da disse er dyre at 

producere, er det vigtigt at brugen af dem optimeres, ved f.eks. at bruge dem til at vise ting, som 

spilmotoren ikke vil kunne klare, såsom højdynamiske actionsekvenser, der ikke vil være mulig at lave 

i spilmotoren (Bateman, 2007, s. 57). 

STORY LINE 

På illustrationen i figur 7, ses strukturen til starten af spillets hovedhistorie. Historien omhandler, 

hvorledes Winston kommer på arbejde og hvilke ting han må igennem for at komme derhen. 

Heriblandt at gemme sin dagbog for vagterne og komme igennem labyrinten af bygninger (det lille 

mini-spil) for at finde hen til sit arbejdsrum. 

Efter dette event er klaret har spilleren fået indblik i miljøet og forlader igen arbejdet, hvor han/hun 

mødes af en mystisk fremmed, som har informationer vedr. oprøret. Det uddybes ikke mere og 

spilleren er nødt til at opsøge en person på den lille kro i proletar området. På denne kro får spilleren 

relevant information om samfundet, hvorfor overvågning (i dette tilfælde) er dårligt og hvorfor det 

totalitære samfund ikke virker. Winston får nu den opgave at hente relevant information fra sit 

arbejde og sine bekendte, i form af informationer om krigen (at den ikke er ægte), nyheder der bliver 

ændret, Emanuel Goldsteins bog, osv., der alt sammen skal bruges for at nedbringe diktaturet. 

Gennem spillerens rejse i spillet, kan der indlægges forskellige scener, som er med til at forklare 

samfundet, uden at have nogen indflydelse på selve hovedhistorien. Disse bi- og sidehistorier vil der 

blive forklaret mere om senere, da de ikke er en del af den udviklede hovedhistorie. Det ønskes ikke 

at spillet skal virke for småt og tomt, så det er overvejet i videreudviklingen. 

Hovedhistorien ses på illustrationen, forløber lineært, hvor der er udspring til at kunne se byen 

undervejs, hvis det skulle have interesse. Det er ikke meningen at spilleren skal føres frem, scene for 

scene, men snarere selv finde vejen gennem udforskning. Dog vil der naturligvis lægges op til hvor 

fortsættelsen er. 

30 of 83

Den info der er tiltænkt gennem forskellige mini-games, puzzles osv. er: 

• Info om at krigen ikke er ægte (tre forskellige stykker information) 

o Information om at landet kun har en informationskilde og meget derfor er falsk 

og/eller propaganda 

o Landet er ikke så fattigt da ingen penge går til krigen, men de mennesker, som 

sidder på magten beholder alt selv, de er korrupte. 

o Krigsfangerne, som bliver taget er ikke rigtige krigsfangere, men ingen ved hvem de 

egentligt er. 

• Nyhederne bliver ændret, så de passer til hvad partiet har sagt eller mener (to forskellige 

stykker information). 

o Giver indblik i hvorledes verden er falsk, og intet er hvad det giver sig ud for. 

• Folk der mystisk forsvinder (to forskellige stykker information). 

o Information er kritisk fortæller det var Partiet der er ansvarlige for folks forsvinden. 

Skal ske inden partiet fjerner det. 

• Find Emanuel Goldtesins bog (en bog) 

o Som taget fra bogen, skal han have den fra O’Brian 

• Sproget bliver ændret 

o Som samtalen mellem Symes og Winston i bogen. Samtalen skal optages. 

I alt giver dette ti stykker information, der skal indhentes. Ideen er at for hvert stykke information, går 

det mere og mere op for befolkningen, hvilket samfund de egentligt lever i, og efter alle ti er blevet 

fundet, kan oprøret endeligt gå i gang. 

Der er samtidig mulighed for at følge bogen endnu mere og efter den 7. til 10. information er fundet, 

bliver Winston anholdt og slutningen følger bogens, for at give spilleren en idé om, hvordan 

samfundet er i denne verden og at det nu er kommet så vidt, at en mand alene ikke kan gøre en 

forskel. 

Denne hovedplotlinie, vist på illustrationen, Skal naturligvis udbygges, med mulighed for at det kan gå 

galt, små sidehistorier passende til universet, måske endda kærlighedshistorien, som beskrevet i 

bogen. Lige nu er det dog valgt at denne er den vigtigste historie, for hvad der gerne vil fortælles. 

31 of 83

Figur 7 

Strukturen af den første akt i spillet. 

32 of 83

UDVIKLINGEN AF ET SPIL 

Som med så mange andre ting, når de kommer over en vis størrelse og kompleksitet, er det en god 

ide at strukturere sit arbejde. Her kommer et bud på hvordan udviklingen af spil fra første ide til 

færdigt produkt; baseret på Chris Crawfords tanker om Game Design. 

Hvis man tager det for afslappet og ikke lægger planer for, hvordan udviklingen bør forekomme og 

vælger bare at hoppe ud i det, vil det hurtigt gå galt og tage endnu længere tid, end hvis man 

planlagde det; skriver han. 

1. Ide udviklingen; Brainstorm. Her er det vigtigt at komme med alle tænkelige ideer, både om grafik, 

historie, interface, udtryk, musik, etc. 

Det er vigtigt ikke at lade sig hæmme af noget, men være kreativ, kom med alle ideer der kunne 

bruges til noget, andre kunne måske blive inspireret og komme med noget. 

2. Udvælgelse af en målgruppe. På dette tidspunkt skal ovenstående reduceres, således der kommer 

et forslag til koncept. Målgruppen vælges; identificeres. Hvem er de, hvilket miljø er de fra; kunne 

være to gode spørgsmål til afklaring af målgruppen. Ud fra denne målgruppe vælges de ideer og 

udtryk fra ovenstående der passer til den givne målgruppe. 

3. Stemningen i spillet skal nu gøres klart. Alt efter valgt målgruppe skal stemningen i spillet vælges, 

alt efter spillets handling og budskab, samt alderen på målgruppen. Stemningen er det ”feel” spillet 

får, i form af grafikken, farvevalget, musikken, hvilket giver stemningen der bliver sat i spillet. Her bør 

dog specificeres mere, i form af udtryk hos venner og fjender, hvilket ”pace” spillet har, og alt hvad 

der ellers er med til at definere spillet. 

4. På nuværende tidspunkt er det vigtigt at finde hjælpemidler til de ting der ikke er styr på mht. det 

videre forløb. Det bør gøres klart, hvorledes folks kompetencer mht. programmering, lyd design, 

grafisk design, tegning af story boards, mv. er. Dette gælder også for eventuelle programmer der 

måtte mangle for at kunne udføre et arbejde. Et eksempel ville være at nævne ”Adobe Flash” 

(tidligere Macromedia Flash) der er et essentielt værktøj for at kunne lave et spil i Flash. 

5. Tiden kontra nødvendigheden. Hvis tiden ikke er til at få alt implementeret inden deadline er det 

nu det skal skæres fra. Det samme gælder hvis det der var regnet med at blive implementeret bliver 

en ballast for spillet. Dette kunne være hvis en given funktion, der egentligt er uden betydning for 

spillet, eller har lille betydning, tager 50% af computerens kapacitet. 

Det gøres her klart, hvor meget at spillet der kan implementeres og vil virke ved deadline. 

6. Lav spillet. Nu er tiden nået til at lave spillet. Her er det evt. muligt at dele spillet op i sektioner og 

uddelegere opgaverne. Forskellige personer kan sagtens arbejde på forskellige funktioner/blokke på 

en gang. 

7. Test. Både interne og eksterne tests er nødvendige. Test internt for at finde åbenlyse fejl der skal 

rettes. Senere test på eksternt publikum, da disse typisk har anden indgangsvinkel til spillet end 

udviklerne, og vil muligvis sætte lys over et problem skaberne havde overset. 

Herefter rettes fejl og mangler i spillet, og bør herefter testes igen (Makar, 2002 kap. 2). 

33 of 83

SPILUDVIKLING – PROTOTYPEN 

1.) I idéudviklingsfasen blev der fremlagt mange forskellige ideer til, hvordan spillet skulle være og 

hvad det skulle indebære. Der var ikke mangel på ideer da alle var kreative og kom med deres bidrag 

til processen. Hver ide der blev præsenteret, sattes nye tanker i gang hos gruppemedlemmerne, 

derved blev ideerne videreudviklet og gennemarbejdet. Alle konceptideer var så unikke at man kunne 

lave spil på alle tænkelige og utænkelige måder. 

Efter en lang konstruktiv diskussion om de fordele og ulemper i de forskellige spil ideer, faldt 

beslutningen på et ”point n’ click” adventure spil. Denne beslutning blev taget på baggrund af den 

faldende interesse for spilgenren, og fordi det er den der er mest oplagt til at lave en bog om til spil, 

da genren i sig selv ligner en fortælling med replikker og handlinger. 

2.) Efter en lang debat om hvorledes målgruppen skulle udvælges og hvem der skulle sættes i fokus, 

blev valget truffet ud fra de følgende punkter; dvs. efter spillet blev designet. 

Det er valgt at spillet skal udvikles efter egne valg og interesser, hvorefter spillet forventes testet på 

målgruppen, og det ses hvorledes de finder produktet. Dermed er spillet ikke udviklet efter, hvordan 

de vil have det, men nærmere hvordan de modtager, det der er valgt for dem. 

3.) Stemningen er, i modsætning til Jobe Makar’s idé om at stemningen skal passe til målgruppen, 

valgt ud fra bogens, 1984, temaer og beskrivelser. 

Miljøet er meget dystopisk, mørkt, kedeligt, trist og håbløst, for at sætte nogle beskrivende tillægsord 

på stemningen. 

Spillets ”feel” forventes at blive som nævnt ovenstående. 

Da adventurespil er valgt, vil spillets pace blive naturligt langsomt, da spillet ikke umiddelbart ligger 

op til hurtig action, men snarere ligger op til lidt langsommere historiefortælling. 

4.) Gruppemedlemmernes individuelle kompetencer blev præsenteret for hinanden mht. 

programmering, lyddesign, grafisk design og tegning af story boards osv. Således blev der fastlagt et 

overordnet standpunkt for gruppen. Dette skubbede gruppen i retningen af en større 

vidensindsamlingsproces, da gruppemedlemmernes kompetencer var vidt forskellige og varierede 

meget efter de forskellige emner. Dog blev der besluttet at alle skulle følges ad i spiludviklingen, 

sådan alle kunne bidrage og forstå de grundlæggende teorier bag spiludvikling. 

Efter gruppens kompetencer og erfaring blev udviklingsprogrammet valgt til Flash, da det lå lige for, 

eftersom der blev givet undervisning i det på semesteret. 

5.) Efter spilkonceptet og handlingsforløbet var gennemarbejdet, blev der valgt et lille forløb ud fra 

spillet, for at blive testet. Dette specifikke forløb skulle færdiggøres, således det var klar til en 

brugertest. Det var ikke så vigtigt at koden bag spillet og tegningerne var som det endelige produkt, 

da det kun skulle testes for layout, navigation og brugervenlighed. 

Spillet blev så at sige delt op i to, hvor en var selve testversionen der skulle udvikles så hurtigt som 

muligt for at kunne teste, mens den anden var selve slutproduktet der skulle beskrives og udvikles på 

den smarteste måde. 

6.) Opgaverne blev delt mellem gruppen, sådan at nogen arbejdede med den grundlæggende motor 

bag spillet og andre arbejdede med design og handlingen. Dog blev det vanskeligt at gøre det reelle 

34 of 83

spil færdig til testen, så grundet tidsmangel, blev prototypen udviklet på en lettere måde, sådan de 

nævnte elementer kunne testes og evalueres. 

Selve den endelige version er beskrevet i rapporten, og fra produktet er lavet og beskrevet med kode. 

7.) Først blev spillet testet af gruppemedlemmerne, og derefter af nogle testpiloter, i form af andre 

medstuderende. Herefter blev de væsentlige fejl rettet og modificeret til brugertestet. 

Brugertesten forløb uden problemer. Under brugertesten blev der fokuseret på nogle væsentlige ting 

indenfor navigation og brugervenlighed, der blev overset. Testresultaterne blev evalueret og 

analyseret til fordel for den endelige version, som også skal igennem en større brugertest. 

BRUGERTESTS 

Baseret på Interaction Design 2nd Edition, kap. 14. 

Det at lave en brugertest er ikke umiddelbart let at gøre. Der ligger meget foran gående arbejde for, 

og mange valg der skal træffes i forbindelse med, hvad der skal testes. Et eksempel er en meget ligetil 

test, hvor fokus er, for testholdet at udarbejde, hvorledes en tekst kan læses, hvilken fonttype og 

opløsning der er bedst mm.. I en test kan fokus ligge på de mere ”humane” mål, såsom sjov, 

frustration, frygt, osv.. 

Man kan derudover samtidig dele testen op i to elementer. Usability testing, hvor fokus ligger på at 

teste et givent produkt, med produktet i centrum. Field studies er den anden mulighed, hvor testen 

bliver taget ud af et testområde og ind i slutbrugerens hjem, for at undersøge, hvordan brugeren 

formår at interagere med produktet i de vante omgivelser. Denne vil dog ikke nævnes yderligere her, 

da det i denne situation er nok med en test af produktet, og der mht. spil generelt ikke er den store 

forskel på fastsatte omgivelser og naturligt miljø. 

USABILITY TESTING 

Formålet er her, en test i et laboratorieområde eller andet kontrolleret testmiljø, hvor produktet og 

testen er i centrum. 

Her er det typisk at give en række brugere en fastsat opgave til løsning. Her kan det f.eks. være 

elementer som tiden, mængden af fejl der opstår og fejl brugeren laver, være det vigtigste. Efterfulgt 

af et spørgeskema, er det en god måde at få en ide om, hvorvidt testpersonen følte at produktet 

virkede og testpersonens forhold til at bruge det. 

Eksempel på overvejelser vedr. testen: 

• Tid for at gennemføre en opgave 

• Tid for at gennemføre en opgave, efter en stykke tid væk fra produktet 

• Mængde og type af fejl 

• Mængde af fejl i forhold til tid (fejl pr. minut f.eks.) 

• Mængde af gange hjælp eller manual brugt 

• Mængde af brugere der laver samme fejl 

• Mængde af brugere der gennemførte testen helt 

Fem til tolv brugere er opfattet, som en acceptabel mængde for en usability test. Af og til kan endda 

endnu færre bruges, i forbindelse med tids- og økonomiske begrænsninger. I andre eksempler, såsom 

indledende valg og placering af logo/billede på en hjemmeside, kan endnu færre bruges, endda helt 

ned til et par enkelte. 

35 of 83

Eksempel af spørgsmål til vores spil: 

• Er knapperne på brugerinterface placeret godt. Kan brugeren finde rundt i dem? 

• Kan brugeren finde ud af at navigere rundt i spillet? 

• Er spillet intuitivt nok til at brugeren kan løse små opgaver i testen? 

Et eksempel for valg af brugertest (efter eksempel i bogen, kap.14) kunne være ved at udspørge en 

række personer om de ønsker at teste og fra start lade dem udfylde et skema med alder, køn, erfaring 

med spil, brug af computer mm.. 

Derudover bør der fremgå en introduktion, som nævner at det er produktet der bliver testet, ikke 

brugerne, og de derfor ikke bør bekymre sig om fejl de laver. 

Efter en række testopgaver er udtænkt, er det en idé at have en testgruppe i nærheden at teste på, 

inden den egentlige test, og succesgrundlag skal sættes op. Et eksempel på et succesgrundlag kunne 

evt. være, om det ville være tilfredsstillende hvis kun 60% klarer testen, som forventet. 

Næste spørgsmål testholdet bør stille sig selv er, hvorvidt de bør interagere med brugeren under 

testen, eller lade ham/hende selv finde svarene uden hjælpemidler, og derefter, hvor meget tid bør 

brugeren have før han/hun bevæger sig videre til næste opgave? (Sharp, 2007, kap. 14) 

36 of 83

IMPLEMENTERING 

1984 – DET VISUELLE 

Dette afsnit vil omhandle en beskrivelse af det visuelle i computerspillet 1984. Hermed bl.a. omkring, 

hvilke ikoner der er blevet benyttet og hvorfor disse ser ud som de gør. 

WINSTON 

Winston er hovedpersonen i bogen, samt spillet. Han bliver omtalt som meget udbrændt og træt af 

det samfund han lever i. Winston er basalt set træt af det liv han lever og mener ikke, at det 

nødvendigvis er det ultimative samfund han lever i, trods de ihærdigt forsøges hjernevasket til at tro 

dette. I forhold til spillet var det derfor ret vigtigt at Winston rent visuelt, så meget træt og udbrændt 

ud. Da han også beskrives som meget tynd og ranglet var dette derfor også en nødvendighed, hvilket 

også associeres som en udmagrethed, der kan give et indtryk af dårligt velvære (Se nedenstående 

figur). 

Figur 8 

Tøjvalget på Winston var bestemt ud fra bogens forklaringer for beklædningen af den klasse af 

mennesker, som Winston tilhørte. 

IKONER 

Når det gælder ikoner er der mange forskellige aspekter der skal betragtes, da genkendelse er vigtigt 

for brugeren, som eksempelvis en papirkurv til når man vil slette filer eller en diskette, for at illustrere 

en ”save funktion”. Dertil kan ikoner også sættes sammen så illustrationen i sig selv illustrere tydeligt, 

hvad denne hentyder til, som eksempelvis et ikon af en printer for at illustrere en udprintning af 

dokumenter. 

CURSOR 

En af de første ikoner der skulle overvejes var selve cursoren. Denne kunne se ud som den 

almindelige Windows cursor eller den kunne være specifik for spillet. I prototypen (det testede 

produkt) var det en almindelig Windows cursor der blev anvendt, men i det senere produkt, var der 

forslag som følgende. Se figuren nedenfor. 

Figur 9 

Disse er nogle forholdsvis almindelige og let genkendelige cursors, der er set før iblandt mange 

forskellige programmer og spil. Både pilene og hånden kan anvendes, da en bruger ikke vil være i tvivl 

37 of 83

om disse. Det færdige spil ville anvende hånden i midten. Dette skyldes bl.a. et senere benævnt ikon 

der illustrerer ”Pick up” funktionen. 

MENU 

Der er mange forskellige måder at lave en menu på, men det blev valgt, at menuen skulle være 

simpel, overskuelig og let at anvende. Derfor blev menuen skabt i en meget minimalistisk stil, figur 10. 

Menuen skulle indeholde nogle basale knapper; et inventory og et område med en save funktion, 

options med videre. Knapperne for de basale funktioner i spillet ses til venstre i menulinjen som 

værende Look, Use, Talk og Pick up. Til højre i Menulinjen befinder inventory’en sig, denne indeholder 

de objekter brugeren opsamler i løbet af spillet. Midten af menulinjen skulle indeholde indstillingerne 

for spillet, som save funktionen, lyd- og grafikindstillinger, hjælpefunktion osv. 

Figur 10 

LOOK 

Denne knap skulle anvendes når spilleren ville kigge nærmere på eksempelvis en plakat af Big Brother 

på væggen, en seddel på et bord eller andet. For at illustrere denne knap var blevet valgt, var det 

nødvendigt at cursoren ændrede ikon så brugeren ikke var i tvivl. Her blev følgende forslag dannet. Se 

figur 11. 

Figur 11 

Alle ikonerne skal forestille øjne, da man på den måde ikke er i tvivl om, hvilken knap der er blevet 

valgt i menulinjen. Det skal nævnes at pilen og første øje, fra venstre, skal være hos alle fire forslag. 

Dette skyldes at brugere skal vide, hvor cursoren skal placeres for at trykke på et givent objekt. Det 

første øje skulle forestille et statisk stirrende øjeæble med en pil over. Dette skulle illustrere tydeligt, 

at funktionen brugeren ville anvende var at kigge/stirre på noget, samtidigt skulle det give et indtryk 

af at blive stirret på, og dermed en følelse af overvågning. Øjet ved siden af skulle være et øje der vha. 

fire billeder skulle dreje rundt. Dette skulle give et indtryk af at kigge rundt omkring. Dette forslag 

blev dog hurtigt fravalgt, da man ofte bruger bevægende ikoner til at illustrere at computeren 

arbejder på noget man skal vente på, som eksempelvis det meget kendte timeglas i Windows. Det 

tredje øje fra venstre skulle associeres med Winstons øjne, meget trætte og udbrændte. Det fjerde og 

sidste forslag skulle forestille et øje der kniber sammen, som hvis det kigger gennem et nøglehul. 

Dette blev dog også hurtigt fravalgt, da dette kunne misforstås og man kunne tro øjet var ved at 

lukke. Derfor stod valget nu mellem det første øje fra venstre samt det tredje. Her blev det tredje 

valgt, da man på den måde associerede det mere med Winston. 

USE 

Denne funktion kunne være svær at illustrere, da mange ikoner kunne anvendes her, men for at 

brugeren skulle være sikker på denne var genkendelighedsfaktoren vigtig. Derfor blev der lavet to 

meget ens forslag til denne, som er brugt i mange andre spil før dette (Figur 12). 

38 of 83

Figur 12 

Disse forslag er begge lavet som en svensknøgle, dog med nogle meget banale forskelle. Dette ikon er 

ofte associeret med, at man som bruger foretager en fysisk handling, hvilket Use også skal illustrere. 

Det valgte forslag blev svensknøglen til højre. Dette skyldes basalt set at dette ikon fysisk lignede 

mere en rigtig svensknøgle. 

TALK 

Til denne funktion blev der skabt flere forslag. Der er på figur 13 illustreret de fire vigtigste. Det var 

her vigtigt, hvis indgangsvinklen skulle være at ikonerne var statiske, at ikonerne var meget maleriske 

og let forståelige. Derfor er billedet helt til venstre meget malerisk illustreret, som en mund der siger 

noget. Dette ses da munden er åben og med en tunge der stikker ud af munden. På det næste ses et 

billede af en frontalt åben mund, hvor princippet basalt set er det samme. Det tredje ikon er 

forskelligt fra de andre, da dette illustrerer omridset af en person og en taleboble. Dette skulle fra 

brugerens synspunkt fortælle, at der nu er mulighed for at tale med en person. Det fjerde og sidste 

ikon er en simplificering af tredje ikon, da der her ganske simpelt bare er tegnet en taleboble (Figur 

13). 

Figur 13 

Den sidste tegning med taleboblen blev valgt, da denne let kan forstås, hvis brugeren har et lille 

kendskab til diverse tegneserier, samt programmer som eksempelvis skype. 

PICK UP 

Denne funktion blev der kun lavet et enkelt forslag til. Dette skyldes at det ofte er et ikon som på figur 

14 der bliver anvendt. 

TEST 

Figur 14 

Dette billede skal forestille en hånd der samler et givent objekt op fra f.eks. et bord. 

For at evaluere produktet i overenstemmelse med projektets mål, valgte vi at udføre en high-fidelity 

test. En high fidelity test er når man tester en advanceret prototype af sit produkt. I modsætning til en 

low fidelity test, hvor prototypen kan være, f.eks. en kuglepenstegning. Fordelene ved at teste en 

prototype er, at det tager mindre tid at fremstille en prototype. En prototype, brugt til test, 

indeholder kun de egenskaber, der er nødvendige for at opnå testens mål. Derfor er den mindre 

kompleks end den endelige udgave af produktet og nemmere at ændre i. 

39 of 83

BRUGERVENLIGHED 

Vi har valgt at teste brugervenligheden af vores produkt. Derfor blev der konstrueret en prototype, 

der passer til dette formål. 

Med brugervenlighed menes her: 

• kan brugerne finde ud af at navigere rundt i spillet, 

• kan brugerne finde ud af at bruge de funktioner spillet tilbyder, 

• kan brugerne følge med i handlingen, altså hvad deres mål er, i spillet såvel som de enkelte 

scener. 

Der kunne også testes for f.eks. stemningen og spiloplevelsen af vores produkt. For at få brugeren til 

at leve sig ind i spillet, skulle prototypen have haft en stærk historie og en mere fremtræden 

interaktion med plot og karakter. Eventuelt skulle brugeren træffe flere valg, der ville have betydning 

for spillets retning. 

Denne prototype ville være vertikal. Det vil sige at den ville indeholde få funktioner og scener, men en 

dybere interaktion med de funktioner og karaktere der var implementeret. 

Test af brugervenligheden af produktet blev valgt, for at få styr på hvordan produktets brugerflade 

skulle designes. Tema rammen for projektet diktere, at der skal designes en brugergrænseflade. Så 

test af brugervenligheden af brugergrænsefladen er oplagt. Testen blev en horisontal test, hvor de 

vigtigste interaktionsformer, man kommer ud for i spillet, blev implementeret over flere scener. 

Brugeren fik ikke lov til at gå i dybden med nogle af interaktionsformerne, men fik til gengæld 

mulighed for at prøve dem alle. 

De interaktionsformer der blev implementeret i prototypen, var hvordan brugeren: 

• opfatter overgangen er fra en scene til den næste. 

• brugeren intuitivt samler objekter op. 

• bruger objekter intuitivt. 

• gøre brug af funktionen til at kikke på ting. ”Look” funktionen. 

• forstår at bruge dialogen. 

• forstår målet med spillet. 

OVERVEJELSER OG ERFARINGER 

I dette afsnit beskrives hvilke erfaringer og overvejelser testen har givet. Under testen blev der brugt 

webcam og mikrofon til at optage, hvad brugerne sagde og gav udtryk for. Programmet ”Camtasia” 

optog samtidigt hvad der foregik på skærmen. På den måde har det været muligt at gennemgå hvad 

brugerne har haft svært ved at udføre i testen, og hvilke kommentarer de har givet. Dette betyder, at 

der via videoerne kan drages flere erfaringer og overvejelser om hvad der kan ændres i produktet. I 

dette afsnit beskrives de overvejelser testen har ført til. 

40 of 83

DAGBOGEN 

Brugerens mål i første scene er at han skal ud af døren. Scenen er designet til at brugeren skal trykke 

på døren, og få at vide at man skal tage dagbogen med. 

Figur 15 

Billedet viser første scene i prototypen. Den røde ring markere et hul i væggen, hvor dagbogen ligger 

gemt. 

Efter brugeren har samlet dagbogen op skal brugeren samle resten af objekterne op før han kan 

forlade scenen. 

Der opstod problemer med at finde dagbogen, der var gemt i hullet på højre væg. Der var 

testpersoner der ikke kunne gætte, at hullet skulle bruges til noget. Intentionen var at Winston skulle 

have gemt dagbogen for kameraerne i et hul i væggen. Testpersonerne der vidste, at dagbogen var 

hemmelig, skulle regne ud at den var gemt væk. Dette problem løses nemmest ved at forbedre 

tegningen af hullet, og måske indikere på tegningen, at der ligger noget i hullet. Det er også muligt at 

fortælle brugerne, at dagbogen ligger gemt væk. 

Bogen på bordet, er newspeak ordbogen. Ordbogen bruger samme grafiske symbol som dagbogen, 

når den er samlet op. Dette betød at brugerne ikke kunne kende forskel på de to bøger, og ofte ikke 

troede, at de havde samlet dagbogen op. Det var intentionen at brugerne skulle bruge look 

funktionen og læse hvad der var hvad, men i en videre version af produktet, ville det være optimalt at 

lave et andet ikon til dagbogen. 

Figur 16 

Figuren viser Newspeak Ordbogen og Dagbogen, som de ser ud i prototypens inventory. 

Det viste sig at dagbogens tekst ikke tydeligt nok indikerede, at det var dagbogen. Kikker man på 

hullet, skulle en tekst beskrive hvad der lå. Denne tekst indikerede heller ikke tydeligt nok, at det var 

dagbogen der var tale om. 

41 of 83

Figur 17 

Figuren illustrer hvad Winston siger når man bruger ”look” funktionen på hullet i væggen. Teksten på 

billedet indikerer ikke stærkt nok at der er gemt en dagbog i hullet. 

I stedet for teksten på billedet, kunne der stå: 

”This is were I hide my diary, free thinkers aren’t well thought of.” 

Teksten skulle gerne give brugeren en fornemmelse af at det er ulovligt, og forkert at have en dagbog, 

men erfaringen viser, at der skal stå at dagbogen er der. 

OVERBLIK 

Prototypen blev designet som fem sammenhængende scener. Testpersonerne fik mundtligt at vide, 

at deres opgave var at få winston til at gå på arbejde. Det blev nedprioriteret at give testpersonen en 

tydelig forklaring på deres mål for testen. Under pilot testen blev testpersonerne meget forvirrede af 

ikke, at have et mål med testen. Derfor indførte vi en intro skærm, der kort skulle sætte 

testpersonerne ind i spillet, og forklare dem hvad deres mål i spillet var. 

Figur 18 

Intro skærmen, der sætter brugeren ind i spillet og spillets opgave markeret med rød skrift. 

I første omgang var alt teksten hvid, men det blev påpeget, at man ikke lagde mærke til selve 

opgaven, fordi den stod nederst og ikke stod ud fra det øvrige tekst. Derfor brugte vi rød tekst til at 

fremhæve selve opgaven. 

På trods af intro skærmen kunne det observeres, at testpersonerne i brugertesten havde svært ved at 

navigere rundt i scenerne. I elevator scenen vidste de ikke, at de skulle tage elevatoren. Hvis de ikke 

42 of 83

umiddelbart kunne løse gåden for at få elevatoren til at virke, blev de frustrerede. I vagt post scenen 

viste de fleste brugere, at de ikke måtte afsløre dagbogen, så de ville undgå kontakt med vagterne. 

Derfor prøvede de at finde en anden vej end gennem vagtposten, som man skulle igennem. 

Figur 19 

Winston i nederste højre hjørne af de to billeder. Karakteren vender den modsatte vej. 

En forklaring på forvirringen kan godt være, at karakteren vender den modsatte vej end man skal. Det 

ser ud til man går væk fra henholdsvis vagtposten og elevatoren. Dette bliver rettet når karakteren 

bliver animeret og bevægelig. Den hovedsagelige forklaring fra testpersonerne er, at de ikke får en 

forklaring i de enkelte scener på, hvad de skal i scenen. Ved at give dem intro skærmen giver vi dem 

et overordnet mål, fra start til slut. 

Figur 20 

De blå kasser repræsenter de enkelte scener. Den sorte pil repræsenterer opgaven fra starten af spillet 

til enden af spillet. 

Figur 21 

De blå kasser repræsenter de enkelte scener. De sorte pile repræsenterer opgaver i de enkelte scener. 

Her er der flere små opgaver. 

For at gøre spillet mere brugervenligt og forståeligt, har vi overvejet at indfører en form for dialog 

eller interaktion, der kan gøre det mere tydeligt hvad karakteren skal i hver enkelt scene. Fx kunne 

kameraet i første scene fortælle karakteren, at han skulle på arbejde nu, og at han skulle ud af 

lejligheden. Ligesom at man får at vide, at man skal tage dagbogen med, når man forlader lejligheden. 

I elevatorgangen kunne en nabo fortælle, at der var noget galt med kortlæseren. På den måde får 

brugeren hele tiden en opdatering på hvad brugeren skal i hver scene. Vist på figur 21. 

43 of 83

Scenerne skal selvfølgelig hænge sammen, derfor ville det være smart at minde brugeren om hans 

overordnede mål undervejs i spillet. Naboen i elevatorgangen i forrige eksempel, kunne for eksempel 

minde karakteren om, at han skulle på arbejde, på den måde får brugeren en helhedsfornemmelse. 

Figur 22 

De blå kasser repræsenterer de enkelte scener. De sorte pile repræsenterer opgaver over forskellig 

varighed. 

Erfaring fra denne test, viser at det vil være smart at bruge modellen, som vist på figuren ovenover, i 

det endelige produkt. 

For netop at give brugerne et overblik ind i mellem scenerne, kommer man i prototypen ind på et 

kort, der viser hvor karakteren er, og hvor karakteren skal hen. Prototypen var oprindeligt designet, så 

man kun kom ind på kortet en gang. Da karakteren skal rejse fra hjemmet til vagt posten. Kortet var 

ikke implementeret da karakteren skal rejse fra vagtposten til arbejdet, fordi brugeren havde set 

kortet en gang, og det ikke var nødvendig at vise det igen. Derfor rejste karakteren direkte fra 

vagtposten til arbejdet. Under pilottesten blev kortet implementeret, fordi det ødelagde testen, at 

brugeren ikke kunne regne ud, at han var kommet frem til arbejdspladsen. 

Figur 23 

Figuren viser kortet over spillet. Spilleren skal i prototypen fra Home, over Guard Post til Work. 

KNAPPER OG FUNKTIONER 

I spillet er der fire knapper, som hver har deres unikke egenskaber, for at interagere med de 

forskellige objekter i spillet. I prototypen virker talk knappen ikke, og pick up knappen virker kun i 

første scene. 

44 of 83

LOOK KNAPPEN 

Figur 24 

Figuren viser de fire knapper der er med i prototypen. 

Selvom de fleste testpersoner forstod ”look” knappens funktion, gik der tid før de fandt ud af, at de 

skulle trykke på ”look” knappen, hver gang de skulle bruge informationer om de forskellige objekter i 

spillet. Desuden havde de svært ved at regne ud, hvornår look knappen var aktiv. Hvis en testperson 

trykkede ”look” og derefter trykkede på et objekt, slog ”look” knappen efterfølgende fra. Flere 

testpersoner havde svært ved at regne dette ud. Der er to løsningsforslag til dette problem. ”look” 

knappen kan kodes, så den ikke slår fra, når man har brugt den en gang. Desuden kan ”look” knappen 

markeres når den er aktiv, og ydereligere vise en animation, når look cursoren er over et objekt, som 

den kan interagere med. 

USE KNAPPEN 

Testpersonerne brugte forskellige måder at interagere med ”use” knappen, for at løse en bestemt 

opgave. De forskellige måder brugeren intuitiv udnytter user interface’et på, kan fortælle noget om 

hvilken metode der er mest brugervenligt. I prototypen blev der anvendt en klassisk måde at bruge 

use knappen på. Man trykker først på ”use” knappen, derefter på objektet og til sidst hvor det skal 

bruges. 

Det viste sig at denne måde ikke er særlig intuitiv for brugerne. Dette kan skyldes at use knappen ikke 

reagere, når man trykker på den. Hvilket skabte usikkerhed hos testpersonerne. Andre testpersoner 

havde en helt anden indgangsvinkel til hvordan user interface’et skulle bruges. De fremgangsmåder 

testpersonerne viste, er ikke forkerte men opfattes som inspiration til nye måder at designe på. Af de 

fremgangsmåder der blev observeret er følgende fremgangsmåde mest interessant. 

Figur 25 

Her illustreres den fremgangsmåde hvor brugeren klikker og trækker ikonet hen hvor det skal bruges. 

Her trak testpersonerne flasken hen til det sted, hvor den skulle bruges. Denne fremgangsmåde er set 

i andre nyere spil. Det smarte ved denne fremgangsmåde er at use knappen kan undlades. Derved 

bliver der mindre at holde styr på for brugeren. I nyere spil bliver de funktioner der ellers ligger i 

knapper, ofte overført til forskellig bevægelser og brug af musen. 

Grunden til at den første fremgangsmåde blev valgt til spillet var, at det er den fremgangsmåde der 

bliver brugt i flere ældre point-and-click adventure spil, såsom ”Monkey Island 1”, og har derfor en 

bevist effektivitet. Testpersonerne der ikke opfattede den første fremgangsmåde som naturlig, har 

ikke haft stort kendskab til point-and-click adventurespil. En markering over den knap der er blevet 

valgt, ville have hjulpet testpersonerne til at finde fremgangsmåden mere naturlig. 

45 of 83

Det kunne være en fordel at lave en high-fidelity eller low-fidelity test, der specifikt afklare hvilken af 

de to måder at interagere med, målgruppen finder nemmest. 

STEMME INDTALELSE 

Spillet bygger på at brugeren får informationer ved at kikke på ting, eller bruge ting. Hvis brugeren 

ikke får disse informationer, får brugeren svært ved at spille spillet, og spil glæden forsvinder. 

Testpersonerne blev informeret mundtligt før testen om, at de skulle bruge look funktionen meget for 

at læse de informationer spillet tilbyder. Det var tydeligt under pilot testen, at testpersonerne 

ignorerede teksten så vidt muligt og nøjedes med at prøve sig frem. For at opfordre brugerne mere 

eksplicit, blev der implementeret et intro billede med tekst som på figuren nedenfor. 

Figur 26 

Viser intro skærmen der forklarer brugeren vigtigheden af at bruge ”look” knappen og andre praktiske 

oplysninger. 

Testpersonernerne i pilottesten der blev udsat for denne intro skærm reagerede ikke anderledes efter 

at have læst denne skærm. Selvom de siger de har læst og forstået den. For at lægge mere vægt på 

tekstens vigtighed, blev der efter pilottesten indtalt stemmer til alle teksterne i spillet. På den måde 

bliver brugeren mere opmærksom på, hvad der bliver sagt. I spørgeskemaet svarede 10 ud af 11 

testpersoner at det var behageligt at få læst teksten op. 

TESTPERSONERNES FORKUNDSKABER 

Test personerne blev spurgt om, hvor meget tid de bruger på at spille computer spil, samt om de 

havde prøvet point-and-click spil før. Denne information er nyttig for at se om der er sammenhæng 

mellem testpersonernes erfaringer, den tid de har brugt på at gennemføre testen og hvad de mener 

om brugervenligheden. Sammenligningen viser, at testpersoner der bruger lang tid på at spille 

computerspil, gennemføre testen 2-3 minutter hurtigere end dem der bruger lidt tid på computerspil. 

Den gennemsnitlige gennemførelsestid, for testpersoner der bruger lang tid på computerspil var 5 

minutter. De testpersoner der bruger mindre tid på computerspil brugte i gennemsnit 8 minutter på 

testen. Der var en testperson i denne gruppe, der brugte 14 minutter på testen. Dette er en stor 

afvigelse, og udelades denne tid, så brugte de kun 7 minutter i gennemsnit. Sammenligningen tyder 

på at hyppigere computerspillere nemmere kan lære at forstå layoutet. 

Layoutet i gamle point-and-click spil går igen i de fleste spil inden for genren. Dette betyder, at man 

nemt kan gå til et point-and-click spil, hvis man har prøvet layoutet før. Dette stemmer overens med 

de test tider vi har målt. Dem der har prøvet point-and-click spil var i gennemsnit 6 minutter om 

46 of 83

testen, hvorimod dem der ikke har prøvet point-and-click spil i gennemsnit var 8 minutter om testen. 

Uden afvigelsen nævnt tidligere, ligner tiderne mere hinanden. Vi vælger at inkludere denne tid, fordi 

testpersonen netop ikke har prøvet point-and-click spil. Derfor er det naturligt, at han vil have svære 

ved at forstå layoutet. Havde testpersonen prøvet point-and-click spil før, ville tiden være mere 

unaturlig. 

METODER 

High Fidelity prototypen blev testet på studerende, der ikke gik på medialogi. Kriteriet for at en 

person kunne blive test person, var at personen havde interesse for computerspil. Prototypen blev 

konstrueret til at teste for brugervenlighed. Som sidste led i konstruktionen, blev prototypen pilot 

testet på fire medialogi studerende, der som medialogi studerende har erfaring med prototyper og 

brugertest. 

PILOT TEST 

Pilot testen fulgte en simpel udgave af spiral modellen. Prototypen blev fremstillet efter krav til hvad 

der skulle testes fra produkt ideen. Prototypen blev testet af en testperson, der efterfølgende 

gennemgik prototypen sammen med testlederen, for at påpege fejl samt hvor prototypen kunne 

forbedres. Fejl og forbedringer blev dernæst rettet og implementeret. 

Pilot testen hjalp også til at klargøre hvilke spørgsmål, der var relevante at stille testpersonerne i den 

efterfølgende test. 

TESTEN 

Testen blev afsluttet med et spørgeskema. Testpersoner skulle give oplysninger omkring deres 

erfaring med computerspil, samt vurdere spillets brugervenlig. Brugervenligheden blev bedømt på en 

skala fra 1-5. Resultaterne blev analyseret ud fra, hvor lang tid de brugte på at gennemføre testen i 

forhold til, hvor erfarne de var med computerspil. Dette gav indsigt i hvorfor de svarede, som de 

gjorde. Ud fra deres besvarelser kunne videooptagelser, af de enkelte testpersoner, selektivt 

udvælges til gennemgang. 

DELKONKLUSION 

Brugertesten var effektiv til at gennemgå brugergrænsefladeelementer med testpersonerne, og sætte 

fokus på de måder brugerne interagere med systemet på. Af de erfaringer der tages med til produktet 

er blandt andet: 

• Det skal være tydeligt for brugeren hvornår han udføre en bestemt handling. 

• Brugeren skal vide hvad målet er med hver situation han står i, uden at afsløre hvordan han 

løser den. 

• Objekter i spillet skal ikke ligne hinanden og skal være tydeligt indikerede i omtale eller 

grafik, hvis de er vigtige for spillet. 

Det overordnede indtryk fra testen er at testpersonerne både kunne navigere og forstå funktionerne 

efter en tilvænningsperiode. Der var tekniske fejl, der kan udbedres, men de havde kun mindre 

indflydelse på testens resultat. Fx var der nogle klikbare områder, der ikke var store nok og ikke 

fungerede optimalt. En vigtig erfaring til produktet er, at hvis et objekt skal aktiveres for at komme ud 

af en udgang, skal man overveje om udgangen også kunne bruges til at aktivere objektet. 

47 of 83

DE BASALE FLASH FUNKTIONER 

Her omhandles de kodetekniske elementer nødvendige for at kunne lave produktet i Flash. Som det 

kan ses ud fra overskriften er det de basale funktioner der omhandles her. 

NAVIGERING 

Navigering i timelinen foregår ved hjælp af Actionscript kommandoer. For at pause en film i et 

bestemt frame, bruger man kommandoen stop() i den aktuelle keyframe. For at køre videre i filmen 

kan man tilføje en play() kommando, som f.eks. kunne bestå i et museklik. Det er også muligt at 

springe frem og tilbage i timelinen med Actionscript, dette gøres med disse kommandoer 

gotoAndPlay(frame) eller gotoAndStop(frame), hvor frame bestemmer placeringen på timelinen. 

Frame kan angives med frame nummer, og på den måde kan man hoppe fra frame 5 til frame 50 og 

omvendt. Dette er dog ikke den bedste løsning, da en enkelt ændring i timelinen kan ødelægge hele 

strukturen. Fx hvis man indsætter nye frames i timelinen vil indholdet jo blive forskubbet, og derved 

vil frame numrene ikke passe. Dette kan også blive forvirrende i længden, hvis man skal hoppe frem 

og tilbage adskillige gange. Men denne opgave kan dog blive løst med frame labels, hvilket går ud på 

at navngive de enkelte frame og derved vil man altid havne på den eksakte frame man ønsker. Derfor 

er det bedst at have en specielt layer for labels. 

Navigering af symboler sker på samme måde, som når man browser efter en fil på computeren. Alle 

stier for symboler og scener bliver defineret af deres ”instance name”. Forskellen mellem dem er, at i 

Windows bliver mapperne separeret med en backslash(\), hvorimod actionscript bruger punktum. 

Kommandoerne for stierne er this, _parent og _root. Kommandoen this gør at vi arbejder med det 

symbol hvor koden befinder sig. _parent går et niveau op – dvs. et skridt tilbage og _root betyder den 

yderste stage af den pågældende scene. Her et eksempel på et movie clips der har instance name 

box: 

this.office.box eller _root.office.box 

Begge stier er korrekte hvis office.box ligger i roden af scenen og koden er i en keyframe samme sted. 

_root kan dog skabe problemer ved brug af flere flash filer. Det bliver berørt på et senere tidspunkt. 

Hvis man har en timeline inde i movie clippet, som man gerne vil ha skal afspilles, kan kommandoen 

play() tilføjes. Man kan kombinere flere forskellige kommandoer med en sti. 

EVENT HANDLERS 

En event handler er den handling der skal fuldføres, når der udføres et bestemt ting. Det kan F.eks. 

være en knap, som skal videreføre brugeren til et bestemt frame, når der trykkes på den. Event 

handler er altså den instruktion der bliver tilføjet et symbol, som fortæller hvad den skal gøre ved et 

bestemt handling. Event handler besidder flere forskellige kommandoer f.eks. onRollOver, onPress, 

onRollout osv. Disse events aktiveres enten når musen kører over, trykker på eller kører ud, af det 

symbol man har skrevet koden til. 

VARIABLER 

Variabler bruges i næsten alle programmeringssprog. En variabel er en slags hukommelse der 

indeholder tal eller tekststrenge, som programmet gør brug af. Indholdet af variablen kan ændres 

efter behov, men dog kan den kun indeholde én værdi ad gangen. 

IF-SÆTNINGER 

If-sætning anvendes til at lave en betingelse, som skal opfyldes før det valgte handling eller program 

afvikles. F.eks. kan det bruges til et ja-nej spørgsmål. Hvis der bliver svaret ja, så skal der udføres en 

bestemt handling og hvis der bliver svaret nej så skal den ikke udføre handlingen. Men dog kan denne 

48 of 83

funktion udvides med et else kommando, hvilket vil sige, at der skal udføres en anden handling, hvis 

der bliver svaret nej. 

Der bliver brugt logiske operatorer, for at sige hvad der skal opfyldes eller ej. F.eks. kunne en logisk 

operator være ”lig med”, som bliver skrevet med dobbelt lighedstegn (==). 

LOOPS 

”For loops” er næsten det samme som en if-sætning. I modsætning til if-sætninger kører loop i ring 

indtil en givet betingelse er opfyldt. Dvs. at for hver gang betingelsen er opfyld, fortsætter den, hvis 

den ikke er opfyldt springer den videre i programmet. ”For loop” består af en tællevariabel, en 

betingelse og en opdatering. 

FUNKTIONER 

Funktioner er et stykke indrammet kode, som kun køres når den bliver kaldt. Dvs. at et bestemt kode 

kan genbruges så ofte man vil, uden at skrive det igen og igen. Med kommandoen setInterval kan 

man få funktionen til at køre igen og igen i et prædefineret interval. 

XML NAVIGATION I ACTIONSCRIPT 

I dette afsnit vil der blive gået igennem hvorledes Actionscript bruges til at navigere i XML arks 

forskellige nodes og undernodes eller childnodes, i en Flash applikation. Afsnittet er inspireret af Jesse 

Stratfords artikel XML 101( http://www.actionscript.org/resources/articles/9/2/XML-101/Page2.html, 

2007) 

For bedst muligt at forklare hvorledes navigationen af et XML ark fungere, tages der udgangspunkt i 

et eksempel: 

 

4815162342 

Commando 

Action 

 

Arnold Schwarzenegger 

 

4 October 1985 

FilmSelskab AS 

 

Det her er et eksempel på hvordan information om en film kunne være gemt i et XML ark, der skal 

bruges til at læse det nødvendige data ind i applikation. Her kan man se et XML arks hierarkiske 

struktur, hvor vi har rodnoden øverst, der indeholder alle de andre nodes, så som løbenummer, 

filmnavn, etc. Disse under nodes, bliver generelt refferet til som nodens børn, eller children, når man 

snakker om XML. Yderligere er det vigtigt at bemærke at skuespillere noden, har sin egen under node, 

skuespiller, hvori navnene på forskellige medvirkende skuespillere står i hver sin node. 

Denne node er grandchild til details noden. 

49 of 83

Figur 27 

Stamtræmodel for nodes i XML ark: 

Her ses det, at skuespiller er barn af skuespillere og barnebarn til root noden details. 

Som førnævnt, er XML hierarkisk, så for at få adgang til information lagret dybt nede i et XML ark, 

som for at tage det førnævnte eksempel i brug, for at finde information om en skuespiller der 

medvirker i denne film, skal vi først bevæge os ned igennem root noden, så videre ned igennem den 

passende childnode, og så videre igennem dennes child, altså barnebarnet, og udvinde 

informationen. Dette kaldes parsing eller analysering. 

denne kode registrerer hvorvidt film_xml er blevet loadet, og I så fald, køre funktionen processFilm, 

som skriver indholdet til til flash’s debugger. 

Alle manipulationer af XML objektet bliver lavet ved hjælp af processFilm funktionen, som accepterer 

referencer til XML objekter. Referencen bliver brugt, i stedet for at køre et check på film_xml, for at 

gøre scriptet mere fleksibelt, således at funktionen kan bruges igen, hvis der på et senere tidspunkt 

ønskes indlæst et andet XML ark. 

Som nævnt tidligere, var målet at lave en flash applikation der kunne vise informationer om film ud 

fra data lagret i et XML ark. Det første der ønskes fremvist i applikationen er filmens løbenummer, 

som er givet under løbenummer noden. 

50 of 83

Figur 28 

Beskrivelse af navigation i et XML ark 

Nå der refereres til nodes inde i et XML ark, er der en virtuel markør som holder styr på hvor man 

befinder sig i det hierarkiske XML ark. Som det ses i det første billede i figuren ovenover, befinder den 

virtuelle markør sig først øverst i XML dokumentet, her er det vigtigt at bemærke at det ikke er den 

første node der er markeret. 

Details er den første node i XML arket. For at få den virtuelle markør til at bevæge sig ned til denne 

node og vise denne, skriver vi følgende kode: 

trace(xmlDoc_xml.firstChild); 

Det er det som er illustreret i billede 2 i figur 28 

For at få markøren til at bevæge sig yderligere ned igennem træet, er det nødvendigt med yderligere 

kode: 

trace(xmlDoc_xml.firstChild.firstChild); 

Her er det vigtigt at bemærke, at det som er markeret i XML arket, nu er løbenummer tag’et, figur 28 

billede 3. Ikke dens value, altså selve indholdet af taget. For at få adgang til selve indholdet af tag’et, 

er det nødvendigt med et yderlige kald, figur 28 billede 4: 

trace(xmlDoc_xml.firstChild.firstChild.firstChild); 

Selvom denne kode I vores tilfælde giver os det ønskede output, er det nødvendig med yderlige kode 

for at sikre sig man får det ønskede output: 

51 of 83

trace(xmlDoc_xml.firstChild.firstChild.firstChild.nodeValue); 

Grunden til at man bruger .nodeValue egenskaben, er at det sikre os at vores output bliver vist 

korrekt. Med denne egenskab tilføjet, vil f.eks. tekststrenge i outputtet, indeholdende f.eks. en HTML 

entitet som ”&amp” blive vist korrekt som et ”&” tegn. 

Hvis man derimod vil have vist film titlen, som er repræsenteret ved noden filmnavn, som er det 

andet barn af details noden, kan det gøres ved en lignende tilgang, hvor man lige som før bevæger sig 

ned på løbenummernode niveauet, og derefter spørger efter nextSibling, som kører vores virtuelle 

markør videre til næste node på samme niveau, som i det her tilfælde er filnavn noden. 

trace(xmlDoc_xml.firstChild.firstChild.nextSibling.firstChild.nodeVal 

ue); 

Figur 29 

Yderligere navigation i et XML ark 

Først kaldes firstChild to gange, figur 29 billede 1 og 2. Man kommer først ned til details noden, og så 

videre ned til løbenummer noden, herfra køres nextSibling, figur 29 billede 3. Herefter forsættes 

videre til film noden, herefter køres firstchild, som sætter os inde i filmnavn noden og så endelig, 

kalder vi nodeValue, som giver os selve filmnavnet figur 29 billede 4. 

52 of 83

SPILMOTOR 

I dette kapitel beskrives hvordan spillet programmeringsmæssigt struktureres. Spillet laves med en 

spilmotor, opdelt i flere moduler. Nogle af modulerne bliver i kapitlets underafsnit beskrevet med 

kode, som et eksempel på hvordan det kan programmeres. At spillet er bygget op omkring en 

spilmotor, betyder at en ramme af kode styre hele spillet. Prototypen af spillet blev lavet uden en 

spilmotor, hvilket betyder at der skal ny kode ind i hver scene. Prototypen, bruger nogle globale 

funktioner og variabler der kan kaldes fra alle scener, men hvert symbol der har kode, er 

programmeret i den scene hvor symbolet optræder første gang. 

Figur 30 

Figuren til venstre viser hvordan spilmotoren er kodet, figuren til højre hvordan prototypen er 

kodet.Man kan se at der er kode i hver scene, i prototypen. Hvor koden er samlet i spilmotoren. 

Der er fordele ved den måde prototypen er kodet på. Det er hurtigere at programmere få scener, ved 

at lægge kode ind i hver enkelt scene, end det er at lave en spilmotor. I prototypen ligger koden for 

hvordan hver enkelt genstand interagere, i genstandens movieclip. Det gør det nemt at overskue 

koden i en scene, fordi den ligger hvor den skal bruges. Ulempen er at når koden skal referere til kode 

et andet sted, bliver det svært at overskue hvordan koden i en scene hænger sammen. Flere instanser 

af et symbol deler samme kode. Skal man personligøre et instans af et symbol bliver man derfor nød 

til at lave et nyt symbol. Det kan blive meget svært at debugge kode, når to movieclips har næsten 

identisk kode men med små ændringer. I prototypen er der seks scener, men i spillet kan der nemt 

være over 40 scener og så bliver koden meget svær at overskue, hvis den ikke er samlet på et sted. 

Derfor bliver spillet bygget op omkring en spilmotor. 

SPILMOTORENS STRUKTUR 

Figur 31 

Her ses et overblik over spilmotorens moduler. 

Spilmotorens struktur virker umiddelbart kompleks. Derfor er den delt op i mindre moduler, der 

behandler hvert sit område af spillet. Når spillet startes hentes spilmotoren som det første, herefter 

kaldes modulerne som der bliver brug for dem. Der er derfor ingen specifik rækkefølge efter hvilken 

modulerne bliver brugt eller hentet. I det følgende beskrives modulernes struktur i forhold til den 

overordnede struktur. 

53 of 83

Spilmotorens primære ide er, at man skal kunne lægge nye scener til spillet eller ændre i scener, så let 

som muligt. Spillets motor bruger én flash fil per scene. Flash filerne hentes af spilmotoren når de skal 

bruges. På denne måde er det nemt at lave flere scener og tilføje dem til spillet. Til hver flash fil hører 

et XML ark med data der skal lægges til objekterne i scenen. Det kunne f.eks. være en beskrivelse af 

et objekt som karakteren skal kunne se. Den data ligger i scenens XML ark og kan nemt redigeres med 

programmer som Microsoft Excel. 

XML 

Spillet laves som en kombination af .swf og .xml filer fordi det giver et godt overblik over scenerne. 

Overblikket gør det nemmere, hurtigere og mere fleksibelt, at tilføje og ændre indhold til spillet. .swf 

filerne indeholder det grafiske indhold i scenen. Alle movieclips har instance navne der gør dem 

identificerbare for spilmotoren. .xml filerne indeholder det tilsvarende data, til .swf filerne, så som 

replikker knyttet til visse objekter, flag og andet. Dette vil blive beskrevet yderligere i senere afsnit. 

Det vil være vanskeligere at tilføje scener ved rent XML, da der skal tilføjes data som x og y 

koordinater og linkage navne til XML arkene. Et linkage navn gør det muligt for Actionscript koden at 

hente et bestemt symbol fra library. Rent XML vil have den fordel, at der er færre løse filer per scene. 

Prisen for dette, er at alt grafik skal tilføjes hoved FLA filen, hvilket giver et meget tungt spil. Der vil 

stadig være et overblik over scenerne, fordi hver scene er beskrevet i et XML ark, dog er der ikke den 

samme fleksibilitet. Da grafikken skal tilføjes en FLA fil, som flere designere ikke kan ændre i på 

samme tid. Dette er modstridende med målsætningen for vores spilmotor men en alternativ løsning 

hvis det viser sig at SWF fil metoden ikke slår til. 

Et scene-XML ark er bygget op af en rootnode og under den, ligger item noder. Der ligger en item 

node for hvert objekt i scenen. Hver item node indeholder de egenskaber objektet skal have. 

Koden øverst i XML arket i rootnoden TEST, fortæller at den skal bruge et XMLSchema. Det er en 

måde at kortlægge XML noderne på. Det betyder at andre programmer, som f.eks. Microsoft Excell 

ved hvordan den skal fremstille dataen. Fordellen ved at basere spilmotoren på XML, er at det er 

nemt at redigere data i et Excell ark, hvilket passer ind med målsætningen for spilmotoren. Se figur 32 

54 of 83

Figur 32 

Eksempel på XML ark sat op i Microsoft Excell. 

På billedet er illustreret en måde at sætte dataen op på i XML arket. Det er muligt at der er bedre 

schemes, dvs. måder at kortlægge XML arket på. Fx kan man samle alle replikker under en Replik 

node, som igen høre under en item node. Det er noget der skal tages op til overvejelse efter 

yderligere undersøgelse. 

Når en ny scene skal laves, bygger man scenen op i Flash, og gemmer .swf filen. De replikker der 

tilhører objekter i scenen, eller anden data der er nødvendig, skrives ind i en .xml fil. Stierne til filerne 

skrives ind i XML arket stages.xml under scenens navn. 

For at inkorporere en scene i spillet skal den refereres til fra andre scener i spillet. En udgang på en 

scene, repræsenteres af et objekt i scenen. I scenens XML ark under objektets data, skrives navnet på 

den scene den skal refereres til. Til at administrere sceneskift bruges modulet Stage Master. 

STAGE MASTER MODULET 

Figur 33 

Stage Master modulet henter stien til scenens .swf og .xml fra stages.xml og sender stierne til 

BuildStage modulet. Filerne .swf og .xml behøves ikke være navngivet efter scenens navn, så længe 

stien er registreret I stages.xml. 

Stage Master modulet indlæser ved starten af spillet stages.xml. Ved sceneskift søges stages.xml for 

navnet på den scene den skal skifte til. Stage Master modulet har to underfunktioner, ClearStage og 

BuildStage. ClearStage ryder stagen for hvad der ligger i forvejen, og BuildStage bygger de nye scener 

op. Stierne til .swf og .xml filerne sendes viddere til BuildStage funktionen, der fortolker XML arket og 

lægger dataen til de tilsvarende movieclips i scenen. BuildStage bruger custom class’en Item.as til at 

lægge movieclips og dataen sammen. 

55 of 83

StageMaster modulet sørger for at der bliver aktiveret funktioner der er nødvendige for at sætte en 

scene igang. Fx aktivere StageMaster modulet en funktion hos lydmodulet der henter stien til 

baggrundsmusikken. 

INVENTORY MODULET 

Figur 34 

Beskrivelse af Inventory modulet. 

Inventory modulet opbevare data der definerer de objekter der bliver samlet op i spillet. Inventory 

Modulet har et Inventory Object. Inventory Object’et har et antal Slot arrays. Et Slot array for hver 

inventory plads i spillet. Når et objekt bliver samlet op, bliver objektets data samlet i et Slot array. 

Et array i inventory modulet, kaldet isFree, opbevare information om hvilke Inventory Slots der er 

tomme og hvilke der er optaget. Arrayet kan også bruges til at opbevare andre informationer. Så som 

inventory pladsernes fysiske placering. isFree arrayet kan også bruges som et flag array. Arrayet vil 

indeholde tekst strenge der virker som flag. Hvis der opstår en situation i spillet hvor spilleren kun kan 

få adgang, hvis han har et bestemt objekt på sig, bliver isFree arrayet tjekket for om det indeholder 

det respektive flag. 

Inventory modulet har en række funktioner til at bestyre de forskellige arrays. De bliver beskrevet 

her: 

GET/ SET SLOT ARRAY 

Dette er to funktioner, en setter og en getter funktion. Setter funktionens opgave er at omdanne et 

objekt af item.as classen til et array, og placere det i et Slot array. Funktionen tager et tager et 

instance name og et slot nummer som parametre. Getter funktionen tager et slot nummer som 

parameter, og returnere et array. 

GET SLOT DATA 

Denne funktion henter specifik data fra et slot array. Hvordan funktionen skal opbygges afhænger lidt 

af hvordan Item.as class’en bliver skrevet. Specifik data der skal hentes fra et slot array, kan f.eks. 

være replikker der beskriver et item. 

GET/SET ISFREE ARRAY 

Set funktionen til isFreeArrayet tildeler værdier til arrayet, hvor Get funktionen returnere specifik 

data fra arrayet. 

56 of 83

PLACE IT FUNCTION 

Denne funktion placerer et objekt i inventory’et. Den returnerer en boolean værdi, der fortæller om 

objektet blev placeret. Bliver objektet ikke placeret returnerer funktionen false. Funktionen tager et 

Slot nummer som parameter. Funktionen bruger Get isFree Array funktionen til at tjekke om Slot 

pladsen er fri. Er pladsen fri, bruger funktionen Set Slot Array funktionen til at placere objektet. 

Dernæst bruger den Set isFree Array funktionen til markere at Slot pladsen er optaget. Er slot pladsen 

optaget, er der to alternativer. Enten skal funktionen finde næste ledige Slot. Ellers skal funktionen 

bytte objektet med det der ligger i forvejen. 

CHARACTER SHEET 

Figur 35 

Her ses Character Sheet modulet. Modulet har en save og en load funktion der komprimere spillets 

arrays, mm. 

Character Sheet modulet er nødvendigt for at spilmotoren ved hvorlangtspilleren er kommet i spillet. 

Hvis spilleren har klaret en opgave i spillet markeres dette i Character Sheet modulets Flag Array. Så 

kan spilmotoren checke Flag Arrayet for markeringen, hvis spilleren kommer til et sted i spillet hvor 

det er nødvendigt at vide om spilleren har klaret den specifikke opgave. I Act Flag Arrayet markeres 

det når spilleren har gennemført en bestemt portion af spillet. Flag Arrayet tømmes og en markering 

bliver sat i Act Flag Arrayet i stedet for. De to arrays har tilsvarende getter, setter og checker 

funktioner. Checker funktionerne søger det respektive array igennem for et bestemt flag. 

Character Sheet modulet har en save og en load funktion. De arrays der nødvendige for at 

spilmotoren kan genoptage spillet bliver behandlet af funktionerne samt navnet på den scene 

karakteren befinder sig i. Save funktionen komprimer informationerne og load funktionen nustiller 

alle arrays og dekomprimerer informationerne. Informationen kan komprimeres som array, som 

objekt eller som XML ark. Load funktionen sender desuden navnet på den scene der blev gemt, til 

StageMaster Modulet. 

Når informationen er komprimeret bliver den gemt på brugerens computer. Enten som shared objekt 

eller som XML ark. Hvis dataen skal gemmes som XML ark, kræver det at spillet er installeret på 

57 of 83

ugerens harddisk og XML arket gemmes lokalt, for ikke at overbelaste serveren. Som shared objekt 

kan det gemmes lokalt, uanset om det spilles fra nettet eller fra brugerens harddisk. 

LYD MODULET 

Dette modul indeholder lyd objekter der styre lyden for, lyd effekter, baggrundsmusik og tale. Lyd 

objekterne ligger i hvert sit movieclip så det er muligt at styre dem individuelt. I _root timeline ligger 

et master lyd objekt der kan manipulere alt lyd i spillet på samme tid. Lyd modulet har funktioner til 

at afspille lyd. 

Lyden til spillet bliver streamet. Det gør den fordi at hvis man skal kunne tilføje scener med lyd skal 

man også kunne tilføje lyden uden at redigere i hoved .fla filen. 

Når en afspilnings funktion bliver kaldt modtager den stien til lydfilen som parameter. 

Lyd modulet har desuden funktioner til at hente stier til baggrundsmusik og effekter fra objekterne i 

scenen. 

DIALOG MODULET 

Figur 36 

Figuren illustrerer hvilken struktur der bliver brugt, når Dialog modulet skal hente replikker og tale. 

Dialog modulet består af en tekst og en tale funktion. Dialog modulet bliver kaldt hvis spilleren f.eks. 

bruger spillets ”look” funktion på et item objekt i spillet. Dialog modulet har to funktioner til at 

håndtere dette. Tekst funktionen henter den replik der skal skrives på skærmen. Dernæst laver den 

en tekstbox og viser teksten. Teksten forsvinder efter en tidsperiode, reguleret af en global variabel 

der kan indstilles i menu modulet. Tekst funktionen henter teksten fra item objektets Data array der 

indeholder replikker. Skal der skal føres en længere samtale er der mulighed for at skrive replikkerne 

ind i et XML ark. 

Tale funktionen henter stien til den lyd der skal afspilles til replikken. I item objektet kan lydstien ligge 

i samme objekt i Data arrayet som replikken. I XML arket kan lyden ligge som en attribute til Svar 

noden. 

MOUSE/CONTROL FUNCTIONS 

Spillet styres med musen, derfor er kontrol og styre funktionerne bundet til musen. Styringen foregår 

ved hjælp af en global variabel kaldet ”actions” der bestemmer hvilken handling der skal ske. Spillet 

har nogle knapper i brugergrænsefladen der bestmmer hvad actions variablen skal være. 

58 of 83

Alle item objekterne har en .onRelease funktion, som kalder Mouse Funktions modulet. Mouse 

Funktions modulet handler ud fra hvad actions variablen er sat til. 

Figur 37 

Figuren illustrerer hvordan brugerfladens knapper til venstre, sætter variablen Actions, når de bliver 

klikket på. Når der klikkes på et objekt på scenen kontaktets Mouse Funktion’s modulet,der bruger 

variablen Actions, til at bestemme hvilken handling, der skal udføres. 

Mouse Funktion switch’en har flere Actions at vælge imellem end knapperne i brugerfladen kan 

instille. Det hænger sammen med at knapper som Pick up skal bruge mere end en action. Hvis 

spilleren trykker Pick Up, ændres Action til ”PickUp”. Når spilleren trykker på et objekt kalds Mouse 

Funktion modulet og switchen vælger PickUp. Hvis det spilleren klikkede på kan samles op sættes 

Actions til ”Place”. Når brugeren klikker for at placere objektet kaldes Mouse Funktion igen, men nu 

med ”Place” som Actions, hvis det er muligt at placere objektet hvor der klikkes sættes Actions til ””, 

en tom streng. Hvis det ikke er muligt at samle objektet op eller placere det, forbliver Actions hvad 

den i forvejen var, så brugeren ikke skal trykke flere gange på PickUp knappen. Det er en erfaring lært 

fra prototype testen. 

Figur 38 

Figuren viser hvilken handling der sker når Actions er sat til PickUp. Der illustreres hvordan Place er en 

handling der bliver sat gennem PickUp handlingen. 

Change Cursor er en funktion der ændre musens cursor i forhold til den handling man foretager sig. 

Den vil blive gennemgået i et senere afsnit. 

59 of 83

MOVEMENT 

I spillet bevæger man sig ved hjælp at Movement modulet. Movement modulet virker på 

.onMouseUp. Det vil sige at hver gang man klikker med musen bevæger karakteren sig. Dog bevæger 

karakteren sig ikke når der klikkes i grænsefladen eller i Menu modulet. Spillet skal gerne 

programmeres således at hvis der klikkes på et objekt går karakteren hen til objektet før karaktere 

interagere med objektet og Mouse Funktion modulet træder i kraft. 

Flere måder at programmere Movement modulet på, vil blive diskuteret i et senere afsnit. Nogle af de 

metoder indvolvere at Movement modulet modtager data fra scenens XML ark. Det vil ske når 

StageMaster Modulet bygger scenen. 

DIVERSE SPILMOTOR OVERVEJELSER 

I dette kapittel beskrives diverse dele og overvejelser omkring spilmotoren . 

USER INTERFACE - UI 

UI’en er den overflade i spillet, som spilleren bruger til at interagere med spilverdenen. Knapper som 

Pick Up og Look reagere på .onRelease metoden. Knapperne styre variablen Actions som beskrevet i 

Mouse/Control Functions afsnittet. 

Da UI’en skal kunne nås fra samtlige scener, lægger spilmotoren op til at UI’en skal være en del af 

motoren. Dog består UI af grafik og knapper, der behandles på en anden måde en alle andre scener. 

UI’en skal kunne nås fra samtlige scener men der er ingen grund til at lave et UI i hver scene. Derfor 

må det overvejes om man med fordel kan placere UI, inklussiv kode, i en .swf fil for sig selv. Stage 

Master modulet vil hente UI filen ind efter hver scene er hentet. 

MENU OG OPTIONS 

Figur 39 

Figuren viser menuens struktur. 

User Interfaced indeholder en menu for spillet. Menuen kommer til at bestå af fem knapper; New, 

Load, Save, Options, Quit. New knappen referere navnet på første scene til StageMasteren, og 

nulstiller alle arrays i Character Sheet og Inventory modulerne. Load knappen aktivere load 

funktionen fra Character Sheet modulet til at hente den nye scene frem. Save knappen aktivere save 

funktionen fra Character Sheet modulet. Quit knappen kalder Confirm Quit funktionen i menu 

modulet. Funktionen spørg brugeren om han er sikker på at han vil forlade spillet. 

Options knappen har egenskaber som: 

Teksthastighed, lydstyrke, for tale, bagrundsmusiik og effekter, og hovedlydstyrke. 

Disse egenskaber referere til styrende globale variabler, som lyd og dialog er afhængig af. 

60 of 83

FIL STRUKTUR 

Spillet bruger fire slags filtyper: .swf, .xml, .mp3 og .as. Fordi man nemt skal kunne tillægge og 

redigere scener kræves det at filerne er godt organiseret. Spilmotoren giver mulighed for at tilføje et 

udefinerbart antal scener. Derfor er det meget upraktisk at placere alle filerne i samme mappe. Det er 

ikke nemt at finde rundt i en mappe med mange filer. Der kan desuden opstå problemer hvis der 

laves to scener med samme navn eller to lydfiler med samme navn. Det kan være praktisk at fordele 

filerne således at alle filerne fra en scene, samles i en scene mappe. Hoved .fla eller .exe filen, samt 

.as og hoved .xml filen samles i stam mappen. 

Figur 40 

Figuren viser hvorledes filerne bliver placereret i stam mappen. Billedet til venstre viser scene filerne 

opdelt i scene mapper. På det miderste billede er lydfilerne arrangeret i en mappe for sig i hver scene. 

På billedet til højre er scenemapperne placeret i en overordnet scene mappe. 

På den måde kan man nemt finde filerne, og hvis to lydfiler fra to scener bliver kaldt det samme 

overskriver de ikke hinanden. Det er imidlertid en fordel at organisere scene mapperne i én scene 

mappe, så stam mappen ikke bliver rodet. 

I prototypen blev filerne organiseret sådan at alle lydfilerne lå i en mappe for sig selv. Det var en 

fordel fordi at nogle lydfiler kunne genbruges i spillet til forskellige scener. Resten af filerne blev 

placeret i stam mappen. Årsagen til at lydfilerne blev placeret for sig, var at stam mappen blev 

uoverskuelig med alle lydfilerne. 

Denne erfaring kan drages med til produktet, men hvis filerne placeres i scene mapper er det 

ummidelbart svært at genbruge filerne. Derfor er det en mulighed at oprette en standard lyd mappe 

til de effekter og lyde der skal genbruges meget. 

Når spilmotoren refere til lydfilerne behøves den kun stien /scener/sceneNavn/lyd/mySound.mp3 

hvis stam mappen, hvor hovedfilen er placeret, er c:/1984/. Fordi mapperne /scener/ og /lyd/ ikke 

skifter navn kan de hardcodes ind i spilmotoren. I så fald skal sceneNavn skrives ind i XML arket 

ligesom mySound.mp3. SceneNavnet skal kun skrives ind en gang pr scene-XML. Placeres alle 

scenens filer direkte i scene mappen kan man vælge at skrive sceneNavn og mySound i samme streng 

i XML arket. /sceneNavn/mySound.mp3. Det kræver mindre programmering, men tilgengæld er der 

større risiko for at skrive fejl. 

PRELOADER OG MOVIECLIP LOADER 

Ved at dele filerne op og have en ”main frame” hvor alle scener bliver loadet ind efterhånden som de 

bliver nødvendige, deles den samlede loadtid op. Brugeren vil kunne begynde spillet umiddelbart med 

det samme, men skal vente kort på sceneskift. Dette kan f.eks. gøres ved en swf fil der indeholder en 

preloader til brug ved sceneskift. Preloader swf filen hentes af en movieclip loader funktion, før 

61 of 83

movieclip loader funktionen henter den scene der skal skiftes til. Preloader swf filen skal fylde så lidt 

som muligt for at sikkre at der ikke er load tider uden preloader. 

Da hver scene-swf fil kun har en begrænset størrelse, sandsynligvis under 1Mb hver, vil det ikke tage 

lang tid at loade, med en standard Internetforbindelse i dag. Derfor kan det i visse situationer vise sig 

at være en ulempe at have en preloader mellem scenerne. Spillet skal dog kunne håndtere situationer 

hvor spillere har langsomme forbindelser. Bliver spillet downloadet til computeren og spillet lokalt, er 

det unødvendigt med en preloader. En overvejelse er at programmere motoren således at hvis den 

spilles lokalt vil den springe preloaderen over. Movieclip loaderen er den funktion i vores motor der 

står for at hente .swf filer til spilmotoren. Funktionen bliver kaldt af StageMaster modulet, med stien 

til .swf filen som parameter. 

KODEEKSEMPEL 

Her følger et eksempel på hvordan en movieclip loader kan kodes: 

Scriptet starter med at lave to nye variabler: mcLoader og mcObject. mcLoader er en instans af 

moviecliploader klassen, som bruges til at overvåge hvorledes indlæsningen af et movieclip 

fremskrider. mcObject er det object der bruges til at registrere forskellige event handlers fra 

mcLoader. En af disse ses her i koden ovenover, .onLoadProgress. Denne event listener holder styr på 

hvor meget af et givent movieklip der er indlæst. Funktionen henter dataene fra moviecliploaderen, 

som har de givne parameter til at beskrive hvor mange bytes af movieclippet der er blevet hentet, og 

hvor mange bytes der er i alt. Math metoden .round på parameterne loadedBytes og totalBytes 

bruges for at runde talene op, og derefter gange det med 100 for at få statusen for indlæsningen vist i 

procent. Herefter skrives det over i vores loader tekstfield. 

onLoadInit event listerneren holder styr på hvorvidt, den givne fil der er i færd med at blive indlæst er 

færdig og eksekveret. Denne eventlistiner er bedere at bruge, i dette tilfælde, end .onLoadComplete, 

da denne registrere hvor vidt alle bytes er blevet indlæst, men ikke om om den første frame er 

eksekveret. 

Her bliver addlistner metoden brugt til registrere objektet mcObject til at blive notificeret når en 

moviecliploader eventhandler er blevet påkaldt. 

62 of 83

mcLoader.loadclip fortæller hvilket moveclip, swf, etc. fil der skal indlæses. Paramterene bestemmer 

hvilken sti filen skal hentes fra og hvor den skal indlæses i den nuværende SWF fil. I eksemplet oven 

over er det main.swf fra den stam mappen, og den skal indlæses i holder objektet. 

ITEM.AS 

Spilmotorens grundlæggende fundament er, at den henter .swf filer med movieclips, og bitmaps og 

sætter det sammen med data fra et XML ark. Data’en og movieclipene bliver samlet med en custom 

class kaldet Item.as. Et Item.as objekt har følgende struktur. 

Figur 41 

Figuren viser strukturen for et Item class objekt. Item class’en er en custom class. 

Item objektet har et movieclip, fra .swf filen, et array til dialog og et array til de flag objektet skal 

kunne sætte. Desuden har item objektet en boolean value kaldt, canPickUp. Den bestemmer om det 

er muligt at samle objektet op. For at interagere med item objekter, har movieclippet en .onRelease 

funktion der kontakter Mouse Funktions modulet. Alle animationer og alt grafik ligger i movieclippets 

timeline. Dialog og flag bliver tildelt fra et XML ark. 

Item classen har en constructor der sorterer værdierne fra XML arket eller arrayet det modtager som 

parameter. Nogle af værdierne bruger constructoren til at finde ud af hvordan den skal bygge 

objektet, andre værdier bliver tilføjet til Flag og Dialog arraysne. 

Constructoren bruger check funktioner fra Inventory og Character Sheet modulernes arrays for at se 

om de indeholder flag den skal tage højde for. Det være at spilleren har gennemført en mission der 

ændre movieclippets grafik. Den mission har efterladt et flag i Character Sheet modulet. Når 

constructoren finder flaget ændre den movieclippets timeline til den relavante frame hvor grafikken 

ligger. 

Constructoren skal tage højde for at et af de arrays eller XML ark den får fra Stage Masteren, 

indeholder data omkring scenen, denne data bliver kædet sammen med baggrundsbilledet, i et 

specielt item objekt 

MODULER I DETALJER 

I dette afsnit beskrives udvalgte moduler i flere detaljer. Desuden vil der være eksempler på hvordan 

det kan udføres i kode. 

MOUSE/ CONTROL FUNCTIONS 

Her beskrives et eksempel på hvordan koden til Change Cursor funktionen fra Mouse/Control 

Function modulet virker. 

63 of 83

De tre funktioner ovenover ændrer variablen ”action” når de forskellige brugeroverfladeknapper 

(look, Pick Up, Use) bliver trykket på. Denne variable bruger vi senere hen, så vi ved hvilken 

interaktions mulighed spilleren ønsker. 

Her introduceres først en ny string, som bruges til at fortælle hvilket item spilleren har valgt. 

Funktionen cursor1.onMouseMove bliver brugt til at bestemme hvordan musen skal blive 

repræsenteret i spillet. Vi starter med at hvis konditionen ”currentitemselected” er lig none og 

variablen action er lig standard, er opfyldt skal movieclippet cursor1’s position på x- og y-aksen sættes 

lig musens. Dette giver den illusion at movieclippet er musen. cursor1.gotoAndPlay(2) sikre sig at 

den rette animation spiller, I det her tilfælde vores mus’ standard animation. updateAfterEvent 

funktionen bliver kørt bagefter, hvilket gør at hele funktionen ikke kun bliver opdateret i slutning af 

framen, men lige bagefter funktionen er kørt, hvilket medfører at musen for en mere flydende 

bevægelse. Herefter, hvis disse konditioner ikke er opfyldt, bliver der igen kørt et check på begge 

variabler, for at se om brugeren har aktiveret pick-up funktionen. Denne funktion er stort set den 

samme, dog med den forskel at vores mus-movieclip af spiller en anden funktion. Den sidste del af 

funktionen der er illustreret oven over, kontrollere om et bestemt item i spilverdenen netop er blevet 

samlet op, og herefter udskifter musen med en grafisk repræsentation af dette. 

64 of 83

STAGEMASTER 

Stage Masteren modulet er afhængig BuildStage funktionen til at bygge de enkelte scener op ved 

hjælp af Item classen. I det følgende afsnit beskrives hvordan BuildStage funktionen kan konstrueres. 

Slutteligt kommer et kodet eksempel på hvordan StageMaster modulet kan kodes. Det er et 

simplificeret eksempel der indeholder de de vigtigste features fra StageMaster modulet. 

BUILDSTAGE 

Der er to måder at BuildStage funktionen kan fortolke data’en fra XML arket på. BuildStage 

funktionen kan enten: 

Fortolke XML ark ved at oprette et array for hvert objekt beskrevet i XML arket, og sortere dataen fra 

hvert objekt til det respektive array. 

Eller: 

Fortolke XML ark ved at oprette et nyt XML ark for hvert objekt. 

Arrayet eller XML arket kan sendes som parameter til constructoren fra Item.as class’en, der bygger 

objektet. 

Ved array fremgangsmåden kan Item class’en ikke skælne mellem dataen. Det betyder at rækkefølgen 

på egenskaberne i XML arket skal være den samme i alle XML ark. Når item constructoren skal 

oprette objektet, tillægger den én værdi fra arrayet ad gangen, til det nye objekt. 

Figur 42 

Der illustreres en item node stillet op i Excell. Item objektets egenskaber er repræsenteret vandret. 

I dette eksempel får Item class’en et array der ser sådan ud: 

myArray:Array = [”Door”,”door1”,”Door”, 120, 120, undefined, undefined, undefined, ”Hallway”]; 

Item class’en tillægger først objektet en Name egenskab, og her vælges konsekvent myArray[0] 

værdien, derefter en ID egenskab som er myArray[1], osv. Item class’en kan ved hjælp af en if else 

sætning sortere de egenskaber fra, der indeholder værdien ”undefined”. 

Ved XML ark metoden kan item constructoren søge efter de egenskaber den skal bruge.Det betyder 

at rækkefølgen af egenskaber fra scene-XML til scene-XML er ligegyldig. Item class constructoren, 

tjekker længden af XML arket ved at bruge koden: 

var myLength:Number = myXML.firstChild.childNodes.length; 

Længden er ensbetydende med antallet af egenskaber item constructoren skal lægge til objektet. 

Item contructoren søger XML arket igennem for kendte egenskaber. Følger vi ovenstående eksempel 

vil de kendte egenskaber være NAME, ID, Instance Name, XCORD, YCORD. Dernæst vil den søge efter 

egenskaber med varierende antal. item objektet har f.eks. et dialog array med replikker, der kan blive 

sagt i spillet. Forskellige items, har forskelligt antal replikker. I ovenstående eksempel er der et 

varieret antal af ”Data”. Constructoren vil bruge en for løkke, til at søge efter egenskaben Data+n. I 

hver iteration vil loopet lægge en til n. I dette eksempel skulle den første Data egenskab hedde Data1, 

istedet for Data. Når contructoren ikke længere kan finde egenskaben, vil den gå viddere til næste 

egenskab. 

For hver egenskab den finder trækker constructoren en fra antallet af items den skal finde. På den 

måde ved constructoren hvornår den skal stoppe med at lede efter egenskaber. 

65 of 83

Af de to metoder beskrevet ovenfor, er den nemmeste at programmere, metoden med arrayet. Det 

er desuden godt at have et bestemt formateret XML ark at gå ud fra. På den måde kan man åbne en 

skabelon når man skal lave en ny scene og derved undgå at skrive fejl. I et stort spil vil skabelonen 

kunne blive meget stor med mange egenskaber. Det kan være svært at navigere i. 

XML metoden kræver at scene designeren kender til hvilke egenskaber, Item.as class’en kan 

acceptere. Tilgengæld kan designeren tilføje de egenskaber han har brug for i den rækkefølge der er 

brug for. For at gøre det nemmere for designere, kan et egenskabs dokument oprettes der beskriver 

hvilke egenskaber der er tilrådighed. Derfor passer XML metoden bedst til spilmotorens målsætning. 

Det skal være nemt at kunne tilføje og redigere scener. 

KODE EKSEMPEL 

I dette afsnit vil der blive givet en løsning på hvorledes scriptet til StageMaster modulet kan kodes. 

Metoden lægger op til at sende et array videre til item objektets constructor. Koden er testet og 

implementeret i flash. 

I den første linje bliver der skabt en string variable kaldet STAGEXMLPATH, hvori stien til .xml filen 

stages.xml ligger. Herefter bliver der skabt en funktion kaldet loadStage, hvis formål er at hente stien 

til den nødvendige .xml fil fra stages.xml, og sende den videre til buildStage funktionen. loadStage 

funktionen bliver kørt med parameteret stageName. En tekst streng med navnet på den scene der 

skal skiftes til.. 

Var stagexml:XML = new XML(); skaber en lokal XML variable, der hedder stagexml. Den kommer 

senere til at få indlæst stages.xml. Den får så tildelt egenskaben ”.ignoreWhite”, hvilket medføre at alt 

hvidt rum i .xml filen ikke bliver parset, hvilket er nødvendigt for at XML class’en kan parse XML koden 

korrekt. Yderligere bliver der også lavet en string variable kaldet Stages. Den skal indeholde stien til 

scene-XML arket til den scene der skal skiftes til. 

Når stagexml er færdig indlæst, aktiveres XML metoden .onLoad Stages. En for løkke søger stagexml 

for scenenavnet i stageName variablen. For løkken kører med konditionen n

For at sikkre mod skrive fejl, omdanner String metoden .toLowerCase stageName variblen til små 

bogstaver. Ligeledes med scenenavnene i stagexml. På den måde kan en ifsætning tjekke om det 

scene navn der er givet som parameter er det samme som et af scene navnene fra stagexml. Uanset 

om kun det ene navn er skrevet med stort. Det foregår i if sætningen: 

if (stageName.toLowerCase() == stagexml.firstChild.childNodes[n].nodeName.toLowerCase()) 

For hver iteration for løkken laver, checkes næste scenenavn i XML arket mod stageName variablen. 

Bliver if sætningen sand sættes scenenavn nodens indhold, .firstChild, sat lig med streng variablen 

Stages, nævnt tidligere. For at sikkre at få den korrekte værdi af scenenavn nodens indhold bruges, 

.firstChild.NodeValue. 

Herefter bliver funktionen buildStage (XMLPATH:String) kørt. Funktionen kaldes med Stages som 

parameter, buildStage(Stages). Den bygger scenen med XML arket fra stien i variablen Stages: 

buildStage funktionens formål er at læse data ind fra et XML ark, hvilket indeholder alt den 

nødvendige data til at bygge den ønskede stage. I koden ovenfor ses hvorledes der bliver bygget et 

array for hvert item objekt i den stage, der er i gang med at blive bygget. 

buildStage funktionen indeholder en lokal XML variabel kaldet sheetxml. sheetxml bliver tildelt det 

XML ark der ligger på stien repræsenteret ved XMLPATH. XMLPATH har værdien af Stage variablen på 

grund af at buildStage blev kaldt med Stages som parameter. 

Når sheetxml er færdig indlæst, bliver sheetxml.onLoad metoden aktiveret. Den køre en funktion 

der indeholder et loop. Loopet kører gentagelser, så længe n er mindre end sheetxml’s childNodes 

antal bestemt af sheetxml.firstChild.childNodes.length. I loopet bliver der skabt et 

nyt lokalt array kaldet itemProp for hver n’te gentagelse. Samtidigt bliver der kørt et nyt loop for 

hvert n, der har den funktion at hente informationerne fra XML arket sheetxml. Informationerne 

tilføjes til vores nyskabte array ved brug af .push metoden. Denne metode lægger dataen bagerst i 

arrayet. 

67 of 83

Efter hvert array er blevet skabt, skal der skabes et nyt item objekt med parameteren itemProp. item 

objektet skal have et unikt navn for hvert item. For at oprette et Item objekt, med custom class skal 

class filen hedde Item.as og ligge i stam mappen. Linjen 

var myItem:item = new item(itemProp); 

Skaber et item objekt, ud fra de egenskaber arrayet har. Der opstod en problem stilling ved at oprette 

item objekter med unikt navn i for løkken. Actionscript 2.0 tillader ikke betegnelsen: 

var itemProp[0]:Item = new Item(itemProp); 

Denne betegnelse skulle lave en variabel med navnet angivet af itemProp arrayets første element. 

Variablen skulle være af typen item, og blive tildelt egenskaberne som constructoren tilføjer med 

parameteret itemProp. Problemstillingen blev løst ved at lave en streng variabel kaldet itemName i 

_root scopet. I løkken efter arrayet er blevet skabt, tildeles itemName egenskaben fra itemProp[0], 

som indeholder et navn. Ved betegnelsen: 

_root[itemName ] = myItem; 

tildeles det navn itemName indeholder, objektets myItem’s egenskaber. Det vil sige at der reelt står: 

itemProp[0]’s værdi = myItem; 

Grunden til at der står _root foran [itemName] er fordi variablen itemName bliver defineret på hoved 

timelinen. Hvis itemName blev defineret inde i løkken, ville man kunne skrive this[itemName]. Dette 

kan dog ikke lade sig gøre fordi så ville variablen være en lokal variabel og Item objektet ville ligeledes 

blive lokalt. Det er smartest at undgå at skrive _root på grund af at når man har med flere .swf filer at 

gøre, kan flash blive forviret over hvilken .swf fil, der har _root timelinen. Det bruges her, fordi den 

relative path eller sti fra loopet, til den streng variabel, der er defineret i hovedtimelinen, ikke er 

kendt. Når streng variablen skal bruge med this[myString] metoden, skal scopet identificeres, selvom 

det er en global variabel. 

MOVEMENT 

I det følgende kapitel vil der blive beskrevet hvilke overvejelser, der er blevet gjort med hensyn til den 

overordnede bevægelsesfunktion. Den omfatter hvorledes spillerens karakter bevæger sig i spil 

verdenen. Der bliver inddraget forskellige designovervejelser for dette modul og slutteligt vil der blive 

gennemgået et eksempel på hvordan det kan implementeres i kode. 

Målet med denne modulet er, at det skal give spilleren mulighed for at navigere sin avatar rundt i 

spilverdenen. Samtidigt skal det være nemt at definere de specifikke bevægelses muligheder i hver 

enkelt scene. Dette skaber en teknisk problemstilling med to krav: 

Designeren skal kunne bestemme hvor avataret skal kunne gå hen. 

Designeren skal have let adgang til at ændre og tilføje bevægelsesmønstret til den enkelte scene og 

spillet. I overenstemmelse med spilmotorens målsætning. 

Non Player Characters eller NPC’er i spillet, kan animeres i movieclippets timeline. Ved brug af 

motionguide kan designeren bestemme hvor og hvordan NPC’en skal bevæge sig på stagen. Det er en 

mulighed at spiller karakteren bruger samme bevægelses form. På den måde kan designeren animere 

karakterens movieclip i hver enkelt scene. Denne form udfylde begge krav stillet ovenfor. 

Det er dog ikke den bedste metode for spillet. Der er flere omstændighedder, der kan hjælpe til en 

bedre oplevelse af spillet. For at give spilleren den bedst mulige indlevelse er det nødvendigt at 

68 of 83

karakteren kan bevæge sig frit i scenen. Spilleren skal kunne bevæge sig foran og bagom andre 

objekter i spilverdenen. For at skabe en sans for dybde i spillet, vil det være optimalt hvis karakteren 

skalerede, og blev mindre når den skal forstille at være længere væk. Disse er designmæssige krav, 

som så vidt muligt, bør indfries. 

For at gøre spillet så alsidigt som muligt, vil det være optimalt hvis forskellige scener, kan have 

forskellig kameravinkel. Det vil kræve mulighed for dynamisk at indstille egenskaber som skalering og 

karakterens hastighed. Samtidigt vil det være optimalt hvis scene kan panere over baggrunde der er 

støre end stagen. Dette er ønsker for spilmotoren der ikke er nødvendige for spillet, men som kan 

implementeres hvis muligt. 

I udarbejdelsen af løsningsmetoder blev der arbejdet på tre forskellige indgangsvinkler. 

• Kurve metoden 

• Path Finding metoden 

• Retlinjet bevægelses metoden 

KURVE METODEN 

Ideen til kurve metoden er at lave bevægelsen efter forudbestemte matematiske kurver. Spillerens 

klik med musen, vil medfører at karateren bevæger sig langs en kurve, indtil den kommer så tæt på 

det punkt musen trykkede på som muligt. Designeren har mulghed for at lave to sideligende 

funktioner. Det gør det muligt for karakteren, at bevæge sig inden for det område der spænder 

mellem funktionerne. Det er også muligt for designeren at lave to uafhængige funktioner. 

Spilmotoren kan vælge mellem den ene eller den anden funktion, alt efter hvilket området af 

skærmen spilleren klikker i. 

Figur 43 

F1A og F1B viser er to funktioner. Karakteren kan bevæge sig i arealet mellem dem. Trykker brugere i 

nærheden af F2, funktionen går brugeren langs denne funktion. 

En ulempe ved denne metode er at designeren, skal regne matematiske funktioner ud, der passer til 

scenen han designer. Dette kan være besværligt og med risiko for regnefejl. Derudover opstår der et 

problem hvis en funktion buer, og overlapper den samme x værdi. 

Figur 44 

F3 er en funktion der overlapper sin egen x værdi. Dette skaber et problem da karakterens y værdi er 

afhængig af x værdien. 

69 of 83

PATH FINDING METODEN 

Path Finding metoden er på nogle punkter lig kurvemetoden. Her er der også en forudbestemt sti, 

som spillerens karakter følger. I stedet for at følge en forudbestemt kurve, er det i stedet 

forudbestemte punkter, waypoints, som spilkarakteren følger. Det er nemmere for designeren, fordi 

designeren ikke skal regne formler ud. Designeren skal registrere koordinaterne på de punkter han vil 

have spilleren bevæger sig imellem. Metoden vil fungere således, at spilleren klikker på et punkt på 

spiloverfladen og karakteren følger en sti af waypoints til det waypoint, der er tættest på det klikkede 

område. 

Figur 45 

Figuren viser hvordan karakteren bevæger sig langs waypoints. Waypoints har deres nabowaypoints 

registrerede, så spilmotoren kan vide hvilket waypoint den kan gå til. 

Path Finding metoden kan, i kode, blive meget advanceret. For at finde en korrekt vej mellem to 

waypoints, skal spilmotoren først regne stien ud fra start til slut, før den bevæger karakteren. Ved at 

registrere waypoints’ne med nabo waypoints kan spilmotoren regne ud hvilke waypoints karateren 

må bevæge sig imellem. Umiddelbart kan karakteren kun stå på waypoints. For at give mere frihed er 

det muligt at programmere modulet sådan, at det regner en position ud mellem wapoints’ne, 

svarende til x værdien for musets klik. 

Denne advancered motor foretager mange udregninger, og kan gøre flashaplikkationen langsom. 

Ved store områder, som f.eks. det store kort der bliver brugt i vores prototype til overblik og 

”speedtravel”, vil være et godt sted at bruge Path Finding mellem de forskellige punkter på kortet, så 

man giver en illusion over en karakter der går mellem de forskellige punkter på kortet, uden samme 

nødvendighed for bevægelses frihed som der er i de andre scener i spillet. 

FRIT RETLINJET BEVÆGELSES METODEN 

Denne metode er umiddelbart den der byder på mest bevægelsesfrihed for spilleren. Her bliver 

bevægelsen klaret ved at spilleren, som før, klikker på et område i spilfladen. Mellem de nye 

koordinater, fra hvor spilleren klikker, og de gamle, fra hvor avataren befinder sig, bliver der regnet 

en lige linje ud. Karakteren bevæger sig langs linjen, til den rammer det nye punkt. 

Figur 46 

Den stiplede linje viser ruten frem til krydset karakteren vil bevæge sig langs. 

70 of 83

Dog er der visse problemer der kræver alternative løsninger. Skal avataren bevæge sig rundt om en 

bygning, eller op ad en sidevej, er det ikke altid, at den kan gå i en lige linjen. Dette problem kan løses 

ved at designeren tegner nogle firkanter karakteren kan bevæge sig indenfor. Trykker spillere på en 

firkant avataret ikke befinder sig i, bevæger avataret sig fra firkant til firkant, indtil den kommer til 

firkanten der indeholder de nye koordinater. Dette er en metode der gør brug af waypoints men ikke 

er afhængige af dem. 

Figur 47 

På figuren til venstre går karakteren ved første klik hen foran huset. Ved andet klik, øverst i billedet vil 

karakteren gå i en ret linje hen over huset. 

På figuren til højre har spilleren klikket øverst i billedet. Her finder spilmotoren vej fra firkant til 

firkant, ved hjælp af waypoints. Når karakteren er nået til den sidste firkant går den i en lige linje til 

det registrerede punkt. 

De metoder, som blev diskuteret, har alle deres stærke og svage sider. En kombination af dem ville 

give det bedste resultat, men ville samtidigt gøre en utrolig kompleks spilmotor. Den simpleste form 

der passer til de specifikationen der blev nævnt, er den sidste metode. Hvis spillet bliver designet ud 

fra den retningslinje at spilleren skal bevæge sig inden for en firkant per scene, vil det være muligt at 

undgå at bruge waypoints. Eventuelt kan spillet bygges op af en forgrund, en baggrund og en 

mellemgrund hvor karakteren kan bevæge sig. 

KODE EKSEMPEL 

Følgende bliver beskrevet koden for bevælgelse i en ret linje mellem to punkter. 

De første linjer kode er til at skabe de forskellige variabler. Den første variable ”speed” er til at 

bestemme hastigheden på spilkarakteren, når han bevæger sig langs den rette linje, altså hvor meget 

spilkarakteren forskyder sig langs den lige linje per frame. NewX og NewY er til at gemme henholdsvis 

x koordinaten og y koordinaten fra hvor spilleren klikker på spiloverfladen. Variablen mouselisten er 

et objekt, der senere bliver sat til at registrere ændringer i musens tilstand, så som f.eks. om den 

bevæger sig, eller om en knap er trykket ned. 

71 of 83

Herover bliver der kørt en funktion hvis museknappen er blevet sluppet. Denne funktion ændre de 

førnævnte variabler til at indeholde den nuværende position af spilkarakteren, samt det punkt hvor 

brugeren klikker og ønsker at karakteren skal bevæge sig hen. Ydermere bliver der regnet 

skæringspunkt og hældningskvotient ud for den rette linje. 

Char.onEnterFrame, medføre at den funktion der er tilknyttet movieclippet Char (spilkarakteren), 

bliver kørt før alle andre funktioner i scriptet. Denne funktion, i det her tilfælde, styrer spilkarakterens 

position på den rette linje mellem de gamle og nye x og y koordinater. Løbende bliver spilleren 

forskudt langs linjen, indtil den endelige position er nået. Løbende bliver der kontrolleret at 

karakteren ikke kommer til at bevæge sig langt, ved at udregne forskydningen og sammenligne den 

med de nuværende NewX og NewY variabler. Til sidst, bliver spilkarakterens movieclip opdateret med 

de nye koordinater, og funktionen er slut, og er klar til at blive kørt igennem ved næste frame. 

Mouse.addListener(mouselisten); knytter listeneren til vores mouselisten objekt, der kontrollere 

hvorvidt brugeren har brugt musen. 

SAVE FUNKTIONEN 

Save funktionen er en underfunktion til Character Sheet modulet. Som nævnt tidligere er Character 

Sheet modulets formål er at holde styr på spillerens progression i spillet. Flag I spilmotoren gør det 

muligt at overvåge denne progression. Flagene bliver sat med tekst værdier. Det har den fordel at de 

værdier der er false ikke bliver sat i arrayet, og dermed spares plads. Save funktionens formål er at 

gemme flagene, således at spilleren kan vende tilbage efter en afsluttet spilsession, og foresætte fra 

det slupne punkt. 

XML er en god struktureret måde at komprimere spillets progression på, og shared objects er en 

måde at lagre det, da det er et lokalt vedvarende objekt. Dette betyder at data bliver gemt og kan 

72 of 83

hentes på et senere tidspunkt. Det er muligt at bestemme hvorvidt flash skal hente det gemte spil 

automatisk, næste gang spillet bliver startet, eller at det først skal ske når brugeren ønsker det. 

Shared Objects har dog den ulempe at dataene bliver gemt som en slags cookies, hvilket medfører en 

række ulemper og begrænsninger. 

Disse ulemper og begrænsninger består bl.a. af at nogle brugere kan have forbudt SWF filer at skabe 

lokale shared objects, og da de ikke bliver skrevet i samme mappe som spillet, kan de blive slettet ved 

et uheld. 

KODEN: 

Koden beskriver hvorledes data fra de forskellige arrays bliver skrevet over i et XML ark. Derefter 

hvordan disse bliver gemt i et shared object og yderligere hvorledes dataene bliver genfundet og 

skrevet til et XML ark igen. 

XML KOMPRIMERING 

De første linjer af kode laver funktionen Save med parameteren saveName. Der bliver så skabt en 

lokal instans af XML klassen kaldet savexml. Herefter bliver der lavet tre XML noder, kaldet Save, Flags 

og Scenes. På nuværende tidspunkt er disse ikke knyttet til noget XML dokument. Herefter bruges 

appendChild metoden, der først knytter saveNoden til XML arket som root node, og herefter to andre 

noder som dens børn. 

Chararcter Sheetet har to arrays. Disse to arrays beskriver som førnævnt progressionen i spillet, og 

disse komprimeres på samme vis. Her er et eksempel på hvorledes dette kan kodes. 

Der bliver skabt en nummer variable der har samme værdi som længden af CharSceneArray. Det er et 

array der bliver brugt tidligere under CharSheet modulet. Herefter bliver der kørt et loop som har den 

funktion at skrive de forskellige elementer i CharSceneArrayet over i vores XML dokument. Det bliver 

den gjort ved at sætte variablen textNode1 lig med de forskellige elementer i arrayet og herefter 

skrive dem ind i XML arket ved hjælp af appendChild metoden. 

73 of 83

KOMPRIMERET XML TIL DISK 

Nu er dataene blevet komprimeret i et XML ark. Dog er det ikke blevet gemt på spillerens harddisk 

endnu. Den følgende kode beskriver hvorledes XML arket ”savexml” bliver skrevet over i vores shared 

object, under storedxml elementet. 

Koden starter med at lave en ny variable kaldet so, som er en instance af shared object klassen, og 

usersave, er det lokale fil navn, hvor so kan skrive eller hente data fra og til. Hvis denne ikke findes, 

bliver den oprettet. So.data.storexml sættes lig savexml, det XML ark, hvor den ønskede gemte data 

blev skrevet til. Shared Objects har egenskaben data, som man kan tildele forskellige attributer, disse 

kan så hentes og deles når man ønsker det. Attributerne kan være basalt objekt i actionscript, så som 

et array, et tal, en boolsk værdi, eller i vores tilfælde et XML objekt. For at gemme so.data.storedxml, 

bruges flush funktionen, som skriver dataen over i usersave. 

HENTE DATA FRA DISK 

Load funktionen bliver brugt til at hente den gemte data. Den henter det shared object fra stien 

usersave, og bagefter skriver den hentede XML data so.data.xml over i vores loadedxml objekt som 

herefter kan skrive de forskellige indeholdende data over i vores nødvendige arrays. 

VIDEREUDVIKLING 

Emner ikke diskuteret i udviklingsfasen eller implementeringen, der kunne forbedre spillet eller gøre 

det en smule mere interessant beskrives her. Der gøres ingen overvejelser om, hvor vidt det kan lade 

sig gøre rent teknisk. 

Da det tidligere er blevet forklaret, hvor vigtig god lyd er i et computer spil til at fremme det narrative 

element, kunne man undersøge yderligere hvilke tekniske implikationer, der ligger i at inkorporere 

bedre lyd. Baggrundsmusik og dialog-tale er med i prototypen til testen, men testen omhandlede ikke 

denne. Der kan evt. undersøges dybere på hvorledes musik og dialog-tale virker i spil, og gennem 

dette forbedre denne oplevelse for brugeren. 

Som nævnt tidligere er den visuelle del, billeder og grafik lavet til prototypen grundet visse 

tidsbegrænsninger. Det vil virke naturligt at have interesse for dette område også, og se på hvordan 

dette bør designes for at bedre spillets generelle stemning. 

Mht. den rent tekniske del, programmeringen af Actionscript, funktionerne i spillet, bør animerede 

objekter overvejes, for at være med til at skabe liv og stemning til spillet. Med små elementer som 

personer der bevæger sig gennem skærmen, ad en lige linie, gennem en kurve, eller hvordan det nu 

kunne komme til at passe ind, se hjemløse dyr på gaden, osv. Det er med til at skabe stemning i spillet 

og med til at få følelsen af at der er liv i spillet. 

74 of 83

De ovenstående nævnte ideer og eksempler ville naturligvis skulle forsøges testet på et publikum med 

henblik på brugerens holdninger og reaktioner, og herfra finpudses eller ændres. 

At spillet fremgår som gennemtænkt og færdigt designmæssigt gør det ikke mindre genstand for 

ændringer og finjusteringer. Da der oftest ikke kan tænkes på alt, vil der som regel være mulige 

emner, der kan forbedres. 

Historien. I spillet blev der taget udgangspunkt i overvågningssamfundet, det totalitære diktatur der 

ønskes skildret. Det er ikke umuligt at inddrage kærlighedselementer fra bogen og indføre bogens 

overordnede historie om Winstons kærlighedsaffære i spillet uden historien om overvågningen og 

samfundet går tabt. 

I en spilverden vil historien på mange måder være lige så lineært som bogen, med samme muligheder 

for bi- eller side-historier, men i en spilverden vil handlingen ikke altid foregå i samme tempo, som 

det at læse en bog. Det er op til brugeren selv at vælge tempoet vedkommende har lyst til at komme 

igennem historien. Spil er mere åben for at brugeren kan udforske verden helt, indtil begrænsninger 

sat af udviklerne. 

Det giver en mulighed for at implementere verden som helhed, mere end beskrevet i bogen. Der kan 

gives mulighed for, at brugeren kan gå på opdagelse i alle byens kvarterer, så frem det er tilladt og 

lovlige steder at bevæge sig. Det kunne tænke sig at en sidehistorie kunne være en udflugt, lidt som 

den allerede beskrevet i 1984 (Orwell, s. 123-133) hvor brugeren får mulighed for at se verden 

udenfor byen, med en lille sidehistorie. 

Dette ovenstående omkring side- og bi-historier vil være lette at inkorporere, da spillet i forvejen er 

tiltænkt kun at have en main fil, hvorind andre eksterne swf filer bliver loadet. Dermed er det bare at 

udvikle scener og lave en tilgang til disse fra allerede eksisterende filer. Dermed skal kun nye scener 

samt actionscript til disse udvikles, hvor alt gennemgående Actionscript ligger i hovedfilen. 

Skulle der videreudvikles på spillet, ville ovenstående emner og eksempler være væsentlige. 

75 of 83

DISKUSSION 

Overvågningen er endnu engang i mediernes søgelys. Fra den 1. juli bliver det i mere vid udstrækning 

lovligt at overvåge det offentlige rum. Med øget overvågning, hvad enten det er til gavn for den 

almene dansker eller ej, er det et skridt på vejen mod det overvågningssamfund George Orwell 

forsøgte at beskrive i romanen 1984. 

Det har været forsøgt i rapporten at omsætte 1984 til et adventurespil og se på, hvordan 

overvågningen og samfundet beskrevet i bogen, kan videregives i dette spil. Det er ikke undersøgt, 

hvorledes tidligere spil er skabt ud fra bøger. I stedet er overvågningsmulighederne beskrevet som de 

eksisterer i dag, samt hvad adventurespil er og hvordan de har udviklet sig gennem tiderne. Denne 

tilgang til projektet kunne være struktureret anderledes, set i retrospekt, da tidligere omsætninger fra 

bog til spil burde være undersøgt og redegjort for. På trods af disse tidligere bog-til-spil konversioner 

ikke er undersøgt, mener vi at måden, hvorpå processen har været, var fornuftig. 

Med det evige tidspres der er for at færdiggøre et projekt og en rapport til tiden, har det gennem 

hovedparten af perioden været nødvendigt at arbejde med flere bolde i luften af gangen. Spillet blev 

udviklet sideløbende med at information til kontekst og designdelen blev fundet, undersøgt og 

videreformidlet i rapporten. Dette har medført at udviklingen af det endelige produkt ikke har fulgt 

Game Design afsnittet beskrevet tidligere i rapporten 100%, men snarere er koden blevet skrevet 

løbende. Prototypen er blevet udviklet efter Game Design afsnittet i videre omfang, hvilket også er 

beskrevet. 

Hvorvidt spillet kunne være udviklet anderledes er der ingen tvivl om. Hvorvidt en anden tilgang 

havde været årsag til at spillet var blevet udviklet anderledes, er dog et andet spørgsmål, eller måske 

er spørgsmålet, om det ville være blevet bedre? 

Det ville være optimalt at have struktureret forløbet anderledes, og fokuseret mere på selve 

udviklingen af spillet, i stedet for den store kontekstuelle del, hvilket gjorde at selve udviklingen led 

under det. Her ville en strammere struktur af arbejdet, eller tidligere uddelegering af opgaverne have 

været en stor bonus for arbejdet. 

Set i et positivt lys har vi haft rig mulighed for test af den udviklede prototype. Det kunne være 

interessant med et færdigudviklet spil og muligheden for, at udføre omfattende tests på dette 

produkt, i form af den visuelle stil, interfacet og spiloplevelsen. 

Hoveddelene af koden til produktet er skrevet, men der er meget der mangler endnu, både i form af 

alt det visuelle, og alle spillets scener. At have videreudviklet på denne var ønskværdigt, men 

desværre ikke muligt grundet tiden. 

På trods af denne mangel, er der endt med en prototype, der virker efter omstændighederne til test. 

Denne test gav en god forståelse for, hvordan den almene bruger forholder sig til spillet, og ikke 

overraskende var det ikke som forventet, og en masse ændringer blev herefter muliggjort, hvilket dog 

ikke er rettet, eftersom tiden ikke var til det og det ikke var nødvendigt i prototypen. 

Det aspekt af rapporten der kunne være blevet arbejdet mere på, er afsnittet omkring Game Design. 

Det ville være ønskværdigt at have brugt mere tid på dette. 

Interessant kunne det være, at have foretaget et interview med en Game Designer og mere praktisk 

tilgang til udviklingen, samt en dybere forståelse for selve Game Design delen. 

Denne udvidelse af Game Design ville, foruden at have udvidet vores viden indenfor området, sikkert 

også have medført en bedre udviklingsfase, og i sidste ende sandsynligvis et mere solidt produkt. 

76 of 83

KILDEFORTEGNELSE 

BØGER: 

- Bateman, Chris (ed.) (2007), Game Writing, Narrative Skills for Videogames,1. Udgave, ISBN: 

1-58450-490-0, Charles River Media 

- Crawford, Cris (2003), On Game Design, 1. Print, ISBN: 0-13-146099-4, New Riders Publishing 

2003 

- Makar, Jobe (2002), Macromedia® Flash MX Game Design Demystified. The official Guide 

to Creating Games with Flash, September 09, ISBN: 0-201-77021-0, Peachpit Press 

- Orwell, George (1998), 1984, 1. Udgave, ISBN: 0-14-027877-X, Penguin Books Limited 

- Phillips, Brian (2002), 1984 George Orwell, Spark Publishing 

- Sharp, Helen et al. (2007), Interaction Design, Beyond human-computer interaction, 2. 

Udgave, ISBN: 978-0-470-01866-8, Wiley 

- Søndersted-Olsen, Hans-Henrik (2003), Marketing håndbogen, Fra strategi til kampagne, 1. 

Udgave, ISBN: 87-593-0994-6, Samfundslitteratur 2003 

HJEMMESIDER 

- Actionscrip.org, XML 101, [Online], http://www.actionscript.org/resources/articles/9/2/XML- 

101/Page2.html, [sidst besøgt d. 28.05.2007] 

- Adventure (2006), [Online], http://game-research.com/index.php/info-pages/history-andgenre/adventure-games/ 

, [sidst besøgt d. 28.05.2007, sidst opdateret d. 16.05.2006] 

- Closed-circuit television (2007), [Online], http://en.wikipedia.org/wiki/Closedcircuit_television, 

[sidst besøgt d. 28.05.2007, sidst opdateret d. 21.05.2007] 

- Dillon, Teresa, Adventure Games for Learning and Storytelling, [Online], 

http://www.futurelab.org.uk/download/pdfs/research/project_reports/Adventure_Author_ 

context_paper.pdf, [sidst besøgt d. 28.05.2007] 

- Flash player Penetration (2007), [Online], 

http://www.adobe.com/products/player_census/flashplayer/, [sidst besøgt d. 28.05.2007, 

sidst opdateret d. 30.03.2007] 

- Frandsen, Bjarne (2005), Terrorlovgivning, overvågning og retssikkerhed, [Online], 

http://www.tidsskriftcentret.dk/index.php?id=428, [sidst besøgt d. 28.05.2007, sidst 

opdateret d. 20.03.2007] 

77 of 83

- Gill, Martin & Spriggs, Angela (2005), Assessing the impact of CCTV, [Online], 

www.homeoffice.gov.uk/rds/pdfs05/hors292.pdf, [sidst besøgt d. 28.05.2007, skrevet 

februar 2005] 

- Gyldendal, under opslaget leg, [Online], www.gyldendalsleksikon.dk, [sidst besøgt d. 

28.05.2007] 

- Interactive Fiction, [Online], http://search.eb.com.zorac.aub.aau.dk/eb/article-233729, [sidst 

besøgt d. 28.05.2007] 

- Justitsministeriet (2007), Forslag til lov om ændring af lov om forbud mod tv-overvågning mv. 

- 28 februar 2007, [Online], http://147.29.40.91/_GETDOC_/ACCN/200612L00162, [sidst 

besøgt d. 28.05.2007, fremsat d. 28.02.2007] 

- Justitsministeriet (2007), Justitsministeriets nyhedsbrev nr. 80 - 2 marts 2007, [Online], 

http://www.justitsministeriet.dk/organisation/ministeriet/nyheder/nyhedsbreve/nyhedsarki 

v/arkivvisning/?tx_ttnews%5Byear%5D=2007&tx_ttnews%5Btt_news%5D=122&tx_ttnews%5Bback 

Pid%5D=414&cHash=bcdddb08b5, [sidst besøgt d. 28.05.2007, fremsat d. 02.03.2007] 

- Justitsministeriet (2002), Retsplejeloven, [Online] 

http://www.retsinfo.dk/_LINK_0/0&ACCN/A20020077729, [sidst besøgt d. 28.05.2007, sidst 


- Jørgensen, Oluf (2002), Anti-terrorpakken: vidtgående kriminalisering og overvågning, 

[Online] http://www.cfje.dk/cfje/Lovbasen.nsf/ID/LB02948626?OpenDocument, [sidst 

besøgt d. 28.05.2007, sidst opdateret d. 13.09.2002] 

- Læs om Kompas Segmenterne (2007), [Online], 

http://www.gallup.dk/test/kompas_segmenter.asp, [sidst besøgt d. 28.05.2007, sidst 


- McCahill, Michael & Norris, Clive (2002), CCTV in London, [Online], 

http://www.urbaneye.net/results/ue_wp6.pdf, [sidst besøgt d. 28.05.2007, skrevet juni 

2002] 

- Nickelsen, Anna karina (2005), TV-overvågning, Fakta om TV-overvågning i Danmark, 

[Online], http://arkiv.dkr.dk/pdf/tv-overvaagning2005.pdf, [sidst besøgt d. 28.05.2007, 

skrevet februar 2005] 

- Talking CCTV brings voice and authority to the street, [Online], 

http://www.homeoffice.gov.uk/about-us/news/talking-cctv?version=1, [sidst besøgt d. 

28.05.2007, sidst opdateret d. 04.04.2007] 

- Town trials talking CCTV cameras (2006), [Online], 

http://news.bbc.co.uk/2/hi/uk_news/england/tees/5353538.stm, [sidst besøgt d. 

28.05.2007, sidst opdateret d. 17.09.2006] 

78 of 83

- USA PATRIOT Act. (2006), [Online], http://en.wikipedia.org/wiki/USA_PATRIOT_Act, [sidst 

besøgt d. 28.05.2007, sidst opdateret d. 26.05.2007] 

- Welsh, Brandon C. & Farrington, David P. (2002), Crime prevention effects of closed circuit 

television: a systematic review, [Online], www.homeoffice.gov.uk/rds/pdfs2/hors252.pdf, 

[sidst besøgt d. 28.05.2007, skrevet august 2002] 

79 of 83

APPENDIX A : PROJEKTBESKRIVELSE 

INDLEDNING 

Siden 3d grafik blev udviklet og taget i brug i computerspil er adventurespilgenren gået en stille død i 

møde. Populære point and click spil som Monkey Island blev i første omgang udviklet i 2d. Først red 

adventurespilgenren med på 3d bølgen, med spil som Monkey Island 4, og Grim Fandango, men der 

er nu næsten ingen udgivelser inden for denne genre. Vi vil gerne skabe en renæssance 

for adventurespillet. 

I Danmarks politiske arena er stemmeprocenten faldende. Politiske ideologier spiller en mindre og 

mindre rolle i valgkampene og grænserne mellem partiernes holdninger viskes ud. Måske er 

befolkningen tilfreds med den nuværende retning samfundet går i, eller det kunne spekuleres at den 

gemene dansker ingen interesse har for politik og er uoplyst om ideologier og de konsekvenser det 

medfører, ikke at stemme I et demokrati. 

FORMÅL 

Formålet med vores projekt er at skabe et spil der kan informere folk og påvirke holdninger. 

Produktet skal designes fra begge sider af skærmen som temarammen foreskriver det. Produktet skal 

være et interaktivt spil, der kan motivere, informere, og være underholdende samt indeholde et 

stærkt narrativ. 

Vi har på nuværende tidspunkt gjort nogle antagelser som vi vil undersøge nærmere i løbet af vores 

projekt: 

• Adventurespil går en stille død I møde. 

• Stemmeprocenten er faldende. 

• Børn i 10-11 års alderen er den mest modtagelige målgruppe. 

Vi vil med projektet forsøge at sætte fokus på politik, ideologier og evt. livsfilosofier, da politisk 

ligegyldighed modstrider det demokratiske grundlag. Som redskab til dette, vil vi bruge et 

adventurespil, der på en narrativ, underholdende og satirisk måde kan informere om konsekvensen af 

politisk ligegyldighed, og inspirere folk til at tage stilling. 

Vores initierende problem er følgende: 

Hvordan kan vi konstruere et adventurespil der kan sætte fokus på ideologier og påvirke folk til at 

tage stilling? 

BAGGRUND 

Den samfundsmæssige kontekstuelle baggrund, bygger som førnævnt, på vores antagelse af 

danskerne er begyndt at leve mere i politisk ligegyldighed. 

Vi er ikke sikre på målgruppen endnu. Vi har overvejet at henvende os til børn i alderen 10-11 år, da 

dette skulle være den bedste alder til politisk påvirkning. Vi har også overvejet at henvende os til 

målgrupper i en ældre aldersgruppe, da det måske vil være sjovere for os at lave et design til en 

målgruppe mere lig os. 

Da vi ikke har fastslået vores målgruppe endnu, kan vi ikke gå i dybden med beskrivelse af den 

yderlige kontekstuelle del. 

80 of 83

MÅL 

Vores mål med P2 projektet er at det skal leve op til de krav som er os stillet, samt vores egne krav og 

forventninger. 

• Flash – Vi vil gerne have at alle gruppemedlemmerne for et dybt kendskab til flash. 

• Færdigt testet produkt 

• Klare og faste deadlines, der overholdes. Generelt velstruktureret arbejdsforløb. 

• ”Politisk Fabel” i form af et adventurespil, med et stærkt narrativ 

• Brugeren/Spilleren skal have mulighed for interaktion og mulighed for at påvirke handlingen 

i spillet. Men mest af alt, underholdende. 

• Færdigt Programmering/Grafisk design/Lyd design 

• Give spillet et professionelt look ’n’ feel 

SKRIV FLERE TING PÅ NÅR GRUPPEN ER SAMLET! 

PROJEKTPLANLÆGNING 

Vi har delt projektet op i 3 arbejdsfaser: en kontekstuelfase, designfase og en implementeringsfase. 

Faserne indeholder forskellige arbejdspakker som f.eks. vidensindsamling, eller rapportskrivning mm. 

Vi håber at vi kan have hele gruppen arbejdende på en fase ad gangen, så ledes at vores projekt 

kommer til at forløbe mere naturligt og være mere sammenhængende, samt at alle 

gruppemedlemmer kommer til at arbejde på alle aspekter af projektet, da det vil være absurd at 

inkorporere elementer i vores produkt uden en designmæssig / kontekstuelle overensstemmelse. 

TIDSPLAN 

Planen er at påbegynde den kontekstuelle fase i uge 10 og at denne gerne skulle være færdig ved 

starten af uge 12. Derefter vil vi foresætte med designfasen som efter planen skulle være færdig i uge 

16. Derefter vil implementeringsfasen starte, som gerne skulle være færdig i uge 19, samt rapporten, 

som derefter vil blive justeret og rettet igennem den følgende weekend. Vi har i vores SFK inkluderet 

en ugentlig dag, hvor vi holder status over projektet, samt gruppe samarbejdet, hvor vi her kan 

inddrage ændringer på vores tidsplan løbende. 

BESKRIVELSE AF ARBEJDSFASER 

Den kontekstuelle arbejdsfase kommer til at omhandle den samfundsmæssige kontekst af vores 

projekt opdelt i mindre arbejdspakker. 

Den designmæssige fase kommer til at omhandle selve designet af vores produkt, så som 

storyboards, plot, gameplay, samt de første indledende tests af vores low- og high fidelity mock-ups 

af vores spil. Her vil vi blandt andet undersøge forskellige teorier der gør sig gældende for spil design, 

samt finde relevante informationer, og eventuelle generelle psykologiske modeller af vores 

målgruppe, der vil hjælpe os til at skræddersy vores spil til vores målgruppe. 

I implementeringsfasen vil vi inddrage den planlægning som vi lavede i designdelen, samt skrive selve 

koden, og animere og tegne det visuelle udtryk af vores spil 

Hvis tiden er til det, vil vi herefter udvikle lydsiden af spillet, som omfatter foley design, stemme 

optagelser til karaktererne i vores spil, samt musik. 

Vi er usikre på hvorledes vi præcist skal fordele de udfærdigende opgaver eller arbejdspakker over 

faserne. 

81 of 83

TEST AF PRODUKT 

Under designdelen, har vi tænkt os at køre nogle initierende tests af vores design, ved at lave papir 

modeller af vores spil, for at undersøge hvorvidt vores spil virker intuitivt og medrivende på brugeren. 

I implementeringsdelen vil vi gerne teste vores produkt løbende, og tage stilling og indrette 

testresultaterne i vores produkt. Vi vil også sammenligne resultaterne med vores designmæssige 

overvejelser vi har gjort på baggrund af de løbende brugertests i designdelen. 

Generelt er det vores håb at vi forhåbentlig kan drage så meget af det relevante stof som vi lærer i 

HCI ind i vores projekt og i test faserne. 

VIDENSINDSAMLING 

Vores nuværende liste over emner der skal researches er som følger: 

Kontekst 

- Problemstilling med valgdeltagelse. 

- Ungdom og politik 

- Statistik af valgdeltagelser 

- Holdninger i de forskellige partier (analyse) 

- Vidensindsamling af alle aldersgrupper og deres viden om politik 

- Ideologier 

- Hvorvidt der bliver stemt efter ideologier eller politiskprogram 

Produktudvikling 

- Spiludvikling 

- Macromedia Flash 

- Analyse af forskellige spiltyper 

- Character development 

- Lyd til spil 

- Grafik 

- Brugertest og analyse 

- Narrativer 

UDKAST TIL INDHOLDSFORTEGNELSE 

Forord 

Indholdsfortegnelse 

Indledning 

Initierende problem 

Kontekst 

Problemanalyse 

Problemformulering 

Designfase 

Produktudvikling 

Implementering 

Test 

Bug-fixes / Rettelse 

Perpektivering 

Vurdering / Konklusion 

82 of 83

TIDSLINIE OG DEADLINES: 

For at være sikker på at opflyde kravene til P2, og nå at få et gennemarbejdet spil, få det testet og 

generelt nå et resultat vi alle kan være tilfredse med, er det vigtigt for os at komme godt fra start, 

med gode og faste deadlines og lægge os fast på at en given ting SKAL være færdig en given dato, og 

vi dermed må planlægge vores dage og arbejde efter disse deadlines, således vi ikke sidder med alt 

arbejdet tilbage, tilsidst. 

En generel tidslinie er lavet for at danne en tidsramme for hvor lang tid vi forventer at bruge på en 

given ting "pakke", test og bug-fixes.. således alt er færdigt til rette tid. 

83 of 83

Untitled - puffin

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?