MonstroCity Ett positionsbaserat MMORPG spel

Transkript

1 MonstroCity Ett positionsbaserat MMORPG spel Johan Afseer Andreas Bjerkeholt Peter Lundberg Hans Andersson Otto Kahne Alexander Nordh 17 maj 2009

2 Sammandrag Vårt projekt har varit att utveckla ett mobilspel som utnyttjar positioneringsteknik för att förstärka spelupplevelsen. Spelet var ett äventyrsrollspel i en storvärld med multipla användare och hade ett Sci-fi tema. I vårt arbete nyttjade vi verktyg XX, YY och ZZ för att skapa både en server och en mobilklient för spelet... Abstract The aim of this project was to develop a mobile game to 3:rd generation mobile phones that utilises positioning technology to enhance the player experience. Sida 2 av??

3 Förord Detta är ett kandidatarbete i Datorteknik vid institutionen för Data och Informationsteknik, Chalmers tekniska högskola. Vi har samarbetat med Nokia och vill tacka för det generösa lånet av mobiltelefonerna som gjort det möjligt att testa vårt spel. Vi skulle vilja tacka Anders Mårtensson, Anders Qvist och Leif Ryd för idéen till Monstro- City [?]. Vi vill tacka vår handledare Sus Lundgren som har varit ett stöd i det vi visste minst om, men också vår andra handledare Staffan Björk. Vi vill också tacka för alla tips och hjälpsamma kommentarer som vi har fått på vägen. Våra examinatorer Peter Lundin och Christer Carlsson. Sida 3 av??

4 Innehåll Sida 4 av??

5 1 Inledning Spel i digital form är en ständigt växande marknad och är nu en etablerad del av underhållningsbranschen. Under årens lopp har spelen utvecklats i takt med tekniken och nya tekniker har gett möjligheter för nya idéer till att spela på. Ett tydligt exempel på senare år där sättet att spela ändrats radikalt är Nintendos senaste konsol Wii, där fokus har varit på kontrollsystemet och att få spelarna mer aktiva i sin interaktion i form av mer rörelser under spelandet. En ny teknik som vuxit fram på senare år och nu blir allt vanligare i bärbara produkter, och främst mobiltelefoner, är GPS-positionering där man med hjälp av satteliter kan se var man är på en karta. Detta öppnar upp nya möjligheter för att få fram en unik spelupplevelse där spelet kan få en medvetenhet var i världen man är och spel där man tar sig från en plats till en annan i verkligheten kan reflekteras i spelvärlden. Då detta är en ny teknik finns det ännu inte många spel som utforskat dessa möjligheter. Vårt arbete har gått ut på att utveckla just ett sådant spel. Med vårt spel ville vi utforska möjligheterna med dagens GPS-teknik i just mobiltelefoner där man enkelt ska kunna ansluta sig till en spelvärld där det har betydelse var man är någonstans. Spelet har utvecklats från grunden och involverat delar som speldesign, där vi fått en inblick i alla aspekter man behöver tänka på före man sätter igång med att skapa ett spel. Utöver det har vi fått nyttiga erfarenheter vad gäller nätverkskommunikation, där bland annat design av ett nätverksprotokoll och skapandet av klient och server ingått. Vi har även bekantat oss med, vad som för oss var, ett nytt programspråk, i form av Python. 1.1 Syfte Syftet var att skapa ett spel som vi kände oss nöjda med, med andra ord ett spel som vi själva tyckte var roligt att spela. Spel skulle innehålla element av socialt utbyte mellan spelarna, i form av både samarbete med, och tävlan mot, andra. Alltså krävdes både incitament till och möjligheter att sätta sitt spelar-alter ego i relation till andra. Spelet skulle även ha ett genomgående tema som vi kunde arbeta utefter i övriga delar av designen. Därtill följde ett medryckande stridssystem som skulle vara både roligt och balanserat. För att skapa motivation för spelaren skulle spelet ge möjligheter att utveckla ens spelkaraktär på något vis. Förutom strider ville vi även att spelet skulle erbjuda spelarna uppdrag att utföra. 1.2 Avgränsning För hela projektet har vi låtit mobiltelefonernas inbyggda funktioner hantera alla GPSberäkningar, att göra något eget skulle varit ett väldigt omfattande arbete, kräva omfattande ämnesstudier och inte nödvändigtvis blivit bättre än vad som nu fanns att tillgå. Denna avgränsning har möjliggjort för oss att fokusera på speldesign och att implementera positio- Sida 5 av??

6 neringen. Projektet har gjorts för att undersöka positionering i spel och vad det kan innebära varför många saker som vanligtvis skulle höra till att utveckla ett stabilt spel inte har behandlats t.ex. användartester, eftersom spelet aldrig var innehållsrikt för att vara lockande för testare. Omfattande utveckling av innehåll, då vi såg det mindre relevant för våra undersökningar har spelet inte fyllts med en stor mängd olika utrustningar, olika typer av monster eller många viktiga platser på kartan; Stresstester, vi har aldrig haft möjligheten att ha ett stort antal spelare i spelet samtidigt, skulle detta ha blivit en kommersiell produkt hade detta behövts göras; Begränsad karta, då testningen skedde på Chalmers campus Johanneberg begränsades spelytan till detta område varför det inte går att spela utanför, något som skulle ha varit eftertraktat i en faktiskt produkt. Slutligen så har avancerad grafik och avancerade grafiska funktioner aldrig varit prioriterat under projektet, dels för att mobiltelefonerna har begränsad beräkningskapacitet men även för att de hade ökat komplexiteten med en hög grad och för att vi saknade specialkompetens inom området. 1.3 Historik GPS har funnits länge men det är först på senare år som de börjat finna sin väg in i var mans hand... Mobilers prestanda, i form av beräkningskraft, har ökat omfattande och således även möjlighetena man har när man arbetar med mobiltelefoner, på senare tid har detta lett till mera och mera avancerade spel och till att mobiltelefoner utrustas med GPS. Samtidigt har införande av 3G och Turbo-3G lett till större möjligheter för högkvalitativa internetanslutning var man än befinner sig. Teknologins utveckling har därmed sakta lett till möjlogheten att skapa positionsbaseradespel. Ett exempel på ett spel som använder denna tekniken är Geocaching. I detta spel så gömmer man undan en behållare innehållande en penna, loggbok och något annat föremål. Andra spelare får sedan försöka hitta denna via koordinater som angivits av spelaren som gömt behållaren på Internet. När en spelare väl hittar den får han skriva ner sitt namn i loggboken och byta ut någon av de andra sakerna i lådan. [?]. Detta är ett väldigt simpelt positionsbaserat spel, som bara använder GPS och något sorts forum. Det kräver ingen specifik applikation mer en GPS applikationen på telefonen, vilket det spel vi arbetat med gör. Tidigare Pervasive games Sida 6 av??

7 1.4 Slutprodukten I slutändan av projektet har gruppen skapat ett spel som spelas på användarnas mobiltelefoner där deras position i den verkliga världen avgör deras position i spelet. Spelarna kan slåss mot monster och strida mot varandra där vinnaren avgörs av spelarna utrustning, nivå och grundvärden. Allt detta hanteras i servern som håller i spelmodellen och via spelarna mobiltelefoner som fungerar som spelarna kommunikationsverktyg med modellen. En del av slutprodukten är en applikation som kan köras på Nokias 6210 Navigator telefoner. Detta kräver dock att man har PyS60 installerat. Slutprodukten består också av en server, skriven i Java, samt en databas skriven i MySQL. Detta system som skapas av de olika delar gruppen framställt är den produkt som lyckats framställas. Sida 7 av??

8 2 Metod 2.1 Hur vi arbetade För att skapa mjukvaran har gruppen utvecklat iterativt. Många delar av projektet gick att arbeta individuellt med, och andra behövde kopplas ihop, därför har gruppen arbetat både individuellt och i grupp. Grupparbete skedde mest när kod mellan server och klient eller bara kod mellan olika klasser behövde kopplas ihop. Gruppen delades tidigt in i en halva som lärde sig Python och dess syntax och hur mobilen fungerade för att kunna skriva klienten, samt en halva som specialiserade sig på, servern och databasen som skrevs i Java och MySQL. 2.2 Använda verktyg Den första gången gruppen träffades bestämde vi genast hur vi skulle kunna kontakta varandra. Därefter lämnade alla ut sina mailadresser, samt annan kontaktinformation som kunde vara viktig. Det sattes upp en Wiki-sida där alla möten skrevs upp, tillsammans med all annan text gruppen skrev inom alla tänkbara delar av projektet. Dessa innefattade allt från spelidéer till tidsloggar. Gruppen har även använt andra medier för att föra kontakten mellan varandra via bl.a. MSN, SMS och mobiltelefoner. För att hantera all den data vi delat, som inte har varit informativ text, har vi använt SVN (Subversion), som sparar revisioner av allt arbete i olika versioner vilket tillät gruppen att arbeta parallellt och ha en uppdaterad version av alla delar av projektet hela tiden. SVN gjorde det även möjligt att återgå till en tidigare revision om det visade sig att nyinförd kod inte fungerade. Gruppen valde att använda sig av Googles Subversion-tjänst vilket gjorde att projektet med dess källkod har funnits öppet att skåda för allmänheten då detta är ett krav från Google för att använda dess tjänst. Vissa i gruppen har använt olika hjälpmedel för att förenkla användningen av SVN på deras lokala datorer i form av Tortoise och NetBeans. Koden har skrivits i två olika språk, Java och Python, eller mer specifikt, PyS60 som står för Python för S60-telefoner. För utvecklingen i Python användes först en emulator från Nokia vid namn S60 Emulator, eftersom gruppen då ännu inte fått tillgång till egna telefoner att arbeta med. Denna emulator fungerade för att göra det mesta, men kunde självklart inte emulera saker som vibrationer eller framförallt GPS. Klientsidan av gruppen använde sig av olika textredigeringsprogram såsom GEdit och Notepad++, som innehöll stöd för syntaxhilight för programmeringsspråk som gjorde det lättare att överskåda koden. Utvecklingen av Java för servern har skett genom utvecklingsmiljön Netbeans. De flesta i gruppen har haft egna bärbara datorer vilket medfört att mycket av arbetet kunnat utföras tillsammans i grupprum där man kunnat ha de andra till hands för oklarheter och frågor. En gemensam Google Calender startades men användes inte i någon större utsträckning. 2.3 Planering Gruppen har arbetat mot deadlines som lades ut tidigt för att sedan justeras efter hand när bilden blev klarare över hur mycket tid det tog att utfärda vissa delar. Dessa visades på Wikisidan som nämns i Använda verktyg. På Wiki-sidan fanns också alla möten, samt vad för Sida 8 av??

9 typ av möte det var. Högpriomöte, arbetsmöte och handledarmöte var de tre huvudsakliga mötestyperna. Efter bilden blev klar över hur slutprodukten skulle se ut sattes det olika prioritet på alla delar av spelet. Grundläggande saker såsom att kunna starta upp spelet och koppla upp sig mot en server och att kunna utföra någon form av strid fick högsta prioritet medan andra saker såsom möjligheten att kunna utföra uppdrag, få erfarenhetspoäng och spelsessioner där vinnare utses hade lägre prioritet. Målet var att hålla det så simpelt som möjligt tills en stabil grund byggts innan extrafunktioner lades in. Eftersom att gruppen bestod av 6 gruppmedlemmar har det ibland varit svårt att planera möten där alla haft möjlighet att medverka. Detta på grund av att många i gruppen har haft minst en annan kurs som pågått parallellt med kandidatarbetet. 2.4 Litteraturstudier En av de få litteraturstudier som gjorts har handlat om tidigare positionsbaserade spel. Detta för att få information om vad dessa spel har haft för tekniska problem, vilket hade kunnat förenkla gruppens arbete och ge insikt i vad för problem som kan uppkomma. Det gav också insikt i vad för andra spelidéer som genomförts på samma område. Dessa har sedan kunnats jämföras med den egen spelidén. Gruppen gjorde även en del litteraturstudier inom olika sorters positioneringstekniker. Detta eftersom det var ett val som var av stor vikt för projektet. Ett dåligt val av positioneringsteknik hade kunnat begränsa speldesignen eller göra spelet otillgängligt för många spelare. Det slutgiltiga valet föll till slut på GPS, men även Triangulering diskuterades. Sida 9 av??

10 3 Speldesign I detta kapitel behandlas själva designen av spelet med de problem det medför. Olika förslag och möjligheter tas upp och hur det skulle påverkat slutprodukten och sedan en motivering till varför designvalen blev som de blev. 3.1 Vision Vår vision var att skapa ett spel som skiljer sig från traditionella dator- och mobilspel genom att införa rörelse. När spelaren slåss i spelet mot andra spelare och monster ska man behöva röra på sig för att gå segrande ur striden. Dessutom ska rörelse ingå på andra sätt, då spelaren kan tvingas ta sig till vissa platser. Vårt mål var att spelet ska vara roligt, det ska vara fördelaktigt att gå samman med andra spelare och bilda lag, men det ska samtidigt fungera och vara roligt att spela ensam. Spelaren ska vara driven att återkomma till spelet för att utveckla sin karaktär och delta i tävlande mellan spelare. På grund av det stora fokus på rörelse är det viktigt att spelaren ska behöva titta på skärmen så lite som möjligt. Eftersom spelet utspelas i staden så skulle risken för olyckor i trafiken vara större om det vore ett spel där spelaren aktivt behövde trycka på knappar under t.ex. strid. Spelet ska kunna spelas på så sätt att spelaren inte behöver väcka oönskad uppmärksamhet. 3.2 Spelmekaniker Användning av positionering Positioneringen används för att avgöra var i spelet man befinner sig. I strid används positioneringen endast till att räkna ut om spelaren eller den spelaren attackerar är inom räckhåll för varandra så de kan utdela skada. Ursprungligen var det tänkt att positioneringen skulle användas för att mäta förflyttningen mellan varje period för att kunna räkna ut chansen att väja för skada. Ju mer spelaren förflyttar sig, desto större chans är det att spelaren undviker att bli träffad. Då tekniken för att bestämma positionen inte är tillräckligt exakt eller responsiv för att på ett rättvist sätt kunna använda ett sådant stridssystem fick idén skrotas. Tanken var också att positioneringen skulle användas till att bestämma om uppdrag har utförts genom att dom förflyttat sig till en specifik plats definierat i uppdraget men det blev inte implementerat i brist på tid Spelsession En viktig fråga för spelet var när en spelomgång slutade, om den slutade överhuvudtaget, och om det skulle finnas vinnare och i så fall hur denna skulle utses. Dessa beslut var otroligt viktiga för hur spelet i slutändan skulle spelas. Korta spelsessioner Sida 10 av??

11 Ett alternativ var att hade kortare spelsessioner där man möttes på en i förhand angiven plats och spelade under en kort men intensiv tid på allt ifrån ett tjugotal minuter till flera timmar innan en slutgiltig vinnare utsågs. Denna idé hade fördelen att man på förhand kunde anordna större spelträffar och få en intensiv spelstund. Spelet skulle då bli ganska simpelt, man skulle lära sig det fort och grunden skulle då bli det sociala umgänget. Spelet skulle riskera att brista i variationen och till slut bli enformigt. Det hade sedan tidigare bestämts att spelarna skulle få belöning och kunna bygga på sin spelkaraktär allteftersom. Även om detta kunnat göras med kortare spelsessioner då man kunde få belöning efter varje avklarad session skulle det bli väldigt begränsat då en som spelade ofta skulle få stora fördelar mot en som spelade mindre ofta och spelet skulle bli svårtillgängligt för nya spelare då de i största del bara kunde spela mot varandra. Fortlöpande Ett annat alternativ var att låta spelet fortlöpa hela tiden och ha topplistor över bland annat dödade monster och hur det gått i möten med andra spelare som spelare kunde följa. En stor nackdel med detta var att de som kom i kontakt med spelet tidigt skulle få en stor fördel mot människor som började spela i efterhand och allt eftersom tiden gick skulle spelet bli mer och mer svåråtkomligt för nya användare. Detta är något som skulle kunna lösas med spelzoner där vissa områden var svårare och andra lättare men det skulle begränsa tillgängligheten då alla spelare skulle få ta sig till specifika områden för att kunna spela vilket skulle ta bort en del av möjligheten för en spelare att ta upp och spontanspela på vägen till affären. En stor del av spontaniteten riskerade att gå förlorad. En annan idé skulle vara att världen delades in i olika nivåer där man enbart såg andra spelare som låg ungefär på samma nivå, mötte passande monster och fick uppdrag som passade till spelarens nivå. Detta skulle dock begränsa spelvärlden och det skulle krävas en väldigt stor användarbas för att det inte skulle bli ödsligt där flera spelare sprang omkring för sig själva och sannolikheten för att träffa på en annan spelare av en slump när man var ute och gick på stan skulle minska. Månadsbaserat spelande Till slut valdes en mellanväg där spelet skulle fortlöpa under en månad innan allt nollställdes och en vinnare utsågs. Det gjordes via en topplista för att ranka spelare under spelsessionen. Det gjorde nya spelare som kom in mitt i den förra sessionen fick en chans att placera sig bättre på topplistan då det är en klar fördel att vara med från början av varje spelsession för att få hög poäng. Topplistan är för att främja tävlande mellan spelare och en genväg för oss som spelskapare att inte behöva tillhandahålla unikt material hela tiden för att sysselsätta spelarna utan att lockelsen att vinna gör att de sysselsätter sig själva. Diskussioner fördes även om att belöna segrarna efter en viss omgång genom att ge dem något som visade att de vunnit. Detta skulle inte göra dem starkare i spelet men till exempel en titel som visades hos en annan spelare när den kom i kontakt med en tidigare segrare. Sida 11 av??

12 Då spelet skulle ge möjligheter att spela själv samt spela med andra behövdes ett system som tillät och motiverade detta. Spelaren behövde kunna välja själv om han ville spela mot andra spelare, samarbeta eller spela själv. Därför behövdes framförallt ett stridssystem som fungerade både för ensamt spelande och för flera. Spelaren borde också kunna hindra andra spelare att anfalla om denne inte ville spela mot andra Spela själv Då andra spelare oftast är inloggade i spelet så spelar du aldrig ensam. Man kanske väljer att inte interagera med dom andra spelarna men alternativet finns alltid så länge det finns spelare online. Spelet är fullt spelbart utan andra medspelare då det finns gott om monster att bekämpa på egenhand. Det är viktigt att möjligheten att kunna spela själv finns då det ger upphov till mer spontant spelande genom att man inte måste samla andra spelare. När man spelar själv kommer man inte heller begränsas ifrån spelets huvudmål. Man kan göra allt som man kan göra i grupp men utmaningen är större men likaså belöningen. Man kan fortfarande samla energi för att bli den starkaste, och sedan försöka vinna vid månadens slut. I slutändan är det inte en grupp med spelare som står som vinnare, utan bara en individ Spela i grupp Genom att spela i grupp så gör man spelet mer socialt. Om man förflyttar sig tillsammans kan man kommunicera genom tal som är ett betydligt snabbare och tydligare sätt än att skriva meddelanden genom spelet till varandra. Det öppnar upp nya möjligheter genom att man kan besegra starkare monster och då få mer pengar och xp!!!!!!!!!!!!??????. Det finns inget sätt att officiellt visa andra spelare att man är en grupp då vi inte har infört ett party-system då detta inte är en nödvändigt funktion för att spelat ska vara spelbart utan har blivit bortprioriterat i brist på tid. Om detta hade varit möjligt så hade det gjort det möjligt att ha större slag mellan olika spelargrupper. Detta hade ökat spelarnas tävlings vilja, och på så sätt fått spelarna mer engagerade i att bli starkare genom att döda monster eller varandra. Det hade tagit spelet till en ny nivå där spelarna inte bara skulle behöva tänka på sitt eget bästa men också gruppens Strider Stridssystemet är uppbyggt genom två olika lägen som en spelare kan vara i. Om en spelare är i passivt läge kan denna ej attackeras men inte heller attackera andra spelare. Men är han i aggressivt läge så kan han både attackera och attackeras. Är spelaren i passivt läge och vill övergå till aggressivt så tar detta 30 sekunder. Samma sak gäller för att gå från aggressivt till passivt. Båda fördröjningarna är avsiktliga för att förhindra att folk missbrukar Sida 12 av??

13 övergångarna genom att byta fram och tillbaka i strider. En övergång mellan lägena visas tydligt för påverkade parter. Spelaren har chansen att skada sin motståndare inom en begränsat område kring sig, vilket utgörs av spelarens egna räckvidd vilket inte ska förväxlas med spelarens synvidd. Även om spelaren inte har någon annan spelare inom sin egen räckvidd betyder inte det att denne är säker från attacker då andra spelare och monster kan ha en större räckvidd. Spelaren kan enbart göra skada på ett objekt i taget. Detta sker genom att markera en spelare och välja att attackera det. Själva skadan utdelas i intervaller på fem sekunder och fortsätter tills spelaren väljer ett nytt mål eller går ur attackläget. Detta kan göras självmant, eller på grund av andra anledningar såsom att målet dör. Om det är en annan spelare kan det även avbrytas när denne loggar ut eller byter till passivt läge. Attacken avbryts inte men ger ingen skada då objektet kommer utanför det området som du skadar inom men så fort objektet är tillbaka inom räckhåll så görs skada som vanligt. En attack pågår tills målet är besegrat, spelaren själv blir besegrad eller attacken avbryts. Om det bekämpade objektet är ett monster så får spelaren pengar och xp för sin insats. Om spelaren i sin tur blir attackerad av ett objekt så måste valet bli att attackera tillbaka för att returnera någon skada eller springa utom räckhåll för att komma undan. Alternativa designer på stridssystemet Det fanns många tankar om hur stridssystemet skulle fungera som till slut inte implementerades eller som skrotades av ett skäl eller ett annat. Ett förslag var att spelaren skulle trycka på en knapp på mobiltelefonen för varje anfall. Ganska fort kom avslogs den idén då detta inte var någon bra idé då man blev väldigt upptagen med att trycka på mobiltelefonen och inte kunde ägna lika mycket tid åt att röra sig i verkligheten vilket var ett av grundmålen med projektet. Ett annat förslag var att spelare och monster inte skulle ha en diskret räckvidd utan ett område där skadan bestäms utav en kvadratisk ekvation beroende av avståndet med effekten att det då skulle gå att finna ett optimalt avstånd som man vill befinna sig inom och att det skulle variera för varje fiende man mötte. Vi kända ett systemet var lovande men att det var väldigt tungt att implementera eftersom det, förutom att se till att alla monster gavs passande ekvationer och se till att alla spelare skulle kunna modifiera sin egen kurva på ett smidigt och lättförståbart sätt innebar att en passande visualisering behövde göras och att det hade krävts omfattande balansering av systemet för att få något som inte bara hade en bästa lösning. Ytterligare en idé var ett system för gruppstrid som innebar att spelarna skulle få en bonus på sina attacker om de omringade och anföll ett monster från flera sidor. Bonusen skulle vara beroende på den vinkel som bildas mellan monstret, spelaren och spelarens närmaste medspelare, vilket skulle leda till att man alltid vill placera sig med jämt avstånd mellan sina medspelare och att alla i laget skulle behöva göra sitt yttersta för att positionerna ska vara rätt medan det man slår mot rör sig. Se förklarande figur-??. Ännu mera intressant hade det Sida 13 av??

14 Figur 1: Hur strid i grupp skulle fungerat. blivit om två lag möts då spelarna skulle göra sitt bästa för att försöka omringa det andra laget och samtidigt se till att vara på jämna avstånd från varandra vilket hade medfört att framgång i spelet hade berott på samarbete, koordination och löpskicklighet. Anledningen att detta inte blev implementerat var pga tidsbrist och även brister i tekniken som utgjorde hinder. Framförallt precision och tidsfördröjning från det att man rör sig till det att spelet uppfattar det gjorde detta svårt att genomföra Föremål Föremål i ett spel såsom MonstroCity kan rent konceptmässigt ses som en karaktärs ägodelar i spelvärlden, men rent spelmekaniskt handlar det i grunden endast om utbytbara permanenta eller temporära ökningar av spelkaraktärers spelmekaniska värden. Det är därför inte helt givet att denna spelmekaniska funktion skall kallas för just föremål, även om detta namn är ett vanligt inslag i merparten av de MMORPG som finns på marknaden idag. Föremål är också av den karaktären att de i regel går att hitta någonstans i spelvärlden, alternativt köpas på specifika platser däri. Hur stor roll dessa föremål skall spela för en karaktärs förmåga att vinna strider kan man dock ha ganska skilda åsikter om. Fördelar och nackdelar Den huvudsakliga diskussionen kring föremål i ett MMORPG är inte alltid gällande deras vara eller icke vara, då det ju kan ses som ett ganska kul spelelement att samla på sig saker som på olika vis förbättrar ens karaktär. Möjligheten att hitta eller införskaffa nya föremål, och de valmöjligheter detta ger för ens karaktärsskapande, är också ett gott incitament för att få spelare att vilja fortsätta spela. Dock kan ett brett föremålsutbud göra ett spel mer svårbalanserat, eftersom antalet kombinationer blir många, och det blir svårt för utvecklare att förutsäga hur spelare kommer att hantera dessa kombinationer. Det är också diskutabelt hur svårt det skall vara att hitta de allra bästa föremålen, och hur stor skillnad det skall vara mellan de bästa och de sämsta föremålen. Om spannet är stort kommer föremålen till stor del att diktera hur striderna går, Sida 14 av??

15 vilket kanske inte alltid är önskvärt. Idéer Det framkom under designfasen ett antal alternativ för hur MonstroCity:s föremålssystem skulle se ut. Ett alternativ var ett system där alla en karaktärs förmågor och värden var helt baserade på föremål eller något dylik spelmekanisk funktion med ett annat namn. Övriga alternativ tonade ned föremålens vikt en aning, till förmån för grundvärden som baseras på en spelares karaktärsnivå. Till en början var det tänkt att man skulle kunna köpa föremål i platsbundna affärer, som var relaterade till affärer i verkligheten; något som sedermera frångicks med anledning av beslut om spelkonceptet. Därtill fanns det tankar om att man skulle kunna hitta föremål på de monster som man besegrat, vilket dock inte blev fallet i den slutgiltiga designen. Systemet Slutligen fick MonstroCity ett system bestående av fyra olika sorters föremål vapen, rustning, övriga föremål som man kan bära på sig själv, samt övriga föremål som man måste bära i sitt inventarium (I spelet: Weapon, Armor, Equippables, Non-Equippables). Den sista kategorin, som man endast bär i sitt inventarium är av formen engångsföremål, som försvinner när man använt dem en gång. I ett givet tillfälle går det endast att nyttja ett vapen, en rustning, samt två föremål som går att bära på sig själv. Namngivningen är dock inte på något vis bundet till spelkonceptet i sig, utan speglar enbart vad föremålen har för spelmekanisk funktion. Systemet fungerar också på så vis att det endast är två värden som grundas enbart på föremål det vill säga hur mycket skada man gör när man anfaller någon, och hur mycket skada ens rustning absorberar när man blir slagen. Övriga värden kan modifieras av föremål, men är i grunden beroende av karaktärsnivå. Detta gör föremålen enklare att balansera, men är ändå viktiga för karaktären, samtidigt som de ger spelaren ett visst mått av valmöjlighet. Det var även tänkt att man skulle kunna köpa föremål i en icke platsbunden affär i spelvärlden, för en monetär enhet som man erhåller då man besegrar monster. Själva affärssystemet är dock, av tidsskäl, ännu inte implementerat Quests Quests eller uppdrag är en del som sågs som ganska viktig men inte hann implementeras på grund av tidsbrist. Målet med uppdrag är att spelaren ska dras in mera i spelet genom att spelaren får uppdrag att utföra som leder till olika former av belöningar, de tänkta belöningarna var främst tänkt att vara föremål, erfarenhetspoäng eller i form av den spelinterna valutan men hade även kunna varit titlar eller tillfälliga förstärkningar för spelarens avatar. Designen av uppdrag var att det skulle finnas två typer, personliga uppdrag och globala uppdrag där den avgörande skillnaden skulle vara vilka som kunde avklara uppdragen och om man skulle göra den i tävlan med andra eller ej. Personliga uppdrag skulle vara uppdrag där Sida 15 av??

16 målet var att ta sig till en plats eller besegra ett visst monster medan globala uppdrag skulle ha samma mål men med kriteriet att det skulle vara tillgängligt för alla spelare samtidigt och att bara en eller ett fåtal spelare skulle kunna få belöning för avklarat uppdrag. Med globala uppdrag hoppades vi få till en större mängd tävlan och action i spelet eftersom spelaren behöver agera snabbt för att försäkra sig om att få uppdragets belöning, en annan fördel var att det skulle ge spelaren en anledning att ha spelet rullande eftersom man aldrig kunde veta när ett globalt uppdrag skulle dyka upp brevid sig. Gällande för alla uppdrag är att när uppdraget var avklarat skulle det försvinna från alla spelares lista över aktiva uppdrag. Det övervägdes även att införa eventuella tidsbegränsningar på uppdrag för att undvika att spelet stagnerade pga oavklarade uppdrag men eftersom detta skulle vara en avvägningsfråga som bäst löses med spelartester och data från faktiskt spelande lyckades vi inte komma till någon slutsatts i frågan. Uppdrag skulle, om de hade implementerats, som det mesta andra ligga i modellen och ett antal ändringar hade behövts göras till koden, nätverksprotokollet skulle behövts utökas, quest-objektet skulle behöva kodas och vid varje tidpunkt skulle det behöva kollas om spelare lyckats uppfylla sina uppdrag. Dessutom skulle lämplig modellering för att ge spelarna en visuell representation av uppdragen behöva göras, den tillgängliga kvarvarande tiden ansågs vara för kort och uppdrag lades på is Accelerometer Efter att ha fått igång simpla strider mot slutet av projektet och det blev klart att precisionen och tidsfördröjningen omöjliggjorde en del av idéerna för stridssystemet börjades det titta på lite alternativ för att få striderna mer interaktiva. Då mobiltelefonerna var utrustade med accelerometer övervägdes vissa funktioner där man skulle interagera på andra sätt än knapptryckningar och position. En idé var under strider när någon händelse, till exempel en attack, skulle inträffa skulle telefonen vibrera och man skulle få några sekunder på sig att skaka telefonen för att få ett bättre utfall. Detta alternativ hann dock aldrig ses över närmre utan stannade i idéstadiet. Sida 16 av??

17 3.2.9 Digitala kompassen Då mobiltelefonen är utrustad med en digital kompass försökte vi få fram idéer i början av projektet hur man skulle kunna använda denna i stridssystemet. Orginaltanken var att man med hjälp av kompassen kunde ta reda på åt vilket håll spelaren riktade mobiltelefonen. Detta kunde då användas som ett sikte för att kontrollera om en spelare verkligen siktade mot det målet som han försöka attackera. Men efter övervägning kom det fram att det var väldigt enkelt att missbruka detta då men enkelt kunde vrida och vända på mobiltelefonen som man ville även om man var på väg åt ett annat håll. 3.3 Tema Handlingen utspelar sig i nutid men har ändå lite av ett futuristiskt inslag. Under ett experiment finner forskare av en slump en länk till en parallell dimension. Det enda sättet att nå denna dimension är via GPS-satelliter. Man är inte i den andra dimensionen fysiskt utan man tar en typ av fysisk form i den dimensionen vars rörelser kan styras med hjälp av att förflytta sig själv och sin GPS-applikation. Vid radioskugga tappar man kontakten med sitt alias i den andra dimensionen. Efter många tester och experiment på den parallella dimensionen får forskarna fram att den består av en oändligt stor, ren och lättutvunnen energi. Denna energin är dock bunden i den andra dimensionens invånare och för att ta tillvara på energin krävs att man förkortar invånarnas livslängs avsevärt. Detta väcker stora protester då invånarna har formen av små gulliga kaninliknande varelser också så kallade monster. Men i vår tid då priset på bränsle nått nya höjder börjar folk bli desperata och drar sig inte för att vara omoraliska. Giriga företag hittar en billig och effektiv lösning för att ansluta till den andra dimensionen genom en mobiltelefon. Företagen söker en massa människor som kan hjälpa till att utforska den andra dimensionen och samla energi, så kallade utforskare. Utvinningen av all energi som alla utforskare samlat görs via ett konstgjort svart hål i slutet på varje månad som skapas genom att man utför en form av Armageddon och allt liv i den dimensionen dör ut för att sedan börja växa sig till igen i början av nästa månad. Varelsernas enda försvar är att försöka kasta ut en ur dimensionen genom att störa din signal. När din signalstyrka är noll så dör ditt alias och du måste ladda upp den igen genom att ta dig till en laddningsplats. Även utforskarna har funnit knep för att störa andra utforskares signal och kasta ut dom ur dimensionen, detta för att temporärt minska konkurrensen. För att motivera utforskarna att göra ett bra jobb hålls en topplista över bästa energisamlare i varje månad. När en månad är slut evalueras utforskarnas arbete och den utforskare som samlat ihop mest energi vinner ära och berömmelse. Han kan också känna att han bidragit starkt till att lösa världens energiproblem även om han är medbrottsling i att förstöra en annan dimension. Med pengarna som utforskarna får kan dom köpa bättre utrustning så som skydd mot störningar och apparatur som avger störningar men detta kan göras på speciellt utvalda affärer. Sida 17 av??

18 3.3.1 Designval gällande temat Temat valdes av ett antal anledningar. En av anledningarna var att till exempel ett fantasytema för spelet kändes gjort och att det är mer än en aning överexploaterat. Gruppen kände också att någon form av verklighetsförankring var önskvärt. GPS-positioneringen skulle vara en del av bakgrundshistorien snarare än bara ett kontrollsätt. Det skulle helt enkelt finnas en anledning till att man styrde spelet som man gjorde. Det diskuterades både post-apokalyptisk Sci-fi och kriminellt-tema men det till slut fastnade idén för en nära framtid/alternativ nutidtemat som nämns ovanför. Eftersom det skulle finnas en viss verklighetsförankring behövdes många delar förklaras. Saker som att monstren inte syns i riktiga världen när man möter dem i spelvärlden, att människor som inte har spelet påverkas, att spelaren själv inte blir fysiskt skadad.anledningen till detta kan lätt förklaras med immersion vilket översätts till försjunkenhet och innebär att spelet känns som mera än bara ett spel. Målet var att uppnå ett scenario spelaren kände att dennes deltagande skulle spela roll. Att få spelaren att tänka- tänk om detta är verkligt och det jag gör nu är avgörande vilket skulle ge spelet något av en extra dimension. Således var allt som skulle implementeras tvunget att ha en förklaring rent storymässigt och när grundscenariot var utarbetat börjades det med att försöka få fram en naturlig förklaring för de spelkoncept och idéer som tagits fram såsom spelsessioner och stridssystem. Bland annat återställningen av spelet varje månad och viljan att ha ett erfarenhetssystem som skulle vara relativt överdrivet för människor. Månadsåterställningen förklarades med det svarta hål som krävdes för att föra över energin mellan världar och den accelererade erfarenhetskurvan förklaras med att det inte är spelaren utan spelarens avatar i den alternativa världen som utvecklas. Även brister i tekniken såsom radioskugga från GPS-satelliter när man är inomhus behövde förklaras Alternativa teman I början av projektet uppkom ett flertal idéer om teman att bygga spelet kring. Dom två huvudsakliga idéerna var ett kriminellt tema och ett fantasytema. Det kriminella temat handlade i stort om att man skulle utföra kriminella gärningar för att tjäna pengar och klättra i rang i en kriminell undre värld. Skriv nåt om fantasytemat här... Sida 18 av??

19 4 Teknik & Kommunikation 4.1 Generellt Vilka delar projektet består av... Vilken information som finns i systemet Hur modellen ser ut 4.2 Nätverk Figur 2: Kommunikationen mellan server och klient. En väldigt viktig del av MonstroCity är kommunikationen som sker mellan klient och server. I dagens nätverk används vanligtvis något av de två olika transportprotokollen TCP och UDP. UDP har fördelen att det är ett lättviktigt protokoll, vilket helt enkelt innebär att mindre information behöver skickas på nätverket. Eftersom kostnaden för spelarna i många fall beror på trafikmängden sågs det som önskvärt att hålla trafiken så låg som möjligt. En annan intressant egenskap hos UDP är att det är förbindelselöst, vilket skulle kunna göra hanteringen av ett stort antal klienter enklare för servern. UDP saknar dessvärre felhantering, vilket innebär att paket som försvinner inte sänds om, utan försvinner spårlöst. Det har heller inget system för att ignorera paket som kommer fram så sent att de saknar relevans. TCP är å andra sidan ett mycket pålitligt protokoll, som hanterar omsändning av paket. Slutligen bedömdes det även vara möjligt att UDP-paket skulle fastna i brandväggar, vilket ledde till att TCP var det protokoll som valdes. För en översikt se bild??. För att servern skulle slippa behöva hantera ett mycket stort antal parallella uppkopplingar, trots det faktum att TCP inte är förbindelselöst, byggdes nätverket så att en ny anslutning upprättas varje gång en klient behöver skicka något till servern. En annan anledning till det Sida 19 av??

20 byggdes på det viset var att data skickas såpass sällan, i nätverkssammanhang, ungefär en gång i sekunden. Innan anslutningen avslutas sänder servern dessutom alla uppdateringar som klienten är i behov av. Arbetet påbörjade sedan med att ta fram ett protokoll som klient och server skulle prata för att förstå varandra. En bit in i projektet kom vi dock fram till att några saker gjorde det onödigt komplicerat och var inte tillräckligt dynamiskt, varpå vi utvecklade ett nytt protokoll med denna lärdomen. Följande underkapitel kommer alltså handla om det gamla och det nya protokollet, och skillnader strukturellt mellan dem Det gamla protokollet Varje del av ett kommando separerades med en radbrytning men avslutas också med en radbrytning. Varje kommando var en kombination av tre bokstäver, detta för att minimera datatrafiken. Det var uppbyggt kring tankesättet att vi skulle skicka enumerationer för att minska trafiken ännu mer. Här följer ett exempel på ett paket som klienten skickar när den uppdaterar sin position. Text inom hakparenteser ersätts av data från klienten. KEY [sessionkey] POS [latitude] [longitude] [satelliter] END Brister i det gamla protokollet Olyckligtvis fanns det flera brister i det första protokollet som utvecklades. Speciellt tekniskt sett blev implementationen svår att hålla snygg och lättläst, vilken innebar att det var lätt att införa buggar. Ett väldigt vanligt sätt att läsa och skicka saker på nätverket är att läsa och skicka hela rader i taget. Nu var det dock så att för att läsa all information tillhörande ett nyckelord var vi tvungna att läsa flera rader. Detta innebar att det blev en mycket loopar och onödigt komplicerat. Dessa problem blev större och större ju längre vi kom och expanderade protokollet. En annan brist var att, om nya nyckelord infördes i protokollet utan att man uppdaterade klienten, så kunde inte klienten tolka kommunikationen alls längre. Den behöver nämligen veta hur många rader den ska förvänta sig efter varje nyckelord Det nya protokollet Med bristerna ovan bestämdes det protokollet skulle skrivas om. Inspiration hämtades från HTTP-protokollet, och likt det infördes huvudkommando och kommando. De två kommandotyperna ersatte det tidigare nyckelordet och fungerar på ungefär samma sätt. Skillnaden Sida 20 av??

21 mellan huvudkommando och kommando är att varje nätverkspaket från klienten alltid börjar med ett huvudkommando, och innehåller max ett sådant. Det som är viktigt med huvudkommandon och kommandon är att de tar maximalt upp en rad. Fördelarna med detta går att läsa i?? Fördelar med nya protokollet. För att se nätverksprotokollet i detalj, samt se vilka huvudkommandon och kommandon som finns, se bilaga?? Nätverksprotokoll. Här följer samma exempel som i underkapitlet?? Det gamla protokollet. UPDATE [sessionkey] POSITION [latitude] [longitude] [satelliter] END Fördelar med nya protokollet Det finns många fördelar med det nya protokollet. Lätt att utöka / Dynamiskt Eftersom varje kommando har sin egen rad är det väldigt lätt att skicka med godyckliga kommandon när man vill. Detta kan komma till nytta då man gör mindre uppdateringar av protokollet, eftersom klienten då fortfarande skulle fungera. Ej beroende av ordning Om ordningen på kommandon någon gång skulle ändras skulle klienten vara opåverkad av detta. Mer felsäkert Om klienten skickar data som servern inte förstår (eller tvärtom) kan den lätt bara ignorera detta eftersom den inte är beroende av att raderna kommer i en speciell ordning. Lätt att dela upp och hantera Eftersom varje kommando har sin rad är det lätt att hantera detta programmeringsmässigt. När programmet läst ut en rad, kan det lätt kontrollera första ordet, som är själva kommandot, och därefter skicka raden vidare till en speciellt funktion som tar hand om just det kommandot Problem I början av projektet när en nätverksförbindelse skulle upprättas mellan server och klient så uppstod problem direkt. Försöket bestod av att skicka en textsträng till servern och då skulle servern svara med en textsträng. Servern fick textsträngen som skickats från klienten men klienten fick bara en tom textsträng tillbaka som svar. Vi ändrade längden på textsträngen och den tillåtna längde på strängen som fick skickas men inget hjälpte. Vi sökte efter exempelkod på klienter och servrar och fann att denna var väldigt lik vår kod så vi uteslöt att koden var felskriven. En temporär kopia av klienten skrevs i Java som vi testkörde på en dator. Detta gav oss ett svar tillbaka och då fick vi en teori för att det kanske var fel på nätverkskommunikationen mellan Java och Python. Men när koden för klienten kördes på en dator istället för på mobiltelefonen returnerades ett svar och då gick misstankarna istället över till att det var något fel i python-biblioteket på mobiltelefonen. Då koden för servern Sida 21 av??

22 kändes korrekt om man jämförde med den exempelkod som fanns tillgänglig blev vi tvungna att byta ut vår kod helt mot exempelkoden för att se om de ändå fanns något dålt fel. Koden för klienten byttes först och det gjorde ingen skillnad, men när koden för servern byttes ut så fick vi äntligen ett svar tillbaka från servern. En ännu mer detaljerad jämförelse mellan exempelkoden och vår kod genomfördes och vi lokaliserade felet till en metod i som gav ett oväntat resultat. Metoden returnerade inte korrekt data enligt dokumentationen i Java:s api [?]. Efter byte till en metod som utför samma operation i vår serverkod returnerades ett svar enligt förväntan och problemet var löst. Sida 22 av??

23 5 Design och utveckling av klienten Klienten är användarnas del av spelet och har som främst uppgift att se till att information förs mellan spelarna och spelet och vice versa. Den har även jobbet att få ut information om positioneringen från GPS:en och skicka detta till servern. En av de intressantaste delarna, och även den största utmaningen, med att utveckla till klienten var att vi fick utveckla till en tidigare okänd hårdvara för oss. Att utveckla till en hårdvara som är mindre kraftfull gav oss begränsningar som vi inte var vana vid men samtidigt fick vi nya möjligheter i och med de funktioner som telefonen gav oss. Språket vi valde till klienten blev Python. Från början hade vi funderingar på att köra med Java då den möjligheten fanns men rådet vi fick från vår kontakt på Nokia var att Python var det bästa valet. Python var ett nytt och obekant språk för alla i gruppen och eftersom tiden för det här projektet var ganska begränsad hade vi inga möjligheter att lägga till någon extra tid för att lära oss språket fick vi helt enkelt lära oss under tiden vi utvecklade klienten. S60-telefoner har dock en egen variant av språket vid namn PYS60 (Python 2.3 för Symbian S60 system) som bygger på en äldre version av Python och saknar vissa av de moduler som annars är standard. Den har även en del egna moduler för användandet av de funktioner som är specifika för hårdvaran så som GPS-positionering, knappavlyssning och utritning av grafik. Ett av de största problemen med att utveckla klienten var bristen på dokumentation och hjälp som fanns att finna på nätet. Att använda Internet som främsta källa när man söker lösning på problem i programmering har blivit standard och när man programmerar applikationer i miljöer med bredare utvecklarbas (antal utvecklare) brukar man kunna hitta någon variant på samma problem med en lösning ganska snabbt med hjälp av simpel sökning. PYS60 har ingen bred utvecklarbas då det bara inriktar sig till S60-mobiler vilket är en ganska smal inriktning vilket gjorde att det var ganska begränsat med vad man kunde hitta och utöver Nokias egna forum för utvecklare på deras hemsida fanns det inte mycket hjälp att finna. Det ska dock nämnas att forumet i sig var väldigt bra och hade lösningen på många av problemen. Dokumentationen för de specifika moduler som tillkom i och med PYS60 kändes bristfällig och väldigt svårtydd Oftast fick vi försöka leta fram något exempel på när det användes på Internet och sedan testa oss fram för att förstå hur de skulle användas. Detta blev ganska tidsförödande. Sida 23 av??

24 5.1 Klientens struktur Trådar En av de moduler som inte ingår i PYS60 är den standardmodul i Python som annars används när man vill programmera med trådar. Detta gjorde att vi fick förlita oss på en äldre trådmodul som är på en mycket lägre nivå. När man programmerar till S60-telefonerna måste man lägga grafiken och knappavlyssningen i huvudtråden, inte ens bilder som laddats in i en annan tråd kunde sedan användas av huvudtråden. Detta gjorde att vi helt enkelt var tvungna till att lägga ut allt annat som kunde låsa applikationen en viss tid i egna trådar. GPS-positioneringen var en process som behövde en egen tråd då den låste applikationen varje gång den sökte position vilket tog någon sekund varje gång. Det gick dock inte att starta upp en egen tråd som skötte GPS-positioneringen manuellt, det vägrade helt enkelt att fungera när vi försökte. Metoden man kallade på hade istället en callback-parameter där man angav en egen metod som skulle köras varje gång man fick en uppdatering från GPSsatelliterna. På så sätt blev detta en egen tråd som kördes i bakgrunden och den låste inte längre resten av applikationen. Nätverkshanteringen var ytterligare en sak som behövdes läggas i en separat tråd. Då vi inte kunde öppna flera anslutningar från servern på samma gång kunde vi helt enkelt inte starta upp en ny tråd som för varje anslutning utan vi behövde en tråd som låg och väntade på att få utgående meddelanden att skicka och även satte dem i en kö när det kom nya innan den var klar med de gamla Strukturen En huvudklass som hanterar trådarna och skapar instanser av det som behövs. En klass som står för kommunikationen mellan klasserna och trådarna i form av Utveckling 5.2 Klientens GUI Eftersom det viktigaste är att alltid veta var man är så är det också det som visas i användargränssnittets bakgrund, detta i form av en karta. Spelaren representeras av ett lysande klot, vilken skärmen alltid följer så att det förblir i mitten vid alla tillfällen. Klot av andra färger representerar andra spelare eller monster. På kartan kan man se alla de hus och byggnader som man hade kunnat se på vanliga GPS:er, men i spelets alternativa dimension syns istället lysande grönt där det är byggnader och svart där det är väg. Där det är rött är utanför kartan, man kan gå dit, men det kommer inte finnas några monster, affärer eller liknande där, eftersom det är ett område vi inte har arbetat med. Se figur-??. Sida 24 av??

25 Figur 3: Spelets karta. Figur 4: Under-spelets-gång-karta. Ovanpå detta ligger två menyknappar nere i varsitt hörn för olika sorters val och högst upp en panel med spelaren link-energy, samt att det uppe i höger hörn finns en bild som visar om man vill slåss med andra spelare eller inte. De två olika menyerna är Menu och Interact. Menu är gjord för att man ska kunna nå alla spelets fullskärms fönster som innehåller övrig viktig information vilken är nödvändig för spelaren. I dessa fönster finns även inställningar för spelaren, som till exempel vilken utrustning han väljer att bära utav den han har med sig. Interact menyn är istället gjord för att endast ta hand om interaktionskommandon man kan skicka till andra spelare eller ett monster. Exempel på detta skulle kunna vara Engage, som gör att man påbörjar en strid med en annan spelare eller ett monster. För att bestämma vem i närheten man vill slåss med får man markera en spelare eller ett monster med den Joystick som finns på mobiltelefonen genom att trycka vänster eller höger. Detta gör att en ring kommer upp runt den andra spelaren eller monstret och du tillåts då att välja en aktion. Om man någon gång vill avbryta en strid finns knappen Disengage i Interact menyn, som gör att spelaren slutar anfalla. I menyn Menu kan man finna två fullskärmsrutor, dessa vid namn Inventory och Stats, se figurerna????. I stats kan man se detaljerad information om sitt alias. Denna information beskrivs i siffror i turkos text på svart bakgrund. Inventory skärmen har delats upp i tre delar, den översta delen är 4 röda rutor som representerar det du bär på dig just nu. Den mittersta delen är 4x4 blåa rutor som representerar den plats du har att bära med dig saker. På både de röda och blåa rutorna kan föremål vara plaserade. Det finns en markör som kan röra sig med hjälp av mobilens Joystick, som kan flyttas över alla rutor, både röda och blåa. Den understa delen är 3 knappar som varierar beroende på vilket läge du är i inom detta fönster. Den knapp som är längst till vänster har 2 lägen, antingen blank eller Inspect. Inspect öppnar ett nytt fullskärmsfönster som visar Inspect vyn. Denna knapp visas bara om du Sida 25 av??

26 Figur 5: Inventory vyn Figur 6: Stats vyn håller markören över ett föremål, annars är knappen blank. Den mellersta knappen har 7 olika lägen. Dessa är Select, Use, Equip, Unequip, Switch, Move here eller blank. I det fall att man inte markerar ett föremål är denna knappen blank, annars visas Select. Om man väl trycker Select på ett föremål, så kommer detta föremål markeras. När man håller med markören över ett markerat föremål syns nu ett av dessa 3 lägen som mitten knappen kan anta, Use, Equip, Unequip. Detta beroende på föremålets typ och platsens typ. Om den ligger på en utrustningsplats så heter knappen Unequip. Om den är på en vanlig bärplats så är knappen antingen Use om typen på föremålet är NonEquippable, annars är den Equip. De 2 sista lägen som finns kommer fram när man har markerat ett föremål, och sedan håller över en annan ruta. Om denna ruta är tom, så kommer den att vara Move here. Om den har ett föremål på sig, så kommer den att heta Switch. Move here flyttar ett föremål, Switch byter plats på 2 föremål. Den sista knappen som ligger längst till höger har 2 lägen. Om man inte har markerat något föremål så backar den bara ut till grund vyn där kartan syns. Däremot om man har något markerat, så har den namnet Unselect, och utför en avmarkering av det du har markerat istället. Det beskrivs hur man kan nå Inspect vyn ovan. I denna vy kan man se mer detaljerad information om det föremål man valt att inspektera. Denna information innefattar en bild på föremålet, samt dess namn, typ och vad det ger för fördel att bära. Allt detta i turkos text, på svart bakgrund. Även här finns de 3 knapparna längst ner, dock med mycket färre lägen. Den första knappen från vänster kan vara antingen Equip eller Unequip beroende på föremålets typ. Mitten knappen är alltid Drop, för att slänga föremålet. Om man trycker på denna knappen så kommer programmet fråga om man verkligen vill göra detta, om man sedan accepterar så kommer föremålet kastas. Den sista knappen längst till höger backar alltid tillbaka till Inventory vyn medans du är i Inspect vyn. Sida 26 av??

27 Figur 7: Inspect vyn Sida 27 av??

28 Figur 8: Knapparnas förändring Utvecklingen av användargränssnittet Från början så var GUI:t bara ett meny system, men med tiden så tillkom fullskärmsrutor, samt kartan och allt annat som nu finns där. Ett exempel på hur utvecklingen har gått är knapparna. Som man kan se på knapparna så har de gått från stora och svårlästa, till små och tydliga, se figur-??. Först när transparens löstes blev de menyknappar man ser på kartan mindre problematiska i den aspekten att de gör kartan svår att se när de är framme. Designen på hur man ska visa den utrustning spelaren bär förändrades radikalt sent under utvecklingen efter tips från handledaren. Istället för att det visades i ett eget fönster vid namn Equip blev det en del av fönstret Inventory, och ligger nu i det fönstret istället. Innan detta kan man se flera olika versioner av hur Inventory bakgrunden har sett ut tidigare i figur-??. Alla har följt samma rutmöster, dock så har antalet rutor och deras storlekar varierat mellan versioner på grund av antalet rutor vi velat ha, samt att storleken på knapparna förändrades. I figur-?? kan man se hur kartan såg ut från början. Den nya kartan har gjorts så att den är mer tydlig och passar bättre ihop med temat Designbeslut När vi designade GUI:t så tänkte vi på att få det funktionellt sett snarlikt det som mobiltelefonen själv använder i sitt GUI. Det är därför det finns en meny längst ner i vardera hörn, samt när det behövs, även en i mitten. Vid val av olika program eller mappar så har användargränssnitt en lista med ikoner för de man kan välja utav. Vårt Inventory fungerar också på detta sätt när man navigerar sig bland sina föremål. Anledningen till att vi har den färgskala som vi har på knappar och bakgrunder är att vi vill ge både ett High-tech intryck, samtidigt som vi vill stämma överens med energi temat. I brist på skärm plats så ansåg vi att det var en bra idé att gömma undan så mycket av den information som man inte alltid ville se som möjligt. Vi ville också undvika att ge för mycket information i grund vyn (där man ser kartan), eftersom det han kunnat förvirra nya spelare. Denna information ligger istället i fullskärmsrutor som man når via den vänstra menyn. Vi ansåg också att det var mycket Sida 28 av??

29 17 maj 2009 MonstroCity Figur 9: Den a ldsta kartan. Figur 10: Inventory Bakgrundens fo ra ndring Sida 29 av??