MOBILT QUIZSPILL

UTVIKLING OG IMPLEMENTERING AV

QUIZ PARK PC-SPILL TIL EN MOBIL ENHET

OVE KRISTENSEN – TORE DAHL – GAUTE HEGSTAD

1

INNHOLDSFORTEGNELSE

SAMMENDRAG..............................................................................................................................................2

INNLEDNING .................................................................................................................................................3 MOTIVASJON..................................................................................................................................................3 BAKGRUNN ....................................................................................................................................................4 SCENARIO 1:...................................................................................................................................................5 SCENARIO 2:...................................................................................................................................................6

SPILL ...............................................................................................................................................................7 EN HISTORISK REDEGJØRELSE .........................................................................................................................7 DATASPILL.....................................................................................................................................................7 MOBILE DATASPILL ........................................................................................................................................8

HÅNDHOLDT TEKNOLOGI.......................................................................................................................10 KORT MOBILTELEFONHISTORIKK...................................................................................................................10 MOBILITET OG KONTEKST .............................................................................................................................10 NY TEKNOLOGI I ET ”GAMMELT” SAMFUNN ...................................................................................................11

PROBLEMSTILLINGER .............................................................................................................................13 ALTERNATIV FOR UTVIKLINGSMILJØ OG PLATTFORMER..................................................................................14 KOMMERSIELLE LEVERANDØRER ..................................................................................................................15 VALG AV SPRÅK, UTVIKLINGSMILJØ OG PLATTFORMER ..................................................................................15

METODE OG UTFØRT ARBEID................................................................................................................17 UTVIKLINGSMETODE OG PROSESSMODELL .....................................................................................................17 GJENNOMGANG AV DATAMODELL .................................................................................................................17 DEMONSTRASJON AV PC-SPILL ......................................................................................................................18 SPØRSMÅLSPAKKER......................................................................................................................................18 PROGRAMMERING ........................................................................................................................................18 UTVIKLINGSUTFORDRINGER....................................................................................................................19 TESTING.......................................................................................................................................................20 BESKRIVELSE AV NETTSTED..........................................................................................................................20

FREMTIDIG ARBEID..................................................................................................................................23

KONKLUSJON .............................................................................................................................................24

REFERANSER ..............................................................................................................................................25

2

SAMMENDRAG

Dette er prosjektrapport for prosjektet ”Mobilt Quizspill”. Rapporten beskriver prosessen med å

portere et pc-basert quizspill til en mobil versjon. Heri inngår en beskrivelse av de metodevalg

som ble truffet, samt en redegjørelse for noen av de problemene som oppsto underveis. I tillegg

gjennomføres en teoretisering omkring spill og mobilitet som begrep og fenomen. Det

problematiseres dessuten litt omkring trådløs oppkobling mot et nettsted for nedlasting av nye

spørsmålspakker til den mobile klienten. Til slutt refererer vi til mulig fremtidig arbeid, og trekker

en konklusjon på grunnlag av prosjektets gjennomføring. Oppgaven er utført på oppdrag for

firmaet Quiz Park, hvor en av prosjektdeltagerne også er medeier i.

3

INNLEDNING

For ganske få år siden var ikke mobiltelefoner så utbredt. De var til dels svært dyre i anskaffelse

og GSM-nettet var dessuten ikke like godt utbygget som det er nå, etter at det overtok og erstattet

det gamle NMT-nettet. Nå har vi fått flere standarder for overføring av nettrafikk som gjør

muligheten for å overføre data raskere enn tidligere. Andre typer mobilenheter som for eksempel

PDA-ene har også gjennomgått en rivende utvikling; 400 Mhz-prosessorene1 i noen av de mest

avanserte er like kraftige som pc-er var for bare få år siden. Nye generasjoner har i de senere år i

stor grad tatt i bruk2 slike rimelige, men avanserte mobiltelefoner med funksjonalitet som grenser

til de ofte langt dyrere PDA-ene (Personal Digital Assistant). Nylig viste en undersøkelse at så

godt som 100 % av ungdomsgruppen mellom 16 og 19 år hadde egen mobiltelefon3, og det var

71 mobilabonnement per 100 innbyggere i Norge totalt4. Helt ned i barneskolen er bruken så

omfattende at skolene må sette inn forbud og kjøreregler for bruken5. Noen eldre mennesker kan

kanskje ha et vanskelig og anstrengt forhold til ny teknologi, men også blant dem viser

undersøkelser at mobilfaktoren er økende; en fjerdedel av utspurte over 60 år intervjuet av MMI

sier de ikke ville klart seg uten mobiltelefonen6.

I takt med utviklingen av datamaskiner har det vokst frem en egen industri for dataspill. Denne

sektoren er nå verdt flere milliarder kroner årlig7, og har blitt en av de største i

underholdningsbransjen. Spill har vist seg å være populært også blant mobilbrukere, og det som

før var forbeholdt pc finnes nå i flere versjoner også for mindre, bærbare enheter. Vi ønsker i

dette prosjektet å se nærmere programmering og utvikling av spill for trådløse applikasjoner.

MOTIVASJON

Motivasjonen for prosjektet er at deltagerne ønsker å se nærmere på problemstillinger omkring

programmering for mobile enheter, fortrinnsvis PDA og mobil-PDA. I den senere tid har

imidlertid også ”vanlige ”mobiltelefoner beregnet for massemarkedet blitt stadig kraftigere

ressursmessig, så det er mulig at noen av dem vil være egnede i denne sammenhengen. Vi ønsker

derfor å lage en prototyp som kan benyttes både på PDA og litt avanserte mobiltelefoner. Denne

prototypen vil senere videreutvikles slik at den kan lastes ned lokalt på den mobile enheten, uten

å måtte gå veien om en stasjonær pc. I den forbindelse gjør vi oss noen tanker om hvordan et

egnet nettsted kan designes for dette formål. I tillegg ville vi se på trådløs teknologi som fenomen

i en teoretisk sammenheng, men med forankring i prosjektet. Med tanke på bakgrunnen for

prosjektet var det derfor naturlig å gjøre det i en sammenheng relatert til spill og

underholdningsindustri.

4

På grunnlag av interesser ble det besluttet at den interne arbeidsfordelingen i prosjektgruppa,

skulle bestå i at to av deltagerne skulle programmere, mens tredjemann foretok en mer teoretisk

undersøkelse om fenomenet spill og andre relevante teoretiske betraktninger.

BAKGRUNN

Bakgrunnen og grunnlaget for prosjektet er et quizspill for pc utviklet av firmaet Quiz Park8, som

det er ønskelig å portere også til en mobil plattform. Spillet, som fremdeles er under utvikling, er

per i dag implementert for en pc-basert Windows-plattform. Det er skrevet i Smalltalk9, og er

tiltenkt en kommersialisering i løpet av 2005/6. I sin enkleste form består spillet av spørsmål og

svar som presenteres for spilleren på skjerm. Spilleren får et varierende antall (2-8)

svaralternativer varierende å velge mellom, og foretar valget ved å klikke på det antatt riktige

svaret, som presenteres i en boks på skjermen. Det finnes dessuten flere ulike spillvarianter, med

ulik kompleksitet for spilleren å velge i mellom, og noen av disse inneholder eller er tiltenkt å

inneholde grafiske elementer. I utgangspunktet er det derfor vanskelig å si på forhånd hvor

omfangsrikt det ville være å foreta en komplett portering av hele spillet, siden spillet ikke er helt

ferdigstilt ennå. Imidlertid er prosjektets deltagere enige om at ett av de enklere spillene synes

egnet for en utvikling av prototyp for mobile enheter. Dette spillet består ganske enkelt av 20

spørsmål som skal besvares ved å velge mellom ulike svaralternativer. Etter at alle spørsmål er

besvart vises en rapportstatistikk for spilleren. Denne informasjonen skal ivaretaes, og taes med i

en total statistikk for alle spill som har blitt spilt. Det betyr altså at informasjonen skal lagres lokalt

på enheten. Under vises et skjermbilde fra pc-versjonen av 20 spørsmål.

5

Skjermbilde pc-versjon

I vår prototyp vil vi legge vekt på at spillet skal være lett forståelig, brukervennlig og kunne

benyttes av flere aldersgrupper. Quizzing er en type aktivitet som i utgangspunktet har potensial

til å engasjere alle aldersgrupper, de fleste har spilt spill som Trivial Pursuit eller benyttet

spørrebøker som kilde til fellesskap og underholdning. Kanskje ligger det også et stort potensial

for de litt eldre, som ikke har vokst opp med dataspill i ”tradisjonell” forstand, men som kjenner

til den gode gamle spørreboken.

I neste kapittel beskriver vi et par situasjoner hvor spillet kunne vært benyttet, enten alene eller

sammen med flere.

SCENARIO 1:

Familien Arnesen har tatt med seg familien Gulbrandsen til en årlig felles ferie på hytta deres ved

Tjøme. De er fire voksne og 5 barn til sammen, og de har feriert sammen der de siste ti årene.

Dagene går med til bading og grilling, men på kveldene liker som mange andre på hytteferie, å

spille spill. Alle er med, og like entusiastiske på å vinne. De har ingen tv eller internett-tilgang

men mange spill til kveldsunderholdning på hytta, og selv om de begynner å bli litt slitte i

kantene, er de fortsatt spillbare. En favorittaktivitet er å teste hverandres kunnskap i det lange og

det brede. Annet hvert år har de kjøpt en ny spørrebok til konkurranseformål; de gamle mot de

unge. De gamle pleier å vinne, men de siste årene har de unge halt innpå. I år regner de

imidlertid med å vinne for første gang, og det overlegent. Men pappa Frank har glemt å kjøpe

6

en ny spørrebok. De forsøker litt likevel med de gamle, men selv om de ikke husker alle svarene

kan de for mange til at generasjonskampen blir riktig spennende. De fem unge begynner å

mistenke pappa Frank for å bevisst ha latt være å kjøpe ny bok, for å sikre nok en eldre-seier. Litt

skuffende er det, men det er syv mil å kjøre til nærmeste bokhandel, det er lørdag og den stenger

klokken tre. Men eldstemann i ungeflokken, Joakim, har en ny mobiltelefon med seg. Den har

internettforbindelse, og kan kjøre Java-applikasjoner. Joakim gjør et søk, og finner frem til noen

nettsider som selger spill. Det finnes ikke mange quizspill, men det finnes ett på norsk. Det har

1000 spørsmål, og mulighet til å laste ned flere senere. Det er akkurat hva de trenger, og ikke er

det dyrt heller, faktisk mye rimeligere enn hva en bok normalt ville kostet. Joakim laster ned

spillet, og det er igjen tid for generasjonskampen!

SCENARIO 2:

Jonas har alltid vært interessert i trivia, eller unyttig men morsom informasjon om alt eller

ingenting. Interessen strekker seg fra barndommen, da han som liten så både gamle og unge

mennesker delta i ”Kvitt eller dobbelt” på tv imponere med sine kunnskaper. Siden har han selv

deltatt i kvalifisering til et par slike programmer, med vekslende hell, og i den senere tid har han

også deltatt i lagkonkurranser på pub, såkalt pubquiz, og spilt Trivial Pursuit med venner. Som

de fleste andre som konkurrerer på hobbybasis vil han gjerne bli bedre, og derfor leser han av og

til i spørrebøker for seg selv som en form for ”trening”. Det er kanskje litt ”nerdete”, men det er

moro og sosialt, og det er det viktigste. Forleden fikk han tak i et quizspill for mobilen, som han

pleier å benytte seg av i ledige stunder, som nå når han venter på bussen. Innen han er hjemme

har han imidlertid spilt ferdig spillet, han har svart på alle spørsmålene. Han kan jo ta dem om

igjen, men spillet gir ham også mulighet til å laste ned spørsmål trådløst direkte til telefonen for

en billig penge, noe han i stedet benytter seg av. Uavhengig av tid og sted kan han altså fortsette

spillet, så fremt han husker det viktigste: mobiltelefonen.

Disse to ovenstående scenariene er en illustrasjon på hvordan en mobil applikasjon kan benyttes

av ulike brukergrupper. Mennesker er forskjellige, og det er interessant å se litt nærmere på

hvordan de benytter seg av håndholdt teknologi i ulike sammenhenger. Vi vil redegjøre for dette i

tillegg til fenomenet spill generelt og i en mobil kontekst.

7

SPILL

EN HISTORISK REDEGJØRELSE

Homo ludens – det lekende mennesket10 – har eksistert i alle fall så lenge vi har nedtegnet

historie. De gamle romerne, grekerne, mayaene, kineserne og egypterne drev alle med sine

former for spill og lek. Ikke bare barn, men også voksne deltok i leken. Til det brukte man gjerne

redskaper – teknologiske hjelpemidler – i form av baller og rackerter. I noen tilfeller som en kilde

til underholdning, men også for å øve opp ferdigheter til krig og jakt. Lenge før det kulturelle

samfunn11 oppstod har mennesket lekt og spilt sine spill, og slik er det fortsatt i dag. Men vi leker

ikke bare ut i fra hva vi vil oppnå, men også ut i fra vår nysgjerrighet, utforskertrang og tvil. I vår

tilværelses mangfold kan en spasertur ut uten noen spesiell hensikt, en spøk, tro, en fiks idé -

være like mye verdt som planer, logikk og studier.

Lek er ikke bare tankeløs underholdning men også en måte å engasjere seg og lære om oss selv

og verden for øvrig - både for voksne og barn. Når vi leker med ting og tanker; når vi snakker

eller dagdrømmer finner vi frem til nye perspektiver og nye måter å løse oppgaver på, skaper nye

mål og ideer. Lek er mer enn bare underholdning.

Spill i våre dager er svært utbredt. Spill i mange varianter, kortspill, brettspill, dataspill; spill som

fordrer ferdighet eller består av flaks; strategiske spill eller spill som gir status12. Mobile spill er

heller ikke nytt. Et lite sjakkspill i en eske som enkelt kan fraktes er mobilt, og trenger heller ikke

kreve stor plass.

DATASPILL

Dataspill er naturlig nok et relativt nytt fenomen i spillets historie. I 1958 laget William

Higinbotham 13 spillet Tennis for two mens han jobbet som fysiker med tilgang til datamaskin i et

forskningslaboratorium i New York. I forbindelse med et årlig åpent hus- arrangement ville han

gjøre omvisningen litt mer spennende enn vanlig, og laget derfor altså det elektroniske

tennisspillet. Men selv dette var ikke det første dataspillet, for seks år før dette igjen ble det

utviklet en digital versjon av spillet Tic-Tac-Toe ved universitetet i Cambridge, England, og dette

spillet kan fremdeles spilles på emulatorer på internett i dag14.

Pong har ofte misvisende blitt beskrevet som det første dataspillet. Det ble produsert av Atari i

1973, og ligner en del på Tennis for two. Dette spillet ble starten på det som siden ble til

konsollmarkedet. Og med konsollmarkedet begynte produsenter virkelig å tjene penger på

8

dataspill, og en egen industri vokste frem. Det fikk naturlig nok også betydning for utviklingen av

datamaskiner generelt. Dataspillindustrien vokste seg større og større etter hvert som ungdom15

brukte mer og mer fritid til dataspill. I 2002 lå omsetningen på dataspillmarkedet på rundt 20

milliarder USD16.

MOBILE DATASPILL

Den første håndholdte konsollen ble introdusert Microvision i 1979. og frem til de avviklet i 1982

produserte de ca et dusin spill17. Mobile spilleenheter ble ikke virkelig populære før Nintendo

kom på banen. I 1989 introduserte de Gameboy som først bare ble en moderat suksess, men som

med spillet Pokèmon ble til en gigantisk suksess; og i dag er titler i serien er fremdeles blant de

mest solgte hvert år18.

I 1997 introduserte Nokia19 spillet Snake på sine mobiltelefoner, og dette ble så populært at de

begynte å installere flere typer spill fast på enhetene sine. I samme tidsrom fikk bruken av SMS

en enorm vekst, og det tok ikke lang tid før spillindustrien skjønte at det var på det og ikke WAP

de skulle gjøre penger på. WAP var ikke spesifisert slik at den kunne aksessere internett direkte

og informasjonen måtte være skrevet i WML20. Dessuten var den lave overføringshastigheten

sammen med den kronglete oppkoblingen til nettet og høy bruksavgift med på gjøre den lite

interessant.

I Japan tok de derimot i bruk en annen type teknologi enn WAP. Noen vil si det var en annen

spesifisering av WAP-teknologien21. Japans ledende mobiltelefonoperatør NTT DoCoMo

lanserte i 1999 iMode22. iMode tilbyr kontinuerlig internettaksess basert på pakkesvitsjeteknologi

som belaster kunden kun for den mengden data som sendes/mottas, og ikke for tiden man er

online. Dette er vel en av grunnene som gjør at iMode fremdeles nyter stor suksess med 40

millioner23 kunder i Japan; både i spillmarkedet og når det gjelder bruk av mobil til å aksessere

internett generelt. iMode bruker compact html (chtml) som gjør det mulig å vise Internett-sider,

men det blir ikke seende så pent ut med mindre sidene er laget i chtml.

Introduksjonen av nedlastbare spill og fargeskjermer på mobile enheter introdusert i 2001 førte til

et oppsving av produksjon og bruk av trådløse spill. Konsumentene viste seg villige til å kjøpe

slike spill og dette førte til at utvalget eksploderte samtidig som kvaliteten ble forbedret. Dette har

igjen ført til at mobiltelefonene utviklet seg mer og mer i retning av å bli til små bærbare

datamaskiner.

Nokia har fortsatt med å være pionerer innen det trådløse spillmarkedet, og i 2003 introduserte de

N-Gage, som støtter trådløs spilling mellom flere spillere samtidig online med N-Gage Arena.

9

Det vil si, ikke helt online. Spillerne er oppkoblet til en server via GPRS24, og dermed er man ikke

faktisk online, det bare virker slik på grunn av den høye hastigheten (171 kbps) og raske

responsen. En annen måte de kunne ha løst dette mobilitetsproblemet på, er i et peer-to-peer

nettverk25 i følge Bradley J. Rhodes, Nelson Minar og Josh Weaver. Dette muliggjør gruppespill i et

"online community" på en helt annen måte enn det som tidligere var mulig; og med N-Gage, og

antagelig med oppfølgeren QD ventet sommeren 2004, har Nokia tatt et steg videre i utviklingen

av trådløse spill.

Den trådløse spillutviklingen har med mobiltelefonen ført teknologien dit hen at det antagelig

ikke lenge før andre typer forretningsapplikasjoner tar i bruk elementer utviklet gjennom

spillteknologi. Teknologien vokser seg inn i vår26 hverdag mer og mer. Snart bærer vi med oss

den teknologien som før var forbeholdt stasjonære enheter. Vi kan da stille spørsmål med hva

som egentlig er stasjonært og hva som er mobilt.

10

HÅNDHOLDT TEKNOLOGI

KORT MOBILTELEFONHISTORIKK

Den første mobiltelefonen som ble utprøvd ble testet av det svenske politiet i Lindingõ i 194627.

Den kunne knapt kalles håndholdt, i og med at den fylte hele bagasjerommet på en bil. Den nye

teknologien tok heller ikke av umiddelbart blant massekonsumentene, og det tok enda noen tiår

før det ble helt vanlig med mobiltelefon. Men fra omtrent midten av 1990-tallet da de ble rimelige

nok for folk flest til å gå til anskaffelse av, og ikke minst ble små nok til å bære med seg overalt,

har spredningen vært ganske fenomenal. Og nå, over femti år etter den første utprøvelsen, har

altså et flertall mennesker i Norge egen mobiltelefon. Det kan derfor være interessant å gjøre seg

noen betraktninger omkring hvordan dette og fenomenet mobilitet påvirker oss i hverdagen.

MOBILITET OG KONTEKST

Det er viktig å ha en viss forståelse av hvordan ulike mennesker benytter teknologi på ulike vis.

Ikke bare for å kunne ta de riktige kommersielle grepene, men også for å kunne tilby en

teknologi som er nyttig for ulike mennesker i mange forskjellige sammenhenger. Det gjelder ikke

bare i jobbsammenheng, men også i fritidsøyemed. Moderne mennesker får stadig mer fritid, og

samtidig med dette vokser det frem ny industri for å dekke voksende behov.

Underholdningsindustrien har da også vokst enormt de siste hundre år, og sysselsetter således et

stadig større antall mennesker, som da også ofte veksler mellom å være konsumenter og

produsenter. Underholdningsindustrien har også vært blant de dyktigste til å ta i bruk ny

teknologi tidlig, og har vært toneangivende innen utviklingen.

En av de nyeste formene for utelivsunderholdning som har blitt populært her til lands de siste

årene er det som kalles pubquiz. Pubquiz er spørresport for lag, og som navnet antyder

arrangeres det gjerne i en pub. Interessant nok oppsto denne formen for quiz med stor

sannsynlighet som en spin-off av en annen trådløs teknologi: fjernsynet. I 1940 og 50-årene

begynte man nemlig å sende spørreprogrammer på tv i Storbritannia og USA. Samtidig var det

ikke vanlig for en vanlig familie å være i besittelse av et tv-apparat. De var ofte kostbare, et tv-

apparat på 1930-tallet kostet tilsvarende 40.000 kroner ($7000)28 etter dagens priser. Men etter

andre verdenskrig sank prisene og ble det mer og vanlig å ha tv, men de som fortsatt ikke hadde

råd gikk i stedet til et sted hvor et apparat som regel fantes, nemlig på pubene. Der kunne de

blant annet se folk delta i spørreprogrammer quizshows, og deres popularitet inspirerte lure

pubeiere til å arrangere egne slike show ”live”, og på den måten bidra til å øke omsetningen. Slik

kunne altså høyteknologi føre til fremskritt som gjør at teknologien rett og slett blir overflødig i

11

den nye sammenhengen – det var ikke lenger nødvendig med tv-apparat for å bli underholdt,

bare et lokale og en eier villig til å påta seg arrangementet. Og slik kan ”myk” og ”hard”

teknologi alternere med å erstatte eller utfylle hverandre; også på motsatt vis slik den trådløse

enheten i det beskrevne scenario 1 midlertidig erstattet en gammel teknologi – spørreboken.

Dette er kanskje ikke helt typiske eksempler på det som omtales som ”det dynamiske og

komplekse samspillet mellom gamle og nye teknologier”29 som videre også beskrives som

”fundamentalt i den teknologiske revolusjonen mot slutten av forrige århundre”. Men det tjener til

i alle fall til en viss grad i å illustrere hvordan et slikt samspill kan arte seg.

NY TEKNOLOGI I ET ”GAMMELT” SAMFUNN

Enten den er ny eller gammel så fører det likevel til spørsmålet om det kan bli for mye teknologi,

og om den kanskje også er fremmedgjørende. Dette spørsmålet er svært sentralt for Amish-folket

bosatt i USA, som har blitt analysert i casestudier om deres forhold til bruk av mobiltelefon30..

Settingen for Amish-folket er ikke ulik den vi beskriver i hyttetilværelsen til de to familiene i det

første scenariet. De lever i en frivillig isolasjon fra resten av verden samtidig som den ikke er

avskrekkende langt borte, og de fører en relativt primitiv tilværelse i forhold til livet i et moderne

samfunn. Men Amish-folkets tilnærming til teknologi er ganske annerledes enn for folk flest. For

dem er teknologi en forbindelse til den ytre verden som kan komplisere det enkle og tradisjonelle

livet de ønsker å føre. Amish-folket ønsker derfor ikke å eliminere, men heller å begrense bruken

av moderne teknologi. Samtidig er de både villige og i stand til å ta den i bruk når det behovet

blir sterkt nok. De lever i et nokså autoritært samfunn, hvor individuelle behov må vike sterkt for

samfunnets. I det siste tiåret har de likevel i stadig større grad tatt i bruk mobiltelefonen, et i høy

grad individuelt instrument i verden for øvrig. Og bruken av den byr derfor på visse dilemmaer i

forhold til livsstil. Tidligere har Amish-folket også tatt i bruk vanlig telefon, men denne ble gjerne

sentral plassert og delt mellom flere husstander omtrent som en telefonboks. Dette gjorde det

enkelt å holde oppsyn med bruken av den, og dermed opprettholde en større grad av kontroll.

Mobilbruken har endret dette mønsteret, og det at den er trådløs vanskeliggjør kontroll. Når det

ikke lenger er nødvendig med ledninger til apparatet, eller en bestemt lokasjon for å benytte det,

blir det nesten umulig å beholde oversikten over bruken. På spørsmål om telefonen er et gode

eller onde, svarer en av de intervjuede at den er begge deler. Den holder folket sammen gjennom

å muliggjøre kommunikasjon når som helst og hvor som helst, samtidig som det skiller dem fra

verden og hverandre. Man trenger ikke lenger dra på besøk for å føre en samtale, ei heller være

avhengig av at personen ikke er opptatt på sin side, hvis vedkommende har telefonsvarer for

eksempel. Det i seg selv kan være fremmedgjørende for et samfunn som legger slik vekt på

samhørighet og felleskap. Det er uansett et moment å forsøke å beholde en viss kontroll med

teknologi, enten den er håndholdt eller ei, for ikke å bli helt og holdent styrt av den. Det kan

være nyttig også for oss å være klar over slike dilemmaer. Vi kan for eksempel designe spill

12

slik at det ikke blir ustyrt med høye lyder som er forstyrrende for omgivelsene. PC-versjonen er

for eksempel utstyrt med ”buzzer”-lyder, som neppe ville være behagelige for tilfeldig

forbipasserende i det offentlige rom.

13

PROBLEMSTILLINGER

Hovedoppgaven var altså å portere deler av spillkode skrevet i Smalltalk til en mobil plattform.

Det var ønskelig, men ikke et absolutt krav at den nye koden ble programmert etter den

eksisterende datamodellen. Dette for å gjøre det enklest mulig med senere utvidelser. Spillet som

skal porteres heter 20 spørsmål, og består av ett spørsmål og fire svaralternativer i tyve

spørsmålsrunder fremvist på mobilen. Det var ønskelig å vise enkelte grafiske elementer i form av

bokser hvor spørsmål og svar kan vises, og eventuelt velges ved hjelp av touchscreen. Den

mobile applikasjonen bør også ha mulighet til å laste ned spørsmålspakker for installasjon direkte

på klienten. Senere vil det også kunne være aktuelt å laste ned hele applikasjonen og installere

den trådløst. Dette var ikke en oppgave i dette prosjektet, men kan være aktuell for et fremtidig

prosjekt. Det kunne også vært ønskelig å se på kryptering og dekryptering av spørsmålspakker på

klienten, men dette ble også vurdert som for tidkrevende for dette prosjektet.

En del spørsmål var aktuelle å besvare i forbindelse med oppgaven: Skulle vi utvikle ut ifra en

standard som ville fungere for ulike plattformer (mobil fra ulike fabrikanter, ulike pda-er, ulike

operativsystemer)? I så fall hvilken type teknologi skulle vi velge (språk, utviklingsmiljø)? Hva var

den nedre begrensningen for at en mobil enhet skulle kunne kjøre mobilversjonen av spillet?

Burde vi forsøke en direkte migrering av kode, eller kode det meste fra bunnen av, basert på

datamodellen?

Vi ville forsøke å løse disse problemene på en så praktisk måte som mulig, ved å ta hensyn til

hva som fantes av ressurser tilgjengelig gratis på internett (kompilator), eller som vi allerede var i

besittelse av (mobiltelefon). Med dette som grunnlag forsøkte vi å komme frem til den mest

praktiske måten å utføre oppgaven på.

I forbindelse med portering av kode måtte det bestemmes om den nye koden skulle kunne kjøres

på flere forskjellige operativsystemer eller om det var best å lage én versjon for hvert enkelt.

Tilsvarende for om det skulle være mulig å benytte spillet både på PDA og avanserte

mobiltelefoner. For å kunne kjøre applikasjonen på små skjermer var det også tilknyttet en del

problemstillinger. Vi foretok en undersøkelse over hva som var minimumskravet for

skjermstørrelse (høyde x bredde i piksler) i forholdet til innholdet som skulle fremvises. Dette

siste kunne nemlig variere mye, ettersom det naturlig nok fantes spørsmål med både korte og

lange formuleringer. I så måte måtte vi vurdere å spesialdesigne egne spørsmålspakker

skreddersydd for de mobile plattformene; som kun inneholdt tekststrenger av en lengde egnet for

fremvisning. Andre begrensninger, som minnestørrelse og prosessorhastighet måtte det også tas

hensyn til. Til slutt skulle vi foreta en tilpasning for den eller de tiltenkte plattformer, og en kode

14

og teste en prototyp. I den skulle også inngå muligheten for trådløs nedlasting av nye

spørsmålspakker. I den forbindelse ville også se litt nærmere på hvordan et nettsted for

oppkobling fra mobilen kunne designes, men dette ville vi kun gjøre i en teoretisk sammenheng

og ikke implementere selve løsningen.

Under følger en beskrivelse av noen av de valg mellom ulike mulige alternativer vi foretok

underveis i utviklingen, og hvordan de igjen var bestemmende for metoden vi benyttet oss av.

ALTERNATIV FOR UTVIKLINGSMILJØ OG PLATTFORMER

Det finnes flere ulike kompilatorer og utviklingsmiljø for koding på mobile enheter. Noen av

disse er:

• Codewarrior Wireless Development Kit; utviklingsmiljø for C++ programmering i Symbian

OS.

• Appforge Crossfire Development Kit for the Sony Ericsson P8/900 – for Visual Basic

programmering til Sony Ericsson P8/900 (Symbian OS)

• Sun Java Wireless Toolkit

• Sun ONE Studio, Mobile Edition (Java)

Tilsvarende finnes det flere ulike operativsystemer å velge mellom:

Symbian31

Windows

Linux

Palm OS

I tillegg kommer selvsagt de ulike hardware-typene som finnes. Både mobiltelefoner og

pda-er kommer i ulike konfigurasjoner, både med hensyn til hvilket operativsystem som

benyttes, og hva slags ressurser som tilbyes. Mobiltelefoner og pda-er fra for eksempel

Nokia, Sony Ericsson, Palm, Pocket PC finnes alle i mange ulike utgaver, og det er ikke

gitt at selv en enkel applikasjon som ikke er spesielt krevende med hensyn til ressurser

kan kjøre på alle utgaver. Av naturlige årsaker kunne vi ikke teste prototypen på alle disse

plattformene i dette prosjektet.

15

KOMMERSIELLE LEVERANDØRER

Dette er flere kommersielle leverandører på markedet som leverer løsninger for utvikling av

applikasjoner på mobile enheter. Ofte ut i fra en trelagsstruktur slik at funksjonalitet, design og

innhold er separert i egne enheter.

En svensk utviklingsselskap Gamefederation32 har utviklet konseptet GEX som kan støtte alle

plattformer samtidig. De har integrert spillutvikling i systemet som har ulik kvalitet for de

forskjellige plattformene, men de kommuniserer via GEX. ”Eksempelvis vil et spill som har farger

og god grafikk på den stasjonære PC-en, ha gråtoner på mobiltelefonen. Kommunikasjonen skal

likevel gå smertefritt mellom de to”33. Løsningen GEX er en Java-basert plattform for utvikling av

programvare for eksterne miljøer. Vi valgte å ikke benytte oss av dette alternativet, da det ble

ansett som for kostbart for oss. Vi beskriver likevel muligheten her med tanke på mulig fremtidige

arbeid, da kanskje andre vurderinger medfører at et slikt verktøy som det Gamefederation tilbyr.

VALG AV SPRÅK, UTVIKLINGSMILJØ OG PLATTFORMER

Per i dag er det altså mulig å programmere for små enheter i en rekke språk. Vi fant det mest

hensiktsmessig å benytte Java til formålet. Begrunnelsen for det er blant annet at programmet

ikke krever spesielt rask kode slik f.eks. C++ er egnet for. C++ har dessuten ingen enkle måter å

konstruere grafiske grensesnitt, det er både tungvint og vanskelig å programmere selv enkel

grafikk i språket. Fordi det er ønskelig at dette prosjektet på et senere stadium skal kunne

tilrettelegge for bruk av enkle skjermbilder som fremvisning av spørsmål og svar i ”bokser” også

på mobilenhetens skjerm, og eventuelle andre grafiske elementer i spill som ikke skulle

implementeres i denne omgang, så ville det være hensiktsmessig å velge et språk hvor dette var

enkelt å få til på et senere tidspunkt. Visual Basic kunne vært benyttet, men ville krevd ekstra

programvare (Appforge Booster) for å være kjørbar på for eksempel Symbian-plattformen. Dette

var ikke ønskelig, og valget falt derfor ganske naturlig på Java (J2ME) som programmeringsspråk.

Java har mulighet for å enkelt konstruere grafiske grensesnitt gjennom innebygde pakker, og er

dessuten en veldig utbredt plattform for utvikling av mobile spill generelt, noe som taler for at det

er både egnet og velprøvd. Java skal i utgangspunktet også kunne kjøre på alle plattformer, noe

som var hensiktsmessig. Oppdragsgiver ønsket nemlig at den mobile versjonen skulle kunne

kjøre på flest mulige typer av håndholdte enheter, noe som er enklest å få til ved å benytte Java.

Dermed slapp vi også å ta noen bestemt stilling til type operativsystem, med et foreløpig unntak

av Pocket PC34.

Spesifikt valgte vi imidlertid å teste ut applikasjonen på enheter med operativsystemet Symbian.

Bakgrunnen for dette valget var rent praktisk, to av prosjektdeltagerne har nemlig hver sin Sony

Ericsson mobiltelefon i P800/900 - serien. Disse telefonene er kombinasjoner av PDA og

16

mobiltelefon, og kjører Symbian 7.0 OS. Som brukere av disse enhetene ønsket deltagerne

naturlig nok å se om de kunne programmere for dem, og om det kunne være var spesielle

problemer forbundet med dette arbeidet. Vi valgte derfor Java som programmeringsspråk,

nærmere bestemt J2ME, som er et subsett av Java spesielt for mobile plattformer. For dette formål

fant vi at vi uten kostnader kunne benytte Suns Java Wireless Toolkit som kompilator. Dette finnes

fritt tilgjengelig for nedlasting, noe vi benyttet oss av. Vi vurderte også Suns ONE Studio 5 Mobile

Edition, men fant dette verktøyet vel tidkrevende å sette seg inn i, noe som syntes unødvendig å

gjøre, ettersom Wireless Toolkit virket tilstrekkelig for vårt formål, noe det da også var. Med

kompilatoren fulgte også med en emulator i et par ulike varianter (mobiltelefon og PDA) hvor vi

kunne teste ut hvordan den kompilerte koden virket på pc.

I tillegg til å bestemme programmeringsspråk, måtte vi også bestemme hva slags filformat

applikasjonen skulle kompileres til. Vi kunne for eksempel laget SIS-filer, som er spesifikke for

Symbian OS og i utgangspunktet ikke ønskelig; eller vi kunne lage Jar-filer, som er komprimerte

Java-filer. Et nøkkelelement i Java 2 plattformen er MIDP (Mobile Information Device Profile),

som kombinert med CLDC (Connected Limited Device Configuration). Denne spesifikasjonen

tilbyr funksjonalitet som enkle brukergrensesnitt og nettverkssikkerhet for mobile enheter.

Kortfattet krever MIDP følgende av enheten:

Skjermstørrelse på minst 96 x 54 piksler

Mulighet for brukerinteraksjon (via tastatur, touch screen, tohånds tastatur)

128 Kb fastminne (nonvolatile)

32 Kb volatile memory

Trådløs nettverksforbindelse

Vi fant ut at MIDP var relativt enkelt å komme i gang med, og valgte derfor å se bort fra SIS-filer i

denne omgang, og bare implementere løsningen som Jar-filer. Med rammeverket J2ME og MIDP

valgte vi en metode vi skulle følge, og gikk så i gang med å programmere applikasjonen.

17

METODE OG UTFØRT ARBEID

UTVIKLINGSMETODE OG PROSESSMODELL

Med bakgrunn i den relativt korte tiden som var til rådighet i dette prosjektet, valgte gruppen å

benytte seg av den klassiske fossefallsmetoden som prosessmodell.

Denne metoden har både fordeler og ulemper. Den primære ulempen med denne metoden blir

hevdet å være at det er vanskelig å finne feil man gjør underveis, og at kunden lett kan bli

sittende med et produkt som ikke var det han hadde tenkt i utgangspunktet. ”If you do not

actively attack the risks in your project, they will actively attack you” (Gilb, 1998)35. Vi vurderte

derfor dette opp mot en mer iterativ utviklingsmetode, som drar kunden mer med i hver av de

avsluttende iterasjonene. Denne metoden har blitt særlig aktuell og populær de senere år med

Rationals innføring og promotering av RUP (Rational Unified Process). Vi avgjorde at så lenge vi

hadde en av oppdragsgiverne i gruppen vår, og som en av utviklerne, var risikoen for å til slutt

havne på tvers av kundens ønsker liten. I tillegg fant vi det praktisk å parprogrammere et stykke

ut i prosessen. Parprogrammering er som kjent et element innen XP – Extreme programming, som

er en annen type utviklingsmetode.

GJENNOMGANG AV DATAMODELL

To av medlemmene i gruppa fikk gjennomgått og demonstrert implementasjonen av

datamodellen for det spillet som i denne omgang var aktuelt for implementasjon på en mobil

klient. Dette ble utført sammen med utvikler Ole Martin Halck hos Quiz Park, som har kodet pc-

versjonen i programmeringsspråket Smalltalk. Som tidligere nevnt består pc-versjonen av flere

ulike spillvarianter, og kun en av disse ble valgt for implementasjon. Det var spillet 20 spørsmål,

som enkelt og greit består i at en spiller får svare på tyve spørsmål i rekkefølge, med fire

svaralternativer til enhver tid. I pc-versjonen kan antall svaralternativer variere mellom to og åtte,

men av hensyn til plass og ønske om konsistens utseende på en liten skjerm, vil mobilversjonen

alltid ha fire svaralternativer. Det betyr at spørsmålspakker antagelig må spesialdesignes for

18

mobile klienter, men dette må uansett på grunn av andre begrensninger. Antall tegn i et spørsmål

og svaralternativene må for eksempel ikke overstige en viss lengde for å kunne fremvises alt på

en gang. I tillegg var det spesifisert at intet spørsmål skulle stilles mer enn en gang. Når spillet

gikk tomt for spørsmål, var det ønskelig at det ble mulig å installere nye spørsmålspakker trådløst.

Vi forsøkte å ivareta datamodellen så langt det lot seg gjøre, for å kunne legge til rette for mulige

senere implementasjoner av mer komplekse spill som finnes i pc-versjonen av spillet. En mulig

kryptering av spørsmålspakker ble nevnt, men ikke valgt å implementere i denne omgang.

DEMONSTRASJON AV PC-SPILL

Forut for gjennomgang av datamodellen var det naturlig å få en demonstrasjon av selve spillet, for

å få en følelse av hvordan det fungerte i praksis. Da Tore Dahl har vært med på å utvikle pc-

versjonen, og derfor kjente den godt fra før, var dette viktigst for den siste av programmererne,

Ove Kristensen. En liten hands-on gjennomgang av de fleste delspillene som finnes ble utført.

Spillet har i dag en GUI som er svært enkel, da spillet som tidligere nevnt ikke er ferdig utviklet

ennå, og GUI-et har ikke vært høyt prioritert. Det er enkelt og funksjonelt, og består ganske

enkelt av et skjermbilde delt opp i hovedsakelig en stor boks for spørsmål, og flere mindre

bokser for et varierende antall svaralternativer.

SPØRSMÅLSPAKKER

Med hensyn til spørsmålspakker med spørsmål av passe lengde for fremvisning på liten skjerm, så

laget vi ganske enkelt nye subsett av spørsmålene i Microsoft Excel. Ved å sortere spørsmålene

etter spørsmålslengde, kunne vi bare fjerne spørsmål med for lang lengde, og så gjenta prosessen

på svarsiden. En annen variant kunne vært å forsøke å omformulere og korte ned

spørsmålslengden, men dette ble ansett som for tidkrevende og ikke så viktig for oppgaven. Det

bør nok likevel vurderes for fremtiden, da en risikerer at en god del spørsmål går tapt på grunn

av sorteringen.

PROGRAMMERING

For selve programmeringen benyttet vi en iterativ metode, hvor vi både programmerte modulene

hver for oss og som parprogrammering. Modulene ble senere koblet sammen til en applikasjon.

Vi fordelte derfor oppgavene der det var mulig, og løste disse hver for oss, som for eksempel

nettverksoverføring og lagring av spørsmålspakker, og koding av selve klassestrukturen i henhold

til datamodellen. I de tilfeller hvor oppgavene virket å være av mer kompleks art, gikk vi sammen

og praktiserte parprogrammering. Denne formen er velegnet for å løse oppgaver hvor en må

treffe en del valg som er bestemmende for senere utvidelser. Arbeidsformen fungerte veldig fint

19

også for dette prosjektet. Programmererne støtte naturlig nok på en del tekniske problemer

underveis i selve kodingen, og noen av disse problemene beskrives i neste kapittel.

Vi valgte å programmere all kode på nytt, fremfor å forsøke å ”oversette” Smalltalk-koden. Dette

henger sammen med at datamodellen var rimelig klar, og at det ikke ville by på store problemer

å reimplementere denne hurtig. Det tok likevel en del til å lære seg verktøyet og syntaksen

innenfor rammeverket J2ME/MIDP, og vi valgte etter hvert å se bort fra grafiske elementer. I

stedet programmerte vi applikasjonen slik at spørsmål ble vist øverst på skjermen, og svarene ble

vist i en flervalgsliste som ble styrt via tastaturet. Dette viste seg å fungere fint. Vi sørget for at

svaralternativene ble randomisert, slik at ikke det korrekte svaret ble vist på samme sted i lista

hver gang. Videre kodet vi det slik at ingen spørsmål ble stilt mer enn en gang, slik det var

spesifisert i modellen. Grensesnittet på mobiltelefon ble seende slik som avbildet under.

Grensesnitt quizspill på emulator

UTVIKLINGSUTFORDRINGER

Nå vi først hadde blitt kjent med verktøyet Wireless Toolkit gikk selve programmeringen relativt

smertefritt. Enkelte problemer oppsto likevel underveis, som hvordan man skulle lagre

informasjon lokalt på klienten. I pc-versjonen løses dette enkelt ved å bare dumpe all

informasjonen i tekstfiler, men dette var ikke uten videre mulig på mobiltelefoner. Til det formålet

måtte vi benytte RMS – Record Management System, som er et persistent filsystem for lagring

20

innenfor MIDP rammeverket. RMS fungerer som en enkel database, som det er mulig å lese og

skrive fra/til, og dessuten sortere og søke etter data med. Data lagres som poster med en unik id,

som dermed inntar rollen som en primary key i en database. Det hele er implementert som en

RecordStore-class med flere tilgjengelige metoder som getRecord(), addRecord() osv. RMS viste

seg relativt behagelig å bruke, og voldte ingen større problemer.

Når det gjaldt å kjøre den kompilerte koden, forsøkte vi å utføre dette på både den medfølgende

emulatoren i Wireless Toolkit, samt egne mobiltelefoner. Det viste seg da at selv om når

applikasjonen virket fint på en emulator, så var det ikke gitt at den uten videre også ville gjøre

det på en mobiltelefon. Vi erfarte da også flere problemer med å kjøre applikasjonen på egne

enheter, uten at det var noen opplagt grunn til hvorfor det ikke virket slik som på emulatoren. I

andre tilfeller var det enklere å finne årsaken. For eksempel hvis koden var kompilert som MIDP

2.0 i stedet for den eldre 1.0, så ville den virke kun på Sony Ericsson P900, men ikke den

foregående modellen P800. Siden det kun finnes et fåtall modeller som kan kjøre 2.0 i dag var

dette et viktig moment å bli klar over. Problemene med overgang fra emulator til ekte vare viser i

grunnen også bare at Java-applikasjoner ikke uten videre kan kjøres uansett plattform, men at

lokale tilpasninger ofte må til. I praksis betyr det for oppdragsvier også at for en applikasjon som

skal selges må en oppgi alle de ulike navngitte modeller som programmet har blitt testet på, slik

at man er sikker på at en eventuell kunde får noe som virker for hans eller hennes modell.

Fordi problemstillingen ikke var så aktuell verken for å kunne kjøre applikasjonen på emulator

eller våre egne enheter, unnlot vi å foreta en lokal sjekk på klienten på om det faktisk var plass til

å installere en ny spørsmålspakke. Dette må selvsagt gjøres for å unngå at eventuelle kunder får

problemer under installasjon.

TESTING

På dette området fikk vi ikke gjort så mye som ønsket. Applikasjonen slik den er i dag er ikke så

robust som ønskelig, og dette arbeidet må fullføres av Quiz Park. Vi fikk heller ikke tid til å teste

ut spillet på andre personer, noe som kunne vært interessant. I forhold til den skisserte

fossefallsmodellen kom vi ikke helt i mål med prosjektet, med evaluering og vedlikehold som

gjenstående faser.

BESKRIVELSE AV NETTSTED

”On a small screen, users will be able to access the information only one object at a time. Their

satisfaction with the experience is determined by how well the user’s expectations are fulfilled” –

J.Hjelm36

21

Det er ønskelig å implementere en design for et nettsted, hvor brukeren kan få mulighet til å laste

ned nye spørsmål. Som tidligere nevnt er spillet av en slik karakter at man ikke skal kunne få

samme spørsmål om igjen, uten å be om det eksplisitt. Årsaken til dette er at spillutviklerne

ønsker å fjerne en svakhet som finnes i tilsvarende spill, nemlig at spørsmål trekkes ukritisk fra en

bunke, og etter at det har blitt besvart, legges tilbake i den samme bunken. Dermed har stilte

spørsmål en like stor sjanse som ikke stilte spørsmål til å bli brukt neste gang. Det er kjedelig for

en bruker å svare på de samme spørsmålene igjen og igjen, og derfor er spillet designet slik at

dette ikke skal skje. Det medfører naturlig nok igjen til at det før eller siden går spillet tomt for

installerte spørsmål. En bruker vil da kunne ønske å få nye spørsmål, og det er altså i denne

forbindelse at en nettjeneste er aktuell. Dette vil til slutt også være implementert som en

betalingstjeneste. Ingen av delene er direkte fokus for dette prosjektet. Vi beskriver likevel et par

aspekter ved et slikt nettsted. Dette henger sammen med at opplevelsen og nytteverdien av dette

et slikt nettsted nesten helt og holdent vil være på mobilbrukerens premiss, slik innledningen på

kapittelet skisserer.

En enkel løsning vil være å kun ha en standard nettsted, som aksesseres med en vanlig

datamaskin. Men senere er det ønskelig å kunne legge til rette for at brukeren skal kunne laste

ned nye spørsmål hvor som helst, direkte til klienten, uten å måtte gå via en pc. Dette vil gi full

mobilitet i forhold til brukeren, som i praksis kan sitte på bussen og hente nye spørsmål, så fremt

han har en Internett-forbindelse til klienten. Dette er ønskelig fra brukerens ståsted, av den enkle

grunn at han eller hun kan gå tom for spørsmål når som helst og hvor som helst også, ikke bare i

nærheten av en pc. Vi har fått i stand å hente en slik pakke fra nett, og å installere pakken på

klienten slik at den kan benyttes i spillet.

Det finnes kommersielle aktører som tilbyr betalingstjenester, slik at man slipper å implementere

slikt selv, noe som er ønskelig siden det er høye krav til sikkerhet for betalingstjenester. Vi ønsket

i utgangspunktet også å foreta en undersøkelse om hvorvidt slike kommersielle tjenester også

finnes for mobile løsninger, men har nedprioritert dette i forhold til annet arbeid. I stedet blir

dette en oppgave innunder fremtidig arbeid.

En kortfattet og målrettet nett-tjeneste er tilstrekkelig for kunder slik som Jonas i scenario 2. Men

hva så i en annen setting med brukere slik som de to familiene i scenario 1? Nemlig de som ikke

allerede er kunder ved at de allerede har installert applikasjonen på sine enheter, men som er på

jakt etter den og ikke på spørsmålspakkene. Disse brukerne vil ha helt andre krav til presentasjon

enn eksisterende kunder. De vil ønske å få vite hva de får, før de går til innkjøp, for å kunne

vurdere verdien av det de får i forhold til kostnad. For dem ville en grafisk design som simulerte

hvordan spillet ville ta seg ut på deres enhet være interessant, i tillegg til hva slags type spill som

22

finnes, og hvor mange spørsmål som var inkludert. Dermed bør nettstedet ha to relativt ulike

designer, en for nye og en for gamle kunder.

I en mobil sammenheng er det uansett den logiske interaksjonen som er den viktigste, ikke

grensesnittets utseende. Undersøkelser viser da også at brukere bryr seg mer om innhold enn

design37 For den eksisterende kundemassen kan en kort beskrivelse av antall spørsmål og

kategorier kunne være tilstrekkelig. For nye kunder stiller det seg annerledes. De vil kunne ønske

å vite både hvordan selve spillet tar seg ut på telefonen, i tillegg til informasjon om innholdet.

Med begrenset plass bør denne informasjonen være så konsis som mulig. Det er selvsagt mulig å

spre den over flere skjermbilder, men det er viktig å sørge for at brukeren ikke navigerer seg bort

underveis. Designen gjøres ikke for å få det til å se pent ut, men for at det skal fungere for en

bruker med et bestemt mål i sinne. En mulig løsning for å oppnå en konsistent brukeropplevelse

er XML-kodete38 data hvor man med stilsett i XSLT kan lage maler for visning på ulike mobile

enheter.

23

FREMTIDIG ARBEID

Når den endelige pc-versjonen blir ferdigstilt, er det en del arbeid som kan utføres. Det som for

eksempel kan være ønskelig å utføre, er ferdigstilling av et nettsted som beskrevet tidligere. Her

skal det være mulig å laste ned hele spillet i tillegg til nye spørsmålspakker, implementert som en

betalingstjeneste. Per i dag er det implementert en teknisk løsning på klientsiden, som gjør at det

er mulig å laste ned og installere nye spørsmålspakker sømløst via GPRS. Det er mulig at det må

gjøres noe mer på klientsiden i forhold til å kunne utføre betaling, men det er ikke sikkert at

dette nødvendigvis må inngå som en del av applikasjonen. Utover dette bør det utføres en

undersøkelse omkring hvordan en betalingstjeneste over mobiltelefonen kan implementeres, og

om man eventuelt bør kjøpe slike tjenester fra en tredjepart.

Det er også aktuelt å portere andre spill som finnes implementert i pc-versjonen. Disse spillene

inkluderer elementer som fordrer en mer utførende grafisk fremvisning: synkende søyler som skal

illustrere tap av tid i spill hvor dette er en faktor. Spill hvor man får poeng gradert etter hvor

nærme man er svaret, og som benytter komponenter som slidere m.fl.

Videre er det ønskelig å kode en krypteringsmodul for å skjule spørsmålsstrukturen helt. Dette

var ikke en oppgave for dette prosjektet, men er ønskelig i en kommersiell versjon. Dette er for å

hindre at spørsmålspakker kan brukes i andre applikasjoner enn Quiz Parks.

24

KONKLUSJON

Alt i alt er prosjektet å anse som vellykket, samtidig som det kunne vært gjort mer på flere

områder. Vi lykkes i å kode en prototyp som følger datamodellen nært. På den annen side kunne

vi gjort mer med hensyn til den grafiske utformingen. Dette arbeidet ble etter hvert nedprioritert

til fordel for å få en prototyp som faktisk virket som tiltenkt. Dette fikk vi derimot til, og fikk

dermed oppfylt en primær motivasjon, nemlig å lære mer om programmering for mobile enheter.

Denne enheten virker som spesifisert, ved at den viser spørsmål og svar for spilleren. Prototypen

skiller seg fra pc-versjonen ved at den viser spørsmålet som normalt, men svaralternativet vises i

en flervalgsliste i stedet for i bokser. Brukeren velger så foretrukket svar ved hjelp av tastaturet på

telefonen. Han eller hun får tilbakemelding for hvert spørsmål om hvorvidt svaret var korrekt eller

ei. Etter endt spill vises en liten statistikk med antall riktige av antall mulige. I tillegg fikk vi til å

laste ned og installere nye spørsmålspakker trådløst til klienten. Vi fikk også tilegnet oss nyttig og

interessant kunnskap omkring spill og mobilitet, både som begrep og konsept. Gruppen synes

dette har vært en engasjerende og lærerik prosjektoppgave.

25

REFERANSER

1 http://komplett.no/k/ki.asp?sku=121108&cks=PRL

2 Masao Kakihara & Carsten Sorensen: Expanding the 'Mobility' Concept, 2001. SlGGROUP Bulletin December 2001 Nol 22, No.3. masao.kakihara.com/papers/Kakihara&Sorensen_SIGGROUP.pdf

3 http://www.stavangeravisen.com/art.asp?art=16967

4 http://www.ssb.no/samfunnsspeilet/utg/200201/11/art-2002-02-28-01.html

4 Umble DZ : The Amish and the telephone (chapter 1), In Consuming technologies, media and information in domestic spaces. Silverstone R and Hirsch E (eds.). London, Routledge, www.amazon.com/exec/obidos/tg/detail/-/0801863759/qid=1075393125/sr=1-2/ref=sr_1_2/102-5399714-1596950?v=glance&s=books

6 http://www.vg.no/pub/vgart.hbs?artid=220388

7 http://en.wikipedia.org/wiki/Video_game#Video_game_market

8 http://www.quiz-park.com/index.php

9 Smalltalk, http://www.smalltalk.org

10Huizinga,J.(1950). Homo Ludens: a STUDY OF THE PLAY-ELEMENT IN CULTURE. Boston:The Beacon Press.

11 Steinaldermenneske ,http://www.hf.uio.no/iakk/roger/lithic/NORSK%20SARC/sarcN.html

12 http://en.wikipedia.org/wiki/Game_classification

13 William Higinbotham , http://www.forskning.no/Artikler/2004/mars/1077822052.02, 2004-04-17

14 http://en.wikipedia.org/wiki/History_of_the_video_game

15 For i utgangspunktet var tenåringene de toneangivende i bruk av dataspill. I dag er bildet blitt litt forandret både som en følge av av de unge er blitt eldre men også som en følge av at bruk av data er blitt mer vanlig.

16 IDC -03.Wedbush Morgan Securites. ARC Group

17 http://www.videogamebible.com/Articles/System%20Overviews/microvision.html

18 http://en.wikipedia.org/wiki/Video_game

19 Silberman S: Just say Nokia, 1999. Wired magazine

20 WML, Wireless Markup Language.

21 http://www.wired.com/news/print/0,1294,38333,00.html, 2004-05-01

22 ’i’ i ”imode” står for internet- informasjon –interaksjon- og jeg.(eller i som de sier på nordmøre.

23 http://en.wikipedia.org/wiki/IMode

24 GPRS, General Packet Radio Service

25 Bradley J. Rhodes, Nelson Minar and Josh Weaver ,Wearable Computing Meets Ubiquitous Computing , Reaping the best of

both worlds, http://www.bradleyrhodes.com/Papers/wearhive.html

26 Mingers, J: Embodying information systems: the contribution of phenomenology, 2001. Information and organization 11.ACM

26

27 J.Hjelm: Designing Wireless Information Services, s10

28 http://en.wikipedia.org/wiki/Television

29 Masao Kakihara & Carsten Sorensen: Expanding the 'Mobility' Concept, 2001. SlGGROUP Bulletin December 2001Nol 22, No.3

30 http://www.wired.com/wired/archive/7.01/amish_pr.html

31 Symbian, http://www.symbian.com/

32 Gamefederation,www.gamefederation.com/products.htm, 2004-03-19

33 Itavisen,www.itavisen.no/art/1297970.html, 2004-03-20

34 http://mindprod.com/jgloss/pocketpc.html

35 Gilb, Tom (1998): Principles of Software Engeneering Management. Harlow, UK: Addison-Wesley, 1998, p. 73.

36 Hjelm, Designing Wireless Informartion Services, s45

37 Hjelm, Designing Wireless Information Services, s 65

38 W3C/XSLT 1999 ,World Wide Web Consortium (W3C), D. Petter (red.), «XSLT Transformations (XSLT) Version 1.0» , 1999http://www.w3.org/TR/xslt [2004-03-20]