3 Stemmebaseret interaktion - The Game Design Chronologist ...

Titel: Kontekstsensitiv talegenkendelse i computerspil
Tema: Formaliserede og uformaliserede sprogformer
Projektperiode: INF3
Projektgruppe: i304a
Vejleder: Keld Pedersen
Synopsis:
Projektets overordnede mål har været at udvikle et computerspil,
der har talegenkendelse som en central interaktionsform, samtidig
med at de tekniske svagheder der normalt forbindes med
talegenkendelse usynliggøres. Det tværfaglige teoretiske grundlag
inkluderer blandt andet en sprogvidenskabelig tilgang til design af
computerspil, mens der metodisk anvendes forskellige
innovationsfremmende teknikker i en iterativ proces. Det
konkrete resultat er et computerspil, hvor målet blandt andet er
oplæring af ninjaelever ved hjælp af talekommandoer, der af
eleverne fortolkes i henhold til den kontekst de befinder sig i.
Talegenkendelsesteknikken er altså ikke forbedret i forbindelse
med den direkte genkendelse, men derimod ved at pragmatiske
forhold vægtes højt i meningstilskrivningen af de genkendte ord.
Både spillet og den tilhørende talegenkender, er implementeret på
den håndholdte spillekonsol Nintendo DS, ved hjælp af omkring
12.000 linjer objektorienteret C++.
Forfatter: . .
Jimmy Marcus Larsen
Oplagstal: 4
Sideantal: 110 (ekskl. forside, bilag og blanke sider)
Kodelinjer: Ca. 12.000 (ekskl. blanke linjer)
Web-side: http://chrono.moogle.dk/nds_1.php
Her findes prototyper, kildekode, rapport i pdf-format,
og billeder og film fra spillet.
3

Forord
Jeg har skrevet denne projektrapport på informatikuddannelsens femte semester, som
dokumentation for projektet kontekstsensitiv talegenkendelse i computerspil. Jeg har lavet
projektet alene, og det vil jeg gerne bruge et par linjer på at forklare, da det
tilsyneladende ikke sker så tit. Der er flere grunde til, at jeg valgte at skrive alene, men
den mest tungtvejende er at min store interesse for computerspil ikke findes tilsvarende
hos de andre studerende. Jeg vil arbejde med computerspil, hvor det er muligt, uanset om
jeg må gøre det alene. Andre årsager til mit valg er, at arbejdsdelingen på tidligere
semestre der har vist mig at jeg sagtens kan lave et projekt alene, og ikke mindst at jeg
ved at skrive alene kan bruge mindre tid på universitetet og mere tid hjemme hos min søn
på snart to år.
Der er en række mennesker som fortjener en stor tak. Først og fremmest skal min kæreste
have tak for på trods af travlhed med specialeskrivning at tage sig tid til at diskutere mit
projekt og læse korrektur på det. Det har været en stor hjælp. Dernæst skal brugerne på
web-stedet Play:Right.dk have tak for altid at være villige til diskussion. Selvom jeg ikke
har diskuteret dette projekt med dem, har mange af deres diskussioner inspireret mig. Til
sidst skal Nintendo DS flashkort-udviklerne NeoFlash.com have tak for at tro på at jeg
kunne lave talegenkendelse til Nintendo DS, og for at sponsere et flashkort til hjælp med
udviklingen.
4

Læsevejledning
Projektrapporten er opdelt i fem dele. Den første og korte del I, indeholder indledning,
problemstilling og afgrænsning. Del II indeholder projektets teoretiske grundlag opdelt i
tre kapitler og en delkonklusion. I tredje del beskrives de anvendte metoder, og i del IV
beskrives, analyseres og diskuteres det spil der er projektets mest konkrete resultat. Del V
indeholder en konklusion og en perspektiverende diskussion, og til sidst findes
litteraturliste, softwareliste og bilag.
Undervejs er der henvist til kilder fra litteraturlisten på følgende måder:
• [Forfatter, År, sidetal eller kapitel]
Er der tale om et opslagsværk udskiftes forfatter med opslagsværkets navn, mens årstal
udelades og sidetal udskiftes med et søgeord - altså i stedet [Opslagsværk, søgeord].
Der henvises til softwarelisten sådan:
• (Udvikler, År)
Hvor titlen fremgår af teksten. I softwarelisten findes henvisninger til websider eller
bøger der omtaler softwaren, som ofte er et spil.
Hvad angår selve teksten i rapporten er det værd at bemærke brugen af ”han” eller ”hun”,
som erstatning for ”spilleren”, for at undgå kluntede sætninger. Tidligere definerede
begreber vil desuden være skrevet med kursiv, for at undgå om- eller gendefineringer.
5

6
Indholdsfortegnelse
I. INDLEDNING….………………………………………………….………...9
1 PROBLEMSTILLING ................................................................................................................12
1.1 AFGRÆNSNING ......................................................................................................................13
II. TEORI...............................................................................15
2 SPROG.........................................................................................................................................16
2.1 SEKS PERSPEKTIVER ..............................................................................................................17
2.1.1 Fonetik.............................................................................................................................18
2.1.2 Fonologi ..........................................................................................................................19
2.1.3 Morfologi.........................................................................................................................19
2.1.4 Syntaks.............................................................................................................................19
2.1.5 Semantik ..........................................................................................................................20
2.1.5.1 Semiotik............................................................................................................................... 21
2.1.6 Pragmatik ........................................................................................................................22
2.1.6.1 Sprog som handling..............................................................................................................22
2.2 OPSUMMERING......................................................................................................................25
3 STEMMEBASERET INTERAKTION.......................................................................................26
3.1 TALEGENKENDELSE...............................................................................................................27
3.2 TALESYNTESE .......................................................................................................................30
3.3 DIALOGMANAGEMENT...........................................................................................................32
3.3.1 Multimodalitet..................................................................................................................33
3.4 OPSUMMERING......................................................................................................................34
4 COMPUTERSPIL .......................................................................................................................35
4.1 MENINGSFULD LEG................................................................................................................36
4.2 DESIGN .................................................................................................................................38
4.3 SYSTEMER ............................................................................................................................40
4.4 INTERAKTIVITET....................................................................................................................41
4.5 HÅNDHOLDTE COMPUTERSPIL................................................................................................43
4.6 OPSUMMERING......................................................................................................................44
5 TEORETISK DELKONKLUSION.............................................................................................46
III. METODE..........................................................................49
6 SYSTEMUDVIKLING................................................................................................................50
6.1 DESIGN AF PROJEKTETS SYSTEMUDVIKLINGSMETODE .............................................................51
6.1.1 Prototyping......................................................................................................................52
6.2 OPSUMMERING......................................................................................................................53
7 UDVIKLING AF COMPUTERSPIL..........................................................................................54
7.1 INDIE DEVELOPER..................................................................................................................55
7.2 DESIGNDOKUMENTET ............................................................................................................58
7.3 OPSUMMERING......................................................................................................................59
8 INNOVATION.............................................................................................................................60
8.1 TECHNOLOGY INSPIRATION....................................................................................................61

8.2 LUDIC ENGINEERING..............................................................................................................62
8.3 OPSUMMERING ......................................................................................................................63
9 METODISK DELKONKLUSION ..............................................................................................64
9.1 FRAVALGTE METODER OG ULEMPER VED DE VALGTE ..............................................................66
IV. DESIGN............................................................................67
10 FILOSOFI....................................................................................................................................68
10.1 TECHNOLOGY INSPIRATION OG MARKEDSANALYSE .................................................................68
10.1.1 Nintendogs...................................................................................................................69
10.1.2 Rainbow Six og SOCOM..............................................................................................70
10.1.3 Strange Adventures in Infinite Space og Weird Worlds .................................................71
10.2 OPSUMMERING ......................................................................................................................72
11 SYSTEM ......................................................................................................................................73
11.1 SYNTAKTISK OPBYGNING.......................................................................................................73
11.1.1 Missioner.....................................................................................................................75
11.1.2 Venner og fjender ........................................................................................................77
11.2 SEMANTISK OG PRAGMATISK OPBYGNING ...............................................................................79
11.3 OPSUMMERING ......................................................................................................................80
12 INTERAKTION...........................................................................................................................81
12.1 TAKTILT INPUT ......................................................................................................................82
12.2 STEMMEBASERET INPUT.........................................................................................................84
12.3 OUTPUT ................................................................................................................................86
12.4 MENINGSFULD LEG ................................................................................................................91
12.5 CONVERSATION FOR ACTION..................................................................................................91
12.6 OPSUMMERING ......................................................................................................................94
13 TEKNIK.......................................................................................................................................95
13.1 TALEGENKENDELSE...............................................................................................................97
13.2 OPSUMMERING ......................................................................................................................97
14 PROTOTYPER............................................................................................................................98
14.1 NUMMER 1 ............................................................................................................................98
14.2 NUMMER 2 ..........................................................................................................................100
14.3 NUMMER 3 ..........................................................................................................................101
14.4 OPSUMMERING ....................................................................................................................103
V. KONKLUSION..................................................................105
15 PERSPEKTIVERENDE DISKUSSION....................................................................................108
16 LITTERATURLISTE................................................................................................................110
16.1 BØGER ................................................................................................................................110
16.2 ARTIKLER OG OPSLAGSVÆRKER ...........................................................................................112
17 SOFTWARELISTE ...................................................................................................................116
17.1 SPIL ....................................................................................................................................116
17.2 VÆRKTØJER ........................................................................................................................117
18 BILAG A – INTERNATIONAL PHONETIC ALPHABET.....................................................118
7

Del I
INDLEDNING
Only those who try will become
Kimahri Ronso, Final Fantasy X
Under temaet formaliserede og uformaliserede sprogformer, er vi på INF3 blevet
opfordret til at udvikle innovative computersystemer, der udfordrer normerne indenfor
traditionel menneske-maskine interaktion. Hertil er det et krav at de udviklede systemer
udnytter sprog eller tekst som data eller interaktionsmedium, hvilket gennem semestrets
tilhørende kurser fører til et krav om udnyttelse af stemmebaseret in- eller output.
Et semester der opfordrer til innovation, er et semester med stor emnefrihed. Der har
været mulighed for at udvikle et væld af forskellige systemer, hvorom fællesnævneren
skulle være brugen af stemmebaserede interaktionsformer i nye kontekster. Valget af
kontekst var semestrets første store udfordring - ikke blot skal stemmebaseret interaktion
være mulig, den bør også være den optimale interaktionsform i den valgte kontekst. Det
er let at forestille sig systemer som uden større tilpasning ville kunne indføre
stemmebaseret interaktion, men det er ofte ligeså let at demonstrere hvordan
interaktionen alligevel vil fungerer bedre med traditionelle in- og outputformer som mus,
keyboard og skærm.
Tilmed er stemmebaseret interaktion, herunder både talegenkendelse og -syntese, endnu
ikke en fejlfri og uproblematisk teknologi. Det sætter nogle begrænsninger, som gør at
eksempelvis systemer der anvendes under risikofyldte forhold, endnu ikke bør
implementere stemmebaseret interaktion som en primær interaktionsform. Valget af en
kontekst hvorunder disse forhold kan accepteres er altså nødvendig, hvis der skal være
forhåbninger om reel og praktisk anvendelse af systemet.
Mit valg af kontekst er computerspil. Et medie der altid søger innovative idéer og nye
veje at gå - et kendetegn der gør computerspil til den perfekte kontekst at udvikle et
system i på dette semester.
9

Stemmebaseret interaktion er dog blevet brugt i computerspil siden 1978, hvor
Magnavox’ spillemaskine Odyssey 2 indførte primitiv talesyntese. I de seneste år er
talesyntese dog blevet brugt mindre og mindre, da mere lagringsplads og hukommelse har
muliggjort opbevaring af længere
talesekvenser af højere og mere
overbevisende kvalitet end syntetisk tale.
Talegenkendelse blev i et kommercielt
computerspil første gang set i 1999, hvor
det i spillet Seaman (Sega, 1999) var
muligt at føre en samtale med bizarre
fiskelignende væsner med menneskeansigter.
Senest er talegenkendelse
anvendt i blandt andet SingStar (Sony,
2004) hvor spilleren får point for at synge
godt, i Mario Party 6 (Nintendo, 2004)
hvor talekommandoer blandt andet bruges
til at kaste bomber efter modstanderne, og
i Nintendogs (Nintendo, 2005) hvor hunde
kan dresseres ved hjælp af
talekommandoer. Det er altså ikke hvad som helst, der kan kaldes innovativ brug af
stemmebaseret interaktion i computerspil, men med kun omkring et par håndfulde
udgivne spil der involverer talegenkendelse er området relativt uudforsket, og indbyder til
nye måder at anvende teknikkerne på, hvad der netop har været mit mål med projektet.
Talesyntese er som nævnt endnu optagne talesekvenser underlegen, men selv i dag er der
maskiner hvor mængden af lagringsplads og hukommelse gør at talesyntese alligevel har
sine fordele. En sådan maskine er Nintendo’s håndholdte spillekonsol Nintendo DS, der
med sin begrænsede hukommelse og
dyre lagringsplads 1 ikke egner sig til
lange og optagne talesekvenser.
Samtidig har Nintendo DS en
indbygget mikrofon, og kan heraf
håndtere talegenkendelse, og
maskinen er af Nintendo lanceret
med det mål at stimulere udviklingen
af nye innovative spil, hvorfor den
også har andre særlige egenskaber -
bl.a. to skærme hvoraf den ene er
trykfølsom. Det er en maskine som
jeg derfor mener, er perfekt som
platform for udviklingen af et
Figur 2: Nintendo DS, innovativ hardware skal motivere
til udviklingen af innovativ software
1 Flash hukommelse er i modsætning til f.eks. optisk lagring ikke billigt.
10
Figur 1: Seaman (Sega, 1999) var det første
kommercielt udgivne spil med talegenkendelse
computerspil der udnytter
stemmebaseret interaktion på en ny
måde.

Jeg nævnte tidligere, at den stemmebaserede interaktion selvfølgelig skal være en fordel,
i forhold til brugen af eksempelvis mus, keyboard og skærm. Det er her flere af de spil
der findes på markedet i dag, som anvender talegenkendelse, har problemer, fordi
kommandoerne ligeså vel kunne være udført med knapper og musebevægelser. Den
åbenlyse løsning er at opfinde et helt nyt spilkoncept - en type spil der ikke tidligere er
set, og hvor interaktion via tale vil virke naturligt. Det var f.eks. hvad Sega gjorde i
Seaman (Sega, 1999) hvor almindelig samtale (med en fisk…) var det centrale i spillet.
En anden løsningsmulighed er at tage et mere traditionelt spilkoncept, og lade spilleren
kontrollere flere eller andre dele af det end sædvanligt, for på den måde at give spilleren
en helt anden oplevelse med spiltypen. Det kunne eksempelvis være, at lade spilleren
styre trænerens råb fra sidelinjen i et fodboldspil. Skal stemmebaseret interaktion være en
fordel, er innovation dermed ikke blot en mulighed - det er en nødvendighed. Enten skal
der findes et nyt spilkoncept, eller et eksisterende skal omtænkes.
Valget af Nintendo DS som platform medfører dog, at de tekniske svagheder i
forbindelse med talegenkendelse (eksempelvis upræcis eller langsom genkendelse) bliver
endnu større - maskinen har ikke overvældende meget regnekraft 2 , og dens mikrofon er
ikke på højde med hvad de fleste folk har til deres pc. Min opfattelse er tilmed at
eksisterende talegenkendelsesteknik i forvejen blokerer for optimal udnyttelse af
talegenkendelse i spil (og alt anden software), fordi den er for upræcis og svag mod
forandringer. Med Nintendo DS er de tekniske svagheder endnu mere markante, hvorfor
det umiddelbart kan virke som et dårligt valg af platform. Mit mål har dog ikke været at
forbedre brugen af talegenkendelse i spil gennem teknikken alene. Talegenkendelse er i
forvejen ikke et forsømt forskningsfelt indenfor computer science, så det er ikke
sandsynligt at jeg kan gøre en forskel her, og programmering og tekniske løsninger er
heller ikke centralt for semestret. I stedet vil jeg lade svaghederne udgøre en del af spillet,
sådan at spilleren enten ikke opdager dem eller på anden vis ikke opfatter dem som
frustrerende. På den måde er Nintendo DS et godt valg af platform, da den motiverer til
bedre brug af talegenkendelse via ikke-tekniske (eller teknisk simple) midler.
2 Målt i Mhz har den én CPU på 66Mhz og en anden CPU på 33Mhz.
11

1 Problemstilling
Med semestrets og projektets grundlæggende mål fremlagt, kan den centrale
problemstilling nu formuleres således:
12
• Hvordan designes et computerspil der har stemmebaseret interaktion
som en primær interaktionsform, sådan at dette samtidig udgør den
optimale interaktionsform uden at synliggøre de tekniske svagheder?
Herunder kan følgende delproblemer opstilles for at strukturere arbejdet med
hovedproblemet:
• Hvad er stemmebaseret interaktion?
o Besvarelsen af dette spørgsmål skal belyse den teoretisk og
praktiske side af stemmebaseret interaktion. Herunder hvordan
sprog og tale kan defineres, samt hvordan det genskabes og
genkendes digitalt i og af en computer.
• Hvordan designes et godt computerspil?
o Besvarelsen af dette spørgsmål skal berøre den teoretiske del af
computerspil, samt belyse den mere praktiske eller metodiske
side af sagen. Herunder hvordan et teoretisk grundlag kan danne
en begrebsmæssig ramme om en analyse af spil, samt hvordan
samme teori kan anvendes praktisk i designprocessen.
Hertil kommer to mindre spørgsmål affødt af to for dette semester særlige forhold:
• Hvordan skabes innovation?
o Besvarelsen af dette spørgsmål skal give konkrete anvisninger i
hvordan et innovativt produkt eller en innovativ løsning skabes.
Herunder vil en række forskellige metoder blive berørt, og nogle
få vil blive belyst nøjere samt anvendt i praksis.
• Hvordan udvikles computerspil af én person alene?
o Besvarelsen af dette spørgsmål skal give konkrete anvisninger i
håndtering af en udviklingsproces med kun én person involveret,
samt i hvordan de deraf begrænsede ressourcer udnyttes sådan at
spillet ikke lider kvalitetsmæssigt.
Min strategi for udarbejdelsen af hele dette studieprojekt, og for besvarelsen projektets
overordnede problemstilling, har været først at besvare de fire delspørgsmål metodisk og
teoretisk. Det vil sige gennem studier og bearbejdelse af forskelligartet teori og relevante
metoder. Resultatet af dette arbejde er derefter blevet praktisk anvendt under udviklingen
af en prototype på et computerspil der anvender stemmebaseret interaktion. Målet med

udviklingen af spillet har været at besvare problemstillingen, og kan deraf ses som et
eksperiment der skulle lede frem til et konkret eksempel på hvordan stemmebaseret
interaktion kan være en optimal og primær interaktionsform i et computerspil, sådan at
tekniske svagheder ikke samtidig bliver tydeliggjort.
Inden jeg tager de første skridt i besvarelsen af projektets problemstilling, nemlig
præsentationen af det teoretiske grundlag, vil jeg kort afgrænse projektet.
1.1 Afgrænsning
Den vigtigste begrænsning for projektet findes i omfanget af det produkt der skal
udvikles. Der er ikke tid til at implementere et helt spil. Det er naturligvis ikke noget
fagligt problem, idet der under en fuldført udviklingsproces vil være mange gentagne
aktiviteter, hvor der ikke gøres så mange nye erfaringer.
Grundet den anvendte iterative metode (se projektets del III) vil et komplet
designdokument for spillet heller ikke eksisterer. Selvom det forholder sig sådan, så
illustrerer designdokumentet den opnåede prototype meget detaljeret, og mere overordnet
skitseres det indhold som det færdige spil forventes at få.
Teoretisk er begrænsningerne få. Teorien er udvalgt og sammensat i forhold til, hvad jeg
har fundet nødvendigt for udviklingen af et computerspil der kunne besvarelse projektets
problemstilling. Der er ikke skelet til ressourcer og forventet tidsforbrug - selvom jeg
havde haft mere tid ville indholdet af teorien ikke være meget anderledes.
Det metodiske grundlag er derimod tilpasset de tilgængelige ressourcer, sådan at
udviklingen af spillet har kunnet forløbe uden store forhindringer. Havde jeg haft længere
tid, er det ikke sikkert min udvikling havde været ligeså iterativ, men det har bestemt
været nødvendigt og fordelagtigt at arbejde sådan under dette projekt.
Opsummeret er der i projektet ingen større afgrænsninger, af andet end den udviklede
prototypes størrelse.
Hermed er projektet introduceret, problematiseret og afgrænset. God fornøjelse med del
II til V - teori, metode, design og konklusion ☺
13

Del II
TEORI
Facts are meaningless. You could use facts to prove anything that's even remotely true!
Homer Simpson, The Simpsons
En vigtig del af en projektrapport er den del, der beskriver projektets teoretiske
fundament, da det er hvor den viden projektet er udarbejdet med kan demonstreres. Jeg
mener ikke, at det er nok blot at sætte velkendt teori (primært fra kurserne) i anvendelse,
og følge den ukritisk - det skaber ingen ny viden, det er ikke selvstændigt, og frem for alt
er det kedeligt at arbejde med (og sikkert også at læse). Igennem kapitlerne har jeg derfor
forsøgt at tage et kritisk afsæt i diverse nyere grundbøger, og supplere disse med flere
mindre udbredte eller ældre artikler og bøger. På den måde har jeg fået et teoretisk
fundament der består af moderne og almindelig udbredt teori, men som samtidig drejes i
nye retninger. Resultatet er at meget få afsnit bygger på én teoretiker alene, men på flere
forskellige, hvad jeg mener både styrker og nuancerer teorien. Samtidig har det været
lettere at fokusere på, og gå i dybden med, netop de emner der er relevante for projektet,
og ikke blot hvad kurserne og grundbøgerne vægter højst.
Teorien indgår naturligvis ikke blot som et element i rapporten, men udgør også basis for
designet af det computerspil, det har været målet at udvikle. Teorien vil altså blive
introduceret i de følgende tre kapitler, men er praktisk anvendt under designet, hvad der
senere vil fremgå af projektets fjerde del.
Det centrale emne i teoriens første kapitel er sprog, hvorunder emnerne naturlige eller
talte sprog samt sprog i samtale udgør de teoretiske byggesten, som teorien om digital
genkendelse og syntese af sprog i næste kapitel kan bygges med. Hertil kommer behovet
for teori omhandlende den konkrete type af system der skal udvikles - teori om spil, hvad
de består af, og hvad der gør dem attraktive for spillerne. Det sidste kapitel i denne del af
projektet er dedikeret en opsummering og delkonklusion.
Her følger nu et kapitel, der som nævnt handler om sprog og har som mål at levere den
definition på sprog som resten af teorien kan bygge ovenpå. Det indledes med en
introduktion til sprogets grundbestanddele, hvor flere tusind års forskning tages i
betragtning. Forståelsen for hvad sproget grundlæggende består af, er nemlig ikke noget
vi først for nylig har opnået.
15

2 Sprog
Omkring 200 år før vor tidsregning nedskrev tamilske sprogforskere (digtere om man
vil), hvad der regnes for verdens ældste eksisterende grammatik, eller formelle definition
af et sprog [Jurafsky & Martin, 2000, s136]. Allerede dengang var det kendt at sproget
indeholdt både vokaler og konsonanter, og at en formel grammatik kunne beskrive
hvordan ord bestående af disse vokaler og konsonanter kunne kombineres for at danne
mening. Yderligere anvendtes abstrakte beskrivelser af lyde, det vi i dag kalder fonemer,
som grundenhed for sproget - en idé der først opstod over 2000 år senere i vesten
[Jurafsky & Martin, 2000, s136].
En forståelse af hvordan fonemer omsættes til ord, og hvordan disse sammensættes til
sætninger efter en grammatik, er dog ikke nok for at kunne forstå et sprog. Selvom en
sætning grammatisk kan eksistere i et sprog, så kan den ofte have flere meninger. Det
kaldes også tvetydighed - et problem der blandt andet er blevet behandlet i bogen
Understanding Computers and Cognition [Winograd & Flores, 1986], hvor dets forfattere
definerer sprogforståelse som en kombination af principperne for hermeneutisk læsning
af tekster, og det af se sprog som handlinger udført af aktører i en fælles kontekst
[Winograd & Flores, 1986, s54]. Det vil sige, at meningen af ytrede ord og sætninger
fortolkes af aktørerne, og påvirkes af deres kultur, forståelse af ordenes litterære
betydning, den situation de befinder sig i og måden ordene udtrykkes på. Teorien har de
konkretiseret i et eksempel på hvordan samtale kan defineres, hvad jeg senere vil
diskutere i afsnit 2.1.6.1 om sprog som handling.
Tvetydighedsproblemet eksisterer uanset hvordan sproget anskues. Ord kan være
tvetydige i deres grundform - ”bank” kan være et synonym for ”tæsk”, men det kan også
være et slag på en dør eller et sted vi gemmer penge. Der kan også være tvetydige når vi
kombinerer ord og endelser - ”kvindelig” kan være en egenskab ved en dame eller det
kan være en død kvindes krop. På sætningsniveau kan der ligeledes være tvetydighed.
”Jeg så manden med kikkerten” er det klassiske eksempel. Her kan jeg have set manden
igennem min kikkert, eller jeg kan have set en mand der havde en kikkert. At forstå sprog
handler om at håndtere tvetydighed på alle niveauer, uanset om man er menneske eller
maskine - uanset om man er studerende under det humanistisk eller naturfaglige fakultet.
Målet med de følgende afsnit er en yderligere udforskning af sprogbegrebet, primært fra
et humanistisk perspektiv, hvad der vil udgøre grundlaget for det mere naturfaglige næste
kapitel. Pladsen som grundbog vil i de følgende afsnit blive delt mellem Speech and
Language Processing [Jurafsky & Martin, 2000], der har været grundlitteratur i
projektenhedskurset Verbal interaktion i multimodal kontekst (VMK), Semantics [Saeed,
2003] der har været anvendt i kurset Sprog og tekstvidenskab (STV) og til sidst bogen
The Handbook of Linguistics [Aronoff & Miller, 2001], som jeg fik anbefalet af
underviseren i samme kursus.
16

2.1 Seks perspektiver
Det sprog vi til daglig går og taler kaldes naturligt sprog [Jurafsky & Martin, 2000, s39].
Det findes i mange varianter som f.eks. engelsk, japansk, dansk eller bornholmsk, og kan
subklassificeres i dialekter og idiolekter - regionale og individuelle variationer af et
sprog. Som grundenhed har et naturligt sprog en række af foner, der er meget korte lyde.
Når vi taler i naturligt sprog starter processen mentalt med, at vi har en idé om, hvad vi
ønsker at sige. Idéen transformerer vi om til en lingvistisk struktur ved at udvælge ord der
kan repræsentere dens mening, for derefter at sortere ordene efter grammatiske regler.
Herefter danner hjernen impulser der aktiverer muskler i blandt andet halsen, tungen og
kæben til at udtale ordene fon efter fon [Furui, 2001, s6]. Resultatet er en lydbølge, og det
er denne lydbølge som vores modtager skal danne mening ud fra. Ses det igen helt
grundlæggende, så sker det ved at modtagerens dertil indrettede organer opfanger lyden
og omsætter den til impulser der sendes til hjernen, hvor talerens afsendte lingvistiske
struktur afkodes sådan at den oprindelige idé og mening modtages [Furui, 2001, s7].
Den omtalte lingvistiske struktur kan anskues fra flere perspektiver [Furui, 2001, s6]. Det
kan gøres overfladisk [Furui, 2001, s6], men min tilgang til det vil være at inddrage hele
det lingvistiske forskningsområde, som traditionelt opdeles i områderne fonetik, fonologi,
morfologi, syntaks, semantik og pragmatik [Crystal, 1985, Contents] [Saeed, 2003, s3]
[Aronoff & Miller, 2001, Contents] [Jurafsky & Martin, 2000, Contents]. Jeg definerer
hermed en lingvistisk struktur som noget, der er udtrykt i naturligt sprog, og som noget
der kan anskues på følgende måder:
• Set fra et fonetisk perspektiv er indholdet i en lingvistisk struktur selve
lyden, bestående af en række foner. Disse kan klassificeres som enten
vokaler eller konsonanter, og der findes forskellige varianter af hver fon
alt efter hvor i en lyd den er placeret. Fonen [t] er eksempelvis ikke den
samme som fonen [t h ].
• Fonologisk set er indholdet fonemer, en abstraktion af foner, hvor alle
variationer af eksempelvis konsonanten t blot skrives /t/. Her studeres
hvordan fonerne sammensættes, og hvor i et ord de forekommer.
• Morfologisk undersøges det hvordan ord dannes og sammensættes. Det
morfologiske indhold i en lingvistisk struktur er dermed selve ordene
(der er sammensat af fonemer).
• Syntaktisk set er ordene sammensat til grammatisk korrekte sætninger
det interessante. Grammatik er altså syntaksens hovedemne.
• Meningen kaldes det semantiske i en lingvistisk struktur. Semantikken
beskæftiger sig med ting som fornuft, logik og referencer (syntaktiske)
og betegner også den lingvistiske struktur som en ytring.
• Den lingvistiske struktur påvirkes af omgivelserne den modtages i eller
afsendes fra, ligesom den påvirkes af måden den afsendes og modtages
på, hvad det pragmatiske perspektiv handler om.
Min første tanke da jeg så denne lagdelte opdeling af lingvistikken var, at mange af
områderne ikke ville være relevante for mit projekt. Der gik dog ikke mange dages
17

arbejde med de forskellige teoretiske afsnit, før det viste sig, at de fleste kunne bygges på
mindst et af de lingvistiske områder. Spil handler eksempelvis, hvad jeg også senere vil
komme ind på, om mening - altså blandt andet semantik, mens stemmesyntese omhandler
blandt andet morfologi og syntaks. Derfor er det relevant med en større indsigt i, alle de
seks dele af en lingvistisk struktur, hvad jeg vil søge at give i de næste seks afsnit.
Hertil er sprog naturligvis også, ifølge studierammerne, semestrets hovedemne. Jeg
mener derfor, at det er interessant at forsøge at se al projektets teori i et lingvistisk lys.
Om det slutteligt har været praktisk er en diskussion jeg vil tage efter projektets
konklusion, men det har skabt et i mine øjne originalt teoretisk grundlag - især hvad
angår det spilteoretiske. Jeg har dog ikke tiden til at gå i detaljer med alt, hvorfor det
indblik jeg nu giver i lingvistikkens seks områder fokuserer på hvad jeg vurderer som
værende mest brugbart i forhold til løsningen af min problemstilling (selv indenfor hvert
område er der flere modstridende retninger, hvad der ville tage mange sider at udrede).
En mere omfattende brug af lingvistikken indenfor eksempelvis det spilteoretiske område
vil være mulig, og måske noget jeg vil forsøge på et senere semester, der ikke involverer
udviklingen af et system, men her ville det være for tidskrævende og unødvendigt.
2.1.1 Fonetik
Fonetikken beskæftiger sig som nævnt med sprogets
grundlæggende lyde, eller foner, og hvordan de dannes.
Dens fornemmeste mål er at beskrive alle de foner der kan
danne verdens mange forskellige sprog [Aronoff & Miller,
2001, s151]. Det mål menes at være tæt på med det
internationale fonetiske alfabet (IPA) [Aronoff & Miller,
2001, s153] [Jurafsky & Martin, 2000, s93], der beskriver
alt fra hviskende til stønnende og raspende foner (alfabetet
kan findes i bilag A). Når vi udtaler et ord opstår en
kontinuerlig lyd, og det antages at denne kan opdeles i
mindre dele (foner), og at der kun er en endelig mængde af
disse, fordi ubevidste egenskaber, som f.eks. tænder der
klaprer eller hvislen mellem tænderne, ikke medregnes.
Dermed kan fonetikken analysere naturligt sprog.
Et særligt felt indenfor fonetikken er artikulatorisk fonetik der omhandler organernes
måde at danne fonerne på [Jurafsky & Martin, 2000, s96]. Fonerne opdeles i de to
varianter vokaler og konsonanter (og nogle gange semivokaler der er en blanding af de to
andre). Forskellen findes i måden lydene dannes på, og især i om de dannes af en muskel
i hvad der populært kaldes adamsæblet eller ej. Vokaler dannes der og har derfor en mere
markant lyd, mens konsonanter ikke bruger musklen på samme måde.
I mit projekt kan jeg bruge fonetiske observationer når jeg udvælger hvilke ord jeg vil
have min talegenkender til at lede efter. Ved at studere fonerne, og især hvilke der
udskiller sig tydeligst i en lydbølge, kan jeg øge succesraten af min talegenkender.
Hviskende foner som f.eks. [h], eller mange andre konsonanter, kan være svære at
18
Figur 3: Det internationale
fonetiske alfabet

udskille fra støj, mens kraftigere foner som [a], er lettere at genkende [Furui, 2001, s249].
Det er den for mit projekt vigtigste oplysning, fonetikken kan bidrage med. Under
designet af spillet og dens talegenkender, er de valgte ord ganske enkelt blevet studeret
fonetisk for at vurdere deres egnethed.
Der er selvfølgelig flere interessante emner indenfor fonetikken, og endnu flere detaljer
ved de emner jeg har berørt, men det har ikke så megen relevans for projektet her.
Akustisk fonetik beskæftiger sig eksempelvis med de talerafhængige kendetegn, også
kaldet ekstralingvistiske egenskaber, ved fonerne, hvilket kan udnyttes i forbindelse med
talergenkendelse. Også paralingvistiske egenskaber studeres for at kunne udskille
talerens attitude eller sindsstemning [Aronoff & Miller, 2001, s151]. Men som nævnt har
det ikke haft den store relevans for mit projekt, så jeg vil afslutte afsnittet om fonetik, og
gå videre med den næste måde at anskue en lingvistisk struktur på.
2.1.2 Fonologi
Selvom vi kan finde grundbestanddelene, fonerne, så er det også interessant at se på,
hvordan de sammensættes i forskellige sprog. Ord det begynder med bl eksisterer f.eks.
(blå, blot, blik, black, blind, bly osv.), mens ingen ord begynder med bn. Fonologien gør
dette ved at indfører ét sæt fonologiske regler (også kaldet sound inventories) pr. sprog
der beskrives [Aronoff & Miller, 2001, s183] [Jurafsky & Martin, 2000, s92]. Der findes
altså ikke noget internationalt fonologisk alfabet, som det var tilfældet med fonetikken
(IPA), men i stedet regler for hvert sprog.
I moderne talegenkendelsessystemer er en viden om en lingvistisk strukturs fonologiske
indhold essentielt, hvad jeg kort vil berøre i kapitel 3, men for mit projekt er dette indhold
mindre relevant, da jeg arbejder med en (på dette lag) simplere form for genkendelse.
Derfor vil jeg forlade emnet her, og gå videre til den tredje videnskab indenfor lingvistik.
2.1.3 Morfologi
Den automatiske stavekontrol som mange er afhængige af, er et godt eksempel på, hvad
morfologien bruges til. Morfologi omhandler de enkelte ord, og hvordan de dannes i et
givent sprog [Jurafsky & Martin, 2000, s86]. På dansk dannes flertal eksempelvis
(næsten) altid ved, at tilføje en særlig endelse til ordets stamform. Det er utvivlsomt et
vigtigt område af lingvistikken, men i mit projekt er dets eneste bidrag den indlysende
oplysning at ord er adskilt af stilhed eller ”mellemrum”. En oplysning der kan bruges når
de enkelte ord skal adskilles fra hinanden af et talegenkendelsessystem.
2.1.4 Syntaks
Hvor fonetikken og fonologien ser på enkelte lyde og morfologien ser på ord, så ser
syntaks på hele sætninger [Aronoff & Miller, 2001, s265]. Den lingvistiske struktur
bliver nu en formel konstruktion kaldet en sætning. For syntaks er følgende to danske
sætninger korrekte:
19

20
1. Denne flodhest spiser asparges.
2. Denne asparges spiser flodhest.
Hvor den sidste tydeligvis er noget vrøvl, så er den syntaktisk korrekt. Til gengæld er
følgende danske sætning ikke korrekt:
3. Asparges denne spiser flodhest.
Og det er netop målet med syntaks - at kende korrekte sætninger fra ukorrekte. Igen noget
der er vigtig for en automatisk stavekontrol, men også noget der er anvendes i dette
projekt.
En af de mest udbredte måder at definere en grammatik formelt på kaldes Backus Naur
Form (herefter BNF), der er en såkaldt kontekstfri grammatik som bruges til formelt at
beskrive kontekstfrie sprog [Jurafsky & Martin, 2000, s327]. Syntaktisk set kan naturligt
sprog ses som et kontekstfrit sprog, og det er derfor nyttigt med en sådan formalisme.
En grammatik beskrevet i BNF består af et sæt regler der udtrykker måden symbolerne i
sproget kan grupperes på, samt et leksikon af mulige symboler eller ord. Et simpelt
eksempel kunne være:
SÆTNING → X Y
X → en | et | ε
Y → flodhest | flæskesteg | asparges | ninja
Her består et sprog af alle sætninger der begynder med enten en, et eller ingenting og
slutter på flodhest, flæskesteg, asparges eller ninja. Det er let at se, hvordan langt mere
komplicerede sprog, som dansk, engelsk eller klingonesisk 3 , kan defineres på denne
måde. Selvom grammatikken i mit spil er simpel, så definerer jeg den senere i BNF for at
opnå en formel klarhed over hvilke muligheder spilleren har for interaktion via tale.
2.1.5 Semantik
Af stor betydning for projektet har også semantikken - et forskningsfelt der arbejder med
at beskrive meningen i en lingvistisk struktur. Hvor syntaksen så den lingvistiske struktur
som sætninger, så ser semantikken den som ytringer.
Semantisk mening afhænger af viden om verden, og denne viden varierer fra person til
person, hvorfor mening er svært at beskrive formelt. Et centralt problem kaldes
cirkularitet [Saeed, 2003, s6], og omhandler hvad ordbøger ofte kæmper med, nemlig at
beskrive betydningen af ét ord med flere andre ord. Skal eksempelvis meningen af
ytringen flodhesten sover tungt beskrives vil ord som pattedyr og vandhuller indgå, og
meningen med disse ord skal derfor være kendt på forhånd. Det ville blive en uendelig
cirkulær definition. Et andet problem er at to personer ikke nødvendigvis har samme
3 Et konstrueret sprog talt af racen Klingon i det fiktive Star Trek-univers [Wikipedia, Klingon language]

forståelse af ordet flodhest; det kan eksempelvis blive forvekslet med flodsvin eller
søhest, hvad der er helt andre dyr, eller nogle tror måske, at flodhesten er blå og har pels.
Indgår førnævnte ytring i en samtale er det dog ikke sikkert, at talernes forskellige
forståelse af ordet flodhest forstyrrer samtalen, men de vil efter samtalen ikke være klar
over, at de talte om to forskellige ting, hvad der naturligvis godt kan være et problem.
Semantikken har to løsninger på problemerne; enten accepteres de og det forsøges
alligevel at beskrive meningen med andre ord (helst nogle som det menes at vi har en
intuitiv forståelse af), eller også defineres et semantisk metasprog der optimalt er
uafhængigt af noget naturligt sprog [Saeed, 2003, s7]. Et muligt metasprog kunne være
logik [Saeed, 2003, s296]. Ytringen flodhesten sover og temperaturen falder kan f.eks.
med logik beskrives som S(f) ^ F(t), og ytringen flodhesten spiser enten flæskesteg eller
asparges som S(f, f ve a). Det løser ikke umiddelbart problemet med meningen af ytringer
bestående af enkelte ord, men meningen i længere ytringer kan beskrives formelt og
uafhængigt af naturligt sprog. I forbindelse med digital repræsentation af mening, er det
logiske metasprog særdeles anvendeligt, og også det jeg vil anvende igennem projektet,
men at se mening som sandhedsværdier er dog filosofisk set snæversynet [Jurafsky &
Martin, 2000, s540]. Det er ikke et emne, jeg vil forfølge yderligere, men skulle det f.eks.
belyses hvorfor computeren aldrig rigtigt vil forstå mening, er det uundgåeligt.
Udover at være en måde at anskue en lingvistiske struktur på, så er semantikken også et
underfelt til semiotikken - læren om hvordan tegn danner mening. Det er derfor relevant
med et kort indblik i semiotikken [Saeed, 2003, s5].
2.1.5.1 Semiotik
Læren om tegn og hvordan de danner mening kaldes som nævnt semiotik. Meningen med
et tegn opstår i forholdet mellem signifier og dets signified [Saeed, 2003, s5], der kan
oversættes med tegnet og dets repræsentation. Hvis f repræsenterer flodhest, så er f
signifier og flodhest er signified. Der er findes tegntyper:
• Ikon, er når der er en lighed mellem tegnet og dets repræsentation.
Eksempelvis et billede af en flodhest og den virkelige flodhest som det
viser.
• Index, er når der er et årsagsbestemt eller indikeret forhold mellem
tegnet og dets repræsentation. Røg er et index af ild, tårer er et index af
sorg eller glæde og summen kan være et index af bier (eller honning hvis
man er Peter Plys).
• Symbol, er når forholdet mellem tegnet og dets repræsentation er
vedtaget ved en konvention. Militære værdighedstegn, mange
trafikskilte, og ikke mindst bogstaver er eksempler på symboler.
Naturligt sprog kan dermed ses som et symbolsk system, da det er konventionelt vedtaget,
og det er ubestrideligt menneskets mest avancerede brug af tegn [Saeed, 2003, s5]. En
grundlæggende forståelse for semiotik er måske ikke uundværligt for at forstå
semantikken, men i forbindelse med eksempelvis designet af brugergrænsefladen i mit
21

spil kan de førnævnte tre semiotiske begreber anvendes, hvad der også er semiotikken
vigtigste bidrag til mit projekt.
Mening er dog ikke alene afhængig af tegnene, men også af konteksten hvori de
eksisterer. Det er emnet for næste afsnit.
2.1.6 Pragmatik
Forholdet mellem den lingvistiske struktur og den kontekst den indgår i er pragmatikkens
hovedemne. Det problem som pragmatikken søger at løse, er hvorfor naturligt sprog er så
let at anvende og udlede mening af (for mennesket), selvom alle ord tilsyneladende kan
tillægges utallige betydninger [Aronoff & Miller, 2001, s395]. Ligesom semantikken
skal der udledes mening, men hvor semantikken så på ytringens objektive mening, så ser
pragmatikken på dens subjektive mening. Det vil sige den mening som lytteren, taleren,
forfatteren eller læseren udleder af en ytring. Hvordan ytringer fortolkes af mennesket, er
altså groft sagt det emne der udlægges teorier om.
Den historisk mest indflydelsesrige tilgang til pragmatisk analyse er udviklet af Paul
Grice og kaldes kooperativ teori [Aronoff & Miller, 2001, s400] [Saeed, 2003, s204]. Jeg
vil ikke beskæftige mig med denne tilgang, men derimod med en tilgang der kan ses som
en videreudvikling. Speech acts blev introduceret af J. L Austin i 1975, og anvendt i
Winograd & Flores i udviklingen af en dialogmodel der tager pragmatiske forhold i
betragtning. Jeg vil nu se nærmere på denne model.
2.1.6.1 Sprog som handling
Jeg har tidligere nævnt, hvordan der i naturligt sprog er mulighed for tvetydighed. For
mennesket er det ikke et stort problem, da vi næsten altid kan danne den rigtige mening
ud af konteksten og vores viden om verden 4 . Altså ved at inddrage de pragmatiske
forhold i vores meningsdannelsesproces. For computeren er problemet derimod
betydeligt, hvis den da skal deltage i en samtale, fordi den ikke har den nødvendige viden
om sin omverden og konteksten.
Winograd & Flores foreslår en løsning på problemet. I en samtale sikrer vi os ikke imod
tvetydighed ved f.eks. at anvende ord uden flere litterære betydninger, men i stedet tager
vi blot hensyn til de pragmatiske forhold, når vi danner mening - det vil sige, at vi møder
verden som et sted vi kender godt, og hvor vi ved, hvordan vi kan handle. Herigennem
kan vi udlede meningen af ytringer, og faktisk kan der selv uden ytrede ord eksistere
mening i en samtale - kun det som ikke er indlysende ytrer vi som ord i en samtale
[Winograd & Flores, 1986, s58]. Det er denne pragmatiske tilgang til problemet, som
Winograd & Flores i 1986 forsøger at overføre til computeren. Ved at se på hele eller
dele af en samtale, frem for de isolerede ytringer skulle der være bedre mulighed for at
4 En undtagelse kan være helt små børn, da de endnu ikke har nogen stor viden om verden. Min søn kunne i
en periode, da han var lidt over 1 år gammel, ikke skelne mellem Peter Plys og pude fordi der på hans
hovedpude var et billede af Peter Plys.
22

undgå tvetydighed, og meningen med den enkelte ytring vil være mulig at udlede for
computeren.
Det er tidligere blevet foreslået, at en samtale ikke blot er ord, men også handling
[Austin, 1962] [Searle, 1969], hvad Winograd & Flores anerkender og bygger deres
såkaldte language action teori på. Austin definerer en speech act som grundelementet i
en samtale. Ved at finde de speech acts der udføres i en samtale, kan meningen i samtalen
afsløres. Searle opstiller fem forskellige typer af speech acts:
• Representatives, der binder taleren til sandheden i det udtrykte (f.eks. at
hævde eller konkludere noget).
• Directives, der er en talers forsøg på at få en modtager til at udføre en
handling (f.eks. at stille et spørgsmål eller at bede om hjælp).
• Commissives, der binder taleren til en fremtidig handling (f.eks. at afgive
løfter eller tilbud).
• Expressives, der udtrykker en mental tilstand (f.eks. taknemmelighed
eller en undskyldning).
• Declarations, der medfører ændringer i de institutionelle omgivelser der
påvirker aktørerne (f.eks. det at indgå giftermål eller at erklære krig).
Winograd & Flores mener dog ikke dette alene er nok til, til at beskrive en samtale så
formelt at en computer kan forstå den. Problemet er, at meningen i en samtale ikke kan
afgøres objektivt, men at den derimod er afhængig af aktørerne (en betragtning jeg er
enig i - det pragmatiske lag er den vigtigste meningsbærer) [Winograd & Flores, 1986,
s63]. For at løse det foreslår de en model kaldet conversation for action [Winograd &
Flores, 1986, s64], hvor den førnævnte vægtning af pragmatikken kombineres med
speech acts, for at danne det de ser som den eneste måde en samtale formelt kan
beskrives, sådan at en computer vil kunne udlede meningen.
Figur 4: The basic conversation for action [Winograd & Flores, 1986, s65]
En samtale vises som en dans med to aktører [Winograd & Flores, 1986, s64], A & B, og
illustreres i et tilstandsdiagram (eller en tilstandsmaskine). Fra den første tilstand
foretager A en efterspørgsel, hvilket giver B mulighed for at trække sig fra samtalen, at
23

ede om uddybning af efterspørgslen eller at love at efterkomme den. A kan også selv
vælge at trække sig fra samtalen. Antager vi, at B vælger at efterkomme efterspørgslen,
må B derefter bekræfte når efterspørgslen er udført. Når A er tilfreds med resultatet, eller
vælger at trække sig, så er samtalen gennemført. B kan også vælge at løbe fra sit løfte
(renege), hvilket også vil afslutte samtalen.
Modellen er så simpel, at jeg ikke finder konkrete eksempler på dens brug nødvendige. I
stedet vil jeg kritisere seks af Winograd & Flores egne pointer omkring forståelsen af
modellen, for at klarlægge de mest interessante ting ved den.
24
1. Modellen omhandler strukturen for en samtale, og ikke detaljerne i selve
samtalen [Winograd & Flores, 1986, s66]. Det er interessant, fordi målet
med modellen er en generalisering af samtale, for herigennem at gøre
det muligt for en computer at forstå den. Hvordan dette konkret løses
formår de dog aldrig at svare på, hvad der også er min kritik af
modellen. Den løser ikke umiddelbart problemet med at få en computer
til at forstå tvetydighed - men den er dog i det mindste en, efter min
mening, realistisk model af en samtale.
2. Alle relevante handlinger er lingvistiske, altså sproglige. Her tæller både
ytringer og stilhed som handlinger, mens en evt. fysisk udførsel af det
efterspurgte ikke medregnes [Winograd & Flores, 1986, s66]. Det er et
punkt der kan diskuteres, for hvad forhindrer en aktør i at udføre en
efterspørgsel uden at bekræfte den lingvistisk bagefter? Her vil
Winograd & Flores mene, at det er stilheden, der virker som bekræftelse
i samtalen, men jeg mener, at stilhed nødvendigvis må tolkes i
konteksten. Altså at stilhed både kan betyde at efterspørgslen ignoreres,
eller hvis den faktisk kognitionsmæssigt opserveres gennemført, at den
er blevet efterkommet. Her vil det nødvendigvis være selve udførelsen
der virker som bekræftelse, og ikke stilheden.
3. Deres tredje pointe forsøger at redde den forrige. Nu er selve
bekræftelsen af en udført efterspørgsel ikke en af de relevante
handlinger fra før, hvormed de tillader at den kan være ikke-lingvistisk.
Dermed kan man sige, at min kritik fra før falder til jorden, eller man
kan sige at deres model er svag fordi ikke alle dele af den har relevans
for samtalens struktur. Jeg vælger den sidste udlægning.
4. Kravene for at en bekræftelse kan accepteres er ikke objektive, men
bundet til samtalens aktører [Winograd & Flores, 1986, s66]. Det vil
sige, at aktørerne kan blive uenige om, hvornår en efterspørgsel er
udført, hvad der kan føre til et nedbrud i samtalen, hvor A mener, at B er
løbet fra sit løfte, mens B ikke forstår hvorfor A ikke kunne acceptere.
Det er interessant, fordi subjektivitet får en stor betydning for samtalens
udfald, og i mine øjne udelukker at modellen kan overføres direkte til en
computer.
5. En afsluttet samtale garanterer ikke at aktørerne er tilfredse med udfaldet
[Winograd & Flores, 1986, s66]. Ser man på figuren er denne pointe

naturligvis åbenlys, da det fra alle samtalens tilstande er muligt at
afbryde den.
6. Diagrammet siger ikke, hvad aktørerne burde gøre, eller hvad
konsekvenserne af handlingerne er [Winograd & Flores, 1986, s66]. Det
er naturligvis vigtigt for en samtale, hvad den resulterer i, men på så lavt
et niveau er det ikke noget der kan have en indflydelse. Modellen
repræsenterer jo kun et lille brudstykke af en egentlig samtale, der oftest
vil udgøres af mange sådanne modeller efter hinanden.
Efter at have overvejet de seks pointer, er jeg nået til den konklusion, at modellen ikke
egner sig til en egentlig implementering i et computerbaseret system der har som mål at
forstå og deltage i en virkelig samtale. Derimod mener jeg, at det med modellen faktisk er
muligt at konstruere strukturen i de fleste samtaler (dog nogle mere kunstigt end andre)
på et detaljeret niveau, hvis systemet da kender til samtalens kontekst. Dermed vil et
system opnå en form for subjektiv forståelse for situationen (mulighed for at inddrage
pragmatiske forhold), hvormed dens handlinger vil kunne virke meningsfulde. Et system
der kan reagere troværdigt i et afgrænset domæne, vil altså kunne have en samtalestruktur
der kan beskrives i conversation for action-modellen.
Derfor vil modellen senere blive brugt til analyse, af det i rapporten beskrevne, og på
semestret designede, spils dialog med spilleren, hvor domænet netop er meget begrænset.
2.2 Opsummering
Herfra vil sprog (naturligt sprog) være defineret som en lingvistisk struktur der kan
anskues fra seks forskellige perspektiver - de seks perspektiver som netop er beskrevet.
Denne definition på hvad et naturligt sprog er, og indsigten der gives af de seks
perspektiver, kan den næste del af teorien nu udnytte.
I resten af rapporten anvender jeg de begreber der er fremlagt hidtil, f.eks. fonemer og
semantik, uden at omdefinere eller gendefinere dem, men vil naturligvis forsøge at
konkretisere dem i den kontekst de anvendes.
Her indledes kapitel 3 der igen omhandlende emnet samtale med en computer, men hvor
mere tekniske tilgange til problemet belyses.
25

3 Stemmebaseret interaktion
Når computeren skal deltage i en samtale, skal den kunne generere lingvistiske strukturer
for at afsende dem til en modtager, og den skal kunne opfange lingvistiske strukturer og
afkode dem fra alle førnævnte seks perspektiver for at modtage mening fra en afsender.
Det er min egen formulering, tilsat teorien fra sidste kapitel, af målet for stemmebaseret
interaktion. Den er analogt med, hvad Jurafsky & Martin skriver i Speech and Language
Processing [Jurafsky & Martin, 2000, s3], om målet med det fag der traditionelt set
kaldes Natural Language Processing (NLP). Bogen vil igen i dette kapitel gøre det ud
som grundbog, denne gang suppleret af Digital Speech Processing, Synthesis, and
Recognition [Furui, 2001] og Fundamentals of Speech Recognition [Rabiner & Juang,
1993] der er stærkere, hvad angår nogle af de (lidt ældre) teknikker jeg har anvendt i mit
spil.
Netop de teknikker der er anvendt i spillet, som det har været projektets mål at udvikle, er
da også fokus for dette kapitel, om end jeg vil forsøge at give et overblik over hele NLPområdet,
da der trods alt er brugt meget tid herpå i projektenhedskurset VMK.
I dette kapitel vil jeg starte med at se på opfangelsen af lingvistiske strukturer - det der
kaldes talegenkendelse, for derefter at se på genereringen af dem - det der kaldes
talesyntese. Afslutningsvis vil jeg se på, hvordan disse to bindes sammen af en
dialogmanager, hvorunder flere forskellige tilgange til praktisk opsætning af
stemmebaseret interaktion belyses.
26

3.1 Talegenkendelse
Talegenkendelse er en kompliceret proces, der har som sit grundlæggende mål at
digitalisere alle dele af en lingvistisk struktur modtaget fra et menneske. Jeg indleder
afsnittet med en illustration af processen, som den (optimalt) kan se ud:
Figur 5: Talegenkendelsesprocessen. Udvidet og generaliseret udgave af figure 7.2 fra [Jurafsky &
Martin, s241, 2000]
27

Figur 5 skal læses oppefra og ned, og viser hvilke generelle teknikker der anvendes
igennem talegenkendelsesprocessen, samt hvad resultatet af hver teknik er. Desuden
fremgår den lingvistiske disciplin som teknikkerne bygger på. Det bør bemærkes at der
vides gradvist mindre om den optimale tekniske håndtering for hvert trin ned igennem
modellen. Sprogets foner og hvordan de repræsenteres digitalt er i dag et forholdsvis
veludviklet felt indenfor NLP, mens der om analysen af ytringens mening, de semantisk
og pragmatiske lag, vides meget lidt. Her følger en gennemgang af illustrationen.
Det første der sker, er at den lingvistiske struktur opfanges af mikrofonen som en akustisk
lydbølge, der af computeren omsættes til et digitalt signal. Dette signal har en frekvens
(sample rate eller sample frequency) på eksempelvis 8Khz, hvilket vil sige 8000
informationer i sekundet, og disse informationer har en opløsning (resolution) på
eksempelvis 8 bit, hvilket vil sige en værdi mellem 0 og 255 hvor 128 er stilhed 5 . Det
første genkenderen gør, er at opsplitte signalet i mindre frames på f.eks. 10ms. Det er den
teknik der kaldes signalbehandling, hvorunder også en reducering af støj hører til. Fra
hver af disse frames fremstilles nu en featurevektor (feature vector), der er en abstrakt
beskrivelse af energien fordelt over de 10ms. Den mest udbredte teknik til beregning af
featurevektorer kaldes Linear Predictive Coding (LPC), hvor en featurevektor så kan
kaldes et LPC-spektrum. I det næste skridt anvendes probabilistiske metoder
(gaussmodeller og neuralske net) til at udlede den statistiske sandsynlighed for at en
featurevektor repræsenterer en bestemt fon, hvorefter en dekoder-algoritme matcher disse
sandsynligheder med et leksikon for at finde de ønskede fonemer. Dekoder-algoritmen
der ofte bruges er Viterbi, men også A* som jeg selv kender fra stifinderalgoritmer i
spilprogrammeringen kan anvendes. Det leksikon der søges i, er i dag ofte en Hidden
Markov Model (HMM), der kan beskrives som en model over et ord eller en fonem,
bygget op som statistisk vægtede tilstandsmaskiner [Jurafsky & Martin, 2000, s241].
Resultatet af dekoderens arbejde er som sagt nogle fonemer, som forholdsvis let kan
omsættes til ord. Ønskes der kendskab til ordenes syntaktiske sammensætning, kan dette
kontrolleres i næste skridt ved at sammenligne ordene med en kontekstfri grammatik i
f.eks. BNF. Er en sætning ikke grammatisk godkendt, kan den afvises inden der søges at
udføre en semantisk og evt. pragmatisk analyse. Hvordan disse sidste skridt foretages er
der ingen klare retningslinjer for, men det er dog her at selve meningen i den lingvistiske
struktur er at finde. Jeg har valgt at illustrere resultatet af en semantisk analyse som et
logisk udtryk, da det er den metode jeg anvender, men der er også andre muligheder. I
forbindelse med det pragmatiske er det conversation for action-modellen som jeg
tidligere har beskrevet der trækkes på.
Alt efter hvor avanceret en talegenkender der ønskes kan nogle lag simplificeres eller helt
undværes. Der skelnes ofte mellem genkendelse af enkelte ord og hele sætninger, mellem
talerafhængighed og -uafhængighed og mellem genkendere med henholdsvist et lavt og et
højt ordforråd. Modellen beskrevet ovenfor er velegnet til genkendelse af hele sætninger,
uafhængig af taler og over et stort ordforråd. For mit projekt er dette uopnåeligt, da jeg
har haft som mål at implementere en talegenkender på Nintendo DS, der er en meget lidt
5 Ofte anvendes et signed signal sådan at opløsningen går fra -128 til 128 hvor 0 så er stilhed.
28

kraftfuld maskine, mens HMM og Viterbi-algoritmen stiller store krav til regnekraft.
Derfor må jeg simplificere modellen, til noget der minder om hvad der i 1993 blev anset
for den mest praktiske arkitektur i et talegenkendelsessystem [Rabiner & Juang, 1993,
s44]. Rabiner og Juang kalder det for en Statistical Pattern-Recognition Approach to
Speech Recognition [Rabiner & Juang, 1993, s51], hvad der kan illustreres således:
Figur 6: En simplere talegenkender baseret på Statistical Pattern-Recognition
Som det fremgår, er det fonologiske lag nu helt væk, og fonetikken er sat i parentes da
dens informationer reelt ikke anvendes i genkendelsesprocessen. Resultatet efter
behandlingen af det morfologiske lag er dog det samme som sidst, hvorfor syntaktisk,
29

semantisk og pragmatisk information stadig kan udledes på samme måde. Jeg vil nu
gennemgå det morfologiske lag, som denne gang er mere kompliceret.
Signalet opdeles som sidst i frames, men nu er det ikke featurevektorer der udledes, men
derimod test patterns som afmåles. Denne afmåling foregår ved at der søges efter
perioder uden stilhed, og disse perioder benævnes så test patterns - der reelt er de ord
eller morfemer der tales ind i mikrofonen. Teknikken kaldes også speech-period
detection [Furui, 2001, s248]. En test pattern udsættes for samme behandling som en
featurevektor, nemlig en LPC-analyse, eller i stedet en diskret fourier transformering
(DFT) der har samme formål (altså at abstrahere de generelle træk over hele perioden),
men kan være betydeligt mindre beregningskrævende, hvis det er en algoritme af typen
fast fourier transform (FFT). Disse test patterns sendes i næste skridt videre til pattern
comparison-modulet, der sammenligner dem med foruddefinerede test patterns og giver
et statistisk output, som beskriver hvilke ord de ligner mest. Teknikken der almindeligvis
anvendes til at sammenligne med kaldes dynamic time-warping. Dens formål er at
kompensere for variationer i hastigheden et ord udtales i, ved at strække det til den
samme længde som den foruddefinerede test pattern der sammenlignes med har [Rabiner
& Juang, 1993, s51], og samtidig gøre dette sådan at de forskellige udsving i lyden
matches overfor hinanden. Til sidst vælges blot den test pattern med størst
sandsynlighed, hvorefter et ord er genkendt og kan sendes til syntaktisk analyse.
Alt dette kan gøres uden et stort behov for regnekraft, og det er derfor den arkitektur jeg
har valgt at bygge talegenkendelsen i mit spil op omkring. Der er naturligvis også
ulemper ved denne arkitektur. I forhold til tidligere nævnte klassificering, så er det en
talegenkender der er talerafhængig, har et lavt ordforråd og som ikke genkender lange
sætninger (medmindre de kan dannes af ordforrådet). Det betyder konkret, at
genkenderen skal trænes af alle som anvender den, og at de skal træne alle de ord som
den skal kunne genkende (derfor er et begrænset ordforråd at foretrække). Ved træning af
genkenderen er det heller ikke optimalt blot at indtale det ønskede ord en enkelt gang, da
et gennemsnit af flere indtalinger vil give den en større succesrate. Der er altså nogle
markante svagheder, men en genkender som denne kan opnå en fejlprocent der ikke
ligger langt fra en moderne talegenkender - hvis førnævnte forhold tages i betragtning.
Efter denne introduktion til talegenkendelse og arkitekturen bag, vil jeg fortsætte med de
relaterede emne talesyntese.
3.2 Talesyntese
Hvor målet med talegenkendelse er at opfange og fortolke lingvistiske strukturer, så er
målet med talesyntese at generere en lingvistisk struktur komplet med pragmatisk og
semantisk mening, syntaktisk korrekthed og velvalgte foner. Det er igen ikke nogen let
opgave, men dog en opgave der i dag løses ganske flot af flere talesyntesesystemer. En ny
illustration er ikke nødvendig, da Figur 5 fra sidste afsnit stort set blot kan vendes på
hovedet.
30

En talesynteseproces starter med, at computeren udleder mening af situationen, for
derefter at konstruere et logisk udtryk der kan repræsentere denne mening. F.eks. win(I).
Denne omdannes så til en sætning - her ”I win”. Fra dette punkt påbegyndes en proces
der kaldes text-to-speech [Jurafsky & Martin, 2000, s92], hvor målet er at omdanne en
tekststreng til en akustisk lydbølge. Der er overordnet set fire måder dette kan gøres på.
• Den første er at optage en begrænset mængde hele ord og sætninger, for
at kunne afspille kombinationer af disse, hvad der giver den højeste
naturlighed i lyden, men det at skulle optage alle ord på forhånd er ofte
en klar ulempe. Både fordi det stiller store krav til lagringsplads, men
også fordi det tager lang tid at implementere hvis ordforrådet skal være
stort. Til gengæld er det beregningsmæssigt simpelt [Furui, 2001, s217],
i det der ikke kræves andet end afspilning af ordene (evt. kan der
foretages en behandling af ordene afhængigt at hvor i en sætning de
placeres). Denne metode anvendes eksempelvis i alle nye fodboldspil,
hvor en kommentator kommenterer kampen. Jurafsky & Martin
beskriver slet ikke denne mulighed, og den er da også meget simpel,
men den er bestemt velegnet til mange formål.
• En anden mulighed er at analysere en mængde af optagne ord, og
opsplitte disse i mindre bidder. Disse bidder kan derefter benævnes
fonologisk, og flere ord kan så dannes ved at kombinere fonemer til
morfemer. Dette kan forbedres gennem anvendelsen af statiske metoder
som HMM, i sprog som dansk og engelsk hvor der ikke er en tydelig
sammenhæng mellem måden et ord staves på, og måden det udtales (og
dermed beskrives fonologisk). Dette er da ikke største problem ved
denne metode. Problemet er i stedet at fonemer ikke indeholder
tilstrækkeligt med information om hvordan en lyd skal udtales, fordi de
blot er abstrakte beskrivelser af en lyd. Derfor kommer talen med denne
metode ikke til at lyde helt naturlig, men til gengæld er den simplere at
implementere end den næste metode [Furui, 2001, s221].
• I forhold til førnævnte medtages nu fonetisk information, hvad der gør
processen langt mere kompliceret og beregningskrævende fordi der
kræves et stort kendskab til hvordan ord almindeligvis udtales, hvad der
også gør at processen kræver meget lagringsplads. Her lagres også
såkaldte triphones og diphones der er kombinationer af foner, hvormed
overgangene mellem dem kan virke mere naturlig [Furui, 2001, s221].
• Til sidst er der såkaldt formant synthesis som er den form for syntese der
blev anvendt i Magnavox’ Odyssey 2 spillemaskine fra 1978 (og tidligere
udenfor spilindustrien). Teknikken foreskriver ren syntetisk fremstilling
af tale, ved at beskrive foner som frekvenser. Det giver ikke et naturligt
resultat, men det er dog alligevel forståeligt, hvad der i nogle situationer
også kan være det vigtigste ved talesyntese.
31

Med Nintendo DS som platform for spillet er den tredje mulighed udelukket, og da jeg
ønsker at mit spil skal tale engelsk er beregningskrævende statistiske metoder nødvendigt
for at skabe naturlig tale med den anden mulighed. Tilbage står den første og sidste
mulighed, hvor jeg vælger den første, fordi jeg ikke har behov for et stort ordforråd og
foretrækker naturlighed over syntetisk tale. Denne metode er dog teknisk så simpel, at der
ikke er behov for yderligere teori i dette afsnit. Det bør selvfølgelig understreges at det
igen er de pragmatiske og semantiske lag som der vides mindst om, hvorfor det trods den
simple teknik på det morfologiske lag (og derunder), er en stor udfordring at få
computeren til at sige noget der giver mening. Mit værktøj på dette område bliver igen
conversation for action-modellen, som blev beskrevet i afsnit 2.1.6.1.
Her ophører min behandling af talesyntese, og jeg vil nu i stedet belyse stemmebaseret
interaktion fra et HCI eller usability-perspektiv.
3.3 Dialogmanagement
At tildele en lingvistisk struktur mening og en position i en samtale håndteres af
førnævnte modeller. At holde samtalen i gang og sikre at den går i den rigtige retning
håndteres derimod af dialogmanageren. I Jurafsky & Martin belyses dette emne kun
overfladisk, hvorfor vi i VMK-kurset også anvendte bogen Spoken Dialogue Technology
[McTear, 2004]. Her præsenteres en række tilgange til dialogmanagement:
32
• Command and control benævnes ikke som en dialogbaseret
interaktionsform, idet brugeren blot giver systemet korte forudbestemte
kommandoer [McTear, 2005, s10]. Jeg mener dog at der kan være tale
om en dialog, i det systemet reagerer på kommandoen. Det er den
samme diskussion som jeg tog i afsnit 2.1.6.1, og jeg mener stadig, at en
fysisk reaktion på en kommando tæller som en del af samtalen. Derfor
mener jeg command and control er en tilgang til dialogmanagment,
selvom den ikke nævnes i kapitlet herom [McTear, 2004, k5].
• System-directed initiative er en af de i alt tre former for ”rigtig”
dialogmanagment som McTear beskriver [McTear, 2004, s108]. Her er
det systemet som styrer samtalen, og på den måde forhindrer brugeren i
at være i tvivl om sine interaktionsmuligheder. I Jeopardy-jargon vil det
være brugeren der har svarene, mens systemet stiller spørgsmålene. Den
største fordel ved denne tilgang er at ordforrådet kan specificeres eller
optimeres på forhånd, fordi spørgsmålene kan stilles sådan at der ikke er
mange forskellige måder at svare på.
• User-directed initiative er den anden tilgang til dialogmanagment som
McTear beskriver [McTear, 2004, s109]. Her er det nu systemet der har
svarene, mens brugeren stiller spørgsmålene. Det stille normalt store
krav til systemets NLP-evner, da brugeren kan formulere sine spørgsmål
meget forskelligt - især hvis der er tale om et system der skal anvendes
af flere brugere. User-directed initiative har tydelige ligheder med

command and control, hvor der det også er brugeren der styrer dialogen,
men med et større ordforråd er der ikke ligeså store begrænsninger i
måden brugeren kan udstede kommandoer.
• Mixed-initiative er den sidste af de overordnede tilgange til
dialogmanagement, og her er det nøjagtigt som det lyder både muligt for
systemet og brugeren at tage initiativ. Brugeren kan eksempelvis besvare
et spørgsmål med et spørgsmål. Det giver et fleksibelt system, men det
er naturligvis også sværere at designe.
• Agent-based er ikke en egentlig tilgang til dialogmanagement, men i
stedet en interessant udvidelse af de førnævnte. Det interessante er at der
nu trækkes på teknikker fra kunstig intelligens (AI), idet dialogen
modelleres som en problemløsningsopgave mellem to intelligente
agenter (hvor den ene er brugeren) [McTear, 2004, s116]. Systemet vil
reagere intelligent på brugerens spørgsmål eller kommandoer, ved at
analysere situationen og brugerens input og giver en meningsfuld
reaktion. Her må systemet naturligvis have informationer om målet med
dialogen og konteksten den befinder sig i, for at give en meningsfuld
intelligent reaktion.
Der er altså flere tilgange til dialogmanagement, og mange ting som bør overvejes inden
stilen vælges. I min situation ville system-directed initiative være praktisk muligt, men
den forhørsagtige dialog der fremkommer, er ikke passende for et spil - her er det efter
min mening spilleren der bør kontrollere forløbet. Af samme årsag mener jeg command
and control er en langt bedre tilgang, og det er denne jeg har kombineret med en agentbased
udvidelse sådan at systemet reagerer fornuftigt næsten uanset brugerens input.
Hvordan det konkret er gjort vil jeg beskrive nærmere i projektets fjerde del, mens målet
nu er at udforske dialogens forskellige modaliteter.
3.3.1 Multimodalitet
Den åbenlyse form på en dialog er at lade den være baseret på tale, men også andre
modaliteter kan med fordel have en plads i dialogen. Der kan tales om både multimodalt
input og multimodalt output [McTear, 2004, s379]:
• Multimodalt input er hvor brugeren kan give systemet information
gennem flere forskellige modaliteter, som f.eks. tale, mus, keyboard og
trykfølsom skærm. Et eksempel kunne være at brugeren peger på et kort
med musens cursor, og stiller et spørgsmål via tale. Der kan desuden
skelnes mellem om input som i eksemplet foregår samtidigt, eller om
brugeren kan vælge mellem flere modaliteter som tilbyder samme
funktionalitet, men har forskellige fordele og ulemper. Man kan
forestille sig en bilradio der kontrolleres via en trykfølsom skærm når
bilen holder stille, og via tale når den kører - Ford har allerede
eksperimenteret med dette [McTear, 2004, s384]. Der kan også skelnes
33

34
mellem aktiv og passiv input. Nogle talegenkendelsessystemer supplere
den akustiske genkendelse, med visuel aflæsning af brugerens læber
hvad der kan betegnes som passivt input, eller som en bivirkning af aktiv
input. På sidste semester var jeg med til at udvikle et spil der modtog
input via spillerens bevægelser foran et kamera, men i denne situation er
det visuelle input at betragte som aktivt fordi brugeren bevidst søger at
give systemet input ad denne vej.
• Multimodalt output inkluderer blandt andet tale, anden form for lyd,
grafik af forskellig art, tabeller og tekst. Ved multimodalt output
udnyttes styrker og svagheder ved de forskellige modaliteter, til at give
brugeren den information han har brug for på den bedste måde.
Søgeresultater, delene i en kompliceret samlevejledning eller andre typer
af lister fungerer eksempelvis ikke så godt som oplæsning, mens de
hurtigt kan læses i et skema.
Der findes mange systemer som udnytter stemmebaseret interaktion som den eneste
modalitet, og eksempelvis via en telefon er det også eneste mulighed. Men er der en
begrundet mulighed for at indføre multimodalitet, så har flere undersøgelser vist at
brugerne faktisk foretrækker dette [McTear, 2004, s381]. Det er da også klart at
kombineres styrker og svagheder ved forskellige modaliteter, kan en langt mere naturlig
og robust interaktion med systemet opnås. Det ville selvfølgelig være originalt at lave et
spil med tale som den eneste modalitet, men jeg er ikke sikker på at det ville være et sjovt
spil, så jeg har valgt en multimodal tilgang til både input og output, hvormed jeg får det
bedste fra alle verdener med. Igen er det dog noget jeg kommer nærmere ind på i
projektets fjerde del om designprocessen. Her følger nu en opsummering på hele kapitlet
om stemmebaseret interaktion.
3.4 Opsummering
Igennem kapitlet er stemmebaseret interaktion blevet belyst på flere måder, og
indledende bestemt som hørende under det forskningsfelt der kaldes Natural Language
Processing (NLP). Jeg har beskrevet hvordan et moderne talegenkendelsessystem
fungerer ved at fortolke alle seks lag i en lingvistisk struktur, samt hvordan jeg har
simplificeret dette ved at udnytte ældre teknikker til morfologisk genkendelse, uden at
ødelægge mulighederne for den vigtige semantiske og pragmatisk genkendelse. Hvad
angår talesyntese har jeg beskrevet fire forskellige muligheder, hvoraf de simpleste
gengiver tale ved enten at efterligne frekvenserne i de foner naturligt sprog består af, eller
ved simpelthen at afspille sammenklippede ord og sætninger. De mere avancerede
muligheder for talesyntese klipper ord og sætninger ud i mindre stykker, analyserer og
klassificerer dem fonologisk og anvender statiske metoder i sammensætningen af dem.
Kapitlet blev afsluttet med at introducere hjernen bag stemmebaseret interaktion, den
såkaldte dialogmanager, samt flere forskellige tilgange til designet af denne.
Nu er tiden kommet til det sidste større kapitel i projektets teoretiske del.

4 Computerspil
Sprog og en digitalisering heraf, udgør den første del af det teoretiske fundament
systemet er designet på. Min forståelse for disse del er blevet udlagt i de foregående
kapitler, og målet er nu at belyse den sidste del - computerspil, hvad de består af og hvad
der gør dem attraktive for spillerne.
I lang tid rasede en verbal krig mellem to lejre - de som mener computerspil bør defineres
som historiefortælling (narratologerne), og de som mener computerspil bør defineres som
leg (ludologerne). Det er som sådan ikke en krig der er slut, men heldigvis en krig mange
har vendt ryggen [Ludologica, 31-08-2005 6 ]. Forskerne er begyndt at indse, hvad
spillerne har været klar over i årevis - at historiefortælling og leg kan eksistere side om
side. Det er også min opfattelse. Kodeordet er for mig selve oplevelsen af spillet, og den
mener jeg primært afhænger af det enkelte individ - nøjagtig som meningsudledning for
pragmatikerne er subjektivt. Nogle vil f.eks. finde spil med en stærk historiefortælling
bedst, mens andre vil finde historien ubetydelig og i stedet blot nyde spillets mere
legende elementer. Jeg mener kort fortalt, at spil kan opleves på utroligt mange måder,
afhængig af individet der oplever dem. Det betyder ikke, at spil kan defineres som alt fra
tidsfordriv til forskning, eller at alt fra krig til kærlighed er spil - det er stadig muligt at
definere præcist hvad spil er, men selve oplevelsen er hovedsageligt afhængig af
individet. Det betyder dog heller ikke, at oplevelsen er så afhængig af individet at alle
forsøg på at skabe et godt spil er ligegyldige - der findes en række generelt gældende
kvalitetskrav til et spil, som er uafhængige af individet der spiller og dets præferencer for
særlige temaer, genrer eller hovedpersoner med store bryster. Mit mål i dette kapitel er at
præsentere en generel og multifacetteret definition på computerspil, hvoraf en række
evigtgyldige kvalitetskrav kan udledes.
Min opfattelse vejer dog i en 5. semesters projektrapport ikke så meget som anerkendte
teoretikeres, og erfarne praktikeres, hvorfor jeg selvfølgelig har studeret flere af dem for
at skrive dette kapitel. Salen & Zimmerman har i 2004 udgivet bogen Rules of Play, der
på kort tid er blevet en indflydelsesrig grundbog indenfor spilteori og -design (den
anvendes blandt andet på AAU’s spiluddannelser), og den vil udgøre grundlaget for
kapitlet. De deler min multifacetterede opfattelse af computerspil, og præsenterer i bogen
mange forskellige teoretikeres og praktikeres synspunkter på de samme emner. Jeg har
ikke behov for at diskutere eller belyse alle synspunkterne, så jeg vil fokuserer på Salen
& Zimmermans sammenfatninger af dem, men vil naturligvis supplere med yderligere
teori eller kritik hvor jeg finder det nødvendigt.
Som Salen & Zimmerman vil jeg nu indlede det spilteoretiske kapitel med en
grundlæggende definition. Mit mål er at opnå en forståelse for hvad spil er, for
derigennem teoretisk at kunne beskrive og analysere de elementer mit eget spil består af.
6 http://konzack.blogspot.com/
35

4.1 Meningsfuld leg
Helt grundlæggende indeholder spil en form for leg 7 [Salen & Zimmerman, 2004, s83].
Det er derfor givtigt at tale om, hvad leg er. Det har hollandske Johann Huizinga, den vel
nok største og mest indflydelsesrige forsker indenfor området, gjort i bogen Homo
Ludens [Huizinga, 1949]. Her beskriver han, meget kort fortalt, leg som en betydelig og
meningsfuld aktivitet. Forstået som at udøverne tillægger legens handlinger mening, og at
legen har en umiddelbar indflydelse på deres liv og behov, hvorfor den også er betydelig
for dem. Salen & Zimmerman finder i denne definition af leg den grundlæggende kvalitet
ved ethvert spil:
36
The goal of successful game design is the creation of meaningful play
[Salen & Zimmerman, 2004, s33]
Altså er målet med ethvert spil, at spillerne oplever mening med den leg der dannes når
det spilles. Ganske som mening er målet med en samtale i naturligt sprog. Meningsfuld
leg dannes dog ikke blot af spillet selv, men gennem spillernes interaktion med det system
der beskriver spillet, og den kontekst spillet spilles i [Salen & Zimmerman, 2004, s33].
Igen er der tydelige paralleller til lingvistikken, hvor pragmatikken også beskriver,
hvordan mening afhænger af konteksten. Det udsagn antyder desuden, at spil består af et
system der begrænser spillernes interaktionsmuligheder, eller deres valg og handlinger.
Dermed kan det udledes, at den meningsfulde leg reelt opstår i forbindelsen mellem
spillerhandling og systemets reaktion herpå.
For at designe eller analysere et spil, der kan danne meningsfuld leg, er det dog også
nødvendigt at evaluerer forbindelsen mellem spillerhandling systemreaktion - altså at
finde frem til hvornår meningsfuld leg vil opstå, og ikke blot hvor den vil opstå. Salen &
Zimmerman skriver, at meningsfuld leg opstår, når forbindelsen mellem spillerhandling
og systemreaktion er synlig, samtidig med at den er integreret i hele spillets kontekst
[Salen & Zimmerman, 2004, s34].
• Synlighed handler løst defineret om de grundlæggende HCI-begreber,
som vi på tidligere semestre er blevet undervist i. Jeg vil ikke gentage
teori her, men det grundlæggende er at brugeren / spilleren skal forstå
reaktionen på en udført handling. Uden synlighed kunne spilleren trykke
tilfældigt på maskinens knapper og opnå tilfældige reaktioner, hvormed
meningsfuld leg aldrig ville opstå. Det kan også forklares med de
semiotiske begreber jeg introducerede tilbage i afsnit 2.1.5.1 om
semiotik. Ses spillets kommunikation med spilleren som tegn, så vil
disse tegn bestå af ikoner, index’er og symboler. Ikoner (enten grafiske
eller auditive) vil være oplagte, hvis spilleren skal have en klar og
tydelig reaktion der ikke kan overses, mens et index vil være oplagt i
situationer, hvor det ønskes, at spilleren selv gør en indsats for at finde
7 Det kan også diskuteres om det forholder sig omvendt - at leg indeholder spil, hvad Salen & Zimmerman
også gør. Jeg mener dog ikke det er diskussion der bidrager praktisk til mit projekt, og undlader derfor at
deltage i den.

tegnet. Hvis spilleren eksempelvis søgte ild, ville røg være det index hun
skulle lede efter. Anvendelsen af symboler vil være mere problematisk,
da deres mening som nævnt tidligere er konventionelt vedtagne, og
derfor har risiko for ikke at betyde det samme i alle kulturer. Et
eksempel kunne være at antage, at spillerne kender til de engelske
symboler for forskellige stjernetegn - det har jeg oplevet på egen krop i
Dark Chronicle (Sony, 2002).
• Integration i en større kontekst handler om det jeg i mine
spilanmeldelser plejer at kalde dybde. En handling skal ikke blot have en
synlig reaktion, men der skal også på længere sigt være betydelig
indvirkning på forholdet mellem spillerhandling og systemreaktion. I
fodbold kan en hård tackling få den umiddelbare reaktion at et mål til
modstanderne forhindres, mens det røde kort tacklingen koster på
længere sigt kan betyde, at resten af holdet må arbejde hårdere. I skak
påvirker åbningen på spillet forløbet af spillet og de muligheder spilleren
står tilbage med til sidst. Det er sådanne forhold der giver et spil dybde
eller, med Salen & Zimmermans ord, sikrer at forholdet mellem
spillerhandling og systemreaktion er integreret i hele spillets kontekst.
Hvor synlighed fortæller spilleren, hvad handlingen resulterede i, så
fortæller integrationen, hvordan den vil påvirke resten af spillet [Salen &
Zimmerman, 2003, s35]. Hver eneste handling en spiller tager, skal altså
have indflydelse på den samlede spiloplevelse. Semantikken vil her tale
om referencer. En handling skal medføre, at der efter en handling er
udført, og på et senere tidspunkt i spillet, opstår referencer tilbage til
denne handling.
For at supplere Salen & Zimmerman’s definition af meningsfuld leg, og hvordan dette
dannes i et spil, vil jeg citere spildesigner Sid Meyer - hovedansvarlig for store klassikere
som Civilization [MicroProse, 1991] og Pirates! [MicroProse, 1987]:
A game is a series of interesting choices
[Rollings & Morris, 2003, s68]
Når Salen & Zimmerman taler om integration, så taler de om, at handlinger skal påvirke
fremtidige systemreaktioner. Sid Meyer siger, at disse handlinger (et valg er også en
handling), tilmed skal være interessante - forstået som at de for spillerne skal have både
negativ og positiv indvirkning på den umiddelbare og/eller fremtidige systemreaktion.
Spillerne bør skulle vurdere konsekvensen ved en handling, hvormed enhver handling
bliver et valg, hvad jeg også senere vil argumentere for er tilfældet i et spil. Om Sid
Meyer mener, at der ikke er tale om et spil hvis valgene ikke er interessante er uvist, men
det er givet, at han mener, at interessante handlinger er et kvalitetskriterium.
Fra dette afsnit kan jeg udlede tre kvalitetskrav, som jeg i mit spil skal søge at opfylde for
at det kan danne meningsfuld leg:
37

38
• Synlighed, at enhver handling afføder en tydelig og umiddelbar reaktion.
• Integration, at enhver handling påvirker den samlede spiloplevelse på
lang sigt.
• Interessante handlinger, at enhver handling har en negativ og positiv
konsekvens.
I de næste tre afsnit vil jeg se på de tre generelle koncepter; design, systemer og
interaktivitet, der til sammen gør det muligt for designeren at konstruere meningsfuld leg
i et spil.
4.2 Design
Design er et ord der kan defineres på mange måder, og som heraf har fået mange
betydninger [Dictionary.com, Design] [Ordbogen.com, Design]. Design kan f.eks. være
en idé, en praksis, en proces, et produkt eller endda en tilstand. Brugbare definitioner kan
konstrueres ud fra alle betydninger, men jeg mener, det vil være mest givtigt at tillægge
design én betydning, og være konsekvent i anvendelsen af den igennem rapporten. Jeg vil
grundlæggende helst se design som en proces der resulterer i et produkt (til dels motiveret
af positive erfaringer fra sidste semesters metode, hvad jeg også kort vil belyse i næste
kapitel), og faktisk minder den opfattelse meget om Salen & Zimmermans definition:
Design is the process by which a designer creates a context to be encountered by a
participant, from which meaning emerges.
[Salen & Zimmerman, 2004, s41]
Deres definition er dannet ved at kombinere otte andre (betydeligt længere og dybere)
definitioner, som jeg ikke vil komme nærmere ind på her, og de definerer altså design
som den proces hvorigennem en designer skaber en kontekst. Målet med konteksten er at
skabe mening i mødet med en deltager. Drejes definitionen over på spildesign, finder vi i
definitionen følgende centrale elementer [Salen & Zimmerman, 2004, s41]:
• Designeren der er individet, gruppen eller kulturen som skaber spillet.
• Konteksten som er spillets kontekst bestående af rum, objekter,
fortællinger og handlemåder.
• Deltagerne der er spillerne som manipulerer, udforsker og bebor
konteksten.
• Mening er det begreb jeg i sidste afsnit kaldte meningsfuld leg (i
spilmæssig kontekst), og som dannes i forbindelsen mellem
spillerhandling og systemreaktion.
Design er altså at skabe en meningsdannende kontekst, og jeg mener at det kan heraf
være givtigt igen at se på semiotikken. Med semiotikken kan det som nævnt forklares
hvordan tegn danner mening, og deraf kan et system af tegn der kan danne mening
skabes, hvad der jo netop er målet med spildesign. Alle spil kan ses som systemer af tegn
- krydset i kryds og bolle symboliserer at et felt er erobret af spilleren der har krydset som
sit tegn, i modsætning til spilleren der har bollen som sit tegn.

Vi er symbolbeherskende væsner, og har meget let ved at lære betydningen af tegn 8 ,
hvorfor det er vigtigt at overveje brugen af tegn i et spil og sørge for at den er
konsekvent. For at opnå synlighed er det naturligt at give spilleren informationerne via
tegn, og de tegntyper der blev defineret i afsnit 2.1.5.1 kan passende inddrages nu. Er en
karakter blevet skudt, vil det være naturligt, at vise det med et indeks der i konteksten
symboliserer netop dette - altså blod. Et index kan også bruges til at give spilleren mindre
tydelige hints - et fodspor i sneen kunne betyde, at nogen har passeret forbi for nylig.
Ikoner, der var tegn med direkte relation til deres repræsentation (deres signified), kan
bruges når spilleren skal have klar besked. Eksempelvis vil det være nyttigt med ikoner
der direkte afbilleder de handlinger spilleren kan udføre. Symboler mener jeg derimod
designeren bør være mere varsom med at anvende, da det stiller krav til ens viden om
spillets målgruppe. Symboler er konventionelt vedtagne, men der er ingen garanti for at
alle spillerne kender konventionerne - det er f.eks. heller ikke alle der kan læse (har et
godt kendskab til de symboler vi kalder bogstaver). I spillets egen kontekst kan nye
symboler naturligvis godt vedtages, men her bør det undersøges om det er et kendt
symbol der har andre betydninger, og om disse bryder med den mening det skal danne i
spillet. Semiotikken er altså et væsentligt teoretisk felt også indenfor spiludvikling, og
bør under designet altid tages i betragtning. Efter denne korte afstikker til semiotikken,
vil jeg nu fortsætte med at karakterisere design.
En definition på design der ligner Salen & Zimmerman’s, men som kan bidrage med
noget jeg selv vægter højt i et spil, nemlig originalitet, findes i Donald Norman’s bog
Design of Everyday Things [Norman, 1990]:
Design is the successive application of constraints until only a unique product is left
[Norman, 1990, s158]
Igen er design en proces, men det interessante er, at det resulterende produkt nu skal være
unikt - noget nyt, originalt eller innovativt. Kombineres denne definition med Salen &
Zimmerman’s, så ses det at mening kun dannes, hvis konteksten hvoraf den skal
udspringe er original.
Originalitet er en kvalitet der af mange vægtes meget højt i et spil [Costikyan, 2005]
[Spector, 2003] [Crawford, 2003, k7], og et emne jeg på sidste semester skrev et essay
om i forbindelse med kurset i systemudviklingsfilosofi [Marcus Larsen, 2005] 9 . Deri
argumenterer jeg for, hvorfor originalitet er vigtigt i spil, og hvorfor den nuværende
mangel på netop dette kan medfører stagnation eller tilbagegang for hele spilindustrien.
Jeg vil ikke gentage hele argumentationen her, men min konklusion, tilsat begreberne
anvendt i denne rapport, er at erfarne spillere ikke længere vil kunne finde meningsfuld
leg i nye spil, hvis de blot er gentagelser af eksisterende spil. Dermed tillægger jeg
originalitet betydning for meningsfuld leg og for spillets kvalitet, hvad der givetvis kun
vil være gældende for spillere der har spillet sammenlignelige spil - noget kan altså godt
8 Min søn på 1½ år ved f.eks. allerede, at økologimærket betyder god mad, at Fætter BR-logoet betyder
legetøj og at Hjem Is-logoet betyder den blå bil der ringer med klokken nede i gården.
9 I øvrigt valgt som et af de 10 bedste essays på daværende semester…
39

virke originalt, selvom det reelt ikke er det. Det tilfører definitionen subjektivitet, hvad
jeg dog ikke mener, er problematisk, da min grundholdning, som beskrevet i starten af
afsnittet, er at spiloplevelsen afhænger af individet. Det vil eksempelvis være muligt, at
udvikle et spil til yngre spillere som for dem virker originalt, selvom det kopierer
konteksten fra spil udviklet før de blev født.
Opsummeret er min definition af design dermed, at det er en proces der har som mål at
skabe en unik kontekst hvoraf mening kan udspringe. Til listen af de kvalitetskrav der
skal kunne udledes af dette kapitel kan jeg dermed tilføje:
40
• Originalitet, at spillet indeholder en original kontekst.
Hvordan det gribes an, at skabe en unik kontekst, vil jeg senere se på i kapitlet der
beskriver de metoder jeg har anvendt. Her er målet først at definerer den kontekst jeg som
spildesigner skal skabe - nemlig hvad systemet der afgrænser legen består af.
4.3 Systemer
Spil er i sig selv systematiske, og kan deraf forstås som systemer [Salen & Zimmerman,
2004, s50]. Denne påstand kræver en definition på hvad et system er, hvad Salen &
Zimmerman også leverer:
A system is a set of parts that interrelate to form a complex whole
[Salen & Zimmerman, 2004, s55]
Det sæt af dele der nævnes i definition tager de fra Stephen W. Littlejohn, som i bogen
Theories of human communication beskriver et system som bestående af følgende
[Littlejohn, 1999, s41]:
• Objekter, der er elementer eller variable i systemet. De kan være fysiske
såvel som abstrakte, afhængigt af systemet.
• Attributter, der er egenskaberne ved systemet og dets objekter.
• Interne relationer, der beskriver sammenhængen mellem objekterne.
• Miljø, som er de omgivelser systemet eksisterer i.
Hvor det nu bliver kompliceret, er i måden delene anskues. Det er muligt at se delene
som et rent formelt matematisk regelsæt, hvor objekterne f.eks. kunne være brikkerne i
skak, attributterne er brikkernes startpositioner og tilladte bevægelsesmønstre, de interne
relationer er brikkernes aktuelle positioner på pladen og hvordan de truer hverandre,
mens miljøet er den leg spillet danner [Salen & Zimmerman, 2004, s51]. Tilsætter jeg
begreber fra kapitlet sprog, er dette et syntaktisk syn på systemer. Det er den åbenlyse og
grundlæggende definition på et system i form af et spil, men Salen & Zimmerman mener
at et spil består af tre systemer.
Det næste, som ligger ovenpå førnævnte, ses når delene belyses fra et erfaringsmæssigt
synspunkt, hvor det centrale ikke længere er det matematiske og logiske, men i stedet

interaktionen mellem spillerne og spillet. Det betyder, at i tilfældet skak, er objekterne nu
spillerne selv, mens attributterne er brikkerne de kontrollerer. De interne relationer er
spillernes interaktioner med spillet og hinanden, og miljøet er alle de umiddelbare
fysiske, psykologiske og kulturelle omgivelser der afgrænser spillet som f.eks. bordet de
sidder ved og deres mening om skak [Salen & Zimmerman, 2004, s51]. Tilsættes igen
begreber fra kapitlet sprog, er dette et semantisk syn på systemer.
Det sidste system ses hvis delene opfattes som et kulturelt system, hvor referencer eller
forbindelser til historien, subkulturer eller andre medier belyses. I skak vil objekterne da
være spillet selv, attributterne vil være spillets dele og informationer om hvornår og
hvordan de er designet. De interne relationer beskriver hvorfor de er designet som de er -
har styrkeforholdet mellem konge og dronning rod i historien, og ses den i brikkernes
udformning, eller kan forholdet mellem sort og hvid forklares med referencer til race
opfattelsen da spillet oprindeligt blev designet. Miljøet er hverken det enkelte spil skak
eller hvad der omgiver dette, men i stedet hele kulturen hvori spillet eksisterer [Salen &
Zimmerman, 2004, s52]. Tilsætter jeg endnu engang begreber fra kapitlet sprog, er dette
et pragmatisk syn på systemer.
Disse tre systemer eksisterer i ethvert spil, og kan bruges som udgangspunkt for både
designet af et nyt spil og analysen af et eksisterende. Det jeg finder interessant ved denne
opdeling, er at den på en overskuelig måde adskiller det der i praksis let flyder sammen
og bliver uhåndterbart. Det gør det muligt, at fokusere en analyse eller designproces på
bestemte facetter af spillet - tilmed på et teoretisk grundlag. Endnu mere interessant er det
at semestrets hovedemne sprog, faktisk er så tæt forbundet med spilteorien som den
ifølge Salen & Zimmerman ser ud. Et spil minder i høj grad om en lingvistisk struktur, i
det den også kan beskrives både syntaktisk, semantisk og pragmatisk. Lidt mere påtaget
kan de andre dele af en lingvistisk struktur, fonetik, fonologi og morfologi, også overføres
til det system der beskriver et spil - fonerne vil være objekterne, fonemerne vil være
attributterne og morfologiske regler ville kunne sidestilles med de interne relationer. Det
vil dog kræve en længere diskussion hvis jeg skulle argumentere for at det forholder sig
sådan, hvorfor jeg undlader at arbejde videre med denne observation.
Fra dette afsnit kan jeg ikke tage deciderede kvalitetskrav, men til gengæld er nogle af de
faktiske dele der skal designes blevet konkretiseret i form af objekter, attributter, interne
relationer og miljø. Disse ting adskiller sig som sådan ikke fra alle mulige andre
systemer, hvorfor jeg i næste afsnit vil se på det som for alvor gør spil til særlige
systemer - interaktiviteten - den direkte deltagelse i legen som systemet afgrænser.
4.4 Interaktivitet
Som design er interaktivitet et begreb der findes mange definitioner på, og det er da også
hvad Salen & Zimmerman indledningsvis studerer [Salen & Zimmerman, 2004, s58].
Resultatet af deres studier er ikke én, men fire definitioner på interaktivitet, der på fire
niveauer forklarer, hvordan begrebet omhandler den aktive deltagelse i et system. Den for
dette projekt mest interessante form for interaktivitet, er denne:
41

42
3: Explicit interactivity; or participation with designed choices and procedures
[Salen & Zimmerman, 2004, s60]
At det er denne definition der er interessant her, skyldes at det er netop den form for
interaktivitet som designeren har betydelig indflydelse på, og den som i højeste grad
skaber den meningsfulde leg [Salen & Zimmerman, 2004, s60]. Definitionen indebærer at
interaktivitet omhandler designede valg, hvorfor valg bliver designeres vigtigste værktøj
når et interaktivt system skal skabes. Valg er det som gør spil interaktive, og det er i
konstruktionen af disse valg, at designeren har mulighed for at skabe et system der kan
medføre meningsfuld leg - hvad der jo, som nævnt tidligere, er målet med spildesign. Et
synspunkt der blandt andet støttes af Tynan Sylvester der i Gamasutra-artiklen Decisionbased
Gameplay Design [Sylvester, 2005] leverer en række praktiske anvisninger i
forbindelse med konstruktionen af det også han betragter som den fundamentale
byggesten et spil skabes med - nemlig valg. Også Sid Meyer-citatet fra tidligere omtaler
valg som det grundlæggende element i et spil.
Derfor må det defineres, hvad et valg er, og hvordan de konstrueres i et spil.
Grundlæggende kan der tales om valg på mikro- og makroniveau, hvor mikroniveauet er
de øjeblikkelige valg en spiller konstant må træffe, mens makroniveauet repræsenterer en
sammensætning af mikroniveauvalg set i grove træk [Salen & Zimmerman, 2004, s61]. I
fodbold er trænerens overordnede strategi for en kamp, f.eks. spillernes formation, et
makroniveauvalg, mens den løbende justering der foretages af både træner og spillere i
måden der spilles på, altså taktikken, er mikroniveauvalg.
Salen & Zimmerman tager derefter denne definition af et valg og beskriver hvordan den
repræsenteres i et spil, sådan at meningsfuld leg kan dannes. Resultatet er fem spørgsmål
der skal kunne besvares af designeren, og som når besvarelsen er god beskriver et valg
der danner meningsfuld leg [Salen & Zimmerman, 2004, s65]:
1. Hvad skete der før spilleren fik valget?
2. Hvordan vises muligheden for valg til spilleren?
3. Hvordan udfører spilleren valget?
4. Hvad er resultatet af valget, og hvordan påvirker det fremtidige valg?
5. Hvordan vises resultatet til spilleren?
Ved at besvare disse spørgsmål kan designeren altså konstruere valg der kan danne
meningsfuld leg. Om hvornår en besvarelse er god, siger Salen & Zimmerman, at det
aldrig kan vides med sikkerhed [Salen & Zimmerman, 2004, s67]. Et svar der
umiddelbart virker utilfredsstillende, men som indregnet mine ord i starten af kapitlet, om
hvordan individet er afgørende for oplevelsen, alligevel siger alt. Designeren kan ikke
garantere meningsfuld leg for enhver, men ved at konstruere valgene så de har potentialet
til at danne meningsfuld leg, det vil sige ved at have synlighed, integration og
interessante handlinger for øje, samt ved at besvare førnævnte spørgsmål, vil chancen
være større. Et synspunkt der støttes af Tynan Sylvester, som beskriver de bedste valg
som dem der er svære at træffe (det vil sige interessante valg), og dem der har de største
og mest håndgribelige resultater (det vil sige synlige valg) [Sylvester, 2005].

Det er også interessant at se, hvordan interaktivitet faktisk beskrives som en
tilstandsmaskine der konstant modtager og behandler valg (ændrer tilstand), og konstant
informerer spilleren om sin tilstand. Medtages systemet fra sidste afsnit, vil spillet udgøre
en tilstandsmaskine, der består af synlige valg, og synlige konsekvenser af valg. Det
perspektiv giver en nærmest matematisk model at opstille interaktiviteten efter, og
antyder at alle delene i et system bør repræsentere et valg i en eller anden form - et objekt
kunne f.eks. være resultatet af et valg eller det som valget omhandler, en attribut kunne
have indflydelse på valgets udfald og de interne relationer ville beskrive, hvordan et valg
påvirker et andet. Det er min måde at binde system og interaktivitet sammen - alt bør
have forbindelse til et valg, ellers har det ingen relevans for spillet. Tynan Sylvester har
hertil en vigtig pointe - systemet skal helst danne valgene dynamisk ud fra spillerens
handlinger, og dermed altså ikke indeholde mange statiske eller forudbestemte valg
[Sylvester, 2005]. Som jeg ser det, er den helt store udfordring under designet af et spil,
altså konstruktionen af et system der dynamisk generer interessante og integrerede valg
med synlige reaktioner. En særdeles kompleks tilstandsmaskine.
Salen & Zimmerman beskriver et spil som et mulighedsrum eksisterende i det system af
valg som designeren har skabt [Salen & Zimmerman, 2004, s67], hvad der vel er en slags
filosofisk udgave af ovenstående tilstandsmaskine.
Fra dette afsnit kan jeg tage en designpraksis - de fem spørgsmål, der kan hjælpe mig
under designet af spillet. Ved hele tiden at have dem for øje, samt ved at overveje
tidligere beskrevne synlighed, integration og interessante handlinger, kan jeg konstruere
valg der kan danne meningsfuld leg. Jeg har også beskrevet, hvordan det at se
interaktivitet som en tilstandsmaskine, og at overføre dette på systemet fra sidste afsnit,
kan gøre at et system gennemsyres af interaktivitet, fordi hver del af systemet har
forbindelse til et valg, og fordi systemet dynamisk skal konstruere valg.
Begreberne design, system og interaktivitet har nu leveret forståelsen for, hvordan den
meningsfulde leg opstår og designes i et spil, hvormed det grundlæggende spilteoretiske
grundlag for projektet beskrevet. Denne begrebsramme har indgået konkret i udviklingen
af spillet, hvor jeg eksempelvis under designet fokusere på spillet som et syntaktisk
system, og hele tiden overvejer hvordan dets interaktivitet skal muliggøre meningsfuld
leg.
Her vil jeg nu nuancere teorien en smule i forhold til mit konkrete projekt.
4.5 Håndholdte computerspil
Selvom Salen & Zimmerman skriver, at deres teori er uafhængig af platform, så mener
jeg alligevel det er relevant at se på hvilke konkrete forskelle der er, eller bør være, på
computerspil til en stationær platform, som eksempelvis en pc eller Playstation, og
computerspil til en håndholdt platform som Nintendo DS - den platform spillet i dette
projekt er udviklet til.
43

En af de udviklere som har støttet maskinen siden den er udkom er Vicarious Visions. I et
interview med Gamasutra-skribent Brandon Sheffield [Sheffield, 2005] udtaler deres
præsident:
To design a game for the DS is, by and large, to design a DS exclusive title. Given the
system's unique capabilities, any game that takes advantage of the hardware is bound to
it by default.
Karthik Bala, 2005
Det er en vigtig pointe. Udvikles et spil til Nintendo DS, så er det ikke let på et senere
tidspunkt at konvertere det til en anden platform. Maskinen har simpelthen så mange
særheder, at det ville være bedre at lave et helt nyt spil. Det samme gælder selvfølgelig
den anden vej - et spil lavet til en traditionel platform vil måske nok kunne konverteres til
Nintendo DS, men det vil ikke udnytte maskinens spændende features, hvorfor det næppe
kan retfærdiggøres. Det spil jeg udvikler, vil derfor ikke blot have Nintendo DS som en
mulig platform, men som den eneste platform.
Hvad angår håndholdte computerspil generelt, så der flere ting som har kendetegnet dem
lige siden de første ”bib-bib-spil” så dagens lys, men desværre er der ikke skrevet meget
om det, hvorfor følgende er mine egne observationer. For det første spilles de mens
spilleren er på farten, hvorfor omgivelserne i høj grad er skiftende og evt. forstyrrende
under spillet. Der bør altså tages hensyn til miljømæssige forhold (semantisk syn på
systemet) i højere grad end i almindelige computerspil. Et eksempel på dette er at der bør
være mulighed for at sætte spillet på pause, eller, endnu bedre, mulighed for at afbryde
spillet hvor som helst og når som helst. Det betyder samtidig, at spillet skal levere den
meningsfulde leg med det samme, og at det skal gøre det lige godt under korte
spilsessioner som når der spilles i længere tid. Jeg vil ikke fremlægge yderligere krav til
håndholdte spil, da det uden teori om emnet blot bliver mine egne krav.
Her følger en opsummering på hele kapitlet.
4.6 Opsummering
Kapitlets første afsnit udlagde den vigtigste kvalitet ved ethvert spil - dets evne til at
danne meningsfuld leg. Det betyder, at spillerne oplever det at spille som en meningsfuld
eller betydelig aktivitet, og det blev samtidig beskrevet at meningen opstår i kontakten
mellem spillerhandling og systemreaktion - altså i interaktionen, hvor også pragmatiske
forhold som spillerens holdning til det at spille, og selve konteksten der spilles i har en
betydning.
Igennem kapitlet har et studie af de tre begreber: design, system og interaktivitet, ledt
frem til række kvalitetskrav, som et spil skal opfylde for at danne den meningsfulde leg:
44
• Synlighed, at enhver handling afføder en tydelig og umiddelbar reaktion.
• Integration, at enhver handling påvirker den samlede spiloplevelse på
lang sigt.

• Interessante handlinger, at enhver handling har en negativ og positiv
konsekvens.
Hvad angår designbegrebet, så defineres det som: den proces hvorigennem en designer
skaber en kontekst, der har som mål at skabe mening i mødet med en deltager. Et vigtigt
værktøj i dannelsen af denne kontekst er semiotikken, der kan forklare hvordan tegn
skaber mening. Jeg beskrev også et vigtigt træk ved resultatet af designet:
• Originalitet, at spillet indeholder en original kontekst.
Senere (se kapitel 8) introducerer jeg forskellige innovationsteknikker der kan hjælpe til
med løsningen af dette kvalitetskrav.
I afsnit 4.3 beskrev jeg spillet som et system der kan anskues fra (mindst) tre perspektiver
- det syntaktiske (formelle ifølge Salen & Zimmerman) hvor systemet er et formelt
regelsæt, det semantiske (eksperientelle ifølge Salen & Zimmerman) hvor systemet er
interaktionen mellem spil og spillere, og det pragmatiske (kulturelle ifølge Salen &
Zimmerman) hvor systemet er en kulturel konstruktion. Når et spil designes, bør alle tre
perspektiver overvejes - herunder især de interne relationerne mellem systemets objekter.
Det sidste begreb der har stor betydning for den meningsfulde leg er interaktivitet -
herunder især eksplicit interaktivitet som er de af designeren skabte valg. Valg er det som
gør spil interaktive, og det er i konstruktionen af disse valg, at designeren har mulighed
for at skabe et system der kan medføre meningsfuld leg. Seks spørgsmål bør stilles i
forbindelse med designet af et valg:
1. Hvad skete der før spilleren fik valget?
2. Hvordan vises muligheden for valg til spilleren?
3. Hvordan udfører spilleren valget?
4. Hvad er resultatet af valget, og hvordan påvirker det fremtidige valg?
5. Hvordan vises resultatet til spilleren?
Kan der svares på disse spørgsmål, og opfylder svarene kravene om synlighed og
integration, vil muligheden for skabelsen af meningsfuld leg i den interaktion som
valgene former (eller i spillets mulighedsrum) være større.
Slutteligt præsenterede jeg en række krav til håndholdte computerspil:
• Spil til Nintendo DS er låst til platformen (hvis dens særheder udnyttes).
• Spillerens omgivelser er skiftende, hvorfor hensynstagen til miljøet er
vigtigt.
• Spillet bør kunne levere meningsfuld leg over selv meget korte
spilsessioner.
Med dette er projektets teoretiske fundament lagt, og det er tid til en delkonklusion.
45

5 Teoretisk delkonklusion
I projektets første kapitel opstillede jeg en række delproblemer der alle skulle løses på
vejen mod besvarelses af projektets problemstilling, der lyder sådan her:
46
• Hvordan designes et computerspil der har stemmebaseret interaktion
som en primær interaktionsform, sådan at dette samtidig udgør den
optimale interaktionsform uden at synliggøre de tekniske svagheder?
En egentlig besvarelse af dette vil jeg først give efter det mere praktiske arbejde er
beskrevet, men projektets første delproblem kan der allerede nu kastes lys over:
• Hvad er stemmebaseret interaktion?
o Besvarelsen af dette spørgsmål skal belyse den teoretisk og
praktiske side af stemmebaseret interaktion. Herunder hvordan
sprog og tale kan defineres, samt hvordan det genskabes og
genkendes digitalt i og af en computer.
Sprog blev i kapitel 2 defineret som en lingvistisk struktur der kunne anskues fra seks
forskellige perspektiver, nemlig det fonetiske, det fonologiske, det morfologiske, det
syntaktiske, det semantiske og til sidst det pragmatiske perspektiv. Bag menneskets
anvendelse af sproget findes en intuitiv og dybtgående forståelse for alle strukturens
perspektiver eller lag, og det er denne forståelse der må genskabes digitalt, hvis naturlig
stemmebaseret interaktion med en computer skal opnås. Igennem kapitel 2 og 3 har jeg
fremlagt forskellige teknikker til håndtering af lagene, med fokus på de teknikker jeg selv
anvender.
Winograd & Flores’ conversation for action-model håndterer det pragmatiske lag, det
semantiske lag håndteres af logiske udtryk, en grammatik i BNF håndterer det syntaktiske
lag, dynamic time-warping håndterer det morfologiske lag, mens de fonetiske og
fonologiske lag i min talegenkendelsesarkitektur ignoreres som meningsbærende lag, og
kun anvendes i udvælgelsen af talekommandoer. Resultatet er en forståelse af hvad
stemmebaseret interaktion er, og hvordan det anvendes og implementeres i praksis, som
er anvendt under designet af det spil det har været målet at udvikle.
Det næste delproblem jeg fremlagde, kan også belyses ud fra det teoretiske grundlag:
• Hvordan designes et godt computerspil?
o Besvarelsen af dette spørgsmål skal berøre den teoretiske del af
computerspil, samt belyse den mere praktiske eller metodiske
side af sagen. Herunder hvordan et teoretisk grundlag kan danne
en begrebsmæssig ramme om en analyse af spil, samt hvordan
samme teori kan anvendes praktisk i designprocessen.

I kapitel 4 introducerede jeg en række begreber der kan anvendes praktisk under design
og analyse af computerspil. De vigtigste begreber var meningsfuld leg, design, systemer
og interaktivitet. De udgør tilsammen et computerspils grundsten. Hertil opstillede jeg en
række kvalitetskrav som et spil bør søge at opfylde for at grundstenene bliver stærke nok
til at bære spillet:
• Synlighed, at enhver handling afføder en tydelig og umiddelbar reaktion.
• Integration, at enhver handling påvirker den samlede spiloplevelse på
lang sigt.
• Interessante handlinger, at enhver handling har en negativ og positiv
konsekvens.
• Originalitet, at spillet indeholder en original kontekst.
Når disse ting er til stede i et spil, kan spillet beskrives som objektivt godt. For at styrke
begrebsgrundlaget, og for at hjælpe med at sikre at førnævnte ting er at finde i spillet,
definerede jeg desuden hvad et computerspil, set som et system, består af:
• Objekter, der er elementer eller variable i systemet. De kan være fysiske
såvel som abstrakte, afhængigt af systemet.
• Attributter, der er egenskaberne ved systemet og dets objekter.
• Interne relationer, der beskriver sammenhængen mellem objekterne.
• Miljø, som er de omgivelser systemet eksisterer i.
Det interessante er at disse kan belyses med de sproglige begreber fra kapitel 2. Spil kan
ses i et syntaktisk, et semantisk eller et pragmatisk perspektiv, hvormed sprogteorien
flettes ind i teorien om computerspil, og styrker dennes begreber. Syntaktisk vil et spils
objekter eksempelvis være de konkrete genstande eller karakterer der er at finde i spillet,
mens de semantisk ville være spillerne. Det er det syntaktiske syn på spil jeg primært vil
beskæftige mig med igennem designet af systemet, mens det semantiske har stor
betydning for systemets interaktion. Det pragmatiske syn bliver også anvendt, om end i
mindre omfang.
Skal jeg kort opsummere de vigtigste egenskaber ved et godt computerspil, må det blive
følgende: Et godt computerspil skal dynamisk genererer interessante og integrerede valg
med synlige reaktioner, sådan at spilleren oplever det som meningsfuld leg.
De to andre delproblemer (se kapitel 1) kan ikke besvares af teorien bag projektet, men
derimod af det metodiske grundlag. Det er emnet for projektets næste del.
47

Del III
METODE
Since when has the world of computer software design been about what people want?
Bill Gates
Arbejdet med et studieprojekt er todelt. Der skal udvikles et system, og der skal skrives
en rapport som dokumenterer de betydeligste aspekter omkring udviklingen.
Teorien beskrevet i forrige kapitel er ét af de betydelige aspekter, da den er grundlaget for
udviklerens forståelse af, hvordan systemet kan eller skal fungere. Et andet betydeligt
aspekt er den plan eller metode der har styret udviklingen, og sikret at den førte til et
produkt af høj kvalitet. I dette kapitel beskrives de forskellige metoder og teknikker der er
blevet anvendt, modificeret og kombineret for at støtte udviklingen bedst muligt.
På tidligere semestre er der blevet arbejdet meget med metoder, og de overvejelser der
skal ligge til grund for eventuelle tilpasninger af dem. Dette semester har dog et større
fokus på resultatet af udviklingen, end på selve metoden, hvorfor dette kapitel også er
forholdsvis kort, og kun indeholder hvad jeg mener, det er essentielt for læseren at vide
om min udviklingsstrategi. Særligt vil jeg fokusere på de enkelte teknikker i metoden, der
beskæftiger sig med innovation og nytænkning, da det dels er et af semestrets
grundlæggende emner og dels et vigtigt element i udviklingen af spil. Der er også et
kapitel om, hvordan udviklingen af spil er anderledes end udviklingen af anden software,
samt om hvordan udviklingen bedst organiseres, når jeg udvikler spillet ene mand.
Indledningsvis kastes et hurtigt blik på nogle af de systemudviklingsmetoder og teknikker
jeg har erfaring med fra tidligere semestre, og hvad der overordnet er taget med fra hver
enkelt.
49

6 Systemudvikling
Systemudvikling er blevet beskrevet på mange måder, men to modsatrettede tilgange
udgør i dag de mest udbredte definitioner. Den traditionelle tilgang, hvor planlægning,
dokumentation, ledelse og en fast forudbestemt kontrakt mellem kunde og udvikler er
essensen, og den agile tilgang hvor interaktionen mellem udvikler og kunde, samt evnen
til hurtigt at reagere på ændrede krav vægtes højst.
De traditionelle systemudviklingsmetoder omfatter flere forskellige procesmodeller
[Pressman, 2000, k3], som f.eks. vandfaldsmodellen og spiralmodellen, og et utal af
forskellige teknikker til at håndtere hvad der ses som de fire centrale discipliner: analyse,
design, implementering og test. Eksempler på traditionelle teknikker er objekt orienteret
analyse og design (OOA&D), Unified Modeling Language (UML) og valideringstests.
De nyere agile systemudviklingsmetoder omfatter blandt andet eXtreme Programming,
Scrum og Feature-Driven Development, hvor især førstnævnte har opnået stor
udbredelse, mens selv enorme Microsoft har indført Scrum på flere større projekter
[eWeek.com, 11-11-2005]. Her er de centrale discipliner ikke længere analyse, design,
implementering og test, men derimod blot design og test. Design er dog blevet en proces
hvorunder det der traditionelt kaldtes analyse, design og implementering udføres. Tilmed
er test ikke blot noget der udføres efter implementering, men også før og under.
Der er altså markant forskel på traditionel og agil systemudvikling, hvad der ses tydeligst
på den figur jeg har lavet herunder. Den viser hvilket arbejde der forelægger indenfor de
forskellige discipliner, og hvad resultatet af arbejdet er.
Figur 7: Traditionel versus agil systemudvikling
50

Som det fremgår så er udviklingsforløbet meget forskelligt alt efter hvilken tilgang der
vælges. Det er dog umuligt at sige noget generelt om hvilken tilgang der bedst, og i
praksis er det da også sjældent at én metode følges stringent uden tilpasning til
situationen [Pressman, 2000, k2]. Derfor er det relevant at se på situationen (herunder
ting som økonomi, mandskab, kultur osv.) hvorunder det konkrete system skal udvikles,
og herudfra vælge hvordan det skal forløbe.
6.1 Design af projektets systemudviklingsmetode
Grundlaget for min sammensætning af udviklingsmetoder er overvejelser der dels
involverer de erfaringer jeg har fra tidligere semestre, dels situationen hvorunder
systemet skulle udvikles og ikke mindst hvilket system der skulle være processens
resultat. Målet har primært været en let håndterbar proces, med plads til løbende
tilpasning og som opfordrer til innovation. Her følger resultatet af overvejelserne, og
dermed en kort beskrivelse af de teknikker og metoder der har dannet metodisk grundlag
for udviklingen.
• Den traditionelle systemudviklings kravspecifikation kan give systemet
en god begyndelse, da der allerede fra det første design udføres
foreligger et konkret mål. Det betyder, at de første skridt ikke bliver
famlende og tilfældige, og dermed at mindre tid spildes. Dog
umuliggøre et spils behov for innovation, at en fuldstændig
kravspecifikation kan udarbejdes, hvorfor blot en liste over overordnede
krav, samt en generel beskrivelse af systemet vil udgøre min
kravspecifikation. Fra den traditionelle systemudvikling tager jeg også
designdokumentet, dog vil det ikke være et komplet dokument inden
implementeringen påbegyndes, men derimod noget der løbende
udbygges. Det vælger jeg dels for altid at have et overblik over det
eksisterende system, og dels for at bidrage til den dokumentation af
forløbet som denne rapport skal indeholde.
• Forrige semesters arbejde med eXtreme Programming (XP), har
introduceret mig til en arbejdsform med mange fordele i forbindelse med
udviklingen af computerspil, hvad jeg har ønsket at udnytte igen. Først
og fremmest tilbyder den iterative udviklingsform mulighed for at skifte
kurs undervejs, samt for at tage små og hurtige skridt, for dermed at
mindske omkostningerne ved hvert enkelt [Beck, 1999, k5]. Jeg
anvender også samme designbegreb som XP, og kan dermed beskrive
mit spil som voksende frem igennem en designproces bestående af en
lang række korte iterationer der både involverer idé-skabelse og -
konkretisering, samt programmering og test. Salen & Zimmerman
anbefaler i øvrigt også at designprocessen udføres iterativt [Salen &
Zimmerman, 2004, s11], da det ifølge dem højner kreativiteten, tillader
eksperimenter og har bedre chance for at føre til innovation.
51

52
• Fra OOA&D tager jeg den objektorienterede modellering af designet,
beskrevet i UML, da dette kan hjælpe betydeligt under arbejdet med
programmeringen. Dog vil det ikke bliver en formel og detaljeret brug af
objektorienteret modellering, da den iterative arbejdsform umuliggør et
detaljeret overblik over hvordan det færdige system ser ud. I stedet
bliver kun de mest centrale dele af designet beskrevet i UML,
efterhånden som de vokser frem af iterationerne. UML vil desuden blive
brugt i denne rapport for at beskrive spillets tekniske opbygning uden
brug af for meget konkret kode.
• For at teste systemet tager jeg flere metoder i brug. I de første mange
iterationer har jeg udelukkende valgt at bruge tekniske tests placeret i
koden (kaldes ofte en whitebox test), for at sikre et stabilt system.
Desuden udfører jeg løbende selv manuelle tests af systemets
funktionalitet (kaldes ofte en blackbox test), for at sikre at det altid
opfører sig som forventet i alle ekstremer. I den senere test af systemet
og dets funktionalitet, har jeg dog involveret dets brugere. Dette er gjort
via Internettet for at sikre et så lavt ressourcebrug som muligt. Konkret
har det betydet, at jeg har inviteret en række spillere til at downloade og
teste spillet, mens jeg løbende har forbedret det på baggrund af deres
forslag og diskussioner. Det er en metode jeg har været med til at
anvende tidligere, hvor resultatet var en betydelig forbedring af spillet i
de perioder hvor spillerne testede.
Jeg vil ikke gå mere i detaljer med metoderne, da læseren dels må antages at have et
basalt kendskab til de fleste, og dels ikke har behov for at kende dem til bunds for at
vurdere resultatet af udviklingen. Hertil er semestres fokus naturligvis heller ikke
systemudviklingsmetoder og teknikker. Følgende figur beskriver overordnet hvordan
forskellige systemudviklingsmetoder har indgået i min udviklingsproces.
Figur 8: Min systemudviklingsmetode
6.1.1 Prototyping
På grund af det iterative i processen er resultatet en række gradvist større, bedre eller bare
ændrede prototyper. Det kan derfor være interessant at introducere fire begreber der kan
beskrive en prototype. Begreberne er taget fra bogen Paper Prototyping der er blevet

anvendt på semestrets Language Action Perspective (LAP) kursus, og de beskriver en
prototype (ikke nødvendigvis af papir) i fire dimensioner [Snyder, 2003, s260]:
• Breadth er den procentdel af systemets funktionalitet der er
repræsenteret i prototypen. At en funktionalitet er repræsenteret betyder
ikke, at den nødvendigvis fungerer, men blot at brugeren kan se, at den
findes i systemet.
• Depth er detaljegraden og robustheden i de enkelte funktioner. En
prototype med meget depth er en prototype, hvor alle repræsenterede
funktioner reagerer som de burde gøre i det færdige produkt, mens en
prototype uden depth er en prototype uden funktionalitet.
• Look er prototypens visuelle fremtoning, og hvor tæt denne er på det
færdige system.
• Interaction er prototypens evne til at håndtere brugerens in- og output.
Faktorer som reaktionstid og fysisk feedback har også betydning her.
En prototype kan så beskrives, ved at give den en karakter i hver af de fire dimensioner.
Det er anvendeligt i forbindelse med en evaluering af hvor langt fremme i udviklingen
systemet er, ligesom det kan sige noget om hvor stort udbyttet vil være ved en brugertest.
En prototype med meget depth vil eksempelvis være god i en brugertest, mens det
forholder sig omvendt, hvis der ingen depth er. Det er da også de to ting jeg har brugt de
fire dimensioner til; altså til at vurdere hvor langt jeg er og om en brugertest vil være
fordelagtig.
6.2 Opsummering
Kapitlet har været kort, så det bliver opsummeringen også. Jeg har kort belyst
systemudvikling fra to perspektiver, det traditionelle og det agile, for derefter at
konstruere den overordnede procesmodel der har dannet grundlag for udviklingen af mit
spil. Denne procesmodel er i høj grad iterativ, den resulterer i en række prototyper og der
indgår teknikker som UML (under modelleringen af designet), tests i form af
funktionalitetstest og kodetests. Hertil kommer en simpel brugertest, så snart prototypen
har tilstrækkelig implementeret funktionalitet (det der kaldes depth) da det vil give størst
udbytte af testen.
Udover de nævnte metoder, kommer brugen af metoder og teknikker jeg ikke tidligere
har anvendt. Det drejer sig om de helt centrale innovations- og designstrategier der har
udgjort en del af semestrets LAP-kursus. Hvordan disse involveres i processen vil jeg dog
først beskrive, efter følgende kapitel omhandlende udvikling af computerspil, da
innovationsstrategien netop er valgt med udviklingen af computerspil i tankerne.
53

7 Udvikling af computerspil
Udviklingen af computerspil kan overordnet set sammenlignes med udviklingen af alle
andre systemer, og kan derfor struktureres som beskrevet i forrige afsnit - altså som al
anden systemudvikling [Bethke, 2003, s4]. Under overfladen er der dog betydelige
forskelle, der dels skyldes at de kvalitetskrav jeg opstillede i sidste kapitel som
udgangspunkt skal opfyldes - systemet skal underholde, chokere eller udfordre, og
samtidig stimulere vores lyst til leg og udforskning. Men også andre egenskaber gør, at
udviklingen af computerspil adskiller sig. Ingen andre systemer har brug for en så stor
mangfoldighed i designernes evner - selv de simpleste computerspil kræver, at designerne
kan anvende følgende discipliner [Bethke, 2003, k5]:
54
• Grafisk arbejde, herunder skitser og omsætning af disse til 2d- eller 3dgrafik
i produktionskvalitet, samt animation der levendegør skitserne.
• Produktion af lyd, hvorunder der skal komponeres musik og optages
lydeffekter.
• Spildesign, hvad der reelt indebærer praktisk anvendelse af teorien fra
sidste kapitel, i kategorier som banedesign, interaktionsdesign og
historiefortælling.
• Programmering, som skal binde det grafiske og lydmæssige arbejde
sammen med spildesignet. Indebærer programmering af blandt andet
grafik, lyd, interaktion og kunstig intelligens.
Jeg vil ikke beskrive de enkelte discipliner, og hvad der kræves af dem indgående. Det
der er vigtigt for dette projekt, hvor produktet er i fokus, er at sikre at designprocessen
kan udføres på acceptabel vis.
Da alle processens discipliner er vigtige, og da jeg har lavet projektet alene, må jeg selv
stå for hver enkelt. Jeg vil ikke påstå, at jeg mestrer nogle af disciplinerne, men jeg har
begrænsede evner indenfor dem alle 10 , hvad der har været nok til, at designprocessen har
kunnet forløbe forholdsvis problemfrit. Hertil har det naturligvis heller ikke været et krav
at spillet, efter projektets færdiggørelse, skulle udgøre et færdigt produkt, hvorfor
elementer af mindre relevans for spillet har kunnet udlades i prototypen - eksempelvis
musik (da dette ikke er så centralt i spillet, som det eksempelvis ville være i et musik eller
rytmespil, kan det godt forsvares at kalde musikken for mindre relevant).
At udvikle computerspil alene er nu heller ikke noget nyt. I sin spæde ungdom bestod
spilindustrien hovedsageligt af kreative og talentfulde individer (hovedsageligt
programmører), der udviklede spillene alene eller i meget små grupper. Det er en
10 Fra flere semestre på multimedieanimatoruddannelsen, har jeg erfaring med hvordan både grafik og lyd
laves. Fra flere tidligere projekter, både på universitetet og andre steder, har jeg erfaring med spildesign,
men her vil designet dog være teoretisk begrundet igennem anvendelse af teori fra projektets kapitel XX.
Programmeringen er naturligvis heller ikke noget problem, da vi har haft flere kurser i netop dette. Ligesom
jeg bruger de fleste ferier på det ;-)

situation der efter flere års fravær, grundet store udvikleres dominans på markedet, er på
vej frem under begrebet indie developers. Jeg vil se nærmere på dette begreb, i det
kommende afsnit.
7.1 Indie developer
Det er først og fremmest Internettet der har banet vejen for de såkaldte indie developers -
eller uafhængige spiludviklere, som det ville hedde på dansk. Talentfulde individer har
altid kunnet udvikle spil alene eller i små grupper, men med Internettet er det også blevet
muligt at distribuere spillene sådan at der kan tjenes penge [Michael, 2004, s16]. Det har
fået flere til at prøve lykken, og mange har også haft stor succes. Det er endda lykkedes
enkelte udviklere at udvikle spil der har opnået så stor popularitet, at de har kunnet
konverteret dem til platforme uden Internetadgang, og distribuere dem på traditionel vis.
Alien Hominid (The Behemoth, 2004) og Darwinia (Introversion, 2005) er eksempler på
dette. I næste generations spillekonsoller, hvoraf Microsoft’s Xbox 360 netop er
udkommet, er der desuden gjort tiltag der skal lette de uafhængige udvikleres adgang til
platformene, sådan at spillene kan lanceres direkte dertil (stadig via Internet)
[BusinessWeek, 14-10-2005]. Konsolproducenterne, Nintendo, Microsoft og Sony, har
fået øjnene op for den store mængde af kreativitet og innovation der findes i indiespillene,
og kappes om at få flest mulige indie-spil på deres respektive konsoller.
Fænomenet er så stort, at der allerede findes mange gode artikler om det på Internettet,
især hos spiludvikler portalen Gamasutra, ligesom der holdes konferencer og festivaler,
som eksempelvis Indie Games Conference 11 og Independent Games Festival 12 der har det
ene formål at hylde spil udviklet af indie developers. Der er tilmed skrevet en allerede
flot modtaget [Lloyd, 2004] bog, The Indie Game Development Survival Guide [Michael,
2004], som omhandler alt fra design til økonomi og markedsføring i forbindelse med
indie development.
Det, jeg ønsker at tilføre projektet, ved at indrage begrebet indie development er ikke
forklaringer på, hvordan udviklerne tjener penge, men derimod råd til hvordan
begrænsede ressourcer kan omsættes til produkter af høj kvalitet. Helt centralt for dette er
det i teorien beskrevne kvalitetskrav originalitet. Det er et faktum, at der findes indie-spil
af mindst ligeså høj kvalitet som spil udviklet med millionbudgetter (hvis spilanmelderes
karakterer bruges som et kvalitetsmål) [Gamerankings, Darwinia] [Gamerankings, Alien
Hominid], men umiddelbart lyder det jo mærkeligt at det forholder sig sådan.
Forklaringen er originalitet. Udviklere der smider millioner i udviklingen af deres spil,
lever med en stor risiko, hvorfor de ser sig nødsaget til altid at satse på de sikre kort -
spilkoncepter der har bevist at de sælger godt [Michael, 2004, s13]. Det er ikke en
begrænsning indie developers lever under; de kan altid søge at opfylde det, efter min
mening, vigtigste kvalitetskrav af dem alle - originalitet. Kravet som de store sjældent
søger at opfylde.
11 http://www.indiegamescon.com/
12 http://www.igf.com/
55

Selvom de økonomiske ressourcer hos en indie developer pr. definition er lave, så er der
andre ressourcer som bør være i top. David Michael lister tre karaktertræk han ser som
nødvendige hos en indie developer, nemlig et lidenskabeligt forhold til spil, evnen til at
kontrollere og opretholde tempo og en stor udholdenhed [Micheal, 2004, s22]. Det er
ikke meget anderledes end hvad der kræves for at skrive et universitetsprojekt om
computerspil i en enmandsgruppe - det er vigtigt aldrig at gå i stå, ikke at give op når der
ikke er andre til at løse problemerne, og ikke mindst at have en brændende interesse for
det man laver (hvis det da skal blive et godt projekt). Eftersom jeg blev færdig med
projektet, må jeg vel besidde nogle af disse egenskaber... Mere interessant er de
principper der gives for at hjælpe med at kontrollere de begrænsede ressourcer, der
hovedsageligt kommer til udtryk i udviklerholdets størrelse og dermed den tid der er til
rådighed for spillets enkelte elementer [Michael, 2004, s46]. Ved at være bevidst om sine
begrænsninger, kan der skabes et spil som alligevel er af høj kvalitet. Jeg opremser og
diskuterer nu disse principper, og tilføjer nogle jeg selv mener, er værd at tage med.
56
• Vælg ikke en af de store mainstream genrer. Den type spil der sælges
bedst er også den type spil markedet er oversvømmet af. De store
udgivere finpudser konstant koncepterne her, og selv hvis en indie
developer formår at lave noget der er bedre, vil de store udgiveres
mange marketingskroner overskygge det. De store genrer, som
eksempelvis lige nu er førstepersonsskydespil, realtime strategispil og
store online rollespil kræver også alt for mange ressourcer at producere
[Michael, 2004, s52]. At sidstnævnte oplysning er sand er jeg ikke i tvivl
om, kvaliteten af de nævnte genrer kan til dels måles kvantitativt, det vil
eksempelvis sige i antallet af baner, våben og modstandere, hvilket givet
vil gøre det til et tidskrævende projekt at udvikle et sådan spil, som en
lille indie developer. Min opfattelse af genrerne er dog måske lidt
bredere, end den som David Michael giver udtryk for, idet jeg mener det
vil være muligt finde ind til essensen i en af de store genrer, og finpudse
den i en sådan grad at selve omfanget af spillet, det kvantitative indhold,
bliver mindre vigtigt. Det er dog ikke et projekt jeg har tænkt mig at
forfølge for at bevise min påstand, og jeg kan sagtens se at det sikreste
selvfølgelig er at holde fingrene fra det de store leger med.
• Søg ikke at skabe fremtidens teknologi, eller at bruge nutidens. Ikke nok
med at de store udviklere konkurrerer på at skabe f.eks. det bedste
førstepersonsskydespil, så konkurrerer de også på at gøre dette med den
mest imponerende teknologi. Det kan en indie developer ikke
konkurrere på, da det igen kræver mange ressourcer i form at
arbejdskraft, tid og penge. Søg i stedet at skabe noget der nok ser
moderne ud, men gør det med gårsdagens teknologi. Den er billig, ofte
gratis, og der findes masser af eksisterende værktøjer og viden som kan
udnyttes [Micheal, 2004, s55]. Jeg har valgt Nintendo DS som platform
for mit spil, men selvom det er en ret ny platform, så er teknologien
forholdsvis primitiv (se bare på Sony’s PlayStation Portable 13 - et
13 http://www.yourpsp.com

teknologisk vidunder i forhold). 2d-grafisk er den at sammenligne med
det bedste fra 1990, mens den 3d-grafisk ofte er blevet sammenlignet
med en Nintendo 64 (Nintendo, 1996) eller Playstation (Sony, 1994).
Den har dog mere regnekraft og hukommelse til rådighed end disse
maskiner, hvad der kan udnyttes til f.eks. fysik, kunstig intelligens og
stemmegenkendelse. Netop stemmegenkendelsen kan også umiddelbart
lyde som et problem hvis rådet om at bruge gårsdagens teknologi skal
følges, men faktisk har stemmegenkendelse jo i mange år været anvendt
på f.eks. mobiltelefoner, der har en endnu mere begrænset regnekraft.
• Fokuser på det centrale - den meningsfulde leg. Sørg for at finpudse de
dele af systemet der gør spillet sjovt. Det er der masser af plads til, når
teknologien ikke først skal opfindes eller videreudvikles [Michael, 2004,
s57]. Selvom stemmegenkendelse har været brugt i mange år, så er der
desværre ikke mange som deler ud af deres teknologiske viden i en
sådan grad, at jeg kan bruge den direkte på Nintendo DS. Derfor må jeg
bruge kræfter på faktisk at genskabe eksisterende teknologi, hvad der
givetvis vil tage tid andre dele af designet. Jeg anser det dog ikke som
noget stort problem, og i forhold til projektet er en perfekt teknologi
hverken et krav eller en nødvendighed (mit spil udnytter at teknologien
er dårlig). Det centrale er, at jeg kan vise hvordan teknologien på en god
måde anvendes i et spil, og hvordan kvaliteten af dette bliver højt.
• Find en niche der ikke er overeksponeret. En simpel markedsanalyse kan
finde frem til hvilke spil der er populære i dag - lav ikke sådan et spil!
Lav helst heller ikke et spil af en type som andre indie developers laver.
Find i stedet et hul i markedet - en spiltype der ikke eksisterer til den
valgte platform, og lad dette være udgangspunktet. Det vigtigste er dog
at lave et spil, man selv ønsker at spille, og som man har nogle unikke
visioner for [Michael, 2004, s76]. Den sidste bemærkning her er også
hvad jeg selv vil betragte som den vigtigste, da ens udholdenhed ellers
sættes på en større prøve end hvad der er nødvendigt. En undersøgelse af
markedet er dog en god idé, og noget jeg derfor løbende har udført under
designet af spillet. Her sammenligner jeg også enkelte elementer i mit
spil, med sammenlignelige elementer i andre spil, for at lære af andres
erfaringer og fejl. Resultatet ses i designdokumentet i næste kapitel.
• Lad begrænsningerne udgøre en del af spillet. Dette er et af mine egne
principper. Begrænsninger kan indarbejdes i spillet på en sådan måde, at
de ikke længere virker som begrænsninger, men som tiltænkte
egenskaber ved spillet. Der findes mange eksempler på dette -
eksempelvis spil der har en simpel grafisk stil, men som netop pga.
denne fremstår unikke i stedet for primitive, selvom det måske reelt er
hvad de er. Killer7 (Capcom, 2005) og Rez (Sega, 2001) er gode
eksempler på dette. I mit spil har jeg valgt at lade den upræcise
57

58
stemmegenkendelse være en del af spillet, ligesom jeg også har valgt en
grafisk stil der er let (for mig) at arbejde med (se næste kapitel).
• Udnyt dine stærke sider. Endnu et af mine råd til mig selv. Ser jeg på
disciplinerne fra før, er der nogle jeg er bedre til end andre, hvorfor det
giver mening at lade dem jeg er bedst til, dominere designet.
Selvfølgelig kan ingen af disciplinerne undværes, men da jeg ikke er
nogen stor komponist, undlader jeg blot at lave et spil hvor musik indgår
som et element der skal kunne danne den meningsfulde leg.
Programmering bliver den disciplin jeg vægter højst, da det centrale i
spillet bliver kunstig intelligens og stemmegenkendelse, mens arbejdet
med 2d-grafik og naturligvis spildesign også får en central plads i
designprocessen.
Ved at følge disse råd, kan et godt spil udvikles selv med meget begrænsede ressourcer
hvad angår tid, mandskab og penge. Det er værd at bemærke, at jeg ikke har satset på at
udvikle et spil der umiddelbart kan distribueres bredt, da det med valget af Nintendo DS
som platform er svært opnåeligt. Det ville kræve at jeg bruger officielle Nintendo DSudviklingsværktøjer,
og at Nintendo godkender spillet til distribution på deres platform.
Dertil er det ikke realistisk at jeg kan lave et færdigt spil på ét semester, men det
forhindrer mig ikke i at følge rådene og udvikle en prototype på et godt spil, med de
ressourcer jeg har til rådighed.
Et sidste råd fra David Michael er at beskrive sit spils centrale elementer skriftligt, da det
er første skridt på vejen mod et reelt spil. At have noget konkret på papir fungerer som en
motivationsfaktor og en vejviser [Michael, 2004, s81]. I følgende afsnit vil jeg præsentere
de overvejelser der ligger bag formen på det designdokument den næste del af projektet
indeholder.
7.2 Designdokumentet
De fleste bøger om spildesign, indeholder et kapitel om hvordan et designdokument
udarbejdes [Michael, 2004, s80] [Rouse, 2005, k19] [Bethke, 2003, k8], eller også
indeholder de bare eksempler på konkrete designdokumenter [Salen & Zimmerman,
2004]. Der er dog ingen faste krav for hvordan et designdokument skal se ud, eller hvad
det skal indeholde, så jeg har set på de forskellige forslag og fundet frem til det de fleste
er enige om. Hertil har jeg tilføjet noget procesdokumenterende, da målet ikke blot er at
stå med et godt spil til sidst, men også at kunne argumentere for, hvorfor det ser ud som
det gør; mit designdokument skal ikke blot støtte designprocessen (som det normalt er
formålet med et designdokument) - det skal også beskrive den. Følgende afsnit vil være at
finde i designdokument:
• Filosofi
Det første et designdokument skal indeholde er en kort introduktion, der
groft beskriver spillets vigtigste elementer, og fortæller hvilken
oplevelse de skal give spilleren. Jeg vælger at kalde dette afsnit for

filosofi, da det er reelt er designerens filosofi for spillet, der skal
videregives. I systemudviklingsterminologi er dette den simple
kravspecifikation jeg tidligere har nævnt.
• System
Selve spillet skal beskrives i detaljer. Målet er som nævnt tidligere i
kapitlet ikke at implementere efter disse detaljer, da jeg arbejder med en
iterativ proces, men i stedet løbende at give et overblik over spillet som
det ser ud. Under system findes en lang række underafsnit, der skal lette
overblikket over spillet ved at opdele det i enkeltdele som eksempelvis
interaktion og opbygning.
• Teknik
Så vidt muligt vil teknikken ikke blive beskrevet under system, men det
bliver den til gengæld her. Alle aspekter beskrives kort, men uden at gå
alt for meget i detaljer, da teknikken som sådan ikke har så meget
relevans for projektets problemstilling.
• Prototyper
For at give et overblik over den proces designet har gennemgået, er det
nyttigt at holde styr på hvornår og hvad der er tilføjet eller ændret. I
dette afsnit gives et overblik over funktionaliteten i de enkelte
prototyper.
Ingen afsnit bliver dog, da dette er en projektrapport, rent deskriptive. Hele tiden vil der
blive argumenteret for enkeltdelene ved brug af teorien fra sidste afsnit, ligesom også
selve beskrivelserne vil tage begrænset form efter den teori der blev fremlagt. Det er altså
ikke et traditionelt industrielt designdokument, men også en designanalyse og -
diskussion.
7.3 Opsummering
Jeg indledte kapitlet med at sidestille udviklingen af computerspil med udviklingen af al
anden software. Herefter tog jeg nogle forbehold for den antagelse, idet computerspil på
flere måder er et ganske særlig form for software. Der stilles brede praktiske krav til
udviklerne, som både skal kunne lave grafik, komponere musik, programmere blandt
andet en kunstig intelligens og ikke mindst skal de designe interaktion som stimulere
vores lyst til leg og udforskning.
For at optimere mit møde med disse udfordringer, blev begrebet indie developers
inddraget. Disse folk arbejder alene eller i meget små grupper og formår alligevel at
udvikle spil af høj kvalitet. Måden de arbejder og træffer designbeslutninger på kan der
læres meget af, og det er netop hvad jeg har forsøgt. Jeg opstillede en række principper
for indie development som jeg har søgt at følge. De inkluderer blandt andet, det at udføre
en markedsanalyse for at finde en ledig niche, det at udnytte gammel teknologi og ikke
mindst det at søge originaliteten og det unikke.
Den sidste, og måske vigtigste, del af min metode er den der beskæftiger sig netop med
dette. Innovation og hvordan det opnås.
59

8 Innovation
Som beskrevet i teorien er innovation et kvalitetskriterium for spil. Innovation kan
fremkomme på mange måder, og forbindes ofte med kreativitet, opfindelser og
tilfældigheder. Det kan derfor være værd at definere innovation, og hvad der adskiller
innovation fra kreativitet og opfindelser. Jeg har søgt i forskellige opslagsværker
[Wikipedia] [Dictionary.com] [Merriam-Webster], og er nået frem til følgende forståelse
for begreberne:
60
• En opfindelse er en konkret ny idé, detaljeret skitseret men ikke udført i
praksis. Leonardo Da Vinci lavede mange opfindelser, men teknologien
var på daværende tidspunkt ikke god nok til, at de kunne udføres i
praksis.
• En innovation er en praksis udført opfindelse. Thomas Edisons
elektriske pære eller, for at blive ved computerspil, samarbejde frem for
konflikt mellem spillerne i Rip Off (Microvision, 1980) og Bullet Time
(en interaktiv slowmotion effekt) i Max Payne (Remedy Entertainment,
2001).
• Kreativitet er evnen til at skabe noget anderledes. Opfindsomhed er et
synonym for kreativitet.
På dette semester er et af målene at skabe innovation; altså et konkret produkt der
demonstrerer en ny idé, eller mere præcist - et produkt der anvender stemmebaseret
interaktion på en ny måde. Som sagt kan innovation fremkommen på flere måder.
Thomas Edison brugte elektricitet på en ny måde, nemlig til at skabe lys 14 , og han har
beskrevet hans fremgangsmåde sådan:
When I want to discover something, I begin by reading up everything that has been done
along that line in the past - that's what all these books in the library are for. I see what
has been accomplished at great labor and expense in the past. I gather data of many
thousands of experiments as a starting point, and then I make thousands more.
[Wikipedia, Edisonian approach]
Lidt groft sagt, så prøvede han sig altså bare frem. Tilfældigheder og held kan dermed
have indflydelse, og det virker ikke umiddelbart særligt videnskabeligt, eller som en
teknik dette projekt vil drage nytte af. Det er dog interessant, at han læser bøger om alt
hvad der tidligere er blevet lavet along that line. Han må altså have haft et mere eller
mindre konkret mål for øje, og faktisk så er hans teknik slet ikke så umoderne som det
kunne lyde - om lidt vil jeg introducere teknikken ludic engineering, der ikke er langt fra
Edisons tilgang til innovation.
14 Faktisk forbedrede han blot den elektriske pære som andre før ham havde opfundet, sådan at den lyste i
længere tid. Han har dog opfundet andre ting helt selv, så han er stadig et godt eksempel.

Tilfældigheder kan der ikke satses på, og det var nok heller ikke hvad Edison gjorde, så i
dag findes der mange forskellige teknikker der forøger chancen for at kreativitet fører til
innovation, og faktisk også teknikker der skaber innovation uden kreativitet. En meget
analytisk tilgang til et problem, kan tilsyneladende skabe innovative løsninger eller
produkter. I kurset Language Action Perspectives (LAP) er vi blevet præsenteret for en
række forskellige teknikker, og i de følgende afsnit vil dem jeg har brugt i dette projekt
blive beskrevet.
8.1 Technology inspiration
I LAP-kurset blev vi introduceret til artiklen Things aren’t what they seem to be:
innovation through technology inspiration [Rogers et al., 2002], der beskriver hvordan
forskere under det såkaldte Equator Project 15 arbejder med innovation. I artiklen
beskrives desuden et konkret projekt, et mixed reality computerspil til børn, hvad der dog
ikke har den store relevans for mit projekt, udover at det viser, at teknikkerne med succes
kan anvendes under designet af et computerspil. Deres grundlæggende princip er, at
innovation opstår mere eller mindre tilfældigt, men at det kan opsøges ved at arbejde
kreativt udforskende og samtidig have et mål for øje - det kunne f.eks. være det mål jeg
satte mig i projektets problemstilling.
For at nå målet arbejder de med to innovationsteknikker; technology inspiration og ludic
engineering. Sidstnævnte vil jeg gemme til næste afsnit, mens det at lade sig inspirere af
eksisterende teknologi vil blive diskuteret her. Rogers et al. beskriver teknikken som en
proces hvori de kigger på eksisterende teknologi og omkonfigurerer den eller
sammensætter den på nye måder, for at skabe nye oplevelser for brugeren af det system
de designer. Min umiddelbare bekymring angående denne teknik vil være om det egentlig
er innovation der opstår af en sådan proces, da brugen af eksisterende teknologi næppe
kan kaldes innovativ. Rogers et al. understreger dog selv, at de ikke ser deres teknik som
teknologistyret, idet teknologien blot inspirerer og sjældent bruges som den oprindeligt
var tiltænkt. Det er et argument, jeg er villig til at acceptere, og i mit eget projekt
anvender jeg da heller ikke ny teknologi - jeg anvender eksisterende teknologi på nye
måder.
Når der skal opnås innovation gennem technology inspiration, er det ifølge Rogers et al.
desuden vigtigt at teknologien der kigges på, den beskues fra flere perspektiver. Det er
ikke nok at se på teknologien med ét forskningsområde eller synspunkt in mente, men
helst med flere, da det vil give større mulighed for nye idéer. I mit projekt er det, hvad jeg
har gjort i sidste kapitel, hvor jeg blandt andet anvender lingvistikken i teorien om
computerspil, for at belyse denne fra nye perspektiver. Det er også, hvad jeg allerede i
indledningen gjorde da jeg så på talegenkendelsesteknikken fra et spildesignersynspunkt,
og fandt frem til, at svaghederne burde indgå som en del af spillet - fra et computer
science-synspunkt ville det naturlige nok i stedet have været at forbedre teknikken.
15 Et tværfagligt forskningsprojekt der arbejder med interaktionen mellem det fysiske og det digitale. Deres
web-side findes på http://www.equator.ac.uk
61

Også andre folk har anvendt technology inspiration som en innovationsteknik. Den
respekterede spildesigner og forfatter Ernest Adams præsenterede i 2001 spilindustrien
for Dogma 2001 [Adams, 2001]. Inspireret af danskerne Lars Von Trier og Thomas
Vinterbergs Dogme 95, var målet at adskille teknologien fra kreativiteten i spildesign, da
han mente at teknologien styrede spildesignet, med lav kvalitet til følge. Det er en
påstand han i nogle situationer kan have ret i, men også en påstand der er direkte
modstridende med at technology inspiration skulle motivere til innovation. Det
interessante i denne sammenhæng er da også at Ernest Adams i 2002 rapporterede fra et
arrangement (Indie Game Jam) hvor 14 spildesignere (med programmørtalent) brugte tre
dage på at modbevise påstanden [Adams, 2002]. Her var målet netop at lade eksisterende
teknologi inspirere til nye spilkoncepter. Resultatet blev 12 forskellige spil, der alle
brugte teknologien på nye måder og på den måde skabte nye spilkoncepter. Ernest Adams
måtte altså trække sine ord i sig igen - teknologi begrænser ikke nødvendigvis
kreativiteten. Igen er technology inspiration altså blevet anvendt med succes under
udviklingen af computerspil, hvilket naturligvis har gjort teknikken attraktiv for mit
projekt.
I næste kapitels designdokument vil jeg nævne hvor teknologien præcist har inspireret
mig, for at dokumentere brugen af technology inspiration teknikken. Her fortsætter jeg
med den anden teknik anvendt af Rogers et al. - ludic engineering.
8.2 Ludic engineering
Johan Huizinga’s Homo Ludens [Huizinga, 1949] er allerede blevet nævnt i projektets
teoretiske del, men også i forbindelse med udvikling og innovation har han et bidrag til
projektet. Homo Ludens - mennesket som legende væsner, med nysgerrighed,
udforskning og undren som de vigtigste egenskaber. Leg er ikke blot underholdning, men
også en måde at lære om verden og os selv på.
Det er den filosofi som Rogers et al. har bragt med over i deres ludic engineering-teknik.
Idéen er, at innovation opstår, når der leges, fordi vi helt naturligt udforsker teknologien
og undrer os over den. Leger vi med teknologien under udviklingen, det vil sige at vi
afprøver og eksperimenterer med den på en underholdende måde, er der god chance for at
innovation opstår, og at brugeren eller spilleren derefter kan få et produkt som leverer en
ny oplevelse [Rogers et al., 2002]. Skal jeg kritisere teknikkens anvendelighed, er det
klart, at den kun kan fungere ordentligt, hvis det produkt der designes er et produkt der
motiverer til leg - som f.eks. et computerspil. Det er nok tvivlsomt, hvad metoden kan
bidrage med under designet af en kontorapplikation, eller andre systemer med mere
praktiske og konkrete mål, da brugen af dem ikke rigtigt kan klassificeres som leg. Man
kan dog forestille sig hvordan teknologier udviklet til leg ved en tilfældighed får mere
praktiske formål. Et eksempel er de farvede sæbebobler der kommer på markedet til
februar, som udover at være en fantastisk opfindelse i sig selv, også introducerer et
farvestof med den praktiske egenskab, at det forsvinder efter kort tids kontakt med luft
[Popular Science, 11-2005]. I forbindelse med mit projekt, er jeg da heller ikke i tvivl om
at det er en god måde at arbejde på.
62

Det understøttes af det meste litteratur om spildesign, der siger at det virkeligt gode spil,
eller den virkeligt meningsfulde leg, først kan sikres når en del af spillet er lavet kan
afprøves og udforskes af udviklerne selv [Salen & Zimmerman, 2004, k2] [Rouse, 2005,
k15]. At udviklerne selv leger med spillet er i øvrigt ikke noget nyt. Et eksempel kunne
være pc-spillet Syndicate (Bullfrog, 1993), der blev udviklet af en lille flok entusiaster,
en af periodens få indie developers, der sad og spillede det efterhånden som de opfandt
og tilføjede flere features [Skog, 2005]. Udviklerne legede altså selv med spillet, og fik
igennem denne proces skabt et spil der var innovativt for sin tid, og som blev modtaget
godt af både spillere og kritikere.
8.3 Opsummering
Overordnet set er min innovationsstrategi at se på og lege med eksisterende teknologi,
med min problemformulering for øje - det vil, med en lille smule held og dygtighed, give
den innovative løsning der er behov for. De konkrete teknikker kaldes technology
inspiration og ludic engineering.
63

9 Metodisk delkonklusion
Uden at bruge meget plads, og uden for alvor at gå i dybden, har jeg beskrevet hvordan
systemudvikling kan foregå, og hvordan det bør foregå i forbindelse med spiludvikling;
særligt når ressourcerne er små og der er behov for innovation.
De forløbne tre kapitler giver mulighed for igen kan belyse projektets delproblemer, dog
stadig uden at give noget svar på den egentlige problemstilling.
64
• Hvordan designes et godt computerspil?
o Besvarelsen af dette spørgsmål skal berøre den teoretiske del af
computerspil, samt belyse den mere praktiske eller metodiske
side af sagen. Herunder hvordan et teoretisk grundlag kan danne
en begrebsmæssig ramme om en analyse af spil, samt hvordan
samme teori kan anvendes praktisk i designprocessen.
Jeg har tilbage i kapitel 4 allerede belyst dette spørgsmål gennem projektets teoretiske
grundlag, men kan nu sige, at metodisk er et godt computerspil resultatet af en
systemudviklingsproces, hvori en række forskellige discipliner og teknikker indgår.
Meget peger desuden på, at den optimale systemudviklingsproces hvad angår
spiludvikling er struktureret iterativt og giver plads til kreativitet for at innovation kan
opnås.
Overordnet er min proces derfor struktureret således:
Figur 9: Min systemudviklingsmetode
Det er en proces inspireret af eXtreme Programming og andre iterative
udviklingsmetoder, hvortil jeg tilføjer en række teknikker. Under design og test anvendes
teknikkerne UML (under modelleringen af designet), tests i form af funktionalitetstest og
kodetests. Hertil inddrages spillerne kort for at teste enkelte prototyper med høj
funktionalitet (depth). Det giver tilsammen en metode der opfordrer til innovation, men
som samtidig besidder en hvis form for struktur, hvorfor den også kan kontrolleres.

Resultatet af denne proces er dels selve produktet, men også et designdokument der
dokumentere processen og viser hvordan teknikker fra dette kapitel og teorien fra forrige
er brugt i praksis. Dette designdokument udgør hele den næste del af projektet.
Ydermere så kan innovation, der er meget vigtigt for et computerspil, opnås ved
anvendelsen af særlige teknikker, hvoraf technology inspiration og ludic engineering er
dem jeg selv har valgt at anvende, hvad der også er svaret på mit næste delproblem:
• Hvordan skabes innovation?
o Besvarelsen af dette spørgsmål skal give konkrete anvisninger i
hvordan et innovativt produkt eller en innovativ løsning skabes.
Herunder vil en række forskellige metoder blive berørt, og nogle
få vil blive belyst nøjere samt anvendt i praksis.
Anvendelsen af technology inspiration indebærer studier af eksisterende teknologi, samt
efterfølgende omkonfigurering af denne. Det kan foregå ved enten at kombinerer den
med anden teknologi, eller ved at modificere den på forskellig vis. Det vil føre til
teknologi der har mulighed for at levere nye oplevelser til brugeren, og som dermed kan
betegnes som innovativ. Hertil er ludic engineering en uvurderlig teknik, da den
faciliterer udforskningen af teknologien gennem leg. Når leg samtidig er en del af spillet,
altså det produkt der skal udvikles, så er legens plads i selve processen berettiget.
Det sidste delproblem fra projektets første kapitel kan også afklares:
• Hvordan udvikles computerspil af én person alene?
o Besvarelsen af dette spørgsmål skal give konkrete anvisninger i
håndtering af en udviklingsproces med kun én person involveret,
samt i hvordan de deraf begrænsede ressourcer udnyttes sådan at
spillet ikke lider kvalitetsmæssigt.
I afsnit 7.1 introducerede jeg begrebet indie developers, uafhængige udviklere, der
dækker over spiludviklere som udvikler deres spil alene eller i meget små grupper. Disse
folk har beviseligt skabt kvalitet med meget få ressourcer, og kan derfor bidrage med en
række retningslinjer for hvordan computerspil designes af én person alene. De inkluderer
blandt andet, det at udføre en markedsanalyse for at finde en ledig niche, det at udnytte
gammel teknologi og ikke mindst det at søge originaliteten og det unikke. Selv
supplerede jeg med krav om at udnytte sine egne forcer mest muligt i spillets design,
samt om at lade svaghederne i den gamle teknologi indgå som en del af spillet.
Tilbage er nu blot at afprøve teorien og metoderne i praksis, for at se om mine
argumenter holder - om de valgte teorier og metoder rent faktisk vil føre til udviklingen
af et innovativt computerspil. Inden jeg indleder projektets designdel vil jeg dog kort
diskutere svaghederne ved min metode, for at undgå at disse påvirker designet for meget,
samt se på hvilke alternative muligheder jeg har fravalgt.
65

9.1 Fravalgte metoder og ulemper ved de valgte
Som altid når der sammensættes en metode, så er der potentielle problemer ved den. Det
første jeg her vil diskutere er dens egnethed i forhold til udviklingen af et innovativt spil,
hvad der jo er metodens direkte mål. I denne henseende mener jeg dog ikke den
indeholder betydelige problemer. De forskellige metoder og teknikker er udvalgt med det
mål at udvikle et innovativt spil, og den opgave bør de derfor kunne håndtere
tilfredsstillende.
Det som kunne overvejes er om yderligere teknikker kan styrke metoden, og i den
henseende er paper prototyping interessant, da det er en innovationsfremmende teknik
som på samme tid også tillader hurtig og iterativ udvikling af prototyper. På semestrets
LAP-kursus er der blevet undervist i teknikken, og vi er blevet opfordret til at anvende
den i projektet. Problemet med teknikken i forhold til udvikling af spil, er at
papirprototyper er meget dårlige til at simulere kompleks interaktion [Snyder, 2003, s74].
Det kan løses ved at lave et spil der interaktionsmæssigt er simpelt, men det har jeg ikke
haft ønsker om - det er ikke metoden der skal diktere hvordan spillet kommer til at se ud,
og det mener jeg paper prototyping ville gøre. Hertil kommer problematikken i at
simulere stemmebaseret interaktion via papir, hvad der naturligvis slet ikke er muligt.
En tænkelig løsning her ville være at indføre såkaldt Wizard of Oz-test, hvor en designer
håndterer den funktionalitet som papirprototypen ikke kan indeholder. Men netop den
komplekse, finmaskede interaktion som et spil indeholder, vil stadig ikke kunne
simuleres nøjagtigt, hvorfor også denne udvidelse af paper prototyping-teknikken er
udeladt. Til gengæld har jeg i mindre omfang anvendt Wizard of Oz-test på de
funktionelle prototyper jeg har udviklet. Det er foregået ved at jeg har mappet forskellige
funktioner til knapperne på Nintendo DS, for så at trykke på dem når jeg har afgivet en
talekommando som systemet ikke kunne håndtere. Jeg mener dog ikke, at dette har
bidraget betydeligt til processen og resultatet, hvorfor det ikke vil blive nævnt yderligere.
I en sidste modifikation af paper prototyping kaldes resultatet hybrid prototyper. Her er
dele af systemet reelt implementeret, mens andre dele består af papir. Det er bestemt en
mulig måde at indføre paper prototyping i min proces på, da jeg så blot ville skulle lave
de mest statiske elementer i papir. Igen har jeg dog vurderet at dette ikke var værd at
bruge tid på, da det trods alt ikke er de statiske elementer der er mest spændende i et spil.
Som det også vil fremgå af næste kapitel, så er der ikke brugt tid på at designe mindre
betydende (i forhold til hvad der gør spillet godt) elementer som menuer og lignende.
Det er også interessant at se på metodens begrænsninger i forhold til det at lave et
studieprojekt, som jo også består af en projektrapport. Her er begrænsningerne til
gengæld betydelige, idet metoden først i det øjeblik noget er implementeret i praksis, står
med det detaljerede design som kan beskrives i rapporten. Jeg har taget lidt løst på denne
del af metoden, og i projektperiodens sidste uger forsøgt at designe lidt mere end hvad
der reelt er blevet implementeret, hvorfor de følgende kapitler også indeholder mere end
der i henhold til metoden og den afsatte tid kan forventes.
66

Del IV
DESIGN
The man who has no imagination has no wings
Muhammad Ali
Metoden beskrevet i forrige del er blevet fulgt, og teorien beskrevet i rapportens del II er
blevet praktisk anvendt. Målet er nu at dokumentere dette forløb og resultatet heraf. Som
nævnt tidligere er dette ikke et rent deskriptivt designdokument, men også i høj grad en
analyse af hvorfor det ser ud som det gør, tilsat den allerede beskrevne teori. Det
beskrivende designdokument vil være fremhævet og indrammet, mens resten af teksten er
det proces- og produkt-analyserende, dokumenterende og diskuterende som et
studieprojekt skal have mest af.
Jeg bør understrege at ikke alt der beskrives i de følgende kapitler er implementeret i den
prototype jeg står med ved projektets afslutning, men det grundlæggende er dog
implementeret, sådan at spillet kan testes og de for semestret vigtigste egenskaber
demonstreres (stemmebaseret interaktion).
Designdokumentet indledes med spillets filosofi, der også kan ses som en løst formuleret
kravspecifikation. Derefter følger designet af det system som beskriver spillet og dets
elementer, hvorefter et kapitel dedikeret til alt hvad angår interaktionen overtager. Den
tekniske side af sagen belyses i kapitel 13, og til sidst beskrives flere af de prototyper som
spillet har gennemgået samt den proces de er et resultat af.
67

10 Filosofi
Som beskrevet i forrige kapitel er designdokumentets første afsnit en introduktion til
spillet. Her vil jeg beskrive, hvad det overordnet indeholder og hvad det skal udtrykke.
Filosofien har været det nedskrevne mål for designprocessen igennem de første
prototyper, indtil mere blev nedskrevet med denne rapport for øje. Min filosofi for spillet
lyder således:
68
Silent Ninja Scream er det paradoksale og foreløbige navn for
Nintendo DS-spillet der omdanner spilleren til en lydløs og
råbende ninja. I rollen som ninjatræneren Sensei udfører spilleren
et væld af forskellige missioner, hvor lydløshed er påkrævet. Med
sig har Sensei dog sine ninjaelever, der udelukkende er
modtagelige for verbal undervisning og instruktion, hvorfor
lydløsheden må brydes.
Den centrale konflikt i spillet er dermed det paradoks Sensei står i
under missionerne, hvor lydløs snigen nogle gange er den bedste
løsning på et problem, mens det andre gange er bedre at råbe
kommandoer til eleverne, og dermed kaste dem ud i åben kamp
mod farlige fjender. Elever der overlever flere missioner under
Sensei, vil med tiden lære at handle selvstændigt, og faktisk kan
Sensei slet ikke klare de sværeste missioner uden en gruppe
dygtige elever. Både af at se Sensei klare en opgave selv, og af at
modtage og udføre ordrer, lærer eleverne at handle selvstændigt.
Missionerne indeholder elementer af både action, udforskning og
kreativ problemløsning, der vil være uendeligt mange af dem, og
de vil alle kunne gennemføres på få minutter. Spillets visuelle stil
er farverig og simpel i sit udtryk, mens dets historiske tema vil
tage et urealistisk afsæt i det feudale Japan.
Det metodisk set første skridt mod denne filosofi, var en undersøgelse af eksisterende spil
der anvendte talegenkendelse, samt af andre spil til Nintendo DS. Altså den
markedsanalyse som blev foreslået i afsnit 7.1, kombineret med technology inspiration.
10.1 Technology inspiration og markedsanalyse
Her følger formålsbestemte analyser af en række spil der har inspireret min filosofi for
spillet, samt diskussioner af hvordan inspirationen konkret indgår i dette. Det er ikke de
eneste spil jeg har set på, men de er dem som har haft størst indflydelse på spillet.

10.1.1 Nintendogs
Nintendogs (Nintendo, 2005) til Nintendo DS har siden det blev introduceret i april 2005
i Japan opnået stor ros over hele verden, og er et
perfekt eksempel på hvordan et innovativt spil kan få
succes. Spillet går i al sin enkelthed ud på at opdrage
og passe en hund. Den skal gå tur i parken, lege med
sine hundevenner, vaskes når den bliver beskidt og
den skal lære at lystre sit navn, når spilleren kalder
gennem maskinens mikrofon. Spillet adskiller sig fra
andre kæledyrsspil som f.eks. den gamle Tamagotchi
(Bandai, 1996), ved at være langt mere spil (forstået
som at det har valg med konsekvens). Hunden har
eksempelvis en begrænset udholdenhed, hvilket
udnyttes til en abstrakt indførelse af det i computer
science velkendte Traveling Salesman-problem 16
[Wikipedia, Traveling salesman], under gåturen med
hunden. Målet er at gå så langt som muligt rundt i
byen, inden hunden bliver træt. Traveling Salesmanproblemet
er et problem i størrelsesordenen NP 17 , og
er måske netop derfor også udfordrende for spilleren.
Det er en innovation indenfor det der populært kaldes
kæledyrsgenren, idet spilleren udfordres og udsættes
for valg der har konsekvens - går spilleren ikke langt
Figur 10: I Nintendogs (Nintendo,
2005) løser spilleren et NP-problem
som var det det letteste i verden...
nok med hunden, så får den ikke nok motion og får ikke øget sin udholdenhed. Spillet
indeholder altså interessante valg, og er generelt et fremragende eksempel på godt
spildesign.
Stemmegenkendelsen i Nintendogs forsøger at udnytte svaghederne i teknikken, ved at
gøre selve træningen af stemmegenkendelsesmodulet til en del af spillet. Når hunden
opnår et bestemt erfaringsniveau, får spilleren mulighed for at lære hunden nye tricks.
Det foregår ved at spilleren gentagne gange siger en kommando - f.eks. ”sit”, og når
hunden genkender kommandoen viser den det til spilleren. Efterhånden som spilleren
siger ”sit” flere gange, bliver chancen for at hunden forstår det bedre, indtil spillet kan
meddele at hunden har lært noget nyt. Derefter kan spilleren altid bruge kommandoen
”sit”. Dog er det stadig muligt, at hunden ikke forstår kommandoen pga. teknikken, hvad
der ikke tages yderligere højde for.
En anden mindre svaghed ved Nintendogs har det arvet fra de tidlige
kæledyrssimulatorer. Spillet straffer spilleren for ikke at spille hyppigt, hvad der efter
min mening er en forkert måde at opfordre spilleren til at spille på, da det let kan
frustrere. Nogle gange er det bare ikke praktisk muligt at spille, og ved spilleren at
hunden er sur, beskidt og træt efter at være blevet forsømt en halv dag, så må chancen for
16 Indenfor grafteori kaldes det også ”at finde den korteste hamiltonsti”.
17 Non-deterministic Polynomial-time - problemer der kan løses i O(n k ) (polynomial-time) af en nondeterministisk
Turing Maskine, svarende til O(k n ) (exponential-time) på en determistisk Turing Maskine
(det vil sige en computer). Kort sagt problemer som ikke er hurtigt løselige af en computer.
69

at hun slet ikke gider tænde spillet igen være betydelig. Problemet viser at det under det
semantiske syn på spillets system, bør overvejes nøje hvordan de interne relationer (her
tiden) påvirker objekter (spiller) og attributter (hund). Det er i mine øjne bedre at gøre
som i World of Warcraft (Blizzard, 2005), der faktisk belønner spilleren for at holde
pause fra spillet, ved at gøre belønningerne (i form af f.eks. erfaringspoint og guld) større
efter en pause. Her kan faren selvfølgelig være at spilleren holder for lange pauser og helt
glemmer spillet. En mulighed er naturligvis også helt at undlade at forbinde spillets tid
med den virkelige tid, hvad langt de fleste spil traditionelt har gjort.
Disse observationer af Nintendogs indgår i filosofien ovenfor på flere måder. Først og
fremmest er opdragelseselementet fra Nintendogs overført på ninjaeleverne, der igennem
Senseis træning skal lære at opføre sig som en ninja, ligesom de skal lystre Sensei ”som
en hund”. Træningen af selve talegenkendelsesmodulet vil jeg ligesom Nintendogs lade
indgå som en del af spillet (dog på en anden måde, hvad jeg vil beskrive senere), men til
gengæld vil det aldrig ske, at eleverne ikke reagerer på spillerens kommandoer. Det sker
ved (kort fortalt) at anvende samme kunstige intelligens som spillets fjender besidder, til
at kontrollere ninjaeleverne. Reelt vil ninjaeleverne dermed ikke reagere alene på
spillerens kommandoer, men delvist i henhold til den kunstige intelligens. Pragmatiske
forhold tages dermed i høj grad i betragtning, og vægtes gradvist højere jo mere erfaren
ninjaeleven er.
Min observation af et problem i størrelsesordenen NP har også haft en betydning for
spillets filosofi, idet kreativ problemløsning indgår i spillets missioner. Med kreativ
problemløsning forstår jeg problemer det ikke er muligt at løse algoritmisk (på kort tid),
men som kan løses forholdsvis hurtigt af den menneskelige hjerne. Problemer i
størrelsesordenen NP har ofte denne egenskab, og under det senere design af spillets
missioner har jeg derfor undersøgt eksempler på disse. De intelligensrutiner som spillets
fjender og ninjaelever reagerer efter, er dog naturligvis ikke i denne størrelsesorden (det
ville ikke være teknisk muligt). Det betyder at de talekommandoer som det skal være
muligt at give ninjaeleverne, skal have et simpelt mål der kan løses algoritmisk. F.eks. vil
talekommandoen ATTACK automatisk angribe nærmeste synlige fjende, på samme måde
som spillets fjender vil angribe ninjaeleverne så snart de er synlige for dem.
Problemet i forbindelsen mellem virkelig tid og spillets tid har jeg løst på traditionel vis,
ved slet ikke at indføre en sammenhæng. En velprøvet og velfungerende ”løsning”.
10.1.2 Rainbow Six og SOCOM
I holdbaserede førstepersonsskydespil er spilleren leder af en lille gruppe af soldater. I
lang tid blev kommandoer til de andre soldater givet gennem et visuelt interface, hvilket
gav spilleren problemer med at holde opmærksomheden på eget gevær, og tvang
udviklerne til at sænke spillets tempo for at mindske problemet. I de nyeste udgaver af
både Rainbow Six (Ubisoft, 2005) og SOCOM (Sony, 2004) kan der gives kommandoer
gennem en mikrofon, hvilket løser fornævnte problem, og gør det muligt at øge
spiltempoet. Der er stadig problemer med talekommandoer der ikke genkendes, men der
indføres alligevel en forholdsvis uproblematisk måde at interagere med holdet på.
70

Rainbow Six 3 og SOCOM II er nogle af de
bedste eksempler på hvordan talegenkendelse
kan anvendes multimodalt i computerspil.
Fordelene ved taleinput udnyttes til fulde i
dialogen med ens hold, mens tale ikke bruges i
den mere tidskritiske interaktion med spillerens
egen soldat. Det jeg også finder interessant ved
spillene er, at langt flere faktorer kontrolleres,
uden at den visuelle interaktion øges. Spillene
viser at det selv i hektiske situationer ikke
nødvendigvis er et problem at styre mere end én
karakter, og at flere brikker at flytte med
forøger spillets mulighedsrum.
Denne type spil har inspireret mig til at lade Sensei kontrollere en hel gruppe af
ninjaelever, og ikke blot en enkelt eller ingen, ligesom spillene har inspireret til at lade
eleverne handle selvstændigt i situationer, hvor Sensei ikke er i nærheden.
10.1.3 Strange Adventures in Infinite Space og Weird Worlds
To indie-spil udviklet af tomandsfirmaet Digital Eel har også haft en betydelig
indflydelse på spillets filosofi. Weird Worlds (Digital Eel, 2005) er 2’eren til Strange
Adventures in Infinite Space (Digital Eel, 2002), hvorfor de to spil minder ganske meget
om hinanden. Temaet er den altid populære udforskning af fremmede planeter, tilsat et
overdrevent eller urealistisk teknisk sprogbrug - der findes f.eks. ingen motorer, men
derimod f.eks. stardrives with extreme
spatial performance due to anti-aliasing. I
forhold til Nintendogs er det interessant at
den helt grundlæggende konflikt igen er
opbygget omkring Travelling Salesmanproblemet,
og at parallellerne til dette nu
er endnu tydeligere. Målet i spillet er at
rejse rundt til så mange planeter som
muligt på 2 år, og undervejs tjene så
mange penge muligt, ved enten at handle
med planeternes beboere eller ved at
skyde dem ned. Igen et bevis på at et NP-
problem kan indgå som en altid
udfordrende del af et spil, og her er det
endda vævet flot ind i spillets præmis.
Figur 11: Rainbow Six 3 (Ubisoft, 2005) er
et holdbaseret førstepersonsskydespil
Figur 12: I Weird Worlds (Digital Eel, 2005)
dannes missionerne tilfældigt af en
missionsgenerator
Den egentlig grund til at jeg trækker dette spil frem er dog en anden. Spillet har nemlig
en temmelig interessant måde at håndtere problemet med indie developers’ små
ressourcer på. Det ville naturligvis være kedeligt, hvis rummet altid så ens ud, altså at
planeterne og afstanden mellem dem var den samme hver gang man spillede, for så ville
NP-problemet have samme variable hver gang. Men i stedet for at lave en lang række
71

forskellige missioner, så har Digital Eel programmeret en missionsgenerator der ud fra
nogle få brugerbestemte parametre sammensætter et tilfældigt univers komplet med
planeter, solsystemer og sorte huller. Det ekstra arbejde der ligger i at programmere en
missionsgenerator er minimalt i forhold til den tid det ville tage at sammensætte et stort
antal forskellige missioner, hvorfor de har sparet mange ressourcer her. Faren ved en
missionsgenerator er at de genererede missioner ikke har mulighed for at danne
meningsfuld leg, fordi de ikke er blevet finpudset gennem mange timers test / leg. Det er
åbenlyst i Playstation 2-spillet Dark Chronicle (Sony, 2002), som igen er et studie i
dårligt design. Spillets missioner genereres tilfældigt, men desværre besidder de ofte
egenskaber der gør dem frustrerende og meningsløse. En mission i Dark Chronicle består
groft sagt af en labyrint som skal ryddes for monstre. Problemet er at nogle gange
genereres missionen sådan at målet er meget kort fra hvor spilleren startede, eller også
generes missionen sådan at labyrinten har alt for mange og lange blinde veje.
Udfordringen i designet af en missionsgenerator er at opstille nogle generelle krav for
hvor fleksibelt de forskellige objekter kan placeres i spillets rum og hvor meget deres
attributter kan variere. Det er den udfordring jeg tager op, når jeg indfører en
missionsgenerator i Silent Ninja Scream. Fordelene er dels, at jeg sparer den tid det tager
at designe en masse missioner, dels at der ikke er nogen (tydelig) grænse for antallet af
forskellige missioner og ikke mindst at jeg ikke skal udvikle et værktøj der letter designet
af en stor bunke missioner. I de første prototyper vil der dog kun være én mission, da jeg
mener den grundlæggende interaktion skal fungere før konceptet generaliseres.
Strange Adventures in Infinite Space og Weird Worlds har desuden inspireret til at søge
en overdreven og urealistisk tilgang til spillets historiske grundlag, der er det feudale
Japan. Der vides meget lidt om ninjaer [Wikipedia, Ninja], men det er ikke sandsynligt, at
de opførte sig som populærkulturen skildrer det (som lydløse dræbere). Alligevel er det i
denne urealistiske retning jeg vil skildre dem, fordi det trods alt er mest underholdende.
Det skal dog ske uden brug af makaber vold, og i en visuelt lys og munter stil hvor alle
kan være med. En inspirationskilde i forbindelse med ninja-temaet er den ”officielle”
ninja-webside 18 , hvor netop det overdrevne urealistiske syn på ninjaerne dyrkes.
10.2 Opsummering
Grundlæggende er spillets filosofi resultatet af en hastigt udført markedsanalyse (det
handler om ikke at bruge for mange ressourcer på det som ikke er ren udvikling), tilsat
min egen viden om markedet og en dosis opfindsomhed. Jeg har analyseret fem spil med
fokus på de ting jeg har ladet mig inspirere af under udarbejdelsen af spillets filosofi.
Nogle observationer indgår tydeligt i filosofien, mens sammenhængen med andre
observationer først bliver klar i de følgende kapitler - f.eks. hvordan NP-problemer indgår
for at give spilleren evig udfordring.
Efter at have præsenteret den overordnede filosofi for spillet, er det nu tid til at dykke ned
i systemets detaljer.
18 http://www.realultimatepower.net/
72

11 System
Målet med en designproces er at skabe en meningsdannende kontekst. I forbindelse med
spil er konteksten et system, og dette system består af de forskellige elementer der blev
introduceret tilbage i afsnit 4.3, altså objekter, attributter, interne relationer og miljø. I
det følgende afsnit vil disse elementer blive beskrevet, og derefter analyseret som et
syntaktisk system, hvilket som nævnt i afsnit 4.3 vil sige som noget der minder om et
matematisk regelsæt. I det efterfølgende afsnit 11.2 vil jeg analysere systemet semantisk
og pragmatisk, igen i henhold til hvad der blev fremlagt i afsnit 4.3 - der i øvrigt byggede
på afsnit 2.1, for lige at få klarlagt den teoretisk røde tråd.
11.1 Syntaktisk opbygning
Jeg indleder med at beskrive spillets opbygning og de vigtigste elementer der indgår i
dets missioner, for derefter at påbegynde analysen.
Silent Ninja Scream er et spil til én person, og det kan spilles på
to forskellige måder.
1. Campaign
2. Quick mission
I en ”campaign” er spilverdenen opdelt i to lag. Det øverste lag er
hvor der vælges mission, mens den nederste er selve missionen.
Når der skal vælges mission foregår det på et kort over et japansk
landskab, hvor der findes landsbyer, templer, skove og andre
steder hvor der kan hverves nye ninjaelever. Det nederste lag er
selve missionerne som foregår i og omkring landsbyerne og
templerne hvor konkurrerende læremestrer og deres elever
kæmper om at hverve de samme nye elever. De andre læremestre
er dog ikke ninjaer, men derimod pirater der søger at hyre
mandskab til deres skuder.
Under valget af mission udsættes spilleren for en række
strategiske valg… (ikke færdigudviklet).
I en ”quick mission” er det kun nederste lag, altså selve
missionen, som er aktuel. Her er et af målene som sagt at hverve
ninja-elever, før de tager hyre på et piratskib (se mere om øvrige
mål senere i dokumentet). Det gøres enten ved at hverve dem før
piraterne, eller ved at nedkæmpe alle pirater, inklusive en kaptajn.
Sensei skal dog være varsom med, hvem han hverver, for ikke
alle elever er lige autoritetstro, og vil fratage Sensei kontrollen
over de andre elever hvis de får chancen. Når en ninjaelev er
73

74
hvervet, skal han desuden oplæres til at forstå Senseis ordrer,
hvad der kræver, at han ser, hvad Sensei foretager sig.
Landskabet ses på den trykfølsomme skærm fra en perspektivløs
tredjepersons kameravinkel, oppe fra og ned. Spilleren peger på
den trykfølsomme skærm for at vælge hvor hovedpersonen Sensei
skal bevæge sig hen, mens der på maskinens anden skærm vises
et oversigtskort over hele landskabet. Dette oversigtskort vil fra
starten af en mission være blankt, og først efterhånden som
landskabet udforskes vil det blive udfyldt. På kortet vil venner og
fjender fremgå som prikker. Fjenderne dog kun når de er synlige i
forhold til Sensei eller en ninjaelev.
Som det fremgår så er målet at give spilleren en spilverden i to lag. I det øverste lag
udsættes spilleren for strategiske makro-valg, som påtænkes at have en indflydelse på
mikro-valgene i missionerne. Det vil give den nødvendige integration mellem spillets
øverste og nederste lag. Som det fremgår, er dette øverste lag dog ikke færdigudviklet,
hvorfor det ikke vil blive belyst yderligere.
I det nederste lag, altså missionerne, beskrives landskabet af de interne relationer mellem
objekter som landsbyer, templer og skove. Hver landsby vil derunder være beskrevet i de
interne relationer mellem objekter som huse, veje og åbne pladser, ligesom skovene vil
bestå af træer og buske. Hvert objekt vil have en række attributter der beskriver dem,
f.eks. størrelsen på et træ og placeringen af et hus. Disse attributter vil slutteligt have en
indflydelse på den leg som dannes i spilverdenen eller miljøet.
De mere aktive objekter er ninja-eleverne, piraterne, de potentielt nye elever og
selvfølgelig Sensei som spilleren har direkte kontrol med. Hertil kommer andre objekter
jeg vil beskrive nærmere i de følgende afsnit. En interessant attribut er
intelligensniveauet, der beskriver hvor dygtige ninja-eleverne er til at forstå Senseis
ordrer, mens det for piraterne er deres intelligens som beskriver, hvor gode de er til at
finde de nye elever, til at holde vagt og til at nedkæmpe ninjaer. Den mest interessante
attribut hos Sensei og hos ninja-eleverne er den som beskriver deres lederevner. Det
miljø af meningsfuld leg som spillet skal danne, skal nemlig (blandt andet) opstå i
spillerens balancering af Senseis lederevner. Disse begrænser antallet af elever han kan
have under sin kontrol, og hverver han flere elever end hans lederevner rækker til, vil der
være risiko for at eleverne selv begynder at kommandere med hinanden - er deres
intelligens samtidig ikke særlig høj, så vil det hurtigt gå galt. Eksemplificeret vil det sige,
at har Sensei en lederevne på 10, kan han højst lede f.eks. to elever med 5 i lederevne,
eller fem elever med 2 i lederevne. Dette lyder som et simpelt problem, og med en lav
lederevne er det da også tilfældet. Med en høj lederevne er det derimod svært at udnytte
den optimalt, og faktisk er dette et problem i størrelsesordenen NP som også kaldes
Knapsack-problemet [Wikipedia, Knapsack problem]. Det er samme problem man står
overfor, når en rygsæk skal pakkes så mest muligt kan være i den.

Spilles kun en enkelt mission, vil Sensei blive tildelt en tilfældig lederevne, mens den
under en Campaign vil stige efterhånden som flere missioner gennemføres. Jeg forestiller
mig desuden, at Sensei i de sidste missioner har en stor hær af ninja-elever under sin
ledelse, og at disse evt. kan opsplittes i mindre selvstyrende enheder, men jeg er ikke så
langt i designet, at jeg kan sige med sikkerhed, at dette vil fungere teknisk (i Rainbow Six
3 kan man f.eks. kun have tre soldater på sit hold).
I designuddraget ovenfor beskrives også
hvordan landskabet ses fra et perspektivløst
fugleperspektiv. Dette er valgt, fordi jeg godt
kan lide kameravinklen, fordi det er let at
tegne grafik uden perspektiv, fordi det
anvendes meget sjældent 19 og ikke mindst
pga. den intensitet den giver. Et af de bedste
eksempler på anvendelsen af perspektivet er
Amiga-spillet Alien Breed (Team17, 1991),
hvor det klare overblik over de umiddelbare
omgivelser er en stor fordel, mens det
manglende overblik over de lidt fjernere
omgivelser bidrager positivt til den for spillets Figur 13: Alien Breed (Team17, 1991) har en
tema meget passende intense klaustrofobiske klaustrofobisk perspektivløs kameravinkel
stemning. I Silent Ninja Scream, hvor der findes åbne grønne landskaber oftere end
indelukkede rumstationer, er en klaustrofobisk stemning dog ikke passende, hvorfor
perspektivet assisteres af et oversigtskort der viser på maskinens øverste skærm. På den
måde opnås et overblik over andet end de nærmeste omgivelser, og ved samtidig at undgå
afdækning af hele oversigtskortet før landskabet er udforsket, så tilføjes et element af,
ja… udforskning - en af menneskets grundlæggende drifter opfyldes dermed af spillet.
11.1.1 Missioner
Her vil jeg nu beskrive, hvordan missionerne genereres, hvad de består af og hvilke
forskellige mål der er i dem.
Missionerne i Silent Ninja Scream kan have et af følgende
hovedmål:
1. Hvervning af et bestemt antal ninjaelever.
2. Nedkæmpning af et bestemt antal pirater.
3. Nedkæmpning af piratkaptajn.
4. Erobring af værdigenstand.
5. Spionage.
6. Eskort.
19 I sin perspektivløse form. Er der et svagt horisontalt eller isometrisk perspektiv findes der utallige
eksempler på spilverdener som ses oppe fra og ned. At perspektivet anvendes sjældent finder jeg
forbløffende, for den ligeså perspektivløse set-direkte-fra-siden-kameravinkel er anvendt utallige gange
med stor succes.
75

76
7. Forsvar af tempelskat eller lignende.
8. …
Hertil kommer en række frivillige delmål:
1. Træning af ninjaelever.
2. Dressering af panda som ridedyr.
3. Indsamling af mindre værdigenstande.
4. Udfør missionen lydløst (et krav under spionagemissioner).
5. …
Opfyldelse af delmål vil øge Senseis lederevner, ninjaelevernes
intelligens og gøre opfyldelsen af hovedmålet lettere. Opfyldes
hovedmålet afsluttes missionen i succes, ellers afsluttes den i
fiasko.
En mission foregår i et landskab der kan have et af følgende
temaer:
1. Landsby
2. Tempel
3. …
Selve landsbyen eller templet fylder aldrig hele landskabet, og
omgives altid af skov eller vand. I skoven findes pandaer som kan
dresseres til ridedyr, og ved vandet findes piraternes skibe fyldt
med pirater og værdigenstande. I landsbyen og templet findes de
nye elever som både piraterne og Sensei er ude efter at hverve.
Eksempler på ting der kan findes i landskabet:
1. Mudderhuller der sløver tempoet og gør fødderne beskidte.
2. Bambusskov hvori pandaer opholder sig.
3. Floder hvor pandaer kan drikke vand.
4. Rismarker hvor kvinder og børn arbejder.
5. Bygninger (tempel eller hytte) hvori nye elever opholder sig.
6. Indhegninger hvor pirater holder pandaer fanget.
7. Kasser med våben (kastestjerner og sværd).
8. Piratskibe med pirater.
9. Træer og andet der kan bruges som skjul.
10. Tåge der sænker synsradius for både venner og fjender.
Det er disse ting som missionsgeneratoren skal placere tilfældigt i
landskabet, sådan at f.eks. pandaer placeres i deres bambusskov
og pirater ved vandet, ingen træer skal vokse på toppen af et hus,

ligesom et hus ikke må være placeret i en rismark og piratskibe
skal ikke sejle her.
(ikke færdigudviklet).
En lang række af de objekter der findes i landskabet under en mission er blevet nævnt, og
det bør fremgå at missionerne selv uden den tilfældige generering af landskabets layout
kan foregå på flere forskellige måder. Jeg har under designet delvist implementeret
missionstype 1 og delmål 2, mens missionsgeneratoren kan opfylde punkt 9. Det er en
forholdsvis begrænset del af systemet, men mere har ikke været nødvendigt for at
demonstrere hvordan stemmebaseret interaktion kan udnyttes på en ny måde.
En realismeforøgende attribut for landskabet som jeg har eksperimenteret med under
udviklingen er tåge med varierende tæthed, som skulle sænke ninjaelevernes synsradius.
Da den samtidig ødelagde overblikket for spilleren er dette dog endnu ikke en
velfungerende attribut. En mulig løsning ville være at gøre tågen gradvist tyndere jo
tættere på Sensei den er, men da dette er beregningsmæssigt tungt er det ikke umiddelbart
opnåeligt på Nintendo DS. Målet med at lade den bølge frem og tilbage var at tilføre den
i teorien omtalte dynamiske generering af interessante valg - det vil være en fordel at
angribe i ly af tågen, men også svært da angrebet skal times sådan at tågens tæthed er
højest i det øjeblik det første slag falder.
11.1.2 Venner og fjender
Her vil jeg beskrive attributterne hos de objekter der har den måske største indflydelse på
spillets miljø af meningsfuld leg, nemlig fjenderne i form af pirater og vennerne i form af
ninjaelever og pandaer.
De aktive karakterer i spillet findes i tre hovedkategorier:
1. Venner, herunder ninjaelever og pandaer
2. Fjender, herunder pirater og piratkaptajner
3. Neutrale, herunder potentielle elever og risbønder
Ninjaeleverne, det vil sige de allerede hvervede elever, har som
deres to vigtigste egenskaber deres intelligens og deres lederevne,
hvis betydning allerede er nævnt. Hertil kommer de statiske
fysiske egenskaber styrke, størrelse, hurtighed, syn og hørelse,
hvor sidstnævnte beskriver den radius som ninjaeleven kan adlyde
Sensei indenfor og synet beskriver den radius som fjenderne kan
ses indenfor. Der er også de dynamiske egenskaber synlighed og
hastighed, hvor sidstnævnte er den hastighed som ninjaeleven
bevæger sig med og førstnævnte er ninjaens aktuelle synlighed
udregnet i forhold til omgivelserne, underlaget og hastigheden. Jo
hurtigere ninjaeleven bevæger sig, jo større er chancen for at blive
opdaget af piraterne.
77

78
For at lette implementeringen har alle andre aktive karakterer
samme egenskaber, om end pandaen f.eks. ikke har brug for at
kende til sin synlighed.
En panda vil være større end ninjaeleverne, og kan derfor ikke gå
på de smalleste stier (evt. uden at lave larm), men til gengæld har
den en større styrke.
Fjenderne har de samme egenskaber som ninjaeleverne, og vil
ligeledes lave larm hvis de bevæger sig for hurtigt. En
piratkaptajn adskiller sig fra de øvrige fjender ved at være større,
stærkere og dygtigere til at angribe.
Karaktererne har udover deres egenskaber, flere forskellige måder
at handle på:
1. Følg Sensei
2. Bestig panda
3. Angrib fjende
4. Angrib fjende lydløst
5. Stop og vent
6. Patruljer tilfældigt omkring i landskabet
7. …
I et senere afsnit om spillets kunstige intelligens vil disse blive
gennemgået.
Som det fremgår, er hvert enkelt aktivt objekt eller karakter udstyret med en lang række
attributter, der beskriver deres egenskaber i forhold til spilverdenen og påvirker de
interne relationer mellem objekterne. Målet med at skabe så komplekse karakterer er at
forøge spillets mulighedsrum, ved at lade karakterernes attributter påvirke de valg der
skal træffes. Det vil eksempelvis være en fordel at bede en ninjaelev med en stor styrke
om at angribe en fjende, mens en ninjaelev med høj hurtighed vil være god at sende ud
for at patruljere omkring i landskabet med det mål at kortlægge det (som beskrevet
tidligere er der på den øverste skærm et kort over landskabet, som først detaljeres
efterhånden som der udforskes). Dermed har flere faktorer en indflydelse på de valg der
skal træffes.
Samtidig er målet med de komplekse karakterer at tilfører troværdighed eller realisme i
de interne relationer mellem objekterne. En interessant attribut er hørelsen, der har
betydning for spillerens brug af talekommandoer, idet piraterne, hvis de har en god
hørelse og står i nærheden af Sensei, vil høre talekommandoerne og dermed opdage
Sensei og hans ninjaelever. Ninjaeleverne vil ligeledes kun kunne angribe en fjende hvis
de kan se ham og bestige en panda hvis de kan se den. Under udviklingen har jeg
implementeret de aktive karakterer som såkaldte ”rigid bodies”, eller objekter der

påvirkes af realistiske fysiske begrænsninger (Newton osv.), men mere om det i kapitel
13 om teknik. Årsagen til fysisk simulation er igen at opnå troværdighed i de interne
relationer mellem objekterne - to karakterer der støder sammen vil f.eks. blive frastødt
hinanden sådan at den stærkeste flytter sig mindst.
11.2 Semantisk og pragmatisk opbygning
Efter at have diskuteret spillets formelle eller syntaktiske opbygning, vil jeg kort belyse
de næste lag.
Semantisk set (eksperientelt ifølge Salen & Zimmerman) er spillets ene objekt spilleren,
attributterne er Sensei og ninjaeleverne, da det er disse spilleren kan kontrollere, de
interne relationer er selve interaktionen med spillet og miljøet er de umiddelbare fysiske,
psykologiske og kulturelle omgivelser i form af blandt andet selve maskinen, støjniveauet
og spillerens humør.
I dette lag bliver flere vigtige egenskaber ved spillet fremlagt. Interaktionen er naturligvis
altafgørende, og vil blive belyst detaljeret i næste kapitel, mens objektet i form af
spilleren er sværere at tage hensyn til. Jeg har som nævnt tidligere valgt en munter og lys
stemning og visuel stil til spillet, for netop at sikre at alle kan være med, men selv dette
vil givetvis afskrække nogle. Målgruppeanalyser er dog et helt emne for sig selv, og et
emne jeg har valgt ikke at gå mere ind i. Attributterne belyst semantisk vil beskæftige sig
med blandt andet spillets visuelle fremtoning, hvad jeg vil behandle kort i kapitel 14.
Overvejelser omkring systemets semantiske miljø, er svære og f.eks. spillerens humør er
næsten umuligt at tage hensyn til. At talekommandoer vil være en del af interaktionen gør
dog alligevel dette element interessant, for hvordan tages hensyn til om spilleren taler i et
ophidset tonefald? Det er et spørgsmål, jeg vil lade stå åbent, da jeg ikke teknisk kan løse
det. Men det ville da være sjovt, hvis ninjaeleverne hørte bedre efter, hvis spilleren var
sur.
Pragmatisk set (kulturelt ifølge Salen & Zimmerman) er objektet hele spillet,
attributterne er informationer om spillets forskellige dele som campaign, mission, Sensei,
osv., samt om udvikleren (mig) og udviklingsprocessen. De interne relationer beskriver
f.eks. den historiske sammenhæng mellem pirater og ninjaer og grunden til at ninjaer er
klædt i sort, mens miljøet er kulturen som spillet eksisterer i.
At det pragmatiske syn på spil som et system kan være vigtigt, er demonstreret af
spiludvikler og udgiver Electronic Arts, der de seneste år har fået megen dårlig omtale
pga. sine udviklingsmetoder hvor medarbejderne presses hårdt og spillenes kvalitet ofres
til fordel for julesalget [GameDaily Biz, 03-12-2004]. En parallel ses i indie-udviklerne
der er blevet populære, fordi det generelt anses for sympatisk og imponerende når små
grupper udvikler gode spil med få ressourcer. Popularitet betyder bedre salgstal, og det
mærker både indie-udviklerne og Electronic Arts. I min situation er det svært at sige
noget fornuftigt om dette, men jeg har da tilpasset både min metode og selve spillet til
mine ressourcer og evner. De historiske paralleller mellem eksempelvis ninjaer i mit spil
og i virkeligheden eksisterer naturligvis, og en analyse af disse ville være mulig. Jeg
79

synes dog ikke det er så interessant i forhold til min problemstilling, at jeg vil bruge tid
på det.
11.3 Opsummering
I kapitlet er spillets formelle og syntaktiske opbygning blevet gennemgået. Opsummeret
så består spillet af to lag, nemlig det øverste campaign-lag og det nederste missions-lag.
Missionerne og deres objekter, attributter, interne relation og miljø er blevet fremlagt og
det ses at de vigtigste objekter er Sensei, ninjaelever og pirater som sammen med
objekterne som danner landskabet beskriver de interne relationer som spilleren skal
påvirke og dermed opleve et miljø af meningsfuld leg. Denne påvirkning er emnet for det
følgende kapitel om spillets interaktion, der også kan ses som de mere detaljerede
overvejelser af spillet som et semantisk system.
80

12 Interaktion
Jeg har tidligere beskrevet hvordan den største udfordring under designet af et spil, er
konstruktionen af et system der dynamisk generer interessante og integrerede valg med
synlige reaktioner - altså meningsfuld leg. Det er den del af designet som der er blevet
brugt mest tid på, fordi selve interaktionen i forhold til semestrets tema er den mest
interessante, da det er her innovationen skal søges.
Valgene i missionerne handler overordnet set om at vælge de rigtige elever for at have så
mange som muligt med sig, og om at kommandere dem rundt for at løse missionens
hovedmål og eventuelt også delmål. Typen af valg i spillet er dels denne tydelige, næsten
forgrenende type som normalt forbindes med valg, men også endeløse mikro-valg kædet
sammen i en længere sekvens er meget vigtige for spillet. Herunder tæller ting som
hvilken vej rundt om et træ der vælges, hvilken hastighed der bevæges i, hvilken måde
der angribes på osv. Altså består en mission dels af valg på makro-niveauet hvor f.eks.
eleverne hverves, og dels af valg på mikro-niveau omhandlende måden ninjaeleverne og
Sensei bevæger sig rundt på og hvordan de handler.
For at opnå en klarhed i den teoretiske analyse af designet, har jeg udvalgt nogle få af de
valg spilleren kan træffe og vil i de næste afsnit fokusere på hvordan netop de valg gøres
synlige, integrerede og interessante. Der skal naturligvis træffes flere valg end følgende,
men en komplet belysning af spillets valg ville forkludre analysen (og kræve mere tid):
I. Spilleren kan vælge at hverve en ny ninjaelev til Sensei.
II. Spilleren kan vælge at bede Sensei om at bestige en panda.
III. Spilleren kan vælge at bede Sensei om at angribe en fjende.
IV. Spilleren kan vælge at bevæge Sensei i enhver retning i flere hastigheder.
V. Spilleren kan vælge at selektere en ninjaelev, som derefter vil forfølge Sensei.
VI. Spilleren kan vælge at give den selekterede elev besked på at bestige en panda.
VII. Spilleren kan vælge at beordre den selekterede elev til at angribe nærmeste fjende.
VIII. Spilleren kan vælge at få eleverne til at stoppe op og ikke længere følge Sensei.
Listen over spørgsmål der kan hjælpe at sikre at disse valg er synlige, integrerede og
interessante var følgende:
1. Hvad skete der før spilleren fik valget?
2. Hvordan vises muligheden for valg til spilleren?
3. Hvordan udfører spilleren valget?
4. Hvad er resultatet af valget, og hvordan påvirker det fremtidige valg?
5. Hvordan vises resultatet til spilleren?
Hvor spørgsmål 1 og 4 handler om integration og interessante valg, spørgsmål 2 og 5 om
synlighed i output og spørgsmål 3 om synlighed i input.
81

Spillet er på alle måder multimodalt, forstået som at der både gives input og output på
flere forskellige måder. Her beskrives nu inputmodaliteterne, hvor som nævnt især
spørgsmål 3 især er blevet overvejet.
12.1 Taktilt input
Spilleren giver spillet input på to måder. Der er dels en direkte kontrol med Sensei via
knapper og trykfølsom skærm, og dels en indirekte kontrol med ninjaeleverne via
talekommandoer. Den første form for input jeg beskriver, er den der gives via knapperne
på Nintendo DS. Figuren herunder illustrerer de forskellige muligheder maskinen har for
taktilt input:
Figur 14: De taktile inputmuligheder på Nintendo DS
Når den trykfølsomme skærm anvendes, så mistes muligheden for at anvende enten
styrekryds + L eller frontknapper + R da enten højre eller venstre hånd bruges til at holde
den pen der bruges på skærmen. Samtidig er det kun L eller R (afhængig af hvilken hånd
spilleren bruger) der er ergonomisk let tilgængelig 20 , mens brug af styrekryds og
frontknapper kræver at maskinen holdes på en bestemt måde. Her følger
designdokumentets beskrivelse af den taktile input.
20 Subjektiv vurdering
82

Kontrollen med Sensei foregår ved at spilleren via den
trykfølsomme skærm peger på det sted i landskabet Sensei skal
bevæge sig hen. Jo længere væk der peges, jo hurtigere bevæger
Sensei sig - på den måde er det også muligt at få Sensei til at
snige sig af sted ved at pege meget tæt på ham. L eller R,
afhængig af om spilleren er højre- eller venstrehåndet, bruges til
at udføre alle tilgængelige handlinger, og er kontekstsensitiv i den
forstand at når spilleren trykker på den, så reageres der afhængigt
af situationen. Følgende reaktioner kan affødes af et tryk på denne
knap:
1. Hvis Sensei står i nærheden af en potentiel elev vil han hverve
denne som ny ninjaelev.
2. Hvis Sensei står i nærheden af en panda vil han bestige den.
3. Hvis Sensei står i nærheden af en fjende vil han angribe.
4. …
Reaktionerne har gradvist højere prioritet, altså vil der f.eks. ikke
kunne hverves en elev så længe der er en synlig fjende i
nærheden.
Målet med denne opsætning af den taktile input har været at opnå simplicitet for spilleren
(uden at dennes mulighedsrum minimeres), da jeg mener at simplicitet fordrer synlighed i
input - er der kun én knap, så er det meget synligt hvad der kan trykkes på. Udfordringen
ligger ikke i at trykke på de rigtige knapper, men nærmere i at trykke på det rigtige
tidspunkt. Spilleren udfører altså altid et valg med den samme knap, men gennem
systemets pragmatiske analyse af situation i spilverdenen, vælges det automatisk hvad der
sker når der trykkes på knappen.
Det ses at designdokumentet har besvaret spørgsmål 3; hvordan udføres valget, med
hensyn til de fire af de otte valg som spilleren stilles:
I. Spilleren kan vælge at hverve en ny ninjaelev til Sensei.
o Dette gøres ved at placere Sensei i nærheden af ninjaeleven og trykke på
knappen.
II. Spilleren kan vælge at bede Sensei om at bestige en panda.
o Dette gøres ved at placere Sensei i nærheden af pandaen og trykke på
knappen.
III. Spilleren kan vælge at bede Sensei om at angribe en fjende.
o Dette gøres ved at trykke på knappen mens en fjende er nær Sensei.
IV. Spilleren kan vælge at bevæge Sensei i enhver retning i flere hastigheder.
o Dette gøres ved hjælp af den trykfølsomme skærm, hvor der peges på
Senseis destination. Hastigheden afhænger af hvor langt væk der peges.
Besvarelsen af spørgsmål 3 med hensyn til de fire andre valg følger i næste afsnit.
83

Ergonomisk besværlig brug af maskinen er i øvrigt søgt undgået, ved at vælge L eller R
som den vigtigste knap. At spillet kan kontrolleres med kun én knap har dog selvfølgelig
gjort dette designvalg meget let at træffe - det ville være dumt at vælge en anden knap.
12.2 Stemmebaseret input
Her fortsættes beskrivelsen af spillets input, der som nævnt flere gange også inkluderer
input via tale.
84
Den anden måde spilleren giver input på er via talekommandoer.
Hver gang Sensei gør noget som han ikke tidligere har gjort, vil
spilleren skulle indtale en talekommando der kan forbindes med
denne handling. Derefter vil eleverne (de som så Sensei udføre
handlingen) kunne instrueres i at gøre det samme som Sensei kan.
Følgende talekommandoer skal indtales:
1. ”STOP” når Sensei første gang stopper op. Denne kommando
vil få eleverne til at stoppe op og lade være med at følge
Sensei.
2. ”NINJA” når Sensei første gang hverver en ninjaelev. Denne
talekommando bliver den mest brugte, idet den også bruges til
at vælge en ninjaelev der er stoppet op og få denne til følge
Sensei igen, ligesom den kan kædes sammen med de følgende
kommandoer. Siger spilleren ”NINJA” er det den ninjaelev
som Sensei kigger på der vil blive valgt, og altså ikke blot den
nærmeste.
3. ”MOUNT” når Sensei første gang bestiger en panda. Kan
senere bruges for at få ninjaeleverne til at bestige en panda
med kommandoen ”NINJA” (hvorefter den elev som Sensei
kigger på vælges) + ”MOUNT” (hvorefter den for den valgte
elev nærmeste panda bestiges).
4. ”ATTACK” når Sensei første gang angriber en fjende. Kan
ligesom ”MOUNT” kombineres med ”NINJA” for at
kommandere en bestemt elev til at angribe nærmeste fjende.
5. …
Talekommandoerne er valgt sådan, at der er adgang til flere instruktioner end der er
talekommandoer til, ved at tillade kombination af talekommandoer. Dette er
hovedsageligt gjort af tekniske årsager, men den opnåede simplicitet er et uventet plus.
Med kun en håndfuld forskellige talekommandoer at huske på, kompliceres input ikke
unødigt og det undgås at spilleren skal huske på en større grammatik. Et interessant
designvalg findes i måden ninjaeleverne selekteres på. Her tages igen pragmatiske
hensyn 21 , idet ninjaeleverne kun er modtagelige for talekommandoer mens Sensei kigger
21 Pragmatisk i spilverdenens kontekst, og ikke som i det tidligere omtalte kulturelle syn på selve systemet.

på dem. På den måde undgås det at skulle kalde hver ninjaelev ved navn, hvilket ville øge
antallet af ord der skulle trænes betydeligt (hvad der heller ikke rent teknisk ville gå an).
Følgende grammatik i BNF beskriver formelt hvordan talekommandoerne kædes
sammen.
COMMAND → X Y
X → NINJA
Y → STOP | MOUNT | ATTACK | ε
Yderligere er ordene valgt sådan at de fonetisk ikke
minder om hinanden, og ikke indeholder hviskende
lyde der er svære at genkende digitalt pga. deres
spektrale lighed med støj. Den fonetiske
transskription af kommandoerne ser ud som på Figur
15Error! Reference source not found., og
sammenlignes med IPA-kortet i bilag A ses det at der
ikke findes foner fra kolonnerne ”dental” (lyde dannet
lige bag tænderne) og ”glottal” (lyde dannet nederst i
halsen), der dem som har størst lighed med
Figur 15: Fonetisk transskription af
spillets grammatik ifølge Longman
Dictionary of Contemporary English
[Longman].
almindelig støj. Det mest problematiske ord er ATTACK, fordi trykket ligger efter første
stavelse, hvad der kan forvirre genkenderen til at tro, at den første del af ordet er støj som
skal fjernes, mens den sidste stavelse så forveksles med STOP. Praktiske tests (læs: ludic
engineering / leg med spillet) har dog vist at problemet er meget lille, med den genkender
jeg har lavet, pga. den pragmatiske tilgang. En af mine overvejelser har været at udskifte
de engelske ord med tilsvarende japanske da de vil passe godt ind i spillets tema, og da
disse ifølge mine egne undersøgelser (via engelsk-japansk ordbøger) har meget simple og
forskellige fonetiske transskriptioner. Slutteligt valgt jeg dog, at dette ville virke
unaturligt på de fleste spillere, da engelsk er mere almindeligt brugt - selv i japanske spil
bruges der ofte engelsk. En multilingual udvidelse af spillet ville dog være forholdsvis
simpel at implementere, og spilleren kan da også selv vælge at indtale andre ord end der
bliver bedt om, da talegenkenderen ikke har noget forhåndskendskab til ordenes fonetiske
opbygning.
Medregnet de nævnte ergonomiske begrænsninger hvad angår taktilt input (at der kun
kan bruges én knap), så tilfører talekommandoerne mulighed for at give spillet input på
flere måder end det ellers ville være muligt. Selv den ”pragmatisk opmærksomme” knap
der bruges som den eneste af maskinens knapper, ville ikke kunne gætte hvornår spilleren
ville have ninjaeleverne til at stoppe, hvormed jeg vil påstå at talekommandoerne er den
optimale form for input i dette spil.
Problemet med talekommandoer er at de ikke altid genkendes korrekt, hvorfor jeg
inddrager pragmatisk analyse i genkendelsen, for at udelukke nogle muligheder og
dermed øge chancen for at det korrekte ord genkendes. Er en ninjaelev ikke i nærheden af
en panda, så er det ikke sandsynligt, at spilleren sagde MOUNT, bevæger ninjaeleven sig
ikke er det ikke sandsynligt, at spilleren sagde STOP, er der ingen fjender i nærheden kan
85

ATTACK udelukkes og kigger Sensei ikke på en ninjaelev kan det udelukkes, at spilleren
sagde NINJA. På den måde kan det med stor sikkerhed altid afgøres, hvad spilleren
sagde, og denne pragmatiske analyse af situationen i spilverdenen kan derfor udnyttes,
når talekommandoens semantiske betydning skal fortolkes. I spillets kode er det f.eks. et
funktionskald som dette; ninjaelev.mount(panda) 22 , der bliver den semantiske logik som
kaldes når genkenderen opdager ordet MOUNT (efter først at have genkendt NINJA og
valgt en bestemt ninjaelev til at modtage kommandoen). Viser den efterfølgende
pragmatiske analyse, at handlingen ikke er meningsfuld, vil den ikke blive udført. Mit
navn for denne teknik er kontekstsensitiv talegenkendelse.
I dette afsnit er spørgsmål 3; hvordan udføres valget, blevet besvaret med hensyn til de
fire sidste muligheder for valg som spilleren har:
V. Spilleren kan vælge at selektere en ninjaelev, som derefter vil forfølge Sensei.
o Dette gøres ved sige NINJA mens Sensei kigger i retning af den ninjaelev
som ønskes selekteret.
VI. Spilleren kan vælge at give den selekterede elev besked på at bestige en panda.
o Dette gøres ved at sige MOUNT mens en ninjaelev er selekteret.
VII. Spilleren kan vælge at beordre den selekterede elev til at angribe nærmeste fjende.
o Dette gøres ved at sige ATTACK mens en ninjaelev er selekteret.
VIII. Spilleren kan vælge at få eleverne til at stoppe op og ikke længere følge Sensei.
o Dette gøres ved at sige STOP, hvorved alle elever der følger Sensei
stopper op.
Med dette er det belyst hvordan alle (de otte udvalgte) valg i spillet udføres, og den del af
interaktionen der beskæftiger sig med spillets output kan nu analyseres.
12.3 Output
God interaktion opstår først, når spillet synligt reagerer på spillerens input, og ligesom i
denne så er multimodalitet også brugt i spillets output. Der anvendes grafisk output via de
to skærme, auditivt output i form af tale, lydeffekter og musik og til sidst taktilt output
via en vibrator 23 . Flere af disse outputmodaliteter er dog ikke meget længere end idé eller
testkode-stadiet, hvorfor jeg i de følgende afsnit vil koncentrere mig om af grafisk output
af forskellig art, og lyd i form af talesyntese.
Målet med spillets output er at opnå den altafgørende synlighed i alt hvad spilleren
foretager sig. At dette er vigtigt ses også i de fem tidligere nævnte spørgsmål, hvoraf både
2 og 5 drejer sig om synlighed i output. For at genopfriske dem:
86
2. Hvordan vises muligheden for valg til spilleren?
5. Hvordan vises resultatet [af et valg] til spilleren?
22 Pseudokode - spillet er implementeret i C++
23 Nintendo DS har mulighed for at afspille både Nintendo DS og Game Boy Advance-spil. Nogle Game
Boy Advance-spilkassetter har indbygget vibrator der kan kontaktes fra et Nintendo DS-spil.

Det er disse to spørgsmål, jeg søger at besvare for de (otte udvalgte) valg spilleren har
mulighed for at træffe.
Grafisk har spillet to måder at reagerer på spillerens handlinger.
Det sker enten via grafiske reaktioner fra karaktererne eller
landskabet, eller via information placeret i et grafisk interface
synligt over selve spilverdenen. Hertil kommer det nævnte
grafiske oversigtskortet på maskinens øverste skærm.
Her følger en liste over handlinger spilleren kan udføre, efterfulgt
at den reaktion spillet vil levere:
1. Sensei styres mod et bestemt mål med en bestemt fart.
Sensei vil begynde at bevæge sig mod målet, i en fart der
afhænger af afstanden derhen. I det grafiske interface vil en måler
vise, hvor meget støj Sensei laver, mens han bevæger sig, og
spilleren vil kunne se sammenhængen mellem hastighed og
støjniveau.
2. Sensei hverver en ny ninjaelev.
Eleven vil trække i ninjabeklædning og begynde at følge efter
Sensei. På oversigtkortet vil den nye ninjaelev blive tilføjet som
en prik i landskabet. I det grafiske interface vil en måler tilføje
ninjaelevens lederevner til summen af alle ninjaelevers
lederevner, og hvis de overstiger Senseis egen lederevne vil det
fremgå. Måleren er udformet som en lodret bar der farvelægges
efterhånden som flere ninjaelever kommer til. Den er grøn, når
Senseis lederstatus ikke er truet, og rød når den er overgået af
eleverne - oftest er den dog en gradientfarve mellem grøn og rød.
3. Sensei bestiger en panda.
Sensei kravler op på pandaen, mens hans prik på oversigtskortet
bliver større for at vise, at han ridder.
4. Sensei angriber en fjende.
Sensei kaster kastestjerner efter fjenden eller slår på ham med sit
nærkampsvåben (ikke færdigudviklet). På oversigtkortet skifter
prikken der repræsenterer Sensei farve til rød, for at vise at han er
i kamp.
Er det første gang i en campaign eller quick mission at de nævnte
handlinger forekommer, skal spilleren tilknytte en talekommando
til handlingen, for at kunne beordre ninjaeleverne til også at
udføre handlingen. Når der skal indtales en ny talekommando
fortælles dette til spilleren i en tankeboble hvor Sensei skal
87

88
forestille at tænke over situationen. Eksempler på tankebobler er
følgende:
1. ”…yes, this panda is a fine MOUNT”
2. “…hmm, I feel he will develop into a first-class NINJA”
3. “…speed is crucial, why did I STOP?”
4. “…the enemy has fallen to my deadly ATTACK”
Hvor spilleren forventes at sige ordet skrevet med store bogstaver.
En anden dialog vil derefter instruere spilleren I hvordan
talekommandoen indtales (evt. kun første gang) (ikke
færdigudviklet).
Med talekommandoerne indtalt, har spilleren mulighed for at
udføre følgende handlinger:
1. Spilleren selekterer en ninjaelev.
Er eleven ikke allerede blandt de elever som følger efter Sensei,
vil han gøre det nu. Selve selekteringen vises ved, at en lysende
cirkel placeres omkring eleven både i spilverdenen og på
oversigtskortet. I det grafiske interface vil ikoner vise elevens
intelligensniveau som de kommandoer han kan forstå - altså de
handlinger han har set Sensei udføre, ligesom støjmåleren vil
stige kortvarigt. Selve selektionen vil være aktiv i fem sekunder,
hvorunder spilleren har mulighed for at afgive yderligere
talekommandoer.
2. Spilleren beordrer den selekterede elev til at bestige en panda.
Eleven kravler op på pandaen, mens hans prik på oversigtskortet
bliver større for at vise at han ridder. I det grafiske interface stiger
støjmåleren kortvarigt.
3. Spilleren beordrer den selekterede elev til angreb på en fjende.
Eleven kaster kastestjerner efter fjenden eller slår på ham med sit
nærkampsvåben (ikke færdigudviklet). På oversigtkortet skifter
prikken der repræsenterer eleven farve til rød for at vise, at han er
i kamp. I det grafiske interface stiger støjmåleren kortvarigt.
4. Spilleren beordrer eleverne til at stoppe op.
Hvad der selvfølgelig får eleverne til at stoppe op. I det grafiske
interface stiger støjmåleren kortvarigt.
Fjenderne vil reagere på lignende måder, så de vil ikke blive
gennemgået yderligere. Alle fjender og potentielle elever vil
desuden kommunikere deres statiske egenskaber grafisk. Her vil
eleverne f.eks. vise deres lederevner, inden Sensei hverver dem i

farven på deres pandebånd. Røde pandebånd betyder høj
lederevne, mens grønne betyder lav. Også intelligensniveauet vil
fremgå af ninjaelevens beklædning - jo flere kommandoer han
forstår, jo mørkere vil ninjadragten være.
Til sidst vil der være output i form af tale. Ninjaeleverne vil
bekræfte deres ordrer verbalt, ligesom de selv vil afgive ordrer
hvis Sensei ikke har tilstrækkelig høj lederevne til at kontrollere
alle ninjaelever. De afgivne ordrer vil være identiske med dem
spilleren har mulighed for at give, dog begrænset af elevens
intelligensniveau. Har eleven f.eks. ikke set Sensei angribe, kan
han ikke kommandere andre elever til at gøre det. Også piraterne
afgiver talekommandoer, hvilket gør at spilleren kan høre dem, og
se dem kortvarigt på oversigtskortet selvom de er ude af syne.
(taktilt output, musik og lydeffekter er ikke færdigudviklet)
Ovenstående del af spillets designdokument har beskrevet hvordan spillets output
fungerer. Jeg har valgt at give grafisk output på flere måder, alt afhængigt af hvad jeg
fandt, ville give den synligste reaktion på de forskellige handlinger. At jeg har valgt at
have et grafisk interface med yderligere information ovenpå selve spilverdenen, er valg
der er inspireret af teknologien som spillet udnytter. Uden at fordybe mig i de tekniske
detaljer, så er årsagen, at det er teknisk fordelagtigt kun at lade spilverdenen dække et
udsnit af skærmen, sådan at en tynd kant i både højre og venstre side ikke udnyttes.
Denne tomme plads kan så i stedet bruges til et grafisk interface, hvor målere af
forskellig art placeres. En anden overvejelse jeg havde omkring udnyttelsen af denne
tomme plads, var om der kunne placeres yderligere knapper her (skærmen er trykfølsom),
men den simple input som talekommandoerne indførte gjorde dette overflødigt. Dermed
bruges den trykfølsomme skærm som nævnt tidligere kun til at kontrollere Sensei.
På trods af dette grafiske interface, har jeg dog søgt at holde mest mulig output i selve
spilverdenen, da det er her spilleren vil have sit fokus og outputtet vil derfor få den største
synlighed her. Utallige målere, tal og anden information ville blot fjerne spillerens
opmærksom fra spilverdenen, hvad der kan få uheldige følger og føre til frustration, fordi
synligheden ikke er høj nok, når spillerens fokus er andetsteds.
Informationen der gives på oversigtskortet er ikke af tidskritisk afgørende karakter,
hvorfor den kan placeres på den anden skærm hvor synligheden givetvis vil være lavest.
Spilleren vælger selv, hvornår det er nødvendigt at kigge på den øverste skærm.
Jeg har noteret mig at intelligens i spil (og i den virkelig verden) ofte modelleres som et
tal, eller en IQ. Jeg mener dette er en forkert måde at måle intelligens på, fordi det er
muligt at være dygtig på ét område og dårlig på et andet. Derfor vælger jeg i stedet at
modellere intelligens som en tilstandsmaskine - jo flere strenge den accepterer, jo højere
intelligens. Det er dette princip der fremgår af de ikoner som viser hvilke
talekommandoer en selekteret ninjaelev kan forstå. Grunden til at jeg har valgt ikoner,
89

frem for eksempelvis symboler er, at spillerens muligheder for valg i dette tilfælde skal
have en høj synlighed, hvad en direkte afbildning af reaktionen på valget vil give.
Output via tale har på nuværende stadie en ret begrænset rolle, men imitationen af
spillerens måde at give talekommandoer medfører nogle interessante overvejelser. For det
første vil en talekommando fra en ninjaelev selvfølgelig lyde fra maskinens højtalere,
hvad der samtidig betyder, at talegenkenderen opfanger den. Minder spillerens stemme
tilfældigvis om ninjaelevens, vil det betyde, at spillet tror, at spilleren har afgivet en
talekommando, da det jo er trænet i at genkende spillerens stemme. Sandsynligheden for
at dette sker, er dog ret lille og det kan helt undgås ved at afbryde talegenkenderen når
elverne taler. En lignende problematik ligger i støjmåleren, og hvornår den skal give
udsving. Skal det give udsving uanset hvad spilleren siger, eller kun når et ord
genkendes? Jeg har valgt første løsning, pga. originaliteten i det, men flere praktiske tests
må vise om det reelt kan fungere uden at frustrere.
En mere interessant konsekvens af imitationen er at den kan have en opdragende effekt
på spilleren, hvorfor man kunne forestille sig en introduktionsmission hvor en højere
rangerende ninja underviste Sensei i brugen af talekommandoer. Dette er dog indtil
videre ikke afprøvet i praksis, hvorfor jeg ikke diskuterer det yderligere. Til sidst er det
interessant, at piraterne anvender samme talekommandoer til at kommunikere, hvad der
kan have den samme opdragende effekt.
Målet var som nævnt at besvare spørgsmål 2 og 5, altså hvordan muligheden for, og
reaktionen af, et valg vises. Her besvares disse spørgsmål med henblik på alle de (otte
udvalgte) valg som spilleren kan træffe.
I. Spilleren kan vælge at hverve en ny ninjaelev til Sensei.
o Den potentielle elev viser, at han kan hverves ved at have et pandebånd på,
som yderligere med sin farve viser konsekvensen af en hvervning, nemlig
i hvor høj grad Sensei vil kunne bibeholde sin lederstatus. Den faktiske
hvervning vises ved at eleven får ninjabeklædning på og begynder at følge
efter Sensei.
II. Spilleren kan vælge at bede Sensei om at bestige en panda.
o Der er intet som viser, at pandaen kan bestiges, idet der antages et
kendskab til spillets muligheder. Den logiske konsekvens af, at Sensei
bestiger en panda er at han placeres på den, mens en mindre grafisk
reaktion finder sted på oversigtskortet.
III. Spilleren kan vælge at bede Sensei om at angribe en fjende.
o Der er intet som viser, at fjenden kan angribes, idet der antages et
kendskab til spillets muligheder. Konsekvensen af, at Sensei angriber en
fjende, er, at en kamp indledes, mens en mindre grafisk reaktion finder
sted på oversigtskortet.
IV. Spilleren kan vælge at bevæge Sensei i enhver retning i flere hastigheder.
o Det antages, at spilleren ved, at Sensei kan bevæges ved at der peges på
skærmen, men valget vises ved at Sensei bevæger sig. På det grafiske
interface påvirkes en måler der viser hvor meget Sensei larmer.
90

V. Spilleren kan vælge at selektere en ninjaelev, som derefter vil forfølge Sensei.
o Spilleren er informeret om at målet med missionen er at hverve
ninjaelever, hvorfor muligheden for at selektere en elev er kendt. Selve
selektionen vises med en lysende ring omkring ninjaeleven, mens det
grafiske interface opdateres med informationer om elevens intelligens.
Selektionen vil være aktiv i fem sekunder, hvorefter den afbrydes.
VI. Spilleren kan vælge at give den selekterede elev besked på at bestige en panda.
o I det grafiske interface vises hvilke talekommandoer den selekterede elev
kan forstå. Reaktionen af valget er, at eleven bestiger pandaen.
VII. Spilleren kan vælge at beordre den selekterede elev til at angribe nærmeste fjende.
o Som ovenstående.
VIII. Spilleren kan vælge at få eleverne til at stoppe op og ikke længere følge Sensei.
o Muligheden for dette valg er blevet vist, da Sensei stoppede op første
gang. Reaktionen på valget er at eleverne stopper.
Med dette er synligheden i interaktionen analyseret færdig. Integrationen i valgene og om
de er interessante diskuteres kort i næste afsnit hvor der argumenteres for hvordan disse
tre elementer til sammen vil føre til dannelsen af meningsfuld leg.
12.4 Meningsfuld leg
Det blev nævnt i kapitel 4, at alle spillets valg skal have konsekvens, da de ellers ville
være overflødige og ikke interessante. Jeg vil ikke gennemgå alle valgene, men
eksempelvis er konsekvensen af noget så simpelt som at bestige en panda, at Sensei eller
ninjaeleven bevæger sig langsommere og er større, mens styrken samtidig vokser. Der er
dermed både fordele og ulemper ved at ride på en panda. Det samme gælder i valget af
den hastighed Sensei skal bevæge sig med - bevæger han sig hurtigt kan missionen
hurtigere fuldføres, men bevæger han sig langsomt kan han undgå at blive opdaget af
piraterne. Jeg mener, at alle spillets valg i en eller anden forstand, er interessante.
At de også er integrerede i hele spillet er sværere at argumentere for, da spillets øverste
lag, dens campaign, ikke er færdigdesignet. Valgene er dog på et lavere plan integrerede i
den kontekst der hedder den aktuelle mission, hvor f.eks. valget af en ninjaelev med høj
lederevne på senere tidspunkt vil medføre at en anden ninjaelev enten må overgå til
piraterne, eller forstyrre Senseis lederskab hvis han alligevel hverves.
Spillet indeholder masser af interessante valg, der samtidig er integrerede i mindst den
aktuelle mission. Dermed vil muligheden for at det danner meningsfuld leg være stor. Her
fortsætter jeg med en teoretisk analyse af spillets input og output set gennem Winograd &
Flores’ conversation for action-model.
12.5 Conversation for action
Jeg har gennem de sidste kapitler omtalt, hvordan ninjaeleverne inddrager deres viden om
situationen, når de modtager og fortolker talekommandoer, og vil nu analysere dette
gennem conversation for action-modellen, for at klarlægge eventuelle svagheder i
91

dialogen mellem spiller og spil, samt hvilke pragmatiske forhold spillet skal kende til for
at kunne tillægge en talekommando den rette mening.
Først er det dog værd at klassificere dialogmanagermodellen der anvendes i spillet. Jeg
har valgt en agent based command and control-tilgang, hvilket konkret vil sige at kunstig
intelligens anvendes i meningsdannelsen af de kommandoer som spilleren kan give
ninjaeleverne. Når en command and control-tilgang anvendes, så kan talekommandoerne
klassificeres i henhold til speech acts-teorien som directives, altså som talers forsøg på at
få modtager til at udføre en handling. Reaktionen fra ninjaeleverne når der siges NINJA
og de dermed selekteres, kan yderligere klassificeres som commisives, altså noget der
binder taleren til en fremtidig handling, idet selekteringen markerer at de er modtagelige
for en talekommando. Til sidst kan beklædningsskiftet der forekommer, når en ninjaelevs
intelligens stiger, betragtes som en expressive speech act da en mental tilstand udtrykkes.
Det er altså ganske ligetil at betragte dialogen som speech acts, og derfor også muligt at
beskrive den med de følgende conversation for action-modeller. Her først modellen for,
når Sensei vil selektere en ninjaelev med talekommandoen NINJA.
Figur 16: conversation for action-model over Senseis selektering af Ninjaelev
Den primære vej (fra punkt 1 til 5) gennem dialogen er fuldt udfyldt. Talekommandoen
NINJA fører til selektering, som ninjaeleven viser med en lysende ring omkring sig selv,
mens ikoner viser hvilke mulige talekommandoer dialogen kan afsluttes med. Dermed
kan dialogen reelt klassificeres som en dialog, og den vil virke realistisk hvis den
fuldføres uden forhindringer. Der er tilmed markeret tre tilfælde hvor dialogen kan
afbrydes. Det er først i tilfældet, hvor Sensei ikke kan se ninjaeleven, eller hvor
ninjaeleven ikke kan høre Sensei. Til sidst er der den mere frivillige afbrydelse af
dialogen, i det tilfælde hvor spilleren venter mere end fem sekunder før næste kommando
afgives. Det, som mangler i modellen, er hele den forhandlende del, der skulle have været
i midten. Jeg mener ikke dette er et problem for hvis det pragmatiske (kulturelle)
systemsyn tages i betragtning - en kulturel viden om militære forhold (det er trods alt en
krigslignende situation Sensei befinder sig i) vil fortælle spilleren, at man ikke forhandler
med en overordnet, ligesom en overordnet ikke forventes at trække en ordre tilbage. De
pragmatiske forhold som spillet skal kende til for at forstå en talekommando, er dermed
92

hvorvidt Sensei ser på ninjaeleven, hvorvidt ninjaeleven er tæt nok på Sensei til at høre
ham, og til sidst er et kendskab til varigheden på dialogen nødvendig.
En svaghed ved dialogen i spillet er også blevet tydeliggjort, idet intet fortæller spilleren
at dialogen er afbrudt pga. syns- eller hørelsesproblemer hos Sensei eller ninjaelev. Det
samme gælder for de fem sekunder - der er ikke nogen indikation af hvornår de fem
sekunder er gået. Det første problem kunne løses ved at lade Sensei verbalt fortælle, at
han intet kan se, at eleven må være døv eller en lignende kommentar. En af grundene til
at jeg ikke tidligere har valgt ikke at lade Sensei tale var dog, at spilleren dermed vil have
bedre mulighed for at identificere sig med ham. Det er set mange gange at et spils
hovedperson ikke taler, netop for at øge spillerens indlevelse. De tidligere nævnte
tankebobler er også en mulighed, men da de vil risikere at blokere for udsynet til
spilverdenen i en kritisk situation er denne løsning heller ikke brugbar. Til sidst er der
muligheden for subtile effekter, som f.eks. at få Sensei til at trække på skulderne eller på
anden måde virke forvirret. Det er den løsning jeg vil søge. Problemet med de fem
sekunder løses derimod meget simpelt, ved blot at lade den lysende ring gradvist miste
sin intensitet, for at vise at selekteringen ikke holder evigt.
Den næste dialog jeg vil analysere gennem conversation for action-modellen, er den som
følger af talekommandoen MOUNT:
Figur 17: conversation for action-model af Sensei der beordrer en ninjaelev til at bestige en panda
Denne gang er den primære vej gennem dialogen ifølge Winograd & Flores ikke fuldt
udfyldt, idet det sidste skridt, hvor Sensei bekræfter overfor ninjaeleven at kommandoen
er accepteret, er blankt. Her mener jeg dog, hvad jeg også diskuterede da modellen blev
gennemgået teoretisk, at stilhed kan fungere som accept. Selve den observationen af at
pandaen bestiges kan også betragtes som accept. En mulig ændring kunne være at lade
Sensei klappe af ninjaeleven, eller nikke med hovedet, om end jeg ikke finder dette
realistisk eller nødvendigt for at ovenstående model kan betragtes som en reel dialog.
Situationen, hvor talekommandoen ikke accepteres, eksisterer også i denne model, og
heller ikke her vises spilleren årsagen. Igen vil jeg løse problemet med små subtile
animationer af Sensei eller ninjaelev der ryster på hovedet eller på anden vis virker
93

forvirrede. Behovet for forhandling kan afvises af samme grund som ovenfor, mens en
sidste udvej (fra punkt 4 til 9) umuliggøres af at stilhed bekræfter kommandoen. Her er
ludic engineering eller test eneste måde at afgøre om dette vil virke realistisk, eller om
stilheden skal aflyses af en bekræftelse for også at muliggøre den sidste udvej.
Som det ses er det meget givtigt at analysere dialogen gennem conversation for actionmodellen,
idet flere problemer kan tydeliggøres inden spillet testes. Jeg vil dog ikke
bruge plads på de to næste talekommandoer, STOP og ATTACK, da analysen af dem
minder meget om modellen for MOUNT.
12.6 Opsummering
Igennem dette kapitel har jeg fremlagt og analyseret spillets interaktion. Både hvad angår
input og output er den multimodal. På inputsiden anvendes taktilt input til kontrol af
spillets hovedperson Sensei, mens talekommandoer anvendes til kontrol af de hvervede
ninjaelever. De vigtigste for den taktile input er at der kun bruges én knap (plus den
trykfølsomme skærm), for at sikre en høj synlighed. Den ene knap er ”pragmatisk
opmærksom” på hvad der foregår i spilverdenen, og den kan dermed bruges til udførelsen
af flere forskellige handlinger eller valg. Talekommandoerne er ligeledes pragmatisk
opmærksomme, idet eksempelvis Senseis synsretning og ninjaelevernes hørelse har en
betydning for hvordan en talekommando tolkes. En anden betegnelse for pragmatiske
opmærksomhed er kontekstsensitivitet - en betegnelse jeg brugt i projektets titel.
På outputsiden anvendes primært grafisk output i form af bevægelige og animerede
karakterer og et grafisk interface indeholdende informationer om den selekterede elev,
om Senseis støjniveau og om hans lederevner. Hertil kommer et grafisk oversigtkort over
hele det landskab som missionen foregår i, hvorpå positioner og tilstande for ninjaelever
og pirater kan aflæses. Sekundært giver ninjaeleverne hinanden talekommandoer på
samme måde som Sensei / spilleren gør, hvad der igen øger synligheden af den
kommunikation som finder sted i spilverdenen.
Hertil er det søgt at gøre alle valg interessante og integrerede, for på den måde at skabe
et spil der danner meningsfuld leg. Det sidste jeg gjorde i kapitlet var at sammenholde
spillet dialogmodel eller management med Winograd & Flores’ conversation for actionmodel,
hvilket tydeliggjorde nogle designmæssige svagheder som bør søges løst i en
senere prototype. Her følger nu et kort kapitel omhandlende teknikken som spillet
udnytter.
94

13 Teknik
I dette kapitel vil jeg beskrive spillets tekniske arkitektur, dog uden at belyse de mindste
detaljer. Indledningsvis kan et klassediagram i UML give et overblik over hvad der
håndteres af den største CPU i Nintendo DS:
Figur 18: Klassediagram indeholdende systemets vigtigste klasser, med nogle af deres attributter og
metoder. Klasserne her håndteres af den største CPU.
Den centrale klasse er GameWorld som repræsenterer spilverdenen, endnu kun i form af
en mission (altså ikke kampagne delen). I spilverdenen / missionen findes op til 32
95

objekter af RigidBody-klassen, der praktisk anvendes til at repræsentere Sensei,
ninjaelever, pandaer og pirater - altså de aktive fysisk simulerede objekter. Mindre
præcist simulerede objekter, såsom kastestjerner og træer, dannes af objekter af klassen
MovingEntity, hvoraf der kan være op til 64 i spilverdenen. Klassen Sprite beskriver de
aktive elementer som spillets grafik består af, og der kan være op til 128 af dem i
spilverdenen. Den grafiske repræsentation af både en MovingEntity og en RigidBody er
en Sprite, ligesom også dele af det grafiske interface er opbygget af Sprites - her kan op
til 32 anvendes, da 64 går til MovingEntity-objekter og 32 til RigidBody-objekter. Viser
en mindre statisk fordeling af Sprite-objekter mellem MovingEntity, RigidBody og det
grafiske interface sig nødvendig, er refaktorering muligt, men 32 er et teknisk maksimum
for antallet af RigidBody-objekter, da disse udnytter maskinens rotationsregister som
maksimalt kan indeholde 32 rotationsvariable.
Spilverdenen indeholder desuden op til fire grafiske Background-objekter eller lag, der
bruges til at indeholde landskabet i de to nederste lag, evt. tåge i næste lag og grafisk
interface i det øverste lag. Selve landskabet genereres af metoden setupTerrain på
GameWorld-objektet, mens også det grafiske interface håndteres af en metode her. En
Background kan desuden være animeret, hvilket kan udnyttes til f.eks. bølgende tågeeffekter.
Den måske mest komplekse klasse er SteeringBehavior, der udnyttes af alle RigidBodyobjekter.
Her udregnes objekternes fysiske påvirkning af hinanden, og deres
bevægelsesmønstre styres også her. SteeringBehavior fungerer som en tilstandsmaskine,
hvor forskellige metoder kan være aktive eller inaktive og påvirke den fysiske kraft som
returneres af metoden calculate i form af en vektor, og anvendes i bevægelsen af en
RigidBody. Vektorer er et objekt der anvendes meget gennem hele systemet, og som
dannes af klassen Vector 24 , hvorpå metoder til udregning af alt fra længde til prikprodukt
findes.
I metoderne handleButtons og handleVoice håndteres spillerens forskellige former for
input. Knapperne er lette at håndtere, mens talekommandoerne håndteres i samarbejde
med objekter kørende på maskinens anden CPU. En multiprocessor-arkitektur er altså
taget i anvendelse, for at udnytte maskinens regnekraft bedst muligt. Den fysiske
simulering er meget beregningskrævende, mens genkendelsen af talekommandoer også er
meget beregningskrævende, hvorfor en uddelegering af opgaverne har været nødvendig.
Jeg havde foretrukket hvis alt beregning kunne klares af én CPU, da det er klart lettere at
arbejde med, men det har bestemt været lærerigt at arbejde med to CPU’er, og resultatet
er da også bedre end hvad det ville have været med kun den ene CPU.
I alt er der skrevet over 12.000 linjer kode, hvorfor jeg ikke har vedlagt det som et printet
bilag. Til gengæld kan koden hentes fra min web-side. Det anvendte objektorienterede
programmeringssprog er C++, der er kompileret med det frit tilgængelige Nintendo DSudviklingsmiljø
DevkitPro [Devkitpro, 2005], der kort fortalt er en modificeret udgave af
open source-kompileren GCC, tilsat dygtige hackeres udforskning af Nintendo DS.
24 Ses ikke på figuren.
96

13.1 Talegenkendelse
I forhold til teorien beskrevet tilbage i afsnit 3.1, hvor det talegenkendelses-system som
jeg ville udvikle blev beskrevet, er der gennem det praktiske arbejde opstået en ændring.
En yderligere forsimpling af talegenkendelsesteknikken er indført, idet jeg ikke har haft
tid og behov til at implementere dynamic time-warping-teknikken. Målet med denne er
som nævnt at skalere de opfangede ord sådan at de har samme længde som de optagne /
indlærte ord, og tilmed at skalere dem dynamisk over tid, altså sådan at det søges at
matche de forskellige udsving overfor hinanden. En simplere mulighed, der giver en
teoretisk dårligere genkendelse på 5 %, er at skalere ordet lineært [Furui, 2001, s270].
Eftersom jeg tager mere hensyn til de pragmatiske forhold, er præcisionen i den egentlige
genkendelse ikke så vigtig og denne lette løsning er derfor anvendt.
På de andre niveauer er min talegenkender stort set identisk med den som blev beskrevet
teoretisk i sidste del af afsnit 3.1. En vital forskel er dog at den før det pragmatiske lag
stort set intet genkender. Det har (ikke helt overraskende) vist sig at være en enorm
udfordring at programmere en talegenkender fra bunden. Med spillets afhængighed af
den pragmatiske genkendelse, er det dog uden betydning, da spillet tager højde for dette
ved udelukkende at basere sin genkendelse på pragmatiske forhold. Ekstrem
kontekstsensitiv talegenkendelse.
13.2 Opsummering
Jeg har ikke beskrevet teknikken bag spillet i mange detaljer, da det både for forståelsen
af spillets funktionalitet og for besvarelsen af problemstillingen er mindre væsentligt.
Derfor er der ikke meget at opsummere. De over 12.000 linjer kode der er skrevet har dog
på ingen måde været en lille del af projektet, og det er udarbejdelsen af disse der har
været den centrale aktivitet igennem en stor del af projektperioden. De erfaringer jeg har
gjort mig, er jeg meget glade for og jeg er bestemt blevet en bedre programmør de seneste
måneder. Især arbejdet med fysiksimulation og kontekstsensitiv talegenkendelse har
været udfordrende, og illustrerer perfekt hvordan brede evner indenfor mange områder er
nødvendig for at lave et spil.
97

14 Prototyper
Udviklingen af spillet har været præget af meget korte iterationer, hvor resultatet altid har
været en ny prototype med en eller flere nye elementer i form af f.eks. ny funktionalitet
eller ny grafik. Da ændringerne fra iteration til iteration har været meget små, vil jeg ikke
beskrive resultatet af dem alle, og har derfor udvalgt nogle få prototyper hvorigennem
udviklingen som spillet har gennemgået kan beskrives i store træk.
14.1 Nummer 1
I løbet af projektperiodens første måned lavede jeg en grundlæggende prototype, hvori
bevægelsen af Sensei blev finpudset gennem ludic engineering og mikrofonen til
Nintendo DS blev afprøvet. Målene var at implementere den mest grundlæggende og
oftest udnyttede inputmulighed (bevægelsen af Sensei via trykfølsom skærm), at lave de
klasser der senere kunne anvendes til andre bevægelige objekter og ikke mindst at
implementere en papegøje-funktion der anvendte mikrofonen til at gentage spillerens
kommentarer. Disse ting blev alle implementeret.
For at gøre det lidt sjovere at finpudse styringen af Sensei, gjorde jeg det desuden muligt
for ham at skyde og jeg tilføjede en ninjaelev (reelt bare endnu en Sensei, da de teknisk
ikke adskilte sig fra hinanden) som fulgte med ham. Så blev situationen mere som et spil,
hvormed princippet fra ludic engineering om, at det virker bedst i en legende kontekst
viste sig korrekt. Et af delmålene før Sensei kunne bevæge sig var et landskab han kunne
gøre det i. Det var under implementeringen af dette, at begrænsninger eller svagheder ved
maskinen inspirerede til at udnytte den yderste højre og venstre side af skærmen til et
grafisk interface. Skulle disse områder af skærmen i stedet have været brugt til visning af
landskabet, så ville hukommelsesforbruget være fire gange så stort for hvert grafisk lag i
landskabet 25 . Den sparede hukommelse kunne i stedet udnyttes til at lade et af
landskabets lag, nemlig tågen, være animeret. Det viser, hvordan technology inspiration
kan bidrage positivt under designet, og det er en opfyldelse af indie-udvikler princippet
om at udnytte begrænsningerne til sin fordel.
Papegøje-funktionen havde jeg også meget sjov udad, og den fik endda lært min søn at
sige et par nye ord. Mere praktisk viste det sig at, når min søn og kæreste talte i
mikrofonen blev deres ord oftere gentaget korrekt, end når jeg selv gjorde det. Senere
fandt jeg ud af at dette skyldtes frekvensforskellen, og at det faktisk er vist at, når lyden
opdeles i stykker på omkring 20ms fungerer talegenkendelsen bedst til kvinder og børn,
mens stykker på omkring 40ms er bedst til mandlige talere [Furui, 2001, s54]. Det bør
derfor overvejes om spilleren skal indtaste alder og køn inden spillet startes, for at gøre
genkendelsen bedre. Resultatet af papegøje-funktionen var et kendskab til mikrofonen og
dens svagheder (lav volumen og meget støj), og en grundlæggende arkitektur for hvordan
selve genkendelsesdelen skulle opbygges; med papegøje-funktionen blev de ord der
senere skulle genkendes opfanget - de manglede ”bare” at blive genkendt.
25 Beregningsmæssigt ville det dog være en fordel, men jeg fandt det vigtigst at spare på hukommelsen.
98

I prototypen blev der i øvrigt ikke brugt original grafik til repræsentation af Sensei, men i
stedet (lettere modificeret) grafik lånt fra spillet Alien Breed (Team17, 1991) der som
nævnt tidligere har samme kameravinkel. Grafik var ikke vigtigt så længe der kun blev
arbejdet med inputmulighederne. Landskabet bestod i øvrigt af græs, der var taget (og
nedskaleret) fra det spil jeg var med til at udvikle på sidste semester - igen fordi grafikken
ikke var afgørende for legen med spillets inputmuligheder.
I henhold til begreberne fra kapitel 6.1.1 omkring prototyping, kan jeg klassificere
prototypen sådan:
• Breadth: 5%
o Meget lidt af spillets tiltænkte funktionalitet er repræsenteret. Sensei kan
bevæges, mikrofonen reagerer (men ikke som den skal i sidste ende), det
fremgår hvilken kameravinkel spillet vil få og det ses at der vil være et
grafisk interface ved skærmens kanter.
• Depth: 65%
o Blandt de repræsenterede funktioner, er der ingen, som ikke er reelt
implementeret. Kamerahåndtering er dog grov og uden bløde bevægelser,
mikrofonen opfanger ikke altid hele ord og det fremgår ikke hvilke
funktioner, der vil være at finde i det grafiske interface.
• Look: 10%
o Selvom ingen original grafik anvendes, så viser kameravinklen alligevel
lidt om hvordan det færdige spil vil se ud.
• Interaction: 50%
o Prototypen håndterer brugerens input, og giver output på alle de
repræsenterede funktioner. Bevægelsen af Sensei fungerer nogenlunde
som den skal, mens mikrofonen opfanger lyden dog uden at forsøge på at
analysere den. Der er intet output fra det grafiske interface.
Procentangivelserne er anslåede i forhold til
spillets nuværende status - skulle jeg tildele
dem senere ville de formentlig være
anderledes, da nye idéer kommer til hele
tiden. Med spillets meget begrænsede
funktionalitet valgte jeg ikke at lave en
egentlig brugertest. Jeg viste det dog til nogen
som laver hardware som gør Nintendo DSudviklingsarbejdet
lettere 26 , og de fandt det
lovende nok til, at de ville donere et særligt
Nintendo DS-flashkort, der da også siden har
været til nytte.
Figur 19: Den første prototype. Dette er den
nederste skærm - den øverste indeholder
bare debug-informationer.
26 De officielle udviklingsværktøjer fra Nintendo er der ingen mulighed for at anvende, medmindre man har
licens fra Nintendo til at lave Nintendo DS-spil. Ikke-licenseret hardware i form af særlige flashkort er
derfor eneste mulighed for at teste spillet på maskinen.
99

14.2 Nummer 2
Meget tid gik i periodens næste to måneder til arbejdet med den teori der er anvendt i
projektet, mens også semestrets kurser tog noget tid, hvorfor udviklingen af spillets anden
prototype gik langsommere. Målet var at tilføje ninjaeleverne og gøre det muligt for
Sensei at kommandere med dem på forskellig vis, samt at berige landskabet med træer.
Grafisk skulle den lånte grafik også skiftes ud, sådan at spillets tema blev tydeligere.
Under tilføjelsen af ninjaeleverne var en af udfordringerne at få dem til at holde afstand
til både Sensei og hinanden, og især var problemet at få dem til at stoppe op hurtigt nok.
Mange halve løsninger blev forsøgt, indtil jeg opdagede at min fysiksimulation ikke
medregnede friktion, altså gnidningsmodstand, hvad der så blev tilføjet, og flere
problemer løste nærmest sig selv derefter. Tilføjelsen af friktion gav både Sensei og
ninjaelever en mere naturlig bevægelse, og viser at for megen fokus på de spilmæssige
sider kan give bagslag. En teknisk bedre fysiksimulation var en klar forbedring af spillet.
Tilføjelsen af træer gjorde det sjovere at bevæge Sensei omkring i landskabet, og
muliggjorde bedre test af ninjaelevernes evne til at forfølge Sensei. Samtidig gav ludic
engineering teknikken bedre resultater, fordi det nu var muligt at gemme sig for
ninjaeleverne bag træerne, som en form for fange- eller gemmeleg. Dermed blev det
sjovere at teste spillet i længere tid, og yderligere finpudsning af bevægelse og
fysiksimulation var mere motiverende.
En ny funktion der blev tilføjet, var muligheden for at bede ninjaeleverne smide
kastestjerner. Da talegenkenderen endnu ikke var udviklet, placerede jeg funktionen på en
af maskinens knapper. Det gav muligheden for at levere den input der senere skulle
leveres via talekommandoer, og forberedte koden til dette. Selvom min metode byggede
på eXtreme Programming, så kan en smule forudseenhed være fordelagtig. Yderligere
blev den tilstandsmaskine som beskriver ninjaelevernes intelligens og tilstand delvist
implementeret. På den måde blev det muligt at bede ninjaeleverne følge efter Sensei,
samt at afbryde forfølgelsen igen, ligesom andre tilstande også kunne stoppe og startes
efter behov. Det var et betydeligt skridt mod muligheden for at tildele talekommandoerne
en semantisk betydning som ninjaeleverne kan forstå.
Det første rigtigt grafiske arbejde med spillet
forløb uden de store problemer. Den valgte
kameravinkel gjorde det let at lave grafik der
så forholdsvis godt ud, på trods af mine evner
indenfor dette område. Indie-princippet om at
udnytte sine stærke sider og undgå de svage
viser sig nyttig, og princippet om at bruge
gammel teknologi var også særdeles nyttig. På
Internettet findes mange forskellige værktøjer
der kan hjælpe med konverteringen af grafik
til et format som Nintendo DS kan anvende,
og blot det at jeg har valgt 2d-grafik frem for
3d-grafik har også lettet arbejdet en del.
100
Figur 20: Den anden prototype. Igen er der
kun spændende ting på nederste skærm.

Fysiksimulering sås i øvrigt ikke særligt ofte for 10 år siden, hvor de 2d-evner som
Nintendo DS besidder, var imponerende, men i dag anvendes fysiksimulering i stort set
alle 3d-spil. Dermed kan der argumenteres for, at jeg har anvendt gammel teknik på en ny
måde, hvad der jo var et af indie-principperne.
Igen kan prototypen klassificeres, for at afgøre om den er værd at teste
yderligere og for at få en idé om hvor langt i udviklingen spillet er.
• Breadth: 20%
o Mere af den tiltænkte funktionalitet er nu repræsenteret, om end ikke
sådan at spilleren kan se det. Koden giver flere muligheder, end der reelt
er tilgængelige i spillet.
• Depth: 45%
o Denne gang er der mere halvfærdig funktionalitet, hvorfor procenttallet er
mindre. Der er meget funktionalitet i koden, men for spilleren vil
prototypens depth virke lav.
• Look: 35%
o Den lånte grafik er udskiftet med mine egne kreationer, hvorfor spillets
tema og den endelige visuelle stil fremgår tydeligere.
• Interaction: 65%
o Interaktionsmæssigt har den forbedrede fysiksimulation gjort det lettere at
give input, og output virker mere troværdig. Talekommandoer fungerer
stadig ikke, men der er heller ikke blevet arbejdet med dem.
Med en lavere depth end tidligere, blev denne prototype, vurderet uegnet til brugertest.
Mere breadth har dog gjort ludic engineering mere effektfuld, og med tilføjelsen af
ninjaelever og træer som af spilmotoren kan tilføres spilverdenen dynamisk, har flere
blackbox-tests hjulpet med at sikre spillets stabilitet i f.eks. en spilverden med et
maksimalt antal træer. De mere kodenære whitebox-tests er i øvrigt blevet anvendt
igennem alle prototyper, og har løbende givet debug-informationer på maskinens øverste
skærm, hvor oversigtskortet endnu ikke er implementeret. Det er altid nyttigt at kende
f.eks. den nøjagtige hastighed af Sensei, eller at vide hvilket objekt koden mener han
kolliderer med, for at kunne sammenholde det med den faktiske situation i spilverdenen.
14.3 Nummer 3
I den forrige periode havde jeg studeret meget teori om talegenkendelse, så i denne sidste
periode skulle min egen genkender implementeres. Hertil kom designet af spillets
centrale mål og delmål, såsom hvervning af ninjaelever og muligheden for at ride på
pandaer. De nødvendige pragmatiske målinger skulle også implementeres, sådan at spillet
fik en viden om f.eks., hvorvidt Sensei kan se en ninjaelev. Til sidst skulle landskabet
dannes tilfældet, hvilket indtil videre betyder tilfældig placering af træer.
Arbejdet med talegenkenderen blev besværliggjort af mikrofonens kvalitet, og af at kun
udviklere i besiddelse af den officielle hardwaredokumentation ved hvordan lydniveauet
indstilles. Jeg fik den grundlæggende arkitektur på plads, sådan at frames kunne opfanges
101

og laves til (simple) feature-vektorer, der kunne samles til speech-patterns som blev
sammenlignet med hinanden. Succesraten var dog alt for lav til, at systemet kunne have
en praktisk anvendelse, hvorfor jeg i stedet fokuserede på finpudsning af de semantiske
og pragmatiske lag i genkendelsen. Ved at antage at et opfanget ord kan være en hvilken
som helst talekommando, og derefter udelukkende basere genkendelsen på konteksten i
spillet, kunne en semantisk mening, i form af et logisk udtryk eller et funktionskald,
tildeles alle spillerens talte input. Da spillet samtidig er opbygget sådan, at der ikke kan
opstå pragmatisk tvetydighed, er behovet for at de lavere lag i genkenderen fungerer ikke
så stort. I prototypen blev den pragmatiske genkendelse af talekommandoerne NINJA og
MOUNT implementeret, sådan at det er muligt at gå omkring i landskabet og hverve
ninjaelever, for derefter at bede dem bestige en panda.
I mit tidlige design havde jeg forventet at de laveste lag i talegenkendelsen ville have
større betydning, men den egentlige implementering og efterfølgende ludic engineering /
leg med spillet viste, at det semantiske og det pragmatiske lag var klart vigtigst. Faktisk
er jeg nu af den opfattelse, at det i spillet vil være nok med et delvist fungerende
morfologisk lag, som kan opfange unikke ord men ikke genkende dem, er det eneste
nødvendige supplement til den semantiske og pragmatiske genkendelse. Dette er delvist
implementeret (og har været det siden papegøje funktionen i prototype 1), så egentlig vil
jeg mene, at talegenkenderen er tæt på at indeholde al den funktionalitet, der er
nødvendig for genkendelse i den begrænsede kontekst som mit spil udgør. Det vil jeg
selv betegne som en stor bedrift - at jeg har implementeret en funktionsdygtig
talegenkender helt fra bunden. Det er i høj grad technology inspiration og en opfyldelse
af indie-princippet om at udnytte de tekniske svagheder til egen fordel.
Designet af de pragmatiske målinger var
forholdsvist hurtigt klaret, idet de blot
udnytter objekternes eksisterende attributter
for syn og hørelse, samt fysikvektorerne der
indeholder informationer om blandt andet
retning og hastighed. Med dem udregnes
hvornår Sensei kan se en ninjaelev, hvor
meget Sensei larmer og om en ninjaelev kan
høre Sensei, og det er disse informationer der
udgør de indtil videre implementerede
pragmatiske målinger. Den semantiske logik
er nogle funktionskald der returnerer
sandhedsværdier baseret på de pragmatiske
målinger, og som på den måde kan afgøre hvilket funktionskald der skal afvikles.
Synliggørelsen af genkendelse af NINJA blev den førnævnte lysende ring omkring den
valgte elev, og da jeg samtidig udførte den omtalte analyse af dialogen gennem Winograd
& Flores’ conversation for action-model, fik jeg også synliggjort, hvordan en selektion
kun holder fem sekunder.
Det andet arbejde som blev udført i forbindelse med denne prototype var den grafiske
udarbejdelse af en panda (se Figur 21), og den tilfældige placering af træer. Sidstnævnte
102
Figur 21: Prototype 3, ninjaelev med
selektion og en omvandrende panda

lev realiseret ved at lave en funktion der returnerede et tilfældigt punkt i landskabet med
en angivet fri radius omkring sig, hvor træet så kunne placeres. En sidegevinst ved denne
funktion var at den også kunne bruges til at placere ninjaeleverne tilfældigt med,
hvormed et udforskende element allerede her blev tilført spillet. Nu indeholdt spillet den
udfordring det er at finde en flok tilfældigt placerede ninjaelever, hvormed det igen blev
sjovere at teste og finpudse de forskellige funktioner.
Her en klassificering af prototypen:
• Breadth: 40%
o Den tiltænkte funktionalitet er stadig ikke fuldt ud repræsenteret, men med
tilføjelsen af talekommandoer, tilfældig generering af landskab og pandaer
er der alligevel sket meget siden sidst.
• Depth: 65%
o Der er stadig mere funktionalitet i koden end hvad spilleren kan se, men
spillet har med tilføjelsen af talekommandoer en betydeligt højere depth,
da spilleren nu kan tilgå mere af denne funktionalitet.
• Look: 40%
o Med tilfældigt placerede træer opnår landskabet en større troværdighed, og
pandaerne hjælper også på den højere score her.
• Interaction: 75%
o Talekommandoerne har givet spillet en interaktion der ligger meget tæt på
den det endelige spil vil have. Med den lysende cirkel omkring den valgte
ninja, er output-delen af interaktionen også tydeligere.
Spillet har nu en funktionalitet, som jeg vurderede ville være egnet til en mindre test der
involvere andre end mig selv. Jeg viste spillet til andre udviklere via et web-forum, og i
det lokale spiludviklernetværk Dreamgames.dk, hvormed det blev en slags uformel
heuristisk inspektion (testet af eksperter), og fik udelukkende positiv feedback.
Kommentarerne har endnu ikke fået betydning for spillet, da dette er den sidste prototype
jeg beskriver i projekt, men en kommentar er dog værd at gengive: Haha very weird, I
like it ... 27
I al beskedenhed er innovation altså ikke det forkerte ord at bruge om mit spil.
14.4 Opsummering
Med prototype nummer 3 er den del af udviklingen som overlapper med dette projekt
beskrevet. I det store hele har udviklingen forløbet uden nævneværdige problemer, og de
valgte metoder og teknikker har støttet den perfekt. Teorien har ligeledes været givtig, og
især anvendeligheden af Winograd & Flores’ conversation for action-model har
overrasket. Jeg har løst projektets problemstilling, idet et spil der ikke synliggør tekniske
svagheder i den stemmebaserede interaktion er blevet udviklet.
27 http://forum.gbadev.org/viewtopic.php?t=7732
103

104

Del V
KONKLUSION
So, this is it then. The showdown. Today there shall be a conclusion.
Azala, Chrono Trigger
I den teoretiske og den metodiske delkonklusion (kapitel 5 og 9) er projektets
delproblemer allerede blevet besvaret, men efter at have gennemgået designprocessen har
svarene ændret sig. De praktiske erfaringer har bidraget med en bedre forståelse af de
fremlagte problemer, og det er denne forståelse, jeg her vil fremlægge, inden projektets
egentlige problemstilling konkluderes.
Det første delproblem lød som følger:
• Hvad er stemmebaseret interaktion?
o Besvarelsen af dette spørgsmål skal belyse den teoretisk og
praktiske side af stemmebaseret interaktion. Herunder hvordan
sprog og tale kan defineres, samt hvordan det genskabes og
genkendes digitalt i og af en computer.
Den teoretiske besvarelse i kapitel 5 bidragede med den grundlæggende viden der kræves
for at kunne anvende stemmebaseret interaktion i praksis. Det vil sige viden om, hvordan
alle lingvistiske lag digitaliseres, sådan at en computer kan udlede eller afgive mening.
Efter at have fulgt de teoretiske anvisninger igennem hele designprocessen, har det vist
sig at især digitaliseringen af det pragmatiske lag har afgørende betydning for hvor godt
den stemmebaserede interaktion fungerer. Talekommandoer, der fortolkes uden systemets
hensynstagen til konteksten, har ringe chance for succes i forhold til talekommandoer der
tager konteksten i betragtning. Det er dog ikke en generel anvisning, idet mange systemer
ikke vil kunne opnå den nødvendige viden om de pragmatiske forhold, men i forbindelse
med computerspil kan talekommandoerne vælges sådan, at der ikke kan opstå pragmatisk
tvetydighed, hvormed genkendelsen altid vil være præcis og meningsfuld.
Det næste delproblem lød således:
• Hvordan designes et godt computerspil?
o Besvarelsen af dette spørgsmål skal berøre den teoretiske del af
computerspil, samt belyse den mere praktiske eller metodiske
side af sagen. Herunder hvordan et teoretisk grundlag kan danne
105

106
en begrebsmæssig ramme om en analyse af spil, samt hvordan
samme teori kan anvendes praktisk i designprocessen.
Den teoretiske besvarelse i kapitel 5 har leveret det ønskede begrebsapparat som igennem
designet er blevet anvendt til at analysere både det udviklede spil, og de spil som det er
delvist inspireret af. Teorien har altså vist sig praktisk anvendelig. Det er tilmed min
opfattelse, at den teoretiske ramme om designet har været særdeles givtig, idet den flere
gange har påvist svagheder i spillet som ellers først ville være blevet opdaget ved en
ressourcekrævende test. Det eneste, der skal sikres er, at hvert eneste valg er interessant,
integreret, synligt og helst også dynamisk dannet - så vil resultatet være et godt spil. Det
er dog i den metodiske besvarelse i kapitel 9, at jeg fandt det efter min mening bedste
svar på, hvordan et godt computerspil designes. Ludic engineering er en uvurderlig teknik
i forbindelse med udvikling af computerspil, idet selve spillets natur, den meningsfulde
leg, overføres på designprocessen. Det har tilmed vist sig, at den iterative procesmodel
jeg har arbejdet efter, har været et nødvendigt grundlag for praktisk anvendelse af ludic
engineering - uden iterationerne ville der ikke have været plads til legens spontane
ændringsforslag.
Det tredje delproblem lød:
• Hvordan skabes innovation?
o Besvarelsen af dette spørgsmål skal give konkrete anvisninger i
hvordan et innovativt produkt eller en innovativ løsning skabes.
Herunder vil en række forskellige metoder blive berørt, og nogle
få vil blive belyst nøjere samt anvendt i praksis.
I kapitel 8 fremlagde jeg to teknikker, der skulle medføre innovation. Den ene var ludic
engineering, og den anden var technology inspiration. Begge er blevet anvendt i praksis,
og erfaringerne kan nu vise om, de reelt har medført innovation. Som altid er det dog
svært at afgøre, hvornår noget er innovation, og hvornår det er set før. Det er klart, at mit
spil ikke er innovativt på alle områder, idet f.eks. ninja-temaet er brugt mange gange
tidligere. Tilfældig missionsgenerering er også set før, og det samme gælder brugen af
talekommandoer i et holdbaseret spil. Alt dette er resultatet af technology inspiration - en
teknik som skulle medføre innovation, men som nu lader til blot at medføre plagiering.
Sådan mener jeg dog ikke det forholder sig. Disse elementer er i forhold til hele spillet
meget små, og tilsammen er de med til at danne meningsfuld leg på en helt ny måde. Det
er selve kombinationen af eksisterende elementer, der er det innovative, og som gør at
mit spil skiller sig ud. Technology inspiration har i øvrigt også bidraget med tydeligt
innovative indslag, som f.eks. menuer placeret i kanten af skærmen for at spare på
hukommelsen, og hele idéen med kontekstsensitiv talegenkendelse er et resultat af
observerede tekniske begrænsninger. Det vel nok mest innovative i hele spillet, den
kontekstsensitive talegenkendelse, er altså et resultat af technology inspiration. Om idéen
er innovativ i forhold til feltet stemmebaseret interaktion ved jeg ikke, men i forhold til
feltet computerspil er der ingen tvivl om, at jeg har skabt noget innovativt, hvormed
semestrets mål om at anvende stemmebaseret interaktion på en ny måde opfyldt. Den
feedback jeg har fået på spillet via web-fora og spiludviklernetværk peger på samme.

Det sidste delproblem kan også løses:
• Hvordan udvikles computerspil af én person alene?
o Besvarelsen af dette spørgsmål skal give konkrete anvisninger i
håndtering af en udviklingsproces med kun én person involveret,
samt i hvordan de deraf begrænsede ressourcer udnyttes sådan at
spillet ikke lider kvalitetsmæssigt.
I kapitel 9 blev dette spørgsmål besvaret med henvisning til de metodiske indieprincipper
som blev fremlagt i afsnit 7.1. Flere af disse har vist sig nyttige under
designprocessen, om end det er svært at vurderer i hvor høj grad, da spillet ikke er
færdigudviklet, hvorfor det samlede ressourceforbrug er ukendt. Det mest brugte princip
har været det om at bruge gammel teknologi på en ny måde, hvad der efter min opfattelse
har været givtigt for både spillet og udviklingen. Det har gjort udviklingen mindre
ressourcekrævende fordi der enten fandtes eksisterende værktøjer (f.eks. til konvertering
af 2d-grafik), eller fordi det som skulle programmeres var simpelt i forhold til de mere
moderne paralleller (talegenkendelse). At bruge gammel teknologi på en ny måde har
tilmed gjort spillet bedre (i kraft af at originalitet jo er en kvalitetsfaktor), hvor f.eks.
fysik-simuleret 2d-grafik er sjældent set. Den gammeldags talegenkendelsesteknik har
også nødvendiggjort den pragmatiske tilgang, hvad der igen viser, at gammel teknik kan
bruges på nye måder og tilmed øge spillets kvalitet, alene fordi det er originalt. Det
bedste svar de praktiske erfaringer kan give på problemet er dog, at et spil kun kan
udvikles af én person alene, hvis denne arbejder hårdt med innovation for øje.
Med de fire delproblemer løst, er der nu kun tilbage at besvare problemstillingen:
• Hvordan designes et computerspil der har stemmebaseret interaktion
som en primær interaktionsform, sådan at dette samtidig udgør den
optimale interaktionsform uden at synliggøre de tekniske svagheder?
Det vigtigste skridt mod dette mål er at sikre, at spillet kan udlede en utvetydig
pragmatisk mening af enhver speech act eller handling udført af spilleren. Jeg kalder
dette kontekstsensitiv talegenkendelse. For at sikre at der også er tale om den optimale
interaktionsform, må det sikres, at den øger spillets mulighedsrum, altså de valg som er
tilgængelige for spilleren, mens den samtidig gør interaktionen mere naturlig. I dette
projekts spil kommunikeres der verbalt med alle andre end hovedpersonen selv, hvad der
virker naturligt i konteksten, ligesom mulighedsrummet forøges ved at der ikke er andre
måder at give de samme input på. I andre spil kan der være andre måder at gøre det på -
der er ingen generelt anvendelig måde at indføre stemmebaseret interaktion på - jeg har i
det mindste ikke fundet den. Disse to retningslinjer er det bedste svar der kan gives:
usynliggørelse af tekniske svagheder kan sikres gennem pragmatisk utvetydighed, mens
optimal interaktion opstår når interaktionen er naturlig og forøger mulighedsrummet.
Dermed er projektet konkluderet. I det næste og sidste (det lover jeg!) kapitel vil jeg kort
diskutere projektet og dets forskellige bidrag i et lidt bredere perspektiv.
107

15 Perspektiverende diskussion
Med projektet afsluttet er det interessant at se på hvad det kan bidrage med, udover en
forhåbentlig fremragende bedømmelse til eksamen ☺
Der er i projektet er blevet arbejdet med teori fra flere forskellige forskningsområder, og i
kraft af at teorien ikke blot er blevet sat i anvendelse, men også videreudviklet, har
projektet et reelt teoretisk bidrag. Det forskningsområde der bidrages til er primært de
teoretiske studier af computerspil, i det sprogvidenskaben er blevet brugt til at forklare
visse spilteoretisk fænomener eller begreber. I den forbindelse vil jeg trække to af mine
nok mest interessante observationer frem. For det første blev det oplevelsesorienterede
eller eksperientelle syn på et computerspil sammenholdt med semantikken. To begreber
der har forståelsen eller udledningen af mening som deres centrale mål. Semantikken er
det ældste og stærkest belyste begreb og kan levere en masse viden, der direkte kan
bruges, når konteksten er computerspil i stedet for sprog. I kraft af semestrets mål og min
problemstilling har en tilbundsgående undersøgelse af dette ikke været nødvendig, men
jeg mener der ligger et stort potentiale i at uddybe sammenhængen mellem semantik og
computerspil.
Det andet interessante bidrag som mit projekt har til spilteorien, er brugen af Winograd &
Flores’ conversation for action-model til at analysere dialogen i et computerspil. Ikke nok
med at det kan lade sig gøre, hvad der vel næppe er en overraskelse, så har analysen den
praktiske sideeffekt at den synliggør dialogens problemer uden at en egentlig test er
nødvendig. I forbindelse med implementering af kontekstsensitiv talegenkendelse, er det
naturligvis også praktisk at få belyst hvilken pragmatisk viden spillet skal have, hvad der
jo også var årsagen til, at jeg anvendte modellen.
Teorien har naturligvis ikke været uproblematisk at anvende, men jeg mener, at det eneste
egentlige problem jeg har, er den begrebsforvirring der kan opstå hos læseren, når der i
forbindelse med computerspil tales om stemmebaseret interaktion, fordi dette område
bruger de samme begreber (pragmatisk mening i en lingvistisk struktur kontra pragmatisk
syn på systemet der skal forstå eller danne strukturen). Jeg håber ikke problemet er alt for
stort i projektrapporten, og ved opmærksom læsning skulle det fremgå klart, hvad der
menes hvor.
Metodisk har projektet ikke et ligeså originalt bidrag til udviklingen af computerspil, idet
eksisterende metoder og teknikker blot er anvendt. Teknikkerne ludic engineering og
technology inspiration, er groft sagt blot en akademisk navngivning af det som
udviklerne længe har gjort. Den succesfulde anvendelse af dem viser dog, at udviklerne
eksempelvis ikke må glemme at lege med spillet hele vejen igennem udviklingen, hvad
der godt kan være en tendens til i mange nyere spil. Computerspil er blevet en industri
hvor effektivitet ofte sættes højere end kvalitet, hvorfor spillets grundlæggende mål, den
meningsfulde leg, tilsidesættes. Med ludic engineering sker dette ikke, men anvendelsen
af den vil dog nok ikke øge udviklingstempoet - ”kun” kvaliteten af det færdige produkt.
108

Generelt til computerspilsmediet bidrager mit spil med en helt ny interaktionsform,
nemlig kontekstsensitiv talegenkendelse. Implementeres den rigtigt, og sikres det at der
aldrig opstår pragmatisk tvetydighed, så har den potentialet til at revolutionere brugen af
stemmebaseret interaktion i computerspil. Aldrig mere vil spilleren frustreres over dårlig
genkendelse af talekommandoer. Hver opfanget talekommando tildeles alle tilgængelige
semantiske betydninger, men grundet den pragmatiske analyse vil kun én af dem vise sig
korrekt og blive udført. Det er både simpelt for udvikleren at implementere (i forhold til
at skulle udvikle talegenkendelse på alle lingvistiske lag), og for spilleren at anvende. Der
er ikke noget forudbestemt ordforråd der skal anvendes, så spilleren kan sige hvad han
mener giver meningen i situationen. Jeg har valgt at forsøge at uddanne spilleren til at
bruge en bestemt grammatik, men reelt er det ikke nødvendigt. Fordelen, og grunden til at
jeg har valgt at bruge en grammatik, er at synligheden øges - jeg fandt det vigtigt at
fortælle spilleren om sine muligheder, og det virkede bedst, hvis spillet bad spilleren om
et bestemt ord, frem for at bede spilleren sige noget tilfældigt.
Afslutningsvis kan projektet dermed siges at være innovativt på to plan: det teoretiske
fordi sprogvidenskaben inddrages i computerspilsteorien, og det produktmæssige fordi en
helt ny interaktionsform, kaldet kontekstsensitiv talegenkendelse, er opfundet og afprøvet
på et computerspil. Dermed mener jeg ikke, der kan være tvivl om, at jeg opfylder
semestrets krav om innovation.
Slutteligt vil jeg blot nævne at det har været spændende at få lov at arbejde med
innovation. Det har været et stort pres, at der absolut skulle udvikles noget innovativt på
få måneder, men at det alligevel er lykkedes, er jeg bestemt stolt af. Jeg håber det har
været en fornøjelse at læse projektrapporten, men skal jeg være realistisk så har den nok,
visse steder, været lidt tung og kedelig - den slags er svært at undgå, når et så stort
teoretisk grundlag tages i anvendelse.
Tak for din tid ☺
109

16 Litteraturliste
Posterne i litteraturlisten er sorteret alfabetisk efter henvisning (forfatter, år), og ved
flere poster med samme henvisning også kronologisk. Følgende formatering anvendes:
Henvisning
Titel, Forfatter(e)
Udgiver, År
Evt. Internetadresse
16.1 Bøger
Aronoff & Miller, 2001
The Handbook of Linguistics, Mark Aronoff & Janie Rees-Miller
Blackwell, 2001
Austin, 1962
How to Do Things with Words, J. L. Austin
Harvard University Press, 1962
Beck, 1999
Extreme Programming Explained: Embrace Change, Kent Beck
Addison-Wesley, 1999
Bethke, 2003
Game Development and Production, Eric Bethke
Wordware Publishing, 2003
Bourg & Seemann, 2004
AI for Game Developers, David M. Bourg & Glenn Seemann
O’ Reilly, 2004
Buckland, 2005
Programming Game AI by Example, Mat Buckland
Wordware Publishing, 2005
Crawford, 2003
On Game Design, Chris Crawford
Prentice Hall, 2003
Crystal, 1985
Linguistics, David Crystal
Penguin, 1985 (second edition)
110

Fowler, 2004
UML Distilled 3 rd Edition, Martin Fowler
Addison-Wesley, 2004
Furui, 2001
Digital Speech Processing, Synthesis, and Recognition, Sadaoki Furui
Marcel Dekker, 2001
Huizinga, 1949
Homo Ludens, Johan Huizinga
Elektronisk udgave hos Ebrary, 2004
Littlejohn, 1999
Theories of human communication, Stephen W. Littlejohn
Wadsworth, 1999
Jurafsky & Martin, 2000
Speech and Language Processing, Daniel Jurafsky & James H. Martin
Prentice Hall, 2000
McTear, 2004
Spoken Dialogue Technology, Michael F. McTear
Springer, 2004
Michael, 2004
The Indie Game Development Survival Guide, David Michael
Elektronisk udgave hos Ebrary, 2004
Norman, 1990
Design of Everyday Things, Donald Norman
Doubleday, 1990
Pressman, 2000
Software Engineering: a practitioner's approach, Roger S. Pressman
McGraw-Hill, 2000
Rabiner & Juang, 1993
Fundamentals of Speech Recognition, Lawrence Rabiner & Biing-Hwang Juang
Prentice Hall, 1993
Rollings & Morris, 2003
Game Architecture and Design, Andrew Rollings & Dave Morris
New Riders, 2003
111

Rouse, 2005
Game Design: Theory and Practice, Richard Rouse III
Wordware, 2005
Saeed, 2003
Semantics
Blackwell, 2004
Salen & Zimmerman, 2004
Rules of Play: game design fundamentals, Katie Salen & Eric Zimmerman
MIT Press, 2004
Searle, 1969
Speech Acts, John R. Searle
Cambridge University Press, 1969
Snyder, 2003
Paperprototyping, Carolyn Snyder
Morgan Kaufmann, 2003
Winograd & Flores, 1986
Understanding Computers and Cognition, Terry Winograd & Fernando Flores
Ablex Publishing, 1986
16.2 Artikler og opslagsværker
Adams, 2001
Dogma 2001: A Challenge to Game Designers, Ernest Adams
Gamasutra, 2001
http://www.gamasutra.com/features/20010129/adams_01.htm
Adams, 2002
Technology Inspires Creativity: Indie Game Jam Inverts Dogma 2001! , Ernest Adams
Gamasutra, 2002
http://www.gamasutra.com/features/20020531/adams_01.htm
BusinessWeek, 14-10-2005
Microsoft Seeds the Indie-Game Ecosystem
BusinessWeek, 2005
http://www.businessweek.com/innovate/content/oct2005/id20051014_827471.htm
Costikyan, 2005
Death to the Games Industry: Long Live Games, Greg Costikyan
The Escapist, #8
http://www.escapistmagazine.com/issue/8
112

Dictionary.com, Design
http://dictionary.reference.com/search?q=design
Dictionary.com, Innovation
http://dictionary.reference.com/search?q=innovation
Dictionary.com, Creativity
http://dictionary.reference.com/search?q=creativity
Dictionary.com, Invention
http://dictionary.reference.com/search?q=invention
eWeek.com, 11-11-2005
Microsoft Lauds 'Scrum' Method for Software Projects
eWeek.com, 2005
http://www.eweek.com/article2/0,1895,1885883,00.asp
GameDaily Biz, 03-12-2004
EA Feeling Pressure, May Reclassify Overtime
http://biz.gamedaily.com/features.asp?article_id=8464
Gamerankings, Darwinia
Gennemsnitlig anmelderkarakter for Darwinia (kun engelske anmeldelser)
http://www.gamerankings.com/htmlpages2/925872.asp
Gamerankings, Alien Hominid
Gennemsnitlig anmelderkarakter for Alien Hominid (kun engelske anmeldelser)
http://www.gamerankings.com/htmlpages2/922130.asp
Lloyd, 2004
Book Review: The Indie Game Development Survival Guide
Gamasutra, 2004
http://www.gamasutra.com/columns/books/20040413/index.shtml
Longman
Longman Dictionary of Contemporary English, brugt til fonetisk transskription
http://www.ldoceonline.com
Ludologica, 31-08-2005
Lars Konzacks er spilforsker ved AAU, Ludologica er hans webside
http://konzack.blogspot.com/
Marcus Larsen, 2005
Hvordan traditionelle systemudviklingsmodeller dræber kreativiteten i spilbranchen,
Jimmy Marcus Larsen i forbindelse med kurset i systemudviklingsfilosofi på INF2, 2005
http://chrono.moogle.dk/originalitet.php
Merriam-Webster, Innovation
http://www.m-w.com/dictionary/innovation
113

Merriam-Webster, Creativity
http://www.m-w.com/dictionary/creativity
Merriam-Webster, Invention
http://www.m-w.com/dictionary/invention
Ordbogen.com, Design
http://www.ordbogen.com/opslag.php?word=design&dict=auto
Popular Science, 11-2005
The 11-Year Quest to Create Disappearing Colored Bubbles
Time Warner, 2005
http://www.popsci.com/popsci/science/0a03b5108e097010vgnvcm1000004eecbccdrcrd.html
Rogers et al., 2002
Things aren’t what they seem to be: innovation through technology inspiration, Rogers,
Y., Scaife, M., Harris, E., Phelps, T., Price, S., Smith, H., Muller, H., Randell, C., Moss,
A., Taylor, I., Stanton, D., O'Malley, C., Corke, G. and Gabrielli, S.
In proceedings DIS2002, ACM Press
Sheffield, 2005
Interview: Going Handheld, Living Vicariously, Brandon Sheffield
Gamasutra, 2005
http://www.gamasutra.com/features/20050107/sheffield_01.shtml
Skog, 2005
Syndicate: En klassiker fødes, Oskar Skog
Egmont, 2005
SuperPLAY #004, januar 2005
Spector, 2003
GDC 2003 Video: Warren Spector's "Sequels and Adaptations: Design Innovation in a
Risk-Averse World", Warren Spector
Gamasutra, 2003
http://www.gamasutra.com/features/20030416/spector_01.shtml
Sylvester, 2005
Decision-based Gameplay Design, Tynan Sylvester
Gamasutra, 2005
http://www.gamasutra.com/features/20050321/sylvester_pfv.htm
Wikipedia, Creativity
http://en.wikipedia.org/wiki/Creativity
Wikipedia, Edisonian approach
http://en.wikipedia.org/wiki/Edisonian_approach
114

Wikipedia, Innovation
http://en.wikipedia.org/wiki/Innovation
Wikipedia, Invention
http://en.wikipedia.org/wiki/Invention
Wikipedia, Ninja
http://en.wikipedia.org/wiki/Ninja
Wikipedia, Klingon language
http://en.wikipedia.org/wiki/Klingon_language
Wikipedia, Knapsack problem
http://en.wikipedia.org/wiki/Knapsack_problem
Wikipedia, Traveling salesman
http://en.wikipedia.org/wiki/Traveling_salesman
115

17 Softwareliste
Posterne i litteraturlisten er sorteret alfabetisk efter henvisning (udvikler, år), og ved
flere poster med samme henvisning også kronologisk. Følgende formatering anvendes:
Henvisning
Titel
URL på Internetside med mere information
17.1 Spil
Blizzard, 2005
World of Warcraft
http://www.worldofwarcraft.com
Bullfrog, 1993
Syndicate
http://www.mobygames.com/game/dos/syndicate
Capcom, 2005
Killer7
http://www.killer7.com/
Digital Eel, 2002
Strange Adventures in Infinite Space
http://www.digital-eel.com/sais/
Digital Eel, 2005
Weird Worlds
http://www.shrapnelgames.com/digital_eel/Weird_worlds/1.htm
Introversion, 2005
Darwinia
http://www.darwinia.co.uk/
Microvision, 1980
Rip-Off
http://www.klov.com/R/Rip_Off.html
Nintendo, 2004
Mario Party 6
http://marioparty6.com/launch/
Nintendo, 2005
Nintendogs
http://www.nintendogs.com/
116

Remedy Entertainment, 2001
Max Payne
http://www.remedygames.com/games/max_payne.html
Sega, 1999
Seaman
http://www.mobygames.com/game/dreamcast/seaman
Sega, 2001
Rez
http://www.mobygames.com/game/dreamcast/rez
Sony, 2002
Dark Chronicle
http://www.mobygames.com/game/ps2/dark-cloud-2
Sony, 2004
Singstar
http://www.singstargame.com/
Sony, 2004
SOCOM II, US Navy SEALs
http://socom2.playstation.com/
Team17, 1991
Alien Breed
http://www.mobygames.com/game/amiga/alien-breed
The Behemoth, 2004
Alien Hominid
http://www.alienhominid.com/
Ubisoft, 2005
Rainbow Six 3
http://www.rainbowsix3.com
17.2 Værktøjer
Devkitpro, 2005
Devkitpro, Nintendo DS kompileringsværktøj
http://www.devkitpro.org
117

18 Bilag A – International Phonetic Alphabet
Det internationale fonetiske alfabet fra dets officielle hjemmeside 28 :
28 http://www2.arts.gla.ac.uk/IPA/ipa.html
118