19 maj 2009 MonstroCity

Transkript

1 Sammanfattning Projektet har gått ut på att utveckla ett mobilspel som utnyttjar positioneringsteknik för att skapa en förstärkt spelupplevelse. Spelet utnyttjar agps för positionering via Nokia:s S60 system och en server vilken hanterar samtliga användare i spelvärlden. Spelet är designat och programerat från grunden upp och utvecklat i Python och Java. Projektet har bidragit till en ökad insyn till att utveckla till mobiltelefoner och positionsbasserade applickationer. 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 game experience. The game utilizes agps to find the players possission through the Nokia S60 system and utilizes a server to control the players in the game world. The game is designed and programed from the floor up and was developed in Python and Java. The result from the project is a greater understanding of developing mobile phone applications and possition based applications. Sida 2 av 59

2 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 MonstroCity [1]. Vi vill tacka vår handledare Sus Lundgren som har varit ett stöd i det vi visste minst om och 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. Slutligen vill vi tacka Björn Arvidsson och Anna Malmer för deras concept art. Sida 3 av 59

3 Innehåll 1 Inledning Syfte Avgränsning Historik Slutprodukten Metod Hur vi arbetade Använda verktyg Planering Litteraturstudier Speldesign Vision Spelmekaniker Användning av positionering Spelsession Spela själv Spela i grupp Strider Föremål Quests Accelerometer Digitala kompassen Tema Designval gällande temat Alternativa teman Teknik & Kommunikation Generellt Nätverk Det gamla protokollet Brister i det gamla protokollet Det nya protokollet Fördelar med nya protokollet Problem Design och utveckling av klienten Klientens struktur Trådar Strukturen Klientens grafiska användargränssnitt Utvecklingen av användargränssnittet Designbeslut Problem med användargränssnittet Sida 4 av 59

4 6 Server Struktur GUI Modell Problem Positionering Problem Andra tekniker Diskussion 36 9 Bibliografi Ordlista 40 A Användarmanual 41 B Systemdokumentation 49 C Utvecklingsdokumentation 52 Sida 5 av 59

5 1 Inledning Spel i digital form är en ständigt växande marknad och är nu en väletablerad 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 att basera spel 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 genom att uppmuntra till mer rörelser under spelandet. En teknik som nu blir allt vanligare i bärbara produkter, och främst mobiltelefoner, är GPSpositionering där man med hjälp av satelliter 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 ta hänsyn till var i världen man är. Det öppnar också upp för spel där det reflekteras i spelvärlden ifall man i verkligheten tar sig från en plats till en annan. Då detta är en relativt ny kombination av teknik finns det ännu inte många spel som utforskat dess möjligheter. Projektet har därför gått ut på att utveckla ett spel som gör just detta. Spelet har utvecklats från grunden utifrån en given spelidé, och projektet har därför involverat delar som speldesign, programmering och nätverkskommunikation. Därmed har gruppen 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. Det har också lett till nyttiga erfarenheter vad gäller design av nätverksprotokoll och skapandet av klient och server. Gruppen har även bekantat sig med Python; ett programspråk som det tidigare saknades ingående kunskaper om. 1.1 Syfte Det huvudsakliga syftet var att skapa ett roligt spel med ett genomgående tema, innehållande element av social interaktion mellan spelarna; i form av både samarbete med och tävlan mot andra spelare. En följd av detta blev att spelet behövde både incitament till och möjligheter för spelare att sätta sina alter egon i relation till andra spelare. Därtill följde ett medryckande stridssystem som skulle vara både roligt och balanserat. För att motivera spelaren att fortsätta spela skulle spelet ge möjligheter att utveckla spelarens spelkaraktär på något vis. Förutom strider skulle även spelet erbjuda spelarna uppdrag att utföra. 1.2 Avgränsning Då mobiltelefonerna har hanterat alla GPS-beräkningar, behövdes ingen tid läggas på detta. En egen implementation hade varit ett för omfattande arbete, som skulle ha krävt omfattande ämnesstudier. Dessutom skulle det inte nödvändigtvis ha blivit bättre än de funktioner som fanns att tillgå i telefonerna. Projektet har gjorts för att undersöka positionering i spel och vad det kan innebära. Därför har många saker som vanligtvis skulle höra till att utveckla ett stabilt spel inte behandlats t.ex. användartester, eftersom spelet aldrig varit innehållsrikt nog för att kunna testas av oberoende testare. Utvecklingen av innehållet blev ej så omfattande, eftersom det sågs som mindre relevant för att undersöka möjligheterna med tekniken. Därför har spelet inte fyllts med en stor mängd olika utrustningar, olika typer av monster eller många viktiga platser på Sida 6 av 59

6 kartan. Inga belastningstester har utförts, eftersom det aldrig funnits någon möjlighet att ha ett stort antal spelare i spelet samtidigt. Kartan, och därmed också spelytan, begränsades till enbart Chalmers campus Johanneberg, då det var på denna plats som testningen skedde. Det går alltså inte att spela alls utanför detta område. Slutligen har avancerad grafik och avancerade grafiska funktioner aldrig varit prioriterat under projektet, dels på grund av mobiltelefonernas begränsade beräkningskapacitet, men också för att det till hög grad hade ökat svårigheten eftersom det saknades specialkompetens inom området. 1.3 Historik Även om GPS-tekniken inte är ny, har den först på senare år börjat finna sin väg in i var mans hand genom att den bland annat integreras i mobiltelefoner. Detta tillsammans med förbättringen av mobilernas Internet-uppkopplingar öppnar upp nya möjligheter för hur spel i framtiden kommer att spelas på dessa. Mobilers prestanda, i form av beräkningskraft, har ökat omfattande under senare tid, och därmed har också möjligheten man har när man arbetar med dem ökat. Detta leder i sin tur till att mer avancerade spel hittar sin väg till mobiltelefonerna, samtidigt som det allmänna funktionsutbudet, såsom exempelvis GPS, ökar. Införande av 3G och Turbo-3G har därtill lett till större möjligheter för högkvalitativa Internet anslutningar oavsett var man befinner sig. Teknologins utveckling har därmed lett till möjligheten att skapa positionsbaserade spel. Ett exempel på ett spel som använder denna teknik är Geocaching. I detta spel gömmer man undan en behållare innehållande en penna, en loggbok samt något annat föremål. Andra spelare får sedan försöka hitta denna behållare med hjälp av koordinater från spelaren som gömt den, vilka anges på Internet. När en spelare väl hittar behållaren får denna skriva ner sitt namn i loggboken och byta ut någon av de andra sakerna i lådan. [3]. Detta är ett väldigt simpelt positionsbaserat spel som endast använder GPS och något slags webbforum. Det kräver, till skillnad från MonstroCity, ingen specifik applikation annat än GPS-applikationen på telefonen. Övriga positionsbaserade spel värda att nämna är Parallell Kingdoms [8] och Virtual Punk [9], som båda är rollspel för flera spelare, innehållande både karaktärsutveckling och något slags stridsmoment, samt PacManhattan och Geo-missions. PacManhattan är en positionsbaserad version av PacMan som spelades på Manhattans avenyer [7], medan Geo-missions är ett spel som går ut på att gå till olika platser i en stad och svara på gåtor. 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. Vår produkt är därmed helt digital. 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 kommunikationsverk- Sida 7 av 59

7 tyg med modellen. En del av slutprodukten är en applikation som kan köras på Nokias 6210 Navigator telefoner. 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. Denna slutprodukt är tillviss del begränsad, eftersom den kräver att användaren har en mycket specifik mobil för att kunna användas. Några av de krav programmet har på mobilen är till exempel GPS, vibration, PyS60 och Symbian operativsystem. Utan dessa så kan inte applikationen köras eller fungera korrekt. Sida 8 av 59

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. Denna innefattade allt ifrån spelidéer till tidsloggböcker. 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 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 Sida 9 av 59

9 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 10 av 59

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 ha 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 de 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 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. Sida 11 av 59

11 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. 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. Sida 12 av 59

12 3.2.3 Spela själv Då andra spelare oftast är inloggade i spelet så spelar du aldrig ensam. Man kanske väljer att inte interagera med de 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å tillkommer även en social aspekt till spelet. 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 överskottsenergi och erfarenhetenergi. Det finns inget sätt att officiellt visa andra spelare att man är en grupp då vi inte har infört ett party-system eftersom detta inte är en nödvändig funktion för att spelat ska vara spelbart. Detta har istället blivit bortprioriterat i brist på tid. Om detta hade varit möjligt så hade det gått att ha större slag mellan olika spelargrupper, som t.ex. klaner. 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 övergångarna genom att byta fram och tillbaka i strider. På detta sätt hade spelare kunnat attackera andra spelare utan att gå att attackera själva. 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å en annan spelare eller monster i taget. Detta sker genom att markera en spelare eller ett monster 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 Sida 13 av 59

13 passivt läge. Om spelaren kommer för långt bort skadas inte det spelaren attackerar längre. Först när spelaren kommer så pass nära att det attackerade målet är nära nog så återupptas attackerandet. 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 överskottsenergi och erfarenhetsenergi 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 eller annat skäl. Ett förslag var att spelaren skulle trycka på en knapp på mobiltelefonen för varje anfall. Denna idéen avslogs ganska fort då detta inte var någon bra idé eftersom 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ämdes 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ände att 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åeligt 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 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 varpå grund av 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. Sida 14 av 59

14 Figur 1: Hur strid i grupp skulle fungerat 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 är en viktig del av att designa ett spel. 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 kan ses som ett 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, 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 föremålsliknande objekt. Ö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 Sida 15 av 59

15 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 få 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 ökningar av spelarens attributerer. 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 dem i tävlan med andra eller ej. Personliga uppdrag skulle vara uppdrag där 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 avklarade uppdrag. Med globala uppdrag hoppades vi få till en större mängd tävlan och spänning 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 bredvid 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. Sida 16 av 59

16 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övt 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, inträffar 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 Digitala kompassen Då mobiltelefonen är utrustad med en digital kompass försökte vi få fram idéer på hur man skulle kunna använda denna i stridssystemet under projektets början. 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 det att man förkortar invånarnas livslängd 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 Sida 17 av 59

17 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 till sig igen i början av nästa månad. Varelsernas enda försvar är att försöka kasta ut utforskarna ur dimensionen genom att störa deras signal. När utforskarens signalstyrka är noll så dör dess alias och måste laddas upp igen genom att färdas till en laddningsplats. Även utforskarna har funnit knep för att störa andra utforskares signal och kasta ut dem 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. De kan också känna att de bidragit starkt till att lösa världens energiproblem även om de är medbrottslingar till att förstöra en annan dimension. Med pengarna som utforskarna får kan de köpa bättre utrustning så som skydd mot störningar och apparatur som avger störningar vilket kan göras i speciellt utvalda affärer 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 och 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 då spelaren känner att dess 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 historiemä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. Sida 18 av 59

18 3.3.2 Alternativa teman I början av projektet uppkom ett flertal idéer om teman att bygga spelet kring. En av de andra idéerna som var på förslag var ett kriminellt tema vilket i stort handlade om att man skulle kunna utföra kriminella gärningar. Genom att utföra dessa gärningar så skulle man kunna tjäna pengar och även klättra i rang i den undre kriminella världen. Detta har vissa liknelser till hur spelet som gruppen har utvecklat blivit, där spelaren även där kan tjänar Pengar, som dock är i from av energi. Titeln MonstroCity hade kunnat gå att passa in på det kriminella temat, även om det saknar monster, om man nu skulle se på spelarna som monstrerna, på grund av deras handlingar. Även detta görs till viss del i det utvecklade spelet, då spelarna är onda och jagar monstrerna, vilka bara försöker försvara sig. Det kriminella temat blev dock aldrig det gruppen utvecklade, detta av flera anledningar. En av anledningarna var att gruppen antog att det skulle kunna leda till missförstånd om en stor grupp med spelare skulle stå utanför en bank medens de pratar om att råna den. Sida 19 av 59

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 tillskillnad från UDP ett mycket pålitligt protokoll, som bla. hanterar omsändning av paket. Slutligen bedömdes det även vara möjligt att UDPpaket skulle fastna i brandväggar, vilket ledde till att TCP var det protokoll som valdes. För en översikt, se figur-2. 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 Sida 20 av 59

20 upprättas varje gång en klient behöver skicka något till servern. En annan anledning till att det byggdes på det viset var att data skickas, i nätverkssammanhang, rellativt sällan, ungefär en gång per sekund. 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 att 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 yttligare. 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 mycket loopar och i övrigt 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. Sida 21 av 59

21 4.2.3 Det nya protokollet Med bristerna ovan bestämdes det att 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 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 B.2 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ängden 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å Sida 22 av 59

22 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 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 Java som gav ett oväntat resultat. Metoden returnerade inte korrekt data enligt dokumentationen i Java:s api [2]. 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 23 av 59

23 5 Design och utveckling av klienten Klienten tillhandahåller ett grafiskt gränsnitt och hanterar kommunikationen med servern. Den håller även information om var spelarens position är i spelvärlden med hjälp av GPSteknik. Det finns stöd för utveckling till S60-mobiler i flera olika språk. Bland dessa ingår C++, Java och Python. Den här klienten har utvecklats i Python. S60-telefoner har 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. 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 vid programmering av trådar. Istället fanns en äldre trådmodul, dock på en mycket lägre nivå. I S60-telefonerna behöver grafikutritningen och knappavlyssningen finnas i huvudtråden och kan inte fördelas ut i andra trådar. Bilder som laddats in i en annan tråd kan inte heller användas av huvudtråden. För att inte störa knappavlyssningen eller grafikutritningen placerades allt 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. Metoden som kallades hade istället en callback-parameter där en egen metod angavs, som skulle köras varje gång en uppdatering togs emot från GPS-satelliterna. På så sätt blev detta en egen tråd som kördes i bakgrunden. Nätverkshanteringen var ytterligare en sak som behövde finnas i en separat tråd. Det gick inte att öppna flera anslutningar från telefonen samtidigt. På grund av detta kunde inte en ny tråd skapas varje gång ny information behövde skickas till servern då detta öppnade upp risken att flera trådar försökte ansluta simultant. Det behövdes således en tråd vars uppgift var att vänta på utgående meddelanden och därefter skicka dem. Utgående meddelanden lades i en kö som behandlades allt eftersom Strukturen Klienten har en huvudklass, Main, som hanterar trådarna och skapar instanser av det som behövs. Utöver det finns en klass, Connection, som hanterar nätverkskommunikationen med servern och en gemensam klass, MGUI, för utritning av grafik samt knappavlyssning. För att sköta kommunikationen mellan klasserna och ha en platshållare för gemensamma variabler Sida 24 av 59

24 skapades även en klass, Model, som alla andra klasser i klienten har en instans av. För att organisera data som kommer från servern skapades klasserna MapObject och Item som finns i Model. Se figur 3. Figur 3: Förenklat diagram över klientstrukturen 5.2 Klientens grafiska användargränssnitt En av de viktigaste aspekterna med användargränssnittet var att visa spelarens position i spelvärlden och dess omgivning. På grund av mobiltelefonens tekniska begränsningar och lilla skärm är grafiken av enklare karaktär och gjort ur ett perspektiv som är rakt ovanifrån där spelaren representeras av ett lysande klot. Spelaren är alltid i mitten av skärmen och istället förflyttas kartan när spelaren rör sig. Klot av andra färger representerar andra spelare eller monster. För att få fram en radarkänsla representeras byggnader och annat som kan störa ut GPS-signalen med grönt, mot en svart bakgrund. Då spelplanen var inom en begränsad yta behövdes det visa grafiskt när man lämnade den. Detta visas med att bakrunden byter från svart till rött. Spelaren kan gå utanför spelplanen, men det kommer inte att finnas några monster, affärer eller liknande där. För att underlätta i icke optimala ljusförhållanden valdes starka färgkontraster mellan rörliga objekt och övriga spelvärlden. Längst ned på skärmen finns menysystemet. Högst upp på skärmen finns en panel med spelarens link-energy. Uppe till höger kan spelaren även se sin inställning för aggressiviteten mot andra spelare. För bilder på spelkartan, se figur 4 och 5. Menysystemet består i huvudsak av två menyer som är lagda nere i varsitt hörn och kontrolleras av varsin knapp. Detta i enlighet med telefonens övriga applikationer. I den vänstra Sida 25 av 59

25 Figur 4: Spelets karta. Figur 5: Under-spelets-gång-karta. menyn, Menu, når spelare helskärmsinformation såsom attribut, utrustning och uppdrag där spelaren också bland annat kan byta utrustningen. I högermenyn, Interact, utför man istället kommandon som har med interaktionen med andra spelare och monster att göra. De interaktionval som finns är Engage, Disengage, Message, Activate och Deactivate. Engage och Disengage används för att gå in i samt avsluta striden. Message används för att skicka meddelanden. Activate samt Deactivate används för att ändra sin inställning för aggressivitet mot andra spelare. Engage, Disengage och Message kräver samtliga att man har ett markerat mål på kartan. Man markerar mål genom att använda telefonens Joystick samt höger- och vänsterknapparna. Målet visualiseras genom att en ring kommer upp runt den andra spelaren eller monstret. I menyn Menu finns helskärmslägen vid namn Inventory och Stats, se figurerna 6 och 7. I Stats kan spelaren se detaljerad information om sitt alias. Skärmen Inventory håller information om spelarens föremål där de fyra översta platserna är de föremål som används för tillfället. Menysystemet i nederkanten av skärmen varierar beroende på de alternativ som finns tillgängliga för olika föremål. Spelarens Inventory fungerar genom tre knappar och en markör. Markören kan styras med mobiltelefonens Joystick vertikalt och horizontellt över alla rutor som finns i spelarens Inventory. Med denna markör kan spelaren sedan hålla över olika föremål för att undersöka dem i ett nytt fönster eller markera dem. Om spelaren skulle markera ett föremål så kommer vissa knapparna att byta namn och funktion beroende på vad för möjliga funktioner som är tillgängliga för det markerade föremålet, beroende på dess typ. Anledningen till att knapparna byter namn och funktion är att det går snabbare att först markera något med en knapp och sedan trycka en gång till på samma knapp för att utföra det vanligaste alternativet. En annan anledning är att det skulle blivit överflödigt att ha en knapp för varje funktion, eftersom många Sida 26 av 59

26 Figur 6: Inventory vyn Figur 7: Stats vyn av de möjliga knapparna isåfall skulle vara oanvändbara för vissa föremål. Alternativet att avmarkera kommer också att synas efter markering. Huvudanledningen till att det existerar ett Inventory i klienten är att man behöver ett grafikst sätt att organisera och hantera sina föremål. De möjliga funktionalliteter som kan nås via Inventory -fönstret är att undersöka föremål och se detaljerad information om dem, att organisera sina föremål, att slänga dem, att använda dem och att bestämma vilka som är burna och vilka som bärs med. För att se en bild på hur det ser ut när man undersöker ett föremål, se figur Utvecklingen av användargränssnittet Från början var användargränssnittet bara ett menysystem men med tiden 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 har de gått från stora och svårlästa, till små och tydliga, se figur-9. Först när transparens löstes blev de menyknappar man ser på kartan mindre problematiska i den aspekten att de stjäl yta som kartan kan visas på vilket minskade hur mycket av omgivningen spelaren kunde se. Designen på hur man ska visa den utrustning spelaren bär förändrades sent under utvecklingen. 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. Flera olika versioner av hur Inventory -fönstret har sett ut tidigare visas i figur-11. Alla har följt samma rutmönster men antalet rutor och deras storlekar har varierat mellan versioner, samt att storleken på knapparna förändrades. I figur-10 visas hur kartan såg ut från början. Kartan gjordes om för att passa bättre ihop med temat. Sida 27 av 59

27 Figur 8: Inspect vyn Figur 9: Knapparnas förändring. Sida 28 av 59

28 19 maj 2009 MonstroCity Figur 10: Den a ldsta kartan. Figur 11: Inventory Bakgrundens fo ra ndring Sida 29 av 59