Rapport over tilblivelsen af spillet: Hitmen: Black Gold

Transkript

1 Rapport over tilblivelsen af spillet: Hitmen: Black Gold Jesper Lysgaard Rasmussen, , IT1 Jonas Degn Grann, , IT1 Tobias Fjelsted Alrøe, , IT1 July 23, 2010

2 Contents 1 Hitmen - Black Gold Designidé og produkt Designidé Produkt En kort beskrivelse af produktets narrativ Scenariet Brugerens opgave Inltrering af et andet agentur Opbyggelse af eget agentur Overblik over historien Anslaget: Præsentation: Uddybning: Point of no return: Koniktoptrapning: Store Klimaks: Udtoning: Textual Architecture Remediation og 4 typer af interaktivitet Beskrivelse af systemet Koordinering spillere imellem Interaktion i konkrete fysiske områder Antal spillere Målgruppen Deployment af systemet Opsætning af systemet i en ny by Spillets varighed Hovedarkitekturen af systemet Oversigt over Client/Server XML-kommunikation De forskellige knuder Håndtering af lokation At bruge et oine kort At hente kort fra en korttjeneste fra Google Valg af teknologi Beregninger zoom level Afstanden mellem to lokationer Hentning af kort Visning af positioner Interaktionsteknikker Accelerometer:

3 1.9.2 Kompas: Bevægelse i verdenen: Keysinput på mobilen: Beskrivelse af prototypen Videoprototypen Optagelse og redigering af videoprototypen Softwareimplementation Prototypeafprøvningen Prototypeafprøvningen i forhold til produktets interaktive narrativ Prototypeafprøvningen i forhold til pervasive computing arkitektur Opdatering af GPS lokation Skud: Accelerometerinput: Rumble feedback Grask feedback på interaktionsmuligheder Konklusion A Appendix 19 A.1 Client/server kommunikation A.2 Håndtering af lokation

4 Chapter 1 Hitmen - Black Gold 1.1 Designidé og produkt Designidé Vores idé tager udgangspunkt i tre agenturer, der hver har agenter, som skal bekæmpe hinanden. Ideen er, at agenterne skal på forskellige missioner, der bliver udstedt af agenturets hemmelige leder, som fungerer som en funktionel karakter [UVG, kap. 8] for agenturet. På hver mission vil der dog blive nogle forhindringer for brugeren. Hvis brugeren er den eneste online, vil denne forhindring sættes ved en tidsgrænse, men mere interessant bliver det, hvis der er ere online fra andre agenturer. Får brugeren fx en mission, der indebærer at transportere en pakke, vil en agent fra et andet agentur (agentur2) blive sat til at dræbe spilleren (sec ). Hvis en bruger bliver dræbt af en agent fra agentur2, mister han/hun vigtige oplysninger omkring sit eget agentur, og efter nok fejlslagne missioner, vil agentur2 have nok oplysninger til at nde placeringen for agentur1. Hovedforløbet kan beskrives med følgende plotgraf: Figure 1.1: Plotgraf over historiens hovedforløbet Når man opretter sig som spiller (helt til venstre), får man automatisk tildelt et agentur. Herefter bliver man sendt på forskellige missioner, som agenturlederen kontrollerer. For hver mission har man en mulighed for at der er blevet indsamlet nok oplysninger om et andet agentur, til at afsløre deres placering i byen. Når denne placering er fundet, vil alle agenter fra det pågældende agentur, blive sendt imod denne placering. Hvis det lykkes at overtage dette agentur, vil det forsvinde, og kun to agenturer vil være tilbage. Forløbet vil her gentage sig, indtil der kun er 3

5 vinderen tilbage. Når spillet starter vil hovedhistorien blive "nulstillet". Dette betyder, at den grundlæggende historie(sec ) vil være den gældende. For hver mission der efterfølgende udføres i spillet, vil brugerne således være med til at skrive på denne historie med sine handlinger. Vi ønsker, at en hjemmeside skal samle trådene omkring hele historien, hvormed historien og tilstanden i den ktive verden hele tiden opdateres. Samtidig vil det også være her, man kan oprette en ny bruger, ved først at kvalicere sig som agent. Dette gøres ved nogle små tests, som tester fx. reaktionstid 1, hurtighed 2, og den logiske tankegang. Når man har kvaliceret sig, skal man efter nogen tid få besked om, at man er blevet optaget i et agentur, og kan derefter starte applikationen på sin mobiltelefon, logge ind, og derefter afvente dens første mission Produkt Vi har igennem projektet implementeret en prototype, der demonstrerer hovedidéerne, som beskrevet ovenfor. Grundet tidspres, har vi valgt, at udelade elementer vi ikke anså for vigtige for at beskrive hovedidéen. For læringens skyld har vi lavet hele systemet i Python, der for os alle var et helt nyt programmeringssprog. Vi har programmeret en mobilklient, der har alle de basale funktionaliteter som login, skud-, opsamlings- og aeveringsgestikker mm. Samtidig har den et grask interface, der underbygger disse funktionaliteter. Klienten kan også modtage nye "target"-punkter fra serveren, og vil opdatere disse på et kort sammen med spillerens nuværende position. Fra vores nuværende klient til den endelige, vil der derfor blot mangle en personlig side, der kan vise din nuværende status, mulighed for at vælge andre våben, samt en grask overhaling. Resten af det endelige spil ville skulle implementeres på serveren/hjemmesiden. På serveren har vi implementeret muligheden for at logge ind vha. en statisk "database" 3 for at lette arbejdet. Der er på serveren også lavet en missionskontroller, hvor vi har implementeret en enkelt mission - nemlig "Collector"- missionen 4, hvilket er den mission, der demonstreres i videoprototyperne. Den grundlæggende funktionalitet på serveren er dog forberedt til udbyggelse, da vi igennem en objektorienteret tilgang har gjort det nemt at tilføje ere missioner, en rigtig database osv. Vi har valgt ikke at fokusere på funktionaliteter som oprettelse af bruger, og forløbet af hovedhistorien, pga. mangel på tid. Vi har derfor ikke lavet hjemmesiden, hvor brugeroprettelse samt overblik over verdenssituationen skulle foregå. 1.2 En kort beskrivelse af produktets narrativ Scenariet Vores plot udspiller sig i året 2040, hvor olien næsten er sluppet helt op. Problemet er opstået pludselig, da de resterende OPEC 5 lande har valgt, at lukke for deres rørledninger, eftersom de hver især ikke kan undvære resterne. Derfor er verdens landes infrastruktur pludselig på bristepunktet, og hårdt plaget af korruption, grundet ulovlig handel med olie og alternative energikilder 6. For nyligt opdagede ODO (Oil Discovery Organisation), den sidste store organisation, der stadig har aktive olielagre verden over, dog er en ny forekomst af olie umiddelbart under byen Århus (her anvendes byen, spillet foregår i). Forekomsten vurderes til at have en størrelse, der ville sikre verden den nødvendige olie 5 år frem. Toppen i ODO er dog blevet splittet grundet interne stridigheder omkring oliens anvendelse, og fordelingen af den magt, som denne nye opdagelse utvivlsomt vil medføre. De tre øverste ledere i organisationen ved alle, at "med penge kan man få", og opretter derfor i al hemmelighed hver sit agentur i Århus, med det ene formål at overtage byen, og hurtigst muligt starte boringerne... 1 Hvor hurtig brugeren reagerer på fx. nye objekter på skærmen 2 Hvor hurtigt brugeren fx. kan trykke på en bestemt tast 20 gange 3 Blot information i en ikke redigerbar l 4 En mission hvor en bruger skal opsamle fx en pakke ved et punkt A, og aevere den ved et punkt B 5 Organization of the Petroleum Exporting Countries 6 Som fx uran 4

6 1.2.2 Brugerens opgave Brugeren er en agent, ansat i et af de tre agenturer, hvis formål er denitivt at få de andre agenturer ud af byen. Brugeren skal igennem en række missioner formå at inltrere de andre agenturer, dræbe andre agenter, samt styre ens eget agenturs plads i byen.( ) Hver gang brugeren er på en mission, er han/hun i højrisiko for at blive opdaget af fjendtlige agenter, som ønsker at forpurre brugerens mission, ved at dræbe brugeren. Når brugeren starter som agent vil hans/hendes omdømme og tillid fra sit agentur være nul, men jo ere agenter fra de andre agenturer, brugeren slår ihjel, og jo ere missioner der klares, jo mere vil brugeren betydning vil brugeren have indenfor sit agentur. Samtidig vil brugerens erfaringsniveau stige, og med stigende erfaring vil man have mulighed for at benytte stadig mere avancerede våben og teknikker. Skulle det ske, at man bliver skudt, eller fejler en mission, er man ikke ude af spillet, men ens omdømme vil dog falde drastisk. Det samme vil gælde sværhedsgraden på de missioner, som brugeren får, der grundet lavere tillid fra agenturet, vil falde Inltrering af et andet agentur Brugerens omdømme indikerer, hvor meget tillid lederen i agenturet har til vedkommende. Jo højere omdømme, jo mere information er han derfor villig til at betro den pågældende bruger. For at inltrere et andet agentur, skal brugeren bruge en række informationer, der til sidst vil indkredse det andet hovedkvarters position, og give mulighed for en overtagelse/inltrering. Denne information opnås ved at slå andre agenter ihjel, hvilket også øger spillerens omdømme. Når en agent bliver slået ihjel, ved lederen i agenturet det straks, og vil derfor sende en agent ud for at rydde op. Dermed vil en agent, der lige har slået ihjel, straks blive den jagede, og har derved mulighed for at miste de oplysninger, han lige har opsamlet, samt sine egne oplysninger. Når en agent bliver myrdet, opdages det hurtigt af oentligheden, og det agentur, der ikke var involveret i mordet, vil typisk opdage et sådant mord indenfor kort tid, og sende en agent, da der både vil være mulighed for at få informationen fra agenten, der har slået ihjel, men også informationer fra den døde agent. En sådan mission vil kunne fortsætte til en agent når tilbage til sit eget agenturs "drop-point" (punktet hvor informationen skal aeveres), hvilket ikke ville være på agenturets lokation (da de andre ellers blot vill kunne følge efter ham, og derved overtage hans agentur). En anden mulighed for at lokalisere et agentur kan være igennem en avancering af agenturets teknologi. En agent kan derved få til opgave at hente dele til et avanceret GPS-agtigt system, der ville kunne lokalisere de andre agenturer. Hvis en agent fejler en sådan mission, vil dette stykke teknologi selvfølgelig kunne falde i de andre agentures hænder, og de vil derved være et skridt nærmere målet Opbyggelse af eget agentur En ting er at inltrere et andet agentur, men lige så vigtigt er det at beskytte sit eget. I starten af spillet vil mange af en agents missioner være at hjælpe med dette. Det vil typisk være at hente nye våben, ammunition eller andre vigtige dokumenter i byen og bringe til et aeveringssted. Under en sådan mission, vil andre agenturer selvfølgelig sende agenter (typisk kun en) efter transportøren. Mange ting som agenten henter er også vigtige at have til tiden (som fx dokumenter, ammunition til en mission ol.), og en sådan mission vil derfor være tidsbestemt, hvilket vil give mere udfordring. Som beskrevet tidligere, vil det også blive muligt at opdage andre agenturer vha. forskellige tekniske løsninger. Der vil selvfølgelig også være mulighed for at lægge den mere defensive stil, og udvikle det agentur som man tilhører, med defensive teknologier. Disse beslutninger vil typisk ikke være op til agenten 7, men agenturet der hver især har nogle forskellige karakteristika at handle ud fra Overblik over historien Historien kan beskrives udfra følgende berettermodel: 7 Ved at acceptere/afvise en type missioner fra aggenturet 5

7 Figure 1.2: Berettermodel Anslaget: Først gang man starter applikationen, modtager man en beskrivelse af verdensituationen, som beskrevet i afsnittet om scenariet(sec ) Præsentation: Man præsenteres for de tre agenturer, der har et magtopgør i gang, samt en mere dybdegående præsentation af ens eget agentur. Dette foregår ligeledes på mobilen ved første start af applikationen Uddybning: Det er her man får hjælp til spillet, en meget kort optræning. Dette nder sted efter første gang man logger ind, og det er her spillet så småt går i gang. Efter spillet er startet, vil det også være muligt at læse hvilke informationer ens eget agentur har opsamlet om de andre Point of no return: Efter man er blevet valgt af et agentur, og har sagt ja til sin første mission, er der ingen vej tilbage. Nu kæmper man for sit agentur, indtil døden! Koniktoptrapning: Man udfører forskellige missioner for sit agentur, og i takt med at ens omdømme stiger, stiger presset, og sværhedsgraden af de opgaver man udfører. I koniktoptrapningen kommer et mindre klimaks hvor det ene agentur bliver slået - herefter er det de sidste to agenturer der bekriger hinanden. Der vil således komme en periode med kun to agenturer, men ved udslettelse af det første, vil det agentur der gør det, automatisk overtage alle oplysninger, det udslettede agentur ligger inde med, om det sidste agentur Store Klimaks: Det store klimaks er ved den sidste store kamp mellem de to tilbageværende agenturer. Dette klimaks minder om det lille klimaks, bortset fra at det her er den endelige sejr og magten der kæmpes om, og ikke blot inltrering af et andet agentur. 6

8 Udtoning: Eksisterer i kraft af en afslutningshistorie, der beskriver hvad konikten mellem agenturene, har betydet for den historie og verden som brugeren blev præsenteret for til at starte med. Derudover beskrives, hvordan det vindende agentur påvirker verdens skæbne. Denne afslutning sendes til alle deltagende spillere. Sammen med en af de færdigskrevne sluthistorier (3 forskellige), vil der også være en liste over begivenheder, der vil vise brugernes vigtigste missioner og de udslagsgivne kampe beskrevet kort. 1.3 Textual Architecture 8 Plottet er som sagt bygget op om tre agenturers kamp imod hinanden. Hvert af de tre agenturer kan vinde i historien, hvilket betyder, at narrativet har tre forskellige slutninger. Denne struktur på den overordnede handling kan vises med en meget simpelt plotgraf[avatars of story, kap. 5](Fig.1.3), hvor den første prik er selve fortællingens introduktion og de tre prikker er tre mulige slutninger på handlingen. Vi har valgt at bruge agenturer for at kunne lave historien brugerpåvirket, men uden at hver brugers historie skal være individuel. Dette gør det overskueligt at lave et narrativ med ere mulige slutninger. Vi diskuterede, om det var bedst med to eller tre agenturer, men kom hurtigt frem til, at tre var det optimale, da det vil tilføje noget mere dynamik til historien og til gameplayet. Det ville hurtigt blive trivielt, hvis det bare var frem og tilbage kamp mellem to agenturer, imens tre agenturer giver muligheden for at en tredje part pludselig træder i aktion og blander sig i en kamp mellem de to andre. Figure 1.3: Struktur over main-story Hvis man ser på historiens forløb fra et enkelt agenturs synspunkt, A1, vil historiediagrammet se ud som på gur1.4. Her ses det, at agenturet starter, når den første spiller tilmelder sig agenturet, og dernæst ses en stor maze. Denne maze illustrerer de mange missioner, der oprettes af systemet og udføres af spillerne, og både dem, der påvirker henholdsvis det ene og det andet agentur. Derefter er der to hovedevents, hvor det ene agentur taber og dermed ikke længere påvirker handlingen. For at nå disse punkter, skal man igennem forskellige guards, der sikrer, at man får skaet en hvis mængde information inden et specikt agentur kan udslettes. Når det ene agentur er blevet udslettet, fortsættes forløbet i mazen med en masse missioner, og når så det andet agentur også udslettes, vil man nå det sidste punkt, som er den endelige sejr. I hele forløbet vil man kunne nå et punkt, hvor agenturet selv bliver udslettet og taber. 8 Ryan kap. 5 7

9 Figure 1.4: Struktur over agenturhistorien Det sidste perspektiv, hvor ud fra man kan se på historien, er brugerens(fig.1.5). Første punkt er, at man installerer applikationen på sin mobil, opretter sin prol og dernæst tildeles man et agentur. Lige meget hvilket agentur man vælger (de tre punkter), er næste punkt en stor maze af missioner, ligesom ved diagrammet fra før. Hver mission kan vindes og tabes og derigennem påvirkes udfaldet af historien. Ved enhver mission kan udfaldet føre til enten et endepunkt hvor agenturet, som spilleren tilhører, vinder, eller et endepunkt hvor agenturet taber. Ved enhver mission kan spilleren ryge tilbage til start, hvis spilleren har tabt for mange missioner for agenturet, idet agenturet derved ikke kan betro ere missioner til spilleren. Figure 1.5: Plotgraf der illustrere brugerhistorien For at give et overblik over hvordan en mission kunne foregå, samt hvilke input og output der bruges ved hvert interaktionspunkt, har vi lavet et storyboard med interaktionsnoder[mud]. 8

10 Figure 1.6: Kort der viser hvor forskellige interaktionsformer benyttes. Missionen starter ved det røde punkt 1, hvor transporteren får sin mission brieng. Her er output lyd og tekst, hvor missionen bliver læst op af en person fra agenturet, imens man kan se teksten på mobilskærmen. Her bruges tastetryk på mobilen til at modtage, eller afvise opkaldet, og efter briengen til at acceptere eller afvise missionen. Efter at have accepteret missionen, får rød spiller et kort med et punkt, der indikerer, hvor en given genstand skal hentes (rød punkt 2). Herfra og hen til punkt 2 vil input være i form af GPS positionen, der opdateres løbende af mobilen og sendes til serveren. Efter at rød spiller har accepteret sin mission, vil grøn spiller, som er lejemorder, modtage en mission brieng (grøn punkt 1) med samme in-/output som rød punkt 1, hvor hans mål så er rød spiller, hvis position bliver opdateret på grøn spillers kort i realtid. Når rød spiller når rød punkt 2, vil han få tekst output, hvor en grask illustration viser, at han kan samle genstanden op. Her benyttes accelerometeret som input til at samle genstanden op med. GPS input og kortoutput fortsættes desuden, hvor kortet opdateres med det nye mål som er aeveringspunktet (rød punkt 3). Hvis rød spiller når rød punkt 3, vil han få en grask illustration af at kunne aevere genstanden vha. accelerometer som input. Når genstanden er aeveret, vil rød spiller igen få et opkald, hvor han bliver gratuleret over en vellykket mission sammen med en tekst, hvor der står, hvad belønningen for missionen var. På dette storyboard bliver rød spiller dog indhentet af grøn spiller i det grønne punkt 2. Dette resulterer i, at begge spillere får fjernet deres kort og kommer til et interface for kamp. De to spillere kæmper så vha. accelerometre som input og vha. slideren på mobilen til at lade våbnet. Når den ene bruger dør, giver personens mobil en meget høj lyd, og der står på mobilen, hvem der skød, samt at han har tabt missionen. Da grøn dræber rød, får grøn spiller en tekst, hvor der står, hvem han har skudt, og at han har taget genstanden, som rød spiller bar på. Grøn spiller får så samme besked, som rød spiller k ved rød punkt 2. I dette scenarie kommer der en spiller fra det tredje agentur, som briefes i pink punkt 1. Pink spiller dræber så grøn spiller i pink punkt 2 og tager genstanden, som han bringer til pink punkt 3 og gennemfører derved missionen. Danger zonerne illustrerer, hvor spillerne er i fare for at blive angrebet af en anden spiller. Dette scenarie er forholdsvis indviklet, hvilket er for at vise mulighederne i, hvad der kan ske på en mission, men en mission vil dog ikke nødvendigvis forløbe sådan i det endelige spil. Den kan slutte ved, at rød spiller aeverer genstanden og slipper væk. 9

11 1.4 Remediation og 4 typer af interaktivitet Vores produkt remedierer et normalt kort, idet GPS lokationen anvendes til at angive punkter/personer på kortet i realtid. Dette betyder at kortet får en interaktiv betydning, hvori interaktionen er at bevæge sig og komme tæt på punktet. Man kan sammenligne vores kortvisning med en GPS vejviser i en bil, hvor vores dog ikke indeholder en oplæser samt rutebeskrivelse. Dette giver brugeren en større frihed i forhold til en vejviser, hvilket også er meningen, idet der ikke kun er en rigtig vej at tage, det handler blot om at komme tæt på målet. Applikationen på mobilen kan også siges at refashion[bag, kap. 1] mission brieng. Den tager både mission brieng fra papirform og fra opkald og samler dem i et nyt medie, men uden egentlig at ændre på hvordan briengen fungerer. Selve mobilen bliver repurposed[bag, kap. 1], imens man spiller, idet den laves om til et våben i nogle missioner, som kan lades, skyde og løbe tør for ammunition. Brugerens rolle i forhold til vores narrativ, jf. Ryans 4 typer interaktivitet[avatars of story, kap. 5], er internt/ontologisk. Rollen er intern, fordi spilleren ér lejemorderen, og selv skal løbe rundt i den fysiske verden, og bliver derved han/huns egen avatar. Samtidig er tiden i vores virtuelle verden næsten lig tiden i den rigtige verden. Brugeren vil således opleve, at handlingerne der udføres i den virtuelle verden afspejler den reelle tid der skal bruges i den rigtige verden (som at lade våbenen, skyde, opsamle pakken osv.)[avatars of story, s. 118]. Rollen er ontologisk, fordi brugeren påvirker handlingsforløbet, idet fx et drab styrker ens eget agentur, og påvirker de fremtidige missioner, samt historiens endelige udfald. Samtidig har de handlinger brugeren foretager direkte indydelse på brugeren selv, samt andre spillere, hvis man fx slår en ihjel[avatars of story, kap. 5, s. 116]. Brugeren er ligeledes situeret i tid og rum og følger handlingsforløbet i verdenen, både som første person, og på den tilhørende hjemmeside, hvilket også gør spilleren ontologisk involveret. 1.5 Beskrivelse af systemet Vigtigt: Følgende beskriver den visionære opbyggelse af den mobile klient, og ikke den implementerede prototype. Mobilklienten er opbygget som en fuldskærmsapplikation, der skal tilføre immediacy[bag, kap. 1] for brugeren. Når applikationen startes, kan man ikke komme videre, før man er logget ind. Hvis det er første gang, man spiller, bliver man først introduceret for den bagvedliggende historie, og et agency vil derefter ringe til en, og fortælle at man er blevet optaget. Derefter vil der, alt efter hvor mange spillere er online, gå et begrænset stykke tid, og man vil så få tilsendt missionbrieng til ens mobiltelefon. Denne missionbrieng efterligner et telefonopkald, og ved hjælp af tilhørende tekst, billeder og syntetisk tale skaber denne hypermediacy. Man kan vælge at sige nej eller ja til missionen, hvor man ved et nej, må vente på en ny mission brieng, og hvis man siger ja startes missionen. Missionen kan fx være en "Transporter" mission, hvor man skal hente og bringe virtuelle dokumenter, eller en "Hitman" mission, hvor ens opgave er at eliminere en anden. Når man går i gang med missionen, får man, når man bevæger sig fra et punkt til et andet, vist et kort, der automatisk er opdateret, og viser ens egen position samt modstanderen/området, som man skal hen til. Når man ankommer til den angivne position, får man vist ens muligheder for interaktion vha. små symboler i højre side af skærmen. Disse interaktioner skal man selvfølgelig benytte sig af for at komme videre. Små tekstuelle beskeder på skærmen, samt en vibrator, giver direkte feedback når benytter sig af en sådan interaktion. Er man hitman, får man, når man er inden for en radius af 100 m af sit mål, vist et billede af modstanderen. Dette billede er forvrænget, men eekten er omvendt proportional med afstanden til målet. Det betyder, at man som bruger, ikke med det samme kan se, hvem man skal skyde. I stedet bliver man nødt at have mobilen fremme, så man kan se hvem der er ens oer. Vi har implementeret dette for at target har en mulighed for at spotte en hitman i tide. Når hitman er indenfor en afstand af 10 m fra target, bliver det muligt for ham at skyde. Det kan han se ved et ikon i højre side af skærmen, hvor han også kan se, hvor meget ammunition han har tilbage. Han lader ved at køre skærmen frem og tilbage, og skyder ved at vippe mobiltelefonen op. Hvis man bliver skudt i spillet taber man missionen. Dette illustreres ved, at der vises blod på skærmen, og der står, hvem man er blevet skudt af. Derudover afspilles en meget høj lyd, som lyden fra en hjertefrekvensmonitor lige inden og efter hjertet er gået helt i stå. Lydens toner minder desuden også til forveksling om en alarm, bl.a. pga. volumen, hvilket får omkringstående til fokusere på den dræbte. Formålet med det er, at få omgivelserne til at reagere, som hvis en blev skudt i virkeligheden, for at indlevelsen for spilleren bliver endnu bedre (se [TD] for demonstration af dette). Det gør det desuden også nemmere for lejemorderen at slippe uset væk fra gerningsstedet. Ved en dødsscene kan man også sige, at folk, der ikke er med i spillet, som normalt fungerer som scenekarakterer, 10

12 får en rolle som ikoniske karakterer, ved at de laver en stemning af forargelse og overraskelse[uvg, kap. 8]. For at blive aktiv i agenturet igen, skal man tage hen til et af ere faste lokationer i byen, som spillet foregår i. Disse lokationer virker som hospitaler, og man kan efter et sådan besøg være med i spillet igen. Vejen til et hospital vises også på ens kort. Efter man har gennemført en mission med success, vises ens belønning i kraft af tre tal. Det ene tal repræsenterer den tillid, som ens agentur har til en. Det andet viser, hvor mange penge man har fået ud af missionen. Og det tredje viser hvor meget erfaring, du har fået for missionen. Tilsammen er dette en status for ens progression igennem spillet, og fungere som en gevinst [UVG, kap. 8] Pengene, som sman har indtjent, har betydning for næste gang, man får en mission. Her kommer der nemlig et skærmbillede op, lige efter at man har sagt ja til en mission, hvor man kan købe udstyr. Udstyret kan være nye våben, beskyttelsesudstyr, radar, aedningsmanøvre mm. De enkelte elementer kan ses som billeder, og man kan læse om de enkelte ting, inden man køber dem, hvilket giver denne del af spillet et ekstra lag af hypermediacy[bag, kap. 1][BaG, kap. 1] Koordinering spillere imellem Idet plottet indeholder tre agenturer, der hver især indeholder en masse spillere, vil der være mange spillere, som på samme tid er modstandere eller medhjælpere. Plottet ligger op til at agenturets medlemmer skal samarbejde, imens de to andre agenturers medlemmer er modstandere. Dette samarbejde og modarbejde kræver en koordinering af spillere, som teknisk foregår over en server. Det vil fungere ved at en mission, der udføres for ens agentur, har en hvis spillerkapacitet, det kunne fx være tre spillere, et fra hvert agentur. Disse spillere udvælges så ud fra serverens spillerdatabase og spillerinformationer, og serveren står så for at informere de udvalgte spillere, koordinere missionen og holde styr på de praktisk detaljer i missionens forløb, som fx hvem der kan dræbe hvem, og hvad der så sker Interaktion i konkrete fysiske områder Den lokationsbaserede interaktion fungerer ved, at GPS-koordinater bruges til at vise destinationen for ens mission på et kort over området. Et eksempel på dette er en mission, hvor man skal ud og hente en genstand for ens agentur. Der er på forhånd deneret nogle afhentningslokationer i byen, som benyttes ved en sådan mission. Missionen foregår så ved at spilleren får vist et kort med sig selv og destinationen, og når spilleren når hen til destinationen, vil spilleren kunne tage genstanden op ved at lave en optagningsbevægelse(1.9.1) med mobilen. En anden lokationsbaseret interaktion er når en lejemorder (en spiller) jagter en anden spiller fra et andet agentur Antal spillere Ser man bort fra serverens hardwarebegrænsning, kan man sige at et uendeligt antal spillere understøttes. Dette er fordi der køres en instans af spillet i hver by/lille område, der fungerer uafhængigt af hinanden, og dermed begrænses spillerantallet til beboertallet i byen. Desuden er det højst sandsynligt også kun en meget lille andel af beboerne i byen der spiller spillet. Mindste antal spillere er i princippet et, da han/hun så vil kunne udføre transporter missioner og vinde spillet på egen hånd i sidste ende. Men for at få udfordring og en smule spænding i spillet er det nødvendigt med mindst tre spillere for at alle agenturer bliver repræsenteret i form af spillere Målgruppen Spillet er udviklet med henblik på en målgruppe i aldersintervallet 15 til 25 år, men det kan spilles af alle der fysisk kan holde til at bevæge sig rundt samt nde ud af at bruge mobilen og installere applikationen. Idet spillet er et actionspil, vil en markedsføring af applikationen dog skulle henvende sig til angivne aldersgruppe. 1.6 Deployment af systemet Opsætning af systemet i en ny by Da der indgår forskellige lokationer i spillet, der skal være tilgængelige for alle spillere, vil en opsætning af spillet i en ny by kræve præcise GPS-koordinater på de forskellige steder, hvor spillets handling skal nde sted. Dette 11

13 kræver, at man enten har god kendskab til området og har adgang til et kort med GPS-koordinater (som Google Maps), eller at man fysisk går rundt i byrummet og opretter disse kordinater med en GPS. En lokation, i spillet, skal være nem at oprette, og skal blot tilføjes til en database, som de forskellige missioner så skal have adgang til at bruge. Når der er oprettet nok punkter, der kan benyttes i missioner, skal der oprettes nogle punkter, der kan være et agenturs hovedkvarter. Grunden til der skal oprettes mere end 3 positioner til agenturer, selvom der kun vil være 3 i hvert spil er, at det skal være muligt for serveren at genstarte spillet, når det slutter. På den måde sikrer vi, at når spillet først er startet i en by, vil det kunne blive ved i ere år. Det skal under et spil være muligt for superbrugere at oprette nye punkter til brug i missionerne. Oprettelse af disse vil foregå på samme måde som beskrevet ovenfor, og fordelen vil være, at det kan give mere variation i spillet. Under spillet kan der selvfølgelig ske uforudsete ting rundt omkring i byen, som fx vejarbejde der kan forhindre en spiller i at nå sit mål. Derfor skal det også være muligt for spillere at rapportere om et "broken point", hvilket vi ønsker at gøre så usynligt som overhovedet muligt, ved at kamuere det som en del af historien på hjemmesiden 9. Når spillet er sat op, vil det være muligt for spillere at registrere sig på nettet, og vælge en af de registrerede byer Spillets varighed Spillet vil strække sig over en længere tidsperiode, og en bruger vil derfor ikke kunne være online igennem hele spillet. Missionernes varighed vil strække sig fra 10 til 30 minutter, og det vil derfor være muligt at tjekke om telefonen fx har strøm nok til at gennemføre en mission. Vi har valgt at holde vores socket åben under hele missionen, dog afhængigt af missionen og antallet af spillere på denne, hvilket kombineret med en GPS hurtigt dræner et batteri. 1.7 Hovedarkitekturen af systemet Oversigt over Client/Server Da hele vores historie er bygget op over et kompliceret, og teoretisk uendeligt stort handlingsforløb, har vi valgt at opbygge kommunikationen, så det vil være muligt for en udvikler hurtigt at benytte sig af. Kommunikationen foregår vha. en simpel XML-protokol, der sendes vha. en TCP/IP socket. Både klienten og serveren er skrevet i python, hvilket har en fordel. Klassen der oversætter fra "kode" til XML, er den samme på klienten og serveren. Koden skal derved kun vedligeholdes et sted, og vi sikrer på den måde at både klienten og serveren altid er opdateret (så længe den nyeste l ligger begge steder). For at få en forståelse for systemet, kan sekvensdiagrammet ses i A.1 on page 19 Det der ses ovenfor er en simpel request fra klienten til serveren. Først benytter klienten "Request"-klassen til at lave en ny besked, der efterfølgende sendes til serveren. Når serveren får et request fra klienten, kalder den igen "Request"-klassen, der oversætter XML'et til en Message. Serveren kan derefter kalde execute() på denne Message, der så, med det samme, ved hvad den skal kalde i Callback-klassen. Den kaldte metode i Callback klassen, udfører så de nødvendige udregninger i forhold til parametrene, der er sendt med, opdaterer serveren (Herunder UserController og MissionController), og afslutter med at sende et svar tilbage til klienten, hvor serveren får ansvaret for at formatere det. Hvad der ikke ses på dette sekvens-diagram, er hvad der sker efter "Forward Response", men kort fortalt er det fuldstændig samme procedure, klienten følger for at oversætte svaret (benytter sig af Request og Callback-klassen). UML - diagrammet i A.2 on page 20 beskriver den overordnede struktur. Klienten og server benytter den samme klasse til at encode og decode XML-requests. Når serveren startes, opretter den en MissionController og en UserController, der hhv. holder styr på alle aktive brugere, og nuværende missioner. Når der laves en instans af en MissionController, starter den automatisk en tråd, der ikke laver andet end at lytte efter nye brugere, der ikke har noget at lave, og starte missioner. MissionControlleren kan håndtere et vilkårligt antal forskellige missioner, da hver mission blot skal tilkendegive hvor mange spillere, der skal bruges for at starte den. Når MissionControlleren ser, der er nok online spillere, starter den missionen i en ny tråd, og derfra kontrollerer missionen, hvad der skal ske med spillerne. 9 Dette kunne fx også gøres ved at brugere ikke skal vælge en menu, der hedder "broken coordinate", men i stedet "package inaccessible" 12

14 XML-kommunikation Kommunikationen imellem klient og server, indeholder et rod-element ("root"), en "auth"-knude, en "callback"- knude og n antal "param"-knuder. Følgende er et eksempel på en request, der vil opdatere en brugers GPS-position: <root> <auth id="uid_2" ip="camel27.cs.au.dk" /> <callback method="updateposition" /> <param latitude=" " /> <param longitude=" " /> </root> De forskellige knuder [4] auth: I denne knude ndes informationerne om klienten/serveren, der ønsker at udføre handlingen. ID'et er medsendt af debugging-hensyn, for at gøre det muligt at håndtere ere klienter på samme maskine. [4] callback: Denne knude indeholder altid en parameter kaldet "method". Denne refererer til navnet på den metode der skal kaldes. [4] param: Et kald kan indeholde alle de "param"-knuder der er brug for. En param knude indeholder altid en parameter, hvor nøglen referer til nøglen på det endelige dictory. Disse parametre bliver således oversat og vidersendt til callback-metoden i et dictionary, hvilket for overstående eksempel vil se ud som følgende: # Call back instance callback_obj = Callback(); # Params will be: # params['latitude'] = ; # params['longitude'] = ; # Get method method = getattr(callback_obj, updateposition); # Execute method(params); 1.8 Håndtering af lokation I vores spil benytter vi os af den virkelige verdens rammer, og tilføjer blot et ekstra lag af data til specikke lokationer, for at underbygge vores historie. Det betyder, at vi i dette spil har "fået foræret" en masse informationer, scenerier og stemning, der alt sammen er med til at udviske grænsen mellem spil og virkelighed. For at dette skal kunne fungere optimalt, forestiller vi os at alle missioner vil blive lavet af spiludviklere eller superbrugere, som har kendskab til stedet, hvor missionen planlægges, som beskrevet tidligere(sec. 1.6). Når spillet kører, er en vigtig del af dette, et kort hvorpå man kan se sin egen position, samt det næste sted, som man skal bevæge sig til. Vi har bevidst valgt mediet kort for at integrere den virkelige verden i spillet og gøre grænsen mellem spil og virkelighed så gennemsigtig som muligt. Stedet der vises(udover ens egen position) kan være en modstander eller en forudbestemt lokation, der er blevet sendt fra serveren til mobiltelefonen. I det tilfælde at denne er sendt fra serveren, er lokationen beriget med ekstra information - fx en virtuel pakke, som man kan samle op. Kortet som man får vist, har vi udviklet, så det er tilstrækkeligt intelligent, grundet kommunikationen med serveren, til selv at kunne vide hvornår det skal opdatere sig ift. markører på kortet, kortets position og zoom niveau. Det har vi gjort for at gemme den underliggende teknologi, og dermed opnå en større transparency[bag, kap. 1]. Vi overvejede følgende to løsninger for implementation af et dynamisk kort på mobiltelefonen: At bruge et oine kort Vil give os fuld kontrol over udseendet af kortet Vil, eftersom det er oine, ikke kræve dataoverførsel over 3G (udover positionerne der skal sendes fra en server) Vil kræve at kortet inddeles i tiles, da vi på telefonen ikke kan vise ét enkelt højtopløselig billede. Vil kræve at der installeres forskellige kort, alt efter hvor man bender sig Vil kræve kode til at sikre overensstemmelse mellem position fra GPS og position på kortet 13

15 1.8.2 At hente kort fra en korttjeneste fra Google Vil kræve dataoverførsel på ca. 18 kb pr. billede Vil ikke give fuld kontrol over kortets udseende Vil gøre det let at vise kort fra hele verden Valg af teknologi Vi valgte at gøre brug af Google Static Maps Api, der gør det muligt at hente et kort fra Google. Et valg vi tog med henblik på deployment af vores spil, da applikationen på denne måde kan benyttes frit i hele verden i, uden at der skal installeres nye kort. For at hente kort fra Google Static Maps skal man specicere en GPS position for centeret af kortet, et zoom level, samt størrelsen af det ønskede kort i pixels. Selvom Google tilbyder at man kan få vist positioner på disse kort, ønskede vi ikke at gøre brug af denne funktion, da det medfører at man, ved hver positionsopdatering, vil blive nødt til at downloade et nyt kort, hvilket ville være spild af dataoverførsel. Derfor bliver vi nødt til at foretage følgende beregninger for at kunne downloade det rigtige kort, og vise positioner derpå Beregninger For at kunne downloade det rigtige kort, har vi følgende oplysninger tilgængelige: Telefonens egen GPS position og en modstanders GPS position, som bliver opdateret løbende gennem spillet. Mobiltelefonens skærmdimensioner zoom level Når man henter kort fra Google maps, kan det gøres i forskellige zoom niveauer. Disse repræsenteres ved et tal mellem 0 og 19, hvor man ved et zoom level på 0 kan se hele verden, ved et zoom level på 1 kan se en fjerdedel af verden osv. Det betyder, at man kan beregne størrelsesforholdet, for hvor mange meter en pixel svarer til på et givent kort, på følgende måde. Omkreds Jorden zoomlevel 1px = 2 (1.1) screenw idth screen Eftersom Google afbilder jorden, som var den kvadratisk, er overstående beregning kun gyldig omkring jordens ækvator. Hvis vi skal omregne fra pixels til meter i Danmark, må vi beregne jordens omkreds ved Danmarks højdegrad. Jordens omkreds ved en given højdegrad er givet ved: c 2 = π (cos(lat) radius) 2 (1.2) (Se g. A.3 on page 20) Da vores skærm er 240 px bred bliver omregningen fra pixels følgende: π (cos(lat) radius) 2 zoomlevel 1px = 2 (1.3) 240px Med disse oplysninger kan vi nde det korrekte zoom level, og dermed downloade det rigtige kort. Det gør vi ved at undersøge om de to positioners afstand er større eller mindre, end det der maksimalt kan vises ved et given zoom level Afstanden mellem to lokationer Da outputtet fra vores GPS er i sfæriske koordinater, er det ikke muligt direkte at omsætte disse til en afstand i meter. Derfor konverterer vi vores positioner til UTM 10. Når dette er gjort, kan afstanden mellem to positioner ndes ved blot at trække disse fra hinanden Hentning af kort Når vi nu kender det korrekte zoomlevel, så kan vi være sikre på, at begge positioner kan ses på kortet, hvis centeret af kortet svarer til et gennemsnit af de to positioner. Derfor beregnes et gennemsnit af positionerne, og det rette kort kan nu hentes med følgende http GET request. \ &zoom="+str(zoom)+"&size="+str(self.screen_width)+"x"+str(self.screen_height)+" \ &maptype=roadmap&mobile=true&key="+self.google_maps_api_key+"&sensor=true 10 Universal Transverse Mercator 14

16 Vi sender her yderligere en parameter maptype=roadmap, som specicerer, at vi henter et alm. kort med veje. Det er et valg vi har taget, da der kan være problemer med, at der mangler kort på andre typer ved høje zoom levels Visning af positioner Ved at omregne kortets dimensioner til meter, kan man vha. alm. forholdsregning nde x og y positionerne på kortet: (se g. A.4 on page 21) x px = wpx W w meter 2 b (1.4) y px = hpx H h meter 2 a (1.5) Med grask overlay bliver resultatet på mobiltelefonen som følgende: (se g. A.5 on page 21) 1.9 Interaktionsteknikker Accelerometer: En interaktionsteknik, vi har valgt at implementere, er en gesture baseret interaktion vha. det indbyggede accelerometer i mobilen. Det er implementeret i form af, at man kan skyde med mobilen, samle ting op med den og aevere tingen igen. Skydebevægelsen foregår ved at holde mobilen vandret og lave en bevægelse bagover som ved rekyl fra et våben. "Samle op" bevægelsen fungerer ved at holde mobilen nedad i lodret position og så bevæge den opad tilbage til en vandret position. Aeveringsbevægelsen fungerer ligesom samle op bevægelsen, bare omvendt. Denne interaktionsteknik tilfører spillet noget immediacy [BaG, kap. 1], idet man anvender mobilen direkte som våben, hvilket gør det nemmere for spilleren at indleve sig i rollen som lejemorder. Derudover er det også et forsøg på transparency [BaG, kap. 1] og at gøre mobilen, som et medie, transparent for brugeren Kompas: I sammenhæng med våbnet hvor accelerometeret anvendes til skud, har vi visioneret en udbygning af denne interaktion vha. retning. Dette skulle fungere med et indbygget kompas i mobilen så retningen på skuddet ville kunne bestemmes. På den måde ville det også blive nødvendigt at sigte mod sin modstander, og derved også muligt at vælge hvem man skyder, hvis der er ere modstandere tæt på, i stedet for at man blot skal være i nærheden af ens oer. Grunden, til at dette ikke er blevet implementeret, er, at N95'eren ikke har et indbygget kompas Bevægelse i verdenen: En anden interaktionsteknik er ved, at man bevæger sig rundt udenfor i den virkelige verden, og på den måde generere input til systemet vha. den indbyggede GPS i mobilen. Denne interaktionsteknik er ligeledes implementeret i systemet, idet applikationen, når man er på en mission, jævnligt laver en GPS request hvorved lokationen af spilleren sendes til serveren. Applikationen sørger selv for automatisk at opdatere lokationen, hvilket vil sige, at man selv blot skal koncentrere sig om at bevæge sig rundt i den virkelige verden, imens man på kortet holder øje med hvor man er, og hvor man skal hen. Dette stemmer også godt overens med den immediacy, transparency og indlevelse, som vi forsøger at opnå i spillet Keysinput på mobilen: Mobilens normale interaktionsteknik, tastetryk, har vi valgt også at udnytte i vores applikation. Denne interaktion benytter brugeren til at navigere i interfacet, fx til at logge ind med, og til at acceptere eller afslå en mission efter brieng. Denne teknik er valgt, fordi den er ligetil og en normal interaktion, som brugeren kender i forvejen fra den øvrige brug af mobilen. Vi har dog holdt denne interaktion udenfor, når man først er på en mission, idet denne interaktionsform gør meget opmærksom på mobilen som medie og gør det sværere at indleve sig i historien. Vi udnytter dog også dette ved, at lade brugeren modtage et opkald ved en missionbrief, hvorved mobilens normale funktion inkorporeres i applikationen og i spillets verden/historie. En lidt anderledes interaktion der også hører ind under keysinput på mobilen, er applikationens brug af sliderfunktionen i N95'eren. Sliderfunktionen er når brugeren lukker telefonen i, så tasterne er skjulte, og åbner den igen, så tasterne kommer til syne. Denne interaktion benyttes til at lade våbnet, som mobilen udgør, når man kan skyde i en mission. Slideren blev valgt, fordi det føles som at lade en pistol, hvor man hiver topstykket bagud og fremad igen. 15

17 1.10 Beskrivelse af prototypen Videoprototypen I prototypen har vi valgt at begrænse os til en mission med 2 spillere, hvor Tobias er transporter og Jesper er hitman (lejemorder). I missionen bevæger Tobias sig fra busterminalen, hvor han modtager missionen, til afhentningspunktet ved rådhuset og opsamler en genstand, som han skal aevere på Sonnesgade (bag musikhuset). Jesper modtager missionen om at dræbe Tobias, imens han sidder på Rarbar, og bevæger sig imod Tobias. De to spillere mødes på park allé, hvor Jesper skyder Tobias og tager genstanden fra ham. Jesper bevæger sig så til Bruuns galleri, hvor han aeverer genstanden på taget og gennemfører missionen. Videoen er vedlagt på CD og kan desuden ndes på: Optagelse og redigering af videoprototypen For at lave videoprototypen så autentisk som overhovedet muligt, valgte vi at lme i Århus centrum. Dette betød der hele tiden var mange folk omkring, hvilket giver den største paranoia eekt for transporteren og den største udfordring for hitman. Da vi kun havde adgang til ét videokamera, var den efterfølgende redigering vigtig. Vi valgte at benytte "Magix Movie Edit Pro 12", et program der understøtter hurtig redigering, med mange forskellige spor, der gav os muligheden for at lave split-screen, og lægge en repræsentation af telefonen på skærmen så man både kan følge personerne, og samtidig se hvad der vises på mobilen Softwareimplementation I forhold til softwaren, har vi implementeret koden der skal til for at gennemføre hele denne mission, med opdatering af GPS positioner, styring af missionen fra serverside, accelerometerinput mm. [TD] Prototypeafprøvningen Afprøvningen af prototypen blev udført af to omgange. Første var torsdag d. 1. okt. ved IT huset, hvor vi færddiggjorde implementationen af softwaren på mobilen og serveren, og testede denne. Anden afprøvning var selve optagelsen af videoprototypen der foregik i Århus C mandag d. 5. okt, og den sidste da den tekniske prototype blev produceret d. 7. okt Prototypeafprøvningen i forhold til produktets interaktive narrativ. Som man kan læse i beskrivelsen af prototypen, er en del af det interaktive narrativ ikke implementeret i prototypen. Efter at have afprøvet og lmet prototypen har vi reekteret over positive og negative ting ved det interaktive narrativ. En af de meget positive oplevelser i vores simulering, var eekten af at man dør i spillet. Dette fungerede optimalt, idet omverdenen reagerede voldsomt, nogle virkede helt skræmte, på den høje alarmlyd, og det drog alt opmærksomheden over på Tobias, hvilket også var meningen, eftersom det er en voldsom begivenhed at blive skudt på åben gade. En negativ ting er, at virkeligheden ikke er som i vores spil. Ment på den måde, at det til tider kan være svært at forholde sig til, at verdenen omkring en, ifølge spillet, er fyldt med korruption, når man blot ser almindelige mennesker der kigger mærkeligt på en, fordi de ikke ved, at man er i gang med et spil Prototypeafprøvningen i forhold til pervasive computing arkitektur. Efter afprøvningen har vi også fået indblik i nogle tekniske aspekter, der ville skulle justeres ved videre udvikling Opdatering af GPS lokation Efter at have afprøvet dynamisk opdatering af GPS lokation i realtid, opdagede vi hurtigt at en opdateringshastighed op 10 sek. er alt for langsom. Denne opdateringshastighed blev dog også kun valgt for at være helt sikre på, at systemet kunne følge med. I en endelig spilsituation vil opdateringshastigheden optimalt lægge på omkring 2 sek. 16

18 Skud: Den tekniske implementation af skud og død fungerede godt, da kommunikationen var så hurtigt og eektiv at dette virker som realtid, og som om at man bliver skudt med næsten samme hastighed som i virkeligheden Accelerometerinput: Implementationen af accelerometeret er ikke færdigudviklet i prototypen, hvilket betyder at den blot understøtter og måler efter 2 bestemte positioner ved hver gesture, i stedet for at understøtte mere ydende bevægelser. Dette er også et punkt, der skulle arbejdes videre på i en endelig version Rumble feedback Vibratoren vil vi gerne have udnyttet i applikationen, men vi nåede desværre ikke at nde en mulighed for at få adgang til vibratoren igennem python. Efter afprøvningen observerede vi, at vibratoren ville kunne udnyttes som nyttigt feedback i ere situationer. Den første er ved gestikkerne; opsamling og aevering, hvor en vibrering vil give brugeren besked om at hans handling er blevet godkendt af mobilen. En oplagt situation er også ved opkaldet ved en mission brieng, da en mobil normalt vil vibrere ved en opringning. Vi fandt også ud af, at det kunne være smart med vibrator feedback ved opdateringer på mobilen, som fx når hitman går fra at få vist et kort med GPS til at få vist et billede af målet. Dette ville medvirke, at man ikke behøver at overvåge mobilens skærm for at se hvornår interfacet viser noget nyt, men i stedet kan man fokusere mere på den virkelige verden, og leve sig ind i spillet på den måde Grask feedback på interaktionsmuligheder I prototypen vises nye interaktionsmuligheder blot ved tekst på skærmen, men i en endelig version vil dette skulle vises ved hjælp af ikoner på skærmen, så man kan se, hvilke interaktionsmuligheder man har på det givne tidspunkt Konklusion Efter at have arbejdet ca. 6 uger med projektet, er vi meget tilfredse med resultatet. Vi har fået udarbejdet software, der demonstrerer en mission med to spillere, og dokumenteret dette med en video af en teknisk demonstration[td]. Vi har også fået udarbejdet en videoprototype af en missionen i Århus by. En udfordring i projektet har været at anvende python til alt kode, idet vi aldrig før har benyttet dette sprog. Udfordringen har især bestået i, at fejlmeddelelserne fra python kan være meget svære at tolke, og mobilen også kan være vanskelig at teste på, da den kan fryse ved nogle mindre fejl i koden. Vi har dog lært meget af sproget og fundet ud af, at det er et eektivt sprog, hvor meget kan udføres med forholdsvis lidt kode. Selve symbian styresystemet, s60, har været en blandet fornøjelse at arbejde med. Mange teknologier, der normalt er komplicerede at implementere, er utroligt nemme igennem s60, som fx TTS (text-to-speech), hvor audio.say("") læser tekst op uden videre. Andre funktioner har derimod været umulige at implementere, som fx at stoppe den røde knap fra at gå ud af programmet uanset hvad, og vibratoren har vi heller ikke kunnet nde hjælp til at benytte igennem python. En anden vigtigt erfaring vi har gjort os i dette projekt, er kollaborativt arbejde, både i forhold til kode og i forhold til rapport. Koden er blevet lavet vha. Eclipse hvor vi har anvendt et SVN (subversion) repository til at synkronisere kode fra alle tre gruppemedlemmer. Vi har også struktureret kode i pakker, så det har været nemt at arbejde på hver vores del og så importeres moduler fra de andres pakker og løbende holdes disse opdateret. Rapporten er hovedsagligt blevet skrevet igennem Google Docs, men for at kunne lave rapportlayout på teksten løbende, er vi så småt gået over til LATEX med SVN til versionskontrol. Efter at have prøvet det, er det absolut måden, vi vil arbejde på fremover, fordi det gør det nemmere at arbejde ere sammen omkring det samme projekt, og det betyder også mere sikkerhed, da alle gruppemedlemmer har en version af alt kode og rapport, samtidig med at der ndes en online backup. 17

19 Bibliography [MUD] Mobile Urban Drama, Setting the Stage with Location Based Technologies - Frank Allan Hansen, Karen Johanne Kortbek, Kaj Grønbæk [UVG] Understanding Video Games - Simon Egenfeldt-Nielsen, Jonas Heide Smith, Susana Pajares Tosca. Routledge [BaG] Remediation, Understanding New Media - Jay David Bolter, Richard Grusin [Avatars of story] Ryan: Avatars Of Story - Marie-Laure Ryan [Videoprototpye] Videoprototype: Kan både ndes på adressen " Og på den vedlagte cd. [TD] Teknisk dokumentationsvideo, som kan ses på den vedlagte cd. 18

20 Appendix A Appendix A.1 Client/server kommunikation Sekvensdiagram: UML - diagram Figure A.1: Sekvensdiagram 19

21 A.2 Håndtering af lokation Beregning af det rette størrelsesforhold: Figure A.2: UML diagram Positionering på mobil skærm: Figure A.3: Omregning fra en kvadratisk og til en kuglerund verden 20

22 Det endelige resultat - kort på mobiltelefonen Figure A.4: Udregning af position på skærmen Figure A.5: Kort på mobilen - det endelige resultat 21