Mobilspel för Android - Utveckling av ett spel av typen Tower Defence Kandidatarbete inom Data- och informationsteknik

Transkript

1 Mobilspel för Android - Utveckling av ett spel av typen Tower Defence Kandidatarbete inom Data- och informationsteknik Albin Andersson Emil Bjunert Johan Elgered Martin Schillström Fredrik Wiström Henrik Åkerberg Institutionen för Data- och informationsteknik CHALMERS TEKNISKA HÖGSKOLA GÖTEBORGS UNIVERSITET Göteborg, Sverige 2010 Kandidatarbete/rapport nr:2010:65 i

2 Projektrapport Grupp 65 Mobilspel för Android Andersson A, Bjunert E, Elgered J, Schillström M, Wiström F, Åkerberg H, 2010 Institutionen för Data- och informationsteknik Chalmers Tekniska Högskola Göteborg Göteborgs universitet Göteborg Handledare Sakib Sistek Examinator Peter Lundin ii

3 Abstract Every day new applications for mobile phones are introduced to the market, these applications provide services such as reading , updating status on Facebook or playing games. All this can be done during the bus ride on the way to school or work. With an increased interest in advanced mobile phones with the ability to easily obtain various kinds of applications, the number of developers and the quality of applications has increased. A large portion of these applications are games. This report documents the development of a mobile game for the Android operating system version 2.1 or later. The game type is Tower Defence which is based on the real-time strategy genre. The goal is to prevent attacking enemies from reaching a certain point on a map. This is accomplished by building a stationary tower defence. The game supports both single- and multiplayer mode, where up to two players can play simultaneously on individual Android devices. The communication between the devices is handled with wireless Bluetooth technology. The report is also meant to serve as a helping guide for people who want to develop applications for the Android platform and contains solutions of problems, design hints and suggestions of development tools. The project resulted in a Tower Defence game for Android, which has not yet been published on Android Market. The report is only available in Swedish. Sammanfattning Dagligen lanseras nya applikationer för mobiltelefoner, med vilka man exempelvis kan läsa , uppdatera status på Facebook eller fördriva tiden med att spela. Allt detta kan ske under bussturen på väg till skola eller jobb. I och med ett ökat intresse för avancerade mobiltelefoner med möjlighet att enkelt införskaffa applikationer av olika slag, har antalet utvecklare och kvaliteten på applikationerna ökat. En stor del av dessa applikationer är spel. Denna rapport redogör för utvecklandet av ett mobilspel för operativsystemet Android version 2.1 eller senare. Spelet är av typen Tower Defence som är baserat på realtidsstrategi-genren. Det går ut på att bygga ett försvar med hjälp av stationära torn mot attackerande fiender. Spelet har stöd för både en- och flerspelarläge, där maximalt två spelare kan spela samtidigt på enskilda Androidenheter. Kommunikationen i flerspelarläget hanteras mellan de båda enheterna med hjälp av den trådlösa teknologin Bluetooth. Rapporten är även tänkt att fungera som en hjälpande guide för personer som vill utveckla applikationer till Androidplattformen och innehåller allt från lösningar av problem och designtips till förslag på utvecklingsverktyg. Projektet resulterade i ett spel av typen Tower Defence för Android, som i skrivande stund inte blivit publicerad på Android Market. iii

4 Förord Denna rapport är utformad som en del utav examinationen för ett kandidatarbete på Institutionen för data- och informationsteknik på Chalmers Tekniska Högskola. Rapporten är författad av samtliga sex medlemmar som ingår i projektgruppen. Vi skulle vilja tacka Chalmers Tekniska högskola för de två mobiltelefoner lånades ut för att kunna genomföra projektet. Vi skulle även vilja tacka vår handledare Sakib Sistek. Om intresse finns kan en demoversion och källkod erhållas genom kontakt med Vi välkomnar konstruktiv kritik och övriga kommentarer gällande såväl spelet som rapporten. iv

5 Innehåll Abstract... iii Sammanfattning... iii Förord... iv 1 Inledning Bakgrund Syfte Problemställning Möjligheter och begränsningar Estetiskt tilltalande spel Marknadskraftig produkt Avgränsningar Plattform Mobiltelefoner Metod Ansvarsfördelning Versionshantering Utvecklingsmetod Material Teori Androidplattformens beståndsdelar Linuxkärnan Android Runtime och kodbibliotek Application framework Applikationer Dalvik VM Spelbeskrivning - Tower Defence Applikationsutveckling för Androidplattformen Android Software Development Kit Programspråk och utvecklingsmiljö Eclipse Android Development Tools Emulator Androidenhet Android Debug Bridge Dalvik Debug Monitor Service Grafisk design och formgivning Fiender och torn Photoshop v

6 4.2.1 Färgval Färgmättning Användargränssnitt och interaktion Grafisk utformning av gränssnitt Spelplan Huvudmeny Knappmeny och torninformation Aktivitet Intent Androids Användrgränssnitt och XML Hierarchy Viewer AndroidManifest.xml Implementering Spelmotor GameLoop GameLoopGUI Sprite Creature Tower Shot Scaler Initiering av spelmotor MapLoader TowerLoader WaveLoader Rendering OpenGL Android Native Kit Multiplayer Kommunikation över Bluetooth Verifiering av Bluetooth Server Klient Upprätthålla en anslutning över Bluetooth Highscore Prestanda och optimering Testning TraceView Test på Androidenheter Testgrupp Diskussion Val av spel vi

7 8.2 Arbetsmetod Utecklingsmiljö och verktyg Eclipse och Android ADT Emulator Git Grafik och formgivning Androids användargränsnitt Java tillsammans med C Trådkommunikation Bluetooth ScoreNinja Konsumentbetyg Slutsats Litteraturförteckning Appendix A - Vokabulär Förkortningslista Tekniska termer Speltermer Appendix B - Individuella bidrag Appendix C - Grafiska komponenter Banor och bakgrundsbilder Spritesheets Ikoner vii

8 Inledning 1 Inledning Mobilspel är en växande marknad, detta på grund av att telefonerna blir mer avancerade men även distributionsmetoderna förbättras; detta möjliggör för applikationsutvecklare att lättare nå en bred och stor konsumentgrupp. Idag har dessutom en växande del av de mobiler som säljs pekskärm, vilket erbjuder helt nya utmaningar för både användare och utvecklare. Ur detta föddes idén att utveckla ett mobilspel då det är både aktuellt och utmanande. 1.1 Bakgrund Helelektroniska spel har i bärbart format funnits sedan år 1977 då företaget Mattel lanserade spelet Auto Race(1). Spelet inbringade, tillsammans med Mattels kommande titlar Football och Battlestar Galactica, flera miljoner amerikanska dollar, vilket blev startskottet för den fortsatta satsningen på spelutveckling inom området(2). Till de mer kända bärbara elektroniska spelen hör Nintendos spelserie Game & Watch, som introducerades Nio år senare släpptes det som skulle komma att bli en av de mest sålda spelkonsolerna världen över, Nintendos Game Boy. Antal sålda enheter uppgår 2010 till 118 miljoner, inklusive Game Boy Color(3). Gemensamt för dessa populära spelenheter är deras mobila egenskaper. Något som har medfört att spel introducerats och blivit accepterade på mobiltelefonmarknaden. I takt med att mobiltelefonernas prestanda ökar så tillåts utveckling av mer avancerade spel. De mobiltelefoner som idag klarar av att driva de mest prestandakrävande mobilapplikationer, går under det gemensamma begreppet smartphones. I denna rapport definieras en smartphone som en mobil enhet, vilken brukar ett öppet eller kommersiellt operativsystem med stöd för tredjepartsapplikationer(4). Den första smartphone-enheten lanserades år 1992 av IBM, känd som Simon. Sedan dess har en mängd nya enheter producerats av tillverkare som Nokia, Sony Ericsson, HTC, Blackberry med flera. Det existerar i dagsläget ingen standard för smartphone-enheter, dock har de vissa faktorer gemensamt(5): Det existerar i dagsläget ingen standard för smartphone-enheter, dock har de tre faktorer gemensamt, operativsystem, mjukvara och internetanslutning (5). Några exempel på operativsystem är Android, Windows Mobile, Iphone OS, Symbian, BlackBerry OS och Maemo. Utöver standardapplikationer som till exempel adressbok, kalkylator och klocka, utgörs den gemensamma mjukvaran av tredjepartsapplikationer som kan laddas ned från respektive tillverkares applikationsdatabas. Under tredje kvartalet 2009 såldes 309 miljoner mobiltelefoner världen över, vilket är en ökning med 0.1% jämfört med tredje kvartalet Av dessa mobiltelefoner är 41 miljoner klassade som smartphones, vilket är en ökning med tretton procent jämfört med samma period året innan(6). En noterbar trend är att antalet smartphones i världen beräknas passera antalet persondatorer inom tre år(7). 1

9 Inledning År 2005 köpte Google upp företaget Android Inc., vilka först la grunden för operativsystemet Android(8). Två år senare bildades en sammanslutning mellan ett antal företag, Open Handset Alliance. Ett delmål med detta konsortium var att bättre motsvara aktuella kundbehov, genom att gynna utveckling av mobiltelefoni inom områdena mobiloperatörer, mobiltelefontillverkning och applikationsutveckling. Bland de delaktiga företagen finns många stora aktörer såsom; Google, Intel, Texas Instruments, NVIDIA, Qualcomm, Sony Ericsson, Samsung, Motorola, LG, HTC och Vodafone. Deras första nyckelprodukt med gemensam prägel blev plattformen Android(9). Smartphones med Android som operativsystem såldes under tredje kvartalet 2009 i cirka en och en halv miljon exemplar globalt. Detta motsvarar mer än tre procent av den totala mängden smartphones som såldes under samma tidsperiod, se Figur 1 (10). Android erbjuder en öppen utvecklarmiljö baserad på en Linux-kärna med öppen källkod. Hårdvaran är tillgänglig för samtliga applikationer som utvecklas till systemet genom en serie API, Application Programming Interface, bibliotek och interaktion mellan applikationer. Tredjepartsapplikationer och befintliga applikationer som följer med systemet utvecklas med hjälp av samma API. Användare har möjlighet att avlägsna befintliga applikationer och ersätta dem med applikationer från tredjepartstillverkare eller tvärtom(11). 18% 9% 21% 3% 3% 46% Symbian RIM Apple Microsoft Google (Android) Övriga Figur 1. Marknadsandelar för operativsystem hos smartphones Android Market är ett öppet distributionssystem som erbjuder användare att hitta, köpa, ladda ned och installera olika typer av mjukvara från tredjepartstillverkare till sin Androidbaserade enhet. Systemet släpptes officiellt den 28 augusti 2008(12). På Android Market finns såväl kostnadsfri som avgiftsbelagd mjukvara. Utvecklare av en given applikation erhåller 70 % av den totala inkomsten, resterande 30 % tas ut av Android Market i from av en transaktionsavgift(13). 1.2 Syfte Det primära målet med detta projekt är att utveckla ett mobilspel till Android. Gemensamt med detta mål föreligger ett antal delmål: Spelet skall vara anpassat för version 2.1,av Android och kunna publiceras på Android Market. Rapporten skall fungera som en hjälpande guide för utvecklingsprocessen inom området för såväl mobilspel som andra applikationer. Den skall på ett koncist och tydligt vis beskriva utvecklingsmetod, testning samt redovisa förslag på lösningar till problem som uppstått. Erhålla ett kundbetyg på minst 4/5 på Android Market. 2

10 Inledning 1.3 Problemställning Under uppstarten av projektet så diskuterades de problem som kan uppstå vid utvecklingen. Detta avsnitt presenterar och diskuterar dessa problemställningar utifrån projektgruppens egna åsikter och kunskap, dock utan att ge lösningar Möjligheter och begränsningar Android är ett nytt och ständigt växande operativsystem. Nya uppdateringar och nya telefonmodeller kräver att spelet anpassas för både kommande och existerande modeller. Även om dagens telefoner har relativt begränsad hårdvara jämfört med mer avancerade datorer är kravet på spelen stora, vilket kräver metoder som effektiviserar programmeringen för att få ut så mycket som möjligt ur hårdvaran. Mobila enheter öppnar även för ett annorlunda spelsätt som bör tas i åtanke. Personer som spelar på mobila enheter vill förmodligen inte spendera lika mycket tid, under en och samma tidslängd, som personer som spelar tv-spel eller datorspel. Detta för att de erbjuder spelutövande på fler platser och under fler tillfällen på dygnet, till exempel som under en bussresa på väg till studier eller arbete, tack vare deras bärbara egenskap. Dagens telefoner öppnar också för nya och innovativa sätt att utveckla spel på tack vare pekskärm, accelerometer och åtkomst till internet Estetiskt tilltalande spel Det grafiska gränssnittet spelar stor roll för det första intrycket av produkten. Vilken stil man väljer att använda speglar hur bra slutprodukten blir och avgör om användarna kommer att fastna för spelet eller inte. Dessutom är det av stor vikt att skapa ett gränssnitt som är implicit och logiskt, då det finns ont om plats på skärmen Marknadskraftig produkt Eftersom att spelet inte programmeras för eget bruk, utan för att kunna lanseras på Android Market, måste spelet planeras för en bred marknad. Spelet skall helst inte försvinna i mängden av nya program och spel som dagligen lanseras. Därför bör spelet hålla en hög kvalitet och tilltala såväl nya kunder som kunder med mer erfarenhet av spel. Vad behöver implementeras för att locka folk att vilja ladda ner ett spel och även fortsätta att spela det efter ett tag? 1.4 Avgränsningar Redan när projektplanering skrevs så togs beslut om att försöka utveckla ett så komplett spel som möjligt, trots det infördes avgränsningar. I detta avsnitt presenteras dessa avgränsningar Plattform Ett beslut togs tidigt att en avgränsning vad gäller version för Androidplattformen är aktuell. För att spelet skall vara så aktuellt som möjligt vid lansering, togs beslutet att utvecklingen skulle ske för Android 2.1. Detta leder till att inte alla Androidmobiler som finns på marknaden i dagsläget klarar av spelet Mobiltelefoner Vad gäller mobiltelefoner så togs ett beslut angående dess storlek på skärmen. För att spelet skall få den kvalité på grafik som eftersträvas, kommer spelet programmeras till skärmar större 3

11 Inledning än 480x320 bildpunkter, detta eftersom bilder blir mer tilltalande om de skalas ner än om de skalas upp. 1.5 Metod I detta avsnitt behandlas utvecklingsmetoden som användes i projektet. Avsnittet presenterar även information om ansvarsfördelningen i gruppen och det versionshanteringssystem som använts under projektets utveckling Ansvarsfördelning Inför utvecklingen av detta Tower Defence-spel delades arbetet upp i två huvudsakliga ansvarsområden: gränssnittets design och underliggande infrastruktur med spellogik. Projektets medlemmar delade upp sig i två delgrupper med var sitt ansvarsområde, medan gruppen som helhet tagit större beslut som till exempel spelregler och gemensam kodgrund. Uppdelningen inom de olika områdena har varit informell och naturlig då olika medlemmar har valt roller som passar deras kompetens Versionshantering All källkod och övriga resurser som spelet använder sig av har versionshanterats. Istället för att använda ett centraliserat versionshanteringssystem som CVS eller Subversion valdes det decentraliserade systemet Git(14). Som stöd för Git användes Github(15), en gratis webbtjänst som erbjuder användare att publicera sin kod, och dela med sig av uppdateringar till andra utvecklare. Git möjliggör samarbete mellan grupper och personer genom stöd för branching och mergeing. Det är möjligt att skriva experimentell kod i ett separat kod-träd för att i ett senare skede slå ihop dem, även om det första trädet har genomgått ändringar under tiden(14) Utvecklingsmetod Agile software development, kort Agile, kom till under 1990-talet till följd av att många systemutvecklare tröttnat på de omfattande och otympliga metoder som var populära då, exempelvis vattenfallsmodellen. I kontrast till dessa stora och ineffektiva utvecklingsmetoder kom mindre och mer lättrörliga metoder till. År 2001 samlades 17 kända personer inom dessa kretsar vid Snowbird ski resort, Utah, där man kom överens om ett samlingsbegrepp, Agile software development. Till följd av detta möte så skrevs även Agiles principer och värderingar ner i ett manifest som kom att kallas för agilemanifesto, se Tabell 1 och Tabell 2. Agile värdesätter: Individer och samspel framför metoder, processer och verktyg. Körbar programvara framför omfattande dokumentation. Kundsamarbete framför kontraktsförhandlingar. Anpassning till förändring framför att följa en statisk plan. (Alla ovan nämnda saker är värdefulla, men de till vänster värderas högre än de till höger.) Tabell 1. Agiles värderingar, hämtade från agilemanifesto(16) Agiles principer: Viktigast är att göra kunden nöjd genom tidiga och regelbundna leveranser av värdeskapande programvara. 4

12 Inledning Anpassning till förändrade krav och förutsättningar är naturligt, även i ett sent skede; utnyttja förändring till kundens fördel. Leverera användbar programvara ofta, helst med bara några veckors mellanrum. Verksamhetskunniga och utvecklare arbetar tillsammans dagligen. Självgående och ansvarstagande individer är den främsta framgångsfaktorn. Med nödvändigt stöd och förtroende kommer de att lösa uppgiften. Kommunikation ansikte mot ansikte är det bästa sättet att förmedla information, både till och inom teamet. Funktionalitet är det främsta måttet på framsteg. Agile verkar för uthållighet; teamet skall kunna upprätthålla jämn arbetsbelastning så länge som behövs. Kontinuerlig uppmärksamhet på teknisk elegans och bra design stärker anpassningsförmågan. Enkelhet - konsten att göra rätt saker, varken mer eller mindre - är grundläggande. Team som organiserar sig och sitt arbete själva, ger bäst problemförståelse, arkitektur och design. Gruppen utvärderar och anpassar regelbundet sitt arbetssätt för att förbättra sin effektivitet. Tabell 2. Agiles principer, hämtade från agilemanifesto(16). Agile är alltså inte en ren systemutvecklingsmetod, utan ett samlingsbegrepp för en rad olika metoder som i grund och botten har samma principer och värderingar. Arbetssätten inom de olika metoderna är i de flesta fall lika varandra, där uppgifter bryts ned till mindre delar som löses vart eftersom. Iterationerna har korta tidsperioder på en till fyra veckor. När en iteration är klar så skickar utvecklarna sina lösningar till medarbetare och kunden. Detta minimerar risken att inte hinna klart med projektet i sin helhet och gör projektet anpassningsbart för snabba förändringar. Det är även den viktigaste grundpelaren i Agiles utvecklingsprocess, att leverera fungerande programvara snabbt(17). Agile främjar grupparbete och personlig utveckling. Gruppmedlemmarna har individuellt eller tillsammans, beroende på om man jobbar i grupp eller ej, ansvar för sina uppgifter. En av grundpelarna är att uppgiften skall lösas så enkelt som möjligt(17). En annan punkt som skiljer Agile från andra utvecklingsmetoder är sättet att kommunicera. Inom Agile är det viktigt att ha kontinuerlig kontakt med medarbetare och kund, detta sker helst personligen då det blir minst missförstånd när talan sker direkt mellan varandra. Diskussioner skall helst ske dagligen för att uppdatera sina medarbetare vart man ligger tidsmässigt. Enligt Agiles principer är dessa diskussioner nödvändiga för att öka effektiviteten, då interaktionen mellan projektets olika delar förbättras(17). 5

13 Inledning Material Under projektet användes ett antal telefoner för testning av programvara. Specifikationen för telefonerna presenteras i Tabell 3. HTC Hero(18) Processor Qualcomm MSM7200A, 528 MHz Minne ROM: 512 MB RAM: 288 MB Skärm 3,2-tums TFT-LCD-pekskärm med HVGA-upplösning på 320x480 Operativsystem Android 1.5 HTC Desire(19) Processor Qualcomm Snapdragon 8250, 1 GHz Minne ROM: 512 MB RAM: 576 MB Skärm 3,7-tums AMOLED-pekskärm med WVGA-upplösning 480x800 Operativsystem Android 2.1 (Éclair) med HTC Sense Acer liquid s100(20) Processor Qualcomm Snapdragon 8250, 768 MHz Minne ROM: 512 MB RAM: 256 MB Skärm 3,5-tums LCD-pekskärm med WVGA-upplösning på 800x480 Operativsystem Android 1.6 (Donut) Tabell 3. Specifikationer för de telefoner som använts i projektet. 6

14 Teori 2 Teori Kunskap om teorin bakom Android är nödvändig för att kunna utveckla applikationer. Detta avsnitt beskriver de olika delar som utgör Android. 2.1 Androidplattformens beståndsdelar Fyra olika lager utgör operativsystemet och kan ses i Figur 2 för en detaljerad överblick. Nedan följer en beskrivning av var och ett av dessa lager. Figur 2 Androidplattformens fyra lager bestånde av Linuxkärnan, Android Runtime, Application framework och applikationer Linuxkärnan Det nedersta lagret är kärnan i operativsystemet som bygger på Linux. Fördelar med att använda sig av ett befintligt operativsystem som Linux är att basala funktioner redan är implementerade, som till exempel hantering av processer, minne, drivrutiner, nätverksfunktion och en säkerhetsmodell(21). Dessutom är dessa funktioner tidigare testade över tid och är på så vis pålitliga Android Runtime och kodbibliotek Lagret ovanför linuxkärnan består av Android Runtime och dess kodbibliotek. Android Runtime är det som utmärker en Androidtelefon och särskiljer den från en mobil linux-implemetering. Det utgörs av Androids bibliotek och Dalviks virtuella maskin (VM), som är optimerad på så vis att en enhet kan exekvera flera instanser samtidigt. Mer om Dalvik VM går att läsa i avsnitt Application framework Application framework är skriven i Java och förser utvecklaren med de klasser som krävs för att skapa Androidapplikationer. Ramverket ger också tillgång till hårdvarufunktioner och hanterar användargränsnitt. 7

15 Teori Applikationer I det fjärde lagret, Application layer, exekveras alla applikationer såväl de ursprungliga standardapplikationerna som tredjepartsapplikationer. Application layer körs på Android Runtime lagret och använder de klasser och tjänster som tillhandahålls i Application framework. 2.2 Dalvik VM En virtuell maskin är en mjukvaruimplementering av en maskin som exekverar program på samma vis som en fysisk maskin(2). Applikationer som körs på en virtuell maskin har endast kännedom om denna och ej om kärnan som existerar i lagret under. Hos Androidplattformen kallas denna virtuella maskin för Dalvik VM. Dalvik VM utvecklades av Google som en egen implementering av Java VM. Detta på grund av den begränsade hårdvara som finns i telefoner. Således är Dalvik VM anpassad att köras på en enhet med låg klockfrekvens, mindre mängd RAM och med hänsyn till batteritid(22). Som referens kan den första Androidmobilen användas, Google G1. Denna smartphone lanserades i november 2008 och har följande specifikationer: 192 Mb RAM, 1Gb SD-kort och en 528MHz Qualcomm MSM7201A processor(23). I jämförelse med en laptop av märket Dell i nedre prissegmentet(24), vars processor är en 2,13 Ghz Intel Core I3-330M och med 3Gb RAM, blir skillnaden signifikant. Optimeringen av Java VM påvisas framförallt inom ett antal områden som tas upp i följande text. Utvecklaren programmerar sina Android-applikationer i språket Java. Dock används inte traditionella Java-klassfiler. Dalvik VM konverterar Java-klassfilerna och kombinerar dem till en eller flera Dalvik Executable -filer (.dex). Den tar bort överflödig information som finns i klassfiler vilket reducerar storleken på den exekverbara filen till ungefär halva storleken(22). Garbage collection är anpassad för en miljö med lite minne(22). Dalvik VM försöker använda sig av CPU-register istället för en stack. Statistik visar att antalet instruktioner minskar med 30% med hjälp av denna metod(22). 2.3 Spelbeskrivning - Tower Defence Med den ökande populariteten av spel på smarthones har nya typer av spelgenrer utvecklats till det bärbara formatet. En av dessa genrer är Tower Defence, som har sitt ursprung från flera av de klassiska Real-time Strategy-spel som utvecklades för spel till datorer. Några exempel på dessa spel är Command & Conquer, Starcraft och Warcraft: Orcs and Humans. Se Figur 3. Ett Tower Defence-spel består av en spelplan där ett visst antal fiender skall försöka ta sig från punkt A (startpunkt) till punkt B (mål). Spelarens uppgift är att placera ut torn strategiskt på spelplanen som eliminerar fienderna så de ej når slutmålet. Spelaren har en begränsad mängd resurser att bygga torn med. Det finns även en indikator för hälsa. För varje fiende som lyckas nå sitt slutmål, kommer värdet på hälsan för spelaren att reduceras. När spelarens hälsa tar slut är spelet över. Om däremot spelaren lyckas klara samtliga nivåer har spelaren vunnit. Utöver denna generella spelbeskrivning, kan ett Tower Defence-spel vara uppbyggt på varierande vis. Följande beskriver mer ingående den typen av Tower Defence som utvecklats i detta projekt. 8

16 Teori Fienderna äntrar spelplanen i olika vågor, en ny våg innebär en ny nivå i spelet. Antal och typ av fiender kan variera mellan de olika nivåerna. Egenskaper som kan vara säregna för varje fiendetyp är mängden hälsa, hastighet, värde och resistans mot vissa torn. Om ett av tornen eliminerar en fiende resulterar det i att spelarens resurser ökar med fiendens värde. Det finns tre olika typer av resistans: eld, is och gift. En fiende som är resistent mot eld förlorar ej lika mycket i hälsa om den blir träffad av ett torn som är av typen eld, jämfört med en fiende som ej är det. Detsamma gäller för övriga typer av resistens. Längs med spelplanen sträcker sig en förutbestämd väg, vilken fienderna följer från start till mål. Spelaren är således medveten om vilka koordinater på spelplanen som en fiende kan befinna sig på. Innan fienderna påbörjar sitt anfall har spelaren ett antal sekunder på sig att förbereda sin strategi och sätta ut nya torn. Figur 3. Skärmdump från gruppens Tower Defence-spel. Torn har olika egenskaper, där varje egenskap varierar beroende på typ av torn, exempelvis mängd skada, verkningsradie, skottfrekvens, kostnad och säljvärde. Ett torn kan uppgraderas i två steg efter byggnation. Uppgraderingen bidrar till ett eller flera förbättrade värden av tornets egenskaper. Det andra uppgraderingssteget erbjuder dessutom att välja vilken elementtyp som tornet skall ha (eld, is eller gift). Torn kan byggas överallt på spelplanen frånsett ett par undantag. Det går ej att bygga torn på den väg vilken fienderna förflyttar sig på. Likaså kan en sten, ett träd eller en buske på spelplanen förhindra åtkomst till byggnation. Det finns således mängder av kombinationer för spelaren att försvara sig mot fienderna. Denna speltyp kräver såväl strategiskt tänkande som förmågan att ta snabba beslut av spelaren(25). 9

17 Applikationsutveckling för Androidplattformen 3 Applikationsutveckling för Androidplattformen För att utveckla applikationer till Androidplattformen finns olika hjälpmedel att tillgå. Dessa inkluderar såväl program som verktyg och behandlas i detta avsnitt. 3.1 Android Software Development Kit Android Software Development Kit, SDK, innehåller samtliga komponenter som krävs för att utveckla, testköra och felsöka Android-applikationer(26). Kärnan i SDK är Androids APIbibliotek som ger utvecklare tillgång till de datatyper som ingår i Android, se Figur 2 för exempel på kodbibliotek. Dessa bibliotek är desamma som brukas av Google då de utvecklar sina ursprungliga Android-applikationer. I SDK:n ingår även Android-emulatorn, den används för att testa en applikations utseende och funktion på en virtuell Androidenhet. Fullständig dokumentation är också inkluderad, vilken ger detaljerad information om samtliga paket och klasser, samt beskrivningar för hur de används. SDK:n innehåller även ett antal kodexempel som demonstrerar en del av möjligheterna hos Android, genom användandet av specifika delar från API. Till detta projekt användes den senaste versionen av Android SDK som i dagsläget är Programspråk och utvecklingsmiljö Vid utveckling av Androidapplikationer är Java ett krav, för att till exempel interagera med resten av systemet och förfoga över pekskärm, ljud och andra tjänster som ingår i projektet. Det är möjligt att skriva rutiner i C och C++, för att sedan kalla på dessa ifrån Java. Dock kan man ej kommunicera med resten av plattformen i dessa rutiner, vilket hindrar utvecklare att skriva hela kodbasen i dessa språk. Till projektet användes utvecklingsmiljön Eclipse som är den enda utvecklingsmiljö som har stöd för ADT, Android Development Tools, plug-in. 3.3 Eclipse Eclipse utvecklades av IBM och lanserades år 2001, med syftet att reducera den stora mängd inkompatibla utvecklingsmiljöer som då fanns tillgängliga för utvecklare. Genom Eclipse utvecklingsmiljö kunde utvecklare använda varandras komponenter och tack vare integrationen av flertalet utvecklingsverktyg smidigt förflytta sig mellan olika projekt. Eclipse erbjuder möjligheten att utvidga produkter som bygger på plattformen via plug-in mekanismer(27). Till detta projekt användes Eclipse Classic 3.5.2, eftersom detta är den senaste versionen av Eclipse som stöder ADT. Operativsystemen Windows, Linux och Mac OS X är alla kompatibla med denna version vilket ej utgjorde någon begränsning för gruppmedlemmarna till detta projekt. 3.4 Android Development Tools ADT är en plug-in som ingår i SDK och finns till Eclipse. ADT ger god överblick av de verktyg som finns för utveckling av applikationer till Androidplattformen. Utvecklaren har tillgång till verktyg som existerar i Dalvik Debug Monitor Service-verktyget, DDMS, till exempel möjligheter att ta skärmdumpar, utläsa debug-text, sätta ut brytpunkter i koden och att analysera processinformation direkt i Eclipse. 10

18 Applikationsutveckling för Androidplattformen ADT erbjuder en guide för att skapa nya Androidprojekt som bygger den katalogstruktur och genererar de filer som behövs för en Androidapplikation. En textredigerare anpassad för Android-kod är också inkluderad, med stödet att skriva XML-kod för källfilerna i ett Androidprojekt. En smidig funktion som ADT automatiserar är att exportera projekt till en signerad APK-fil. APK-filen är ett ZIP-arkiv som innehåller.dex-filen. Det är APK-filen som distribueras till Android Market. Exempel på ytterliggare verktyg som existerar i ADT är Hierarchy Viewer och Traceview. Till en början användes ADT revision 0.9.5, som lanserades i december Halvvägs in i projektet uppdaterade samtliga gruppmedlemmar ADT till revision 0.9.6, vilken blev tillgänglig mars Emulator Emulatorns funktion är att simulera Androidplattformen på en dator. Emulatorns miljö är begränsad då den ej har samma funktioner som en smartphone. Till exempel saknas stöd för testning av USB-anslutning, fotografering, videoinspelning, användning av hörlurar, simulering av batteritid samt Bluetooth-anslutning. Emulatorn exekverar sina processer genom en emulator-teknologi, QEMU(28), som är likvärdig med den som tillåter simulering av ett operativsystem ovanpå ett annat utan hänsyn till processorn. Emulatorn stöder konfigurationer för Android Virtual Device, AVD. AVD ger utvecklare möjligheten att specificera vilken version av Androidplattformen som skall köras på emulatorn, samt modifiera hårdvaruinställningar(29). Exempel på hårdvaruinställningar är knappsats, mängd minne, emulerat SD-kort och definition av skärmupplösning. Man kan skapa ett obegränsat antal AVD:er, beroende på vilken typ av Androidenhet man vill efterlikna. 3.6 Androidenhet Även om emulatorn erbjuder testning av Androidapplikationer, finns möjligheten att använda en fysisk enhet. Olika metoder existerar för att installera stöd för applikationsutveckling på en enhet beroende på operativsystem. Vid utveckling på Linux krävs en fil som innehåller regler för USB-konfigurationen och ett unikt id för enheten. MAC OS X kräver inga ytterliggare inställningar. Vid utveckling på Windows krävs installation av drivrutiner för USB-anslutningen. Under projektets gång har kandidatgruppen använt sig av operativsystemen MAC OS X, Windows Vista, Windows 7 samt Ubuntu Linux. Version av drivrutiner för USB-anslutning som användes var Androids USB Driver for Windows, revision 3, som släpptes januari Android Debug Bridge Android Debug Bridge, ADB, är ett server-klient-program som ansluter till en emulator eller en Androidenhet. Utvecklaren har, via ADB, möjlighet att individuellt hantera varje specifik instans av emulatorn. ADB erbjuder i huvudsak två tjänster, varav en är en klient som körs på datorn. Klienten kan anropas antingen från ett shell, exempelvis kommandoprompten i Windows, eller genom ADT plug-in i Eclipse. Den andra tjänsten är en server som körs i 11

19 Applikationsutveckling för Androidplattformen bakgrunden på datorn. Servern hanterar kommunikationen mellan klienten och ADB:n som körs på emulatorn eller Androidenheten(30). 3.8 Dalvik Debug Monitor Service Dalvik Debug Monitor Service, DDMS, är ett verktyg för utvecklaren som bidrar med en tydlig bild över vad som händer då en applikation exekveras, antingen på en emulator eller på en ansluten enhet. DDMS agerar som mellanhand för att ansluta IDE:n till applikationen som exekveras. På Android körs varje applikation som en egen process med tillhörande VM. Där varje process lyssnar efter en debugger på en separat port(31). När en Androidenhet ansluts till en dator så startar en övervakningstjänst mellan DDMS och ADB. Övervakningstjänsten meddelar DDMS när en enhet ansluts eller kopplas från. När en enhet är ansluten skapas en anslutning till debuggern. Detta görs för varje enhet som ansluts. Således finns möjlighet använda debuggern på flera enheter samtidigt. DDMS erbjuder en överblick över anslutna enheter och tillgång till verktyget LogCat. LogCat registrerar statusrader från Android och dess exekverades applikationer. Det går att applicera filter på LogCat, exempelvis går det att visa de loggar som har definierats med en unik tag för en specifik applikation. Processinformation för aktuell VM är integrerad i DDMS och det finns möjlighet att följa aktiviteten hos skräphanteraren, samt att manuellt aktivera denna. Exempel på andra tjänster som följer med DDMS är möjligheten att sätta ut brytpunkter i koden, ta skärmdumpar, uppdatera koordinater för den virtuella GPS:en samt hantera virtuella telefonsamtal och meddelanden i emulatorn(32). 12

20 Grafisk design och formgivning 4 Grafisk design och formgivning Grafisk design och formgivning kan inte anses vara en exakt vetenskap, istället kan det tyckas att det baseras på användarintryck, uppfattning och framförallt smak; likväl kan man med enkelhet särskilja ett grafiskt välgjort spel, därför anser projektgruppen att även om smaken kan variera från person till person så kan en välgjord grafisk design och formgivning ge ett professionellt intryck som signalerar kvalité. Utmaningen låg i själva skapandet och att kunna analysera resultatet. Som granskare användes projekt- och testgruppens omdöme då några större empiriska undersökningar inte kändes aktuella eller genomförbara inom projektets tidsram. De delar som framförallt utgör denna del är layout, färglära, bild och form samt bildhantering dessa kommer behandlas i kommande avsnitt. Att ett spel uppfattas som snyggt och attraktivt kan anses påverka användarupplevelsen till det bättre, det faktum att samtliga spelutvecklingsföretag har stora grafikavdelningar pekar på detta. Ett genomgående tema och en enhetlighet i grafisk design och formgivning bidrar enligt projektgruppen till en helhet som gör att spelet ser professionellt och tilltalande ut; om det dessutom kan stå ut från mängden bidrar även det till att spelet ger ett unikt och minnesvärt användarintryck. På grund av detta lades stor vikt vid spelet utseende och användarvänlighet. Ett tema togs fram för att skapa enhetlighet, valet föll på sött möter blod, som illustreras i Figur 4, då det kan anses sticka ut och roa användaren. Bland de skrotade temaalternativen fanns futuristiskt med robotar, lasrar och liknande samt medeltid med pilbågar och katapulter. Att valet föll på just sött möter blod var, förutom det tidigare nämnda påståenden, att en tecknad stil kunde tillämpas vilket underlättade för gruppen då endast begränsade grafiska kunskaper fanns att tillgå. Nedan nämns de viktigaste verktyg och tillvägagångssätt som användes för att skapa detta tema och spelets grafik. I appendix C kan all grafik beskådas. 4.1 Fiender och torn Vid utvecklingen av de fiender och torn som figurerar i spelet så fanns det mer eller mindre ett krav, storleken på dem fick inte vara större än 64x64 bildpunkter. Detta på grund av att OpenGL endast kan läsa in bildobjekt med tvåpotens, mer om detta under Rubrik Med temat för spelet i tankarna togs en hel del idéskisser fram som sedan gruppen godkände för användning. När väl en fiende eller ett torn fått godkännande så realiserades skissen med hjälp av Photoshop. Figur 4. Kanin med kula i ryggen som visas i huvudmenyn i spelet. Figur 5. Dödsbild av fiende. 13

21 Grafisk design och formgivning För varje fiende målades benen som ett spritesheet för att få en animation. Ett spritesheet består av en bild i PNG-format som innehåller de bildrutor som skall animeras, i Figur 6 visas ett exempel med två rutor. Varje fiende har även en tillhörande dödsbild som ersätter den levande animationen när en fiende elimineras, detta kan ses i. Tornen har målats i samma stil som fienderna, dessutom har alla torn två extra bilder för uppgraderingar. Skotten till tornen har likt fiendernas fötter realiserats med hjälp av spritesheet för att få en välgjord animation vid träff, detta kan ses i appendix C. Figur 6. Spritesheet för gånganimationen. 4.2 Photoshop Adobe Photoshop är ett bildredigeringsprogram som används av grafiker världen över för att skapa, manipulera och redigera bilder. Det är vida känt som ett av de bättre alternativen för detta, ett annat är Adobe Illustrator som använder sig av vektorgrafik till skillnad från Photoshop som tillämpar bildpunktsgrafik. Då det redan fanns kunskap om Photoshop valdes detta som verktyg för att skapa spelets grafik. I följande avsnitt behandlas de viktigaste och mest användbara funktioner samt verktyg som programmet har att erbjuda Färgval De flesta grafiker väljer en färg för att förmedla en känsla(33) och enligt Sibagraphics(34) kan färger bära budskap som är oberoende av användarens etnicitet, kultur och kön; därför gick mycket arbete åt för att hitta färger som förmedlade rätt känsla till användaren framförallt logotypen och de kaniner som kan ses på startmenyn. Valet blev rosa då det förmedlar kärlek, romans, Figur 7. Spelets ikon, ett R med kaninöron. lugnande och fred(34), en ytterst passande färg för kaninen som representerar de fiender som användaren kommer stöta på i spelet då målet är att skapa en gullig och mysig sådan. Denna färg används även i logotypen men i ett starkare utförande, detta förmedlar ungdomlighet och energi vilket är det som framförallt skall förmedlas första gången man stöter på applikationen. Logotypen återkommer som ikon men då bara i form av R:et som kan ses i Figur 7 och är det första användaren ser i Android Market, målet är att försöka ge ett fräscht och kraftfullt intryck samt att sticka ut från mängden med en starkare färg. 14

22 Användargränssnitt och interaktion Färgmättning I Photoshop är det möjligt att justera en bilds färgmättning, ton och styrka. Detta verktyg användes dels för att justera gräsbanans färgmättning men också för att göra knapparna i menyn (se Figur 10). En för grå färgmättning i förhållande till startmenyn användes till en början på gräsbanan, detta åtgärdades genom att höja färgmättningen enligt Adobes guide och resultatet går att se i Figur 8. Banan blev mer i samspel med startmenyn och dessutom kan det anses att detaljer och konturer syns bättre. Figur 8. Skillnaden i färgmättning, bilden till höger har fått höjd färgmättning. 5 Användargränssnitt och interaktion Det huvudsakliga målet med gränssnitten är att förse användaren med lättbegriplig information och logiska spelkontroller. För att åstadkomma detta är gränssnitten baserade på tidigare spelapplikationer, med särskilda modifieringar för att anpassa dem efter de funktioner som existerar i detta projekt. Två typer av gränssnitt förekommer, dels det gränssnitt som utgör huvudmenyn med dess olika undermenyer, samt användargränssnittet som är aktivt under själva spelfasen. Den agila utvecklingsmetoden och uppdelningen av gruppen har resulterat i att arbetet i stora drag utförts parallellt mellan grafik samt formgivning och implementering, och hela tiden utvecklats samt förfinats under projektets gång. Detta avsnitt är upplagt att presentera de bakomliggande grafiska layout-teorier samt utförande först följt av implementeringsbeskrivning. 5.1 Grafisk utformning av gränssnitt För att kunna ta fram ett fungerande grafiskt gränssnitt till projektet behövdes till en början en idé samt en idéskiss som förmedlar detta till samtliga deltagare i arbetet, dessutom krävs det kunskap kring gränssnittsdesign. 15

23 Användargränssnitt och interaktion Till hjälp för att producera en idéskiss finns diverse mockup-program verktyg som gör det möjligt att göra en snabb grafisk prototyp som till skillnad från penna och papper är lätta att justera och ändra. I dagens läge är det ont om gratis mockup-program som riktar sig till Android-utveckling och de som finns håller enligt gruppens egna tester inte tillräckligt hög kvalité för att kunna underlätta arbetet. Detta jämfört med att använda sig av ett vanligt bildbehandlingsprogram som det redan i gruppen finns kunskap kring. 1 Nedan följer mer ingående de viktigaste momenten vid utformningen av de ovan nämnda gränssnitten Spelplan För att utforma detta gränssnitt så specificerades vilken information som behöver förmedlas till användaren såsom pengar och liv, samt vilka funktioner som skall finnas till hands som exempelvis möjligheten att bygga ett torn. Detta resulterade i en kravspecifikation som vidare utökades på grund av att det råder ständig platsbrist på en mobilskärm till att så mycket av skärmen som möjligt skulle ägnas åt själva spelet. Vad som gick att urskilja ur kravspecifikationen var tre delar i huvudsak; en meny med knappar (Figur 9.a) som utförde olika kommandon för användaren, en statusbar (Figur 9. c) där information presenterades samt en spelplan (Figur 9. b). Att placera knappmenyn på undersidan spelplanen föll sig naturligt då tummen placeras i denna höjd på de flesta telefoner. Idén att låta banan ha blandade perspektiv föddes ur att vi helst ville ha en naturlig statusbar det vill säga inte en svart remsa med Figur 9. Spelplanens uppdelning. text längst upp utan snarare något som kunde förhöja intrycket av banan men samtidigt förmedla information; dessutom bidrar detta designmönster till en enhetlighet mellan de olika banorna Interaktion Själva spelplanen kan framförallt använda sig av två layouter om man ser till befintliga tower defence-spel(35)(36); antingen ett rutnät där användaren endast kan placera torn i tomma rutor eller en friare lösning där en algoritm för kollision mellan önskad torn-placering och anfallarnas väg eller andra hinder behöver implementeras. Fördelen med ett rutnät är framförallt att användaren har lättare för att placera tornet på önskad plats och risken för felplaceringar eller feltryck på skärmen bör teoretiskt sett minska då rutnätets knappar är större än en specifik punkt. 1 Framförallt testades DroidDraw, ett av de få gratis mockup-programmen för Androidapplikationer på marknaden i skrivande stund. 16

24 Användargränssnitt och interaktion Apple och Google har båda viss dokumentation på sina respektive utvecklarsidor kring vad de anser vara god interaktionsdesign vid utveckling av mobila applikationer, något som har applicerats i utvecklingen av spelet. Enligt Apple bör användaren få feedback vid varje interaktion med gränssnittet i form av en förändring i färg på en knapp eller en animation, detta får användaren att känna att applikationen är snabb, tydlig och mottaglig (37). I spelet tillämpas detta på knappar i de båda gränssnitten och kan ses i Figur 10. Figur 10. En knapps tre tillstånd Huvudmeny Det första som användaren ser efter introduktionssekvensen är huvudmenyn. Denna har, ihop med dess undermenyer, ett genomgående tema. Från huvudmenyn kan användaren navigera sig till de olika delarna som spelet erbjuder såsom en- och flerspelarläge, inställningar, spelinformation och information om utvecklarna. Knapparna som används för navigation tar upp en betydande del av skärmen, detta för att göra det lättare att träffa dem med ett finger på pekskärmen. Möjligheten att navigera med knappsats på telefonen finns också. Varje separat sida som ingår i huvudmenyn är representerad av en så kallad aktivitet; detta behandlas utförligare under Rubrik Knappmeny och torninformation Ett problem som var överhängande vid utvecklingen var den tidigare nämnda platsbristen på skärmen och framförallt då mycket information behöver förmedlas, ett exempel är hur man på ett effektivt vis skall presentera varje torns räckvidd, pris, styrka och liknande utan att behöva ta mer plats till menyn från spelplanen. Enligt Tidwell är card stack en god lösning på problemet; (38) detta innebär i korthet att man lägger information i ett fliksystem. Med detta i åtanke arbetades det fram en anpassad lösning för vår mobila enhet, antingen kunde vi välja att göra tornknapparna mindre med flikar ovanför eller att varje knapp användes som en stor flik. Det sistnämnda blev det som implementerades enligt Figur Aktivitet Aktiviteten handhar de datastrukturer som utgör användargränssnittet och styrs över tid, antingen genom användaren eller av operativsystemet. Aktiviteten kan befinna sig i ett antal tillstånd, vilka är en förutsättning för att användaren skall kunna interagera med telefonens funktioner(39), detta illustreras i Figur 11 som visar en aktivitets livscykel. 17

25 Användargränssnitt och interaktion Figur 11. Livscykeln hos en aktivitet. När aktiviteten först skapas, anropas metoden oncreate(). Här skapas de vyer och referenser till synliga objekt, exempelvis bilder, som aktiviteten använder sig av. Tillfället innan aktiviteten blir synlig på skärmen körs onstart(). Aktiviteten behöver dock ej bli synlig, om den av någon anledning ej skall vara förgrundsaktiviteten. I annat fall anropas metoden onresume(). I denna fas av livscykeln sker interaktionen mellan användare och aktivitet genom input från skärmen eller telefonens knappsats. OnResume() anropas även då aktiviteten ej befinner sig i förgrunden på grund av en annan aktivitet, som slutligen avslutas och åter sätter aktuell aktivitet i fokus. När aktuell aktivitet inte befinner sig i förgrunden, det vill säga att en annan aktivitet sätts i fokus, körs metoden onpause(). Under denna fas har aktiviteten som sätts i vänteläge ej tillgång till skärmen. Utvecklarens uppgift är då att tillfälligt stoppa överflödiga processer i denna fas som körs i bakgrunden och konsumerar batteri och processorkraft i onödan. 18

26 Användargränssnitt och interaktion Möjligheten finns dock att aktiviteten inte återupptas i det fall då minnet tar slut på den telefonenhet som exekverar spelapplikationen och således måste avsluta aktiviteten för att skapa utrymme till systemprocesser med högre prioritet. Android har följaktligen behörighet att avsluta aktiviteten då den befinner sig i detta tillstånd. onstop()-metoden körs då aktiviteten ej längre är synlig, antingen på grund av att en annan aktivitet placeras i förgrunden eller för att aktuell aktivitet avslutas. I aktivitetens sista tillstånd i livscykeln har ondestroy() anropats. Väl i detta tillstånd är sista möjligheten för aktiviteten att exekvera ytterligare kod innan finish() anropas, som avslutar aktiviteten. För att skifta och kommunicera mellan olika aktiviteter, används så kallade Intent. 5.3 Intent Intent-objekt kan beskrivas som en mekanism för transport av meddelanden, som tillåter applikationer att specificera enskilda aktiviteter. De används för att skapa schemat för vilken aktivitet som placeras i förgrunden beroende på händelse. Aktiviteterna startas antingen explicit eller implicit(40). Vid explicit exekvering anges aktivitetens klassnamn (se kodexempel 1) som komponent. Det gäller då att applikationen har en referens till klassen som skall startas, vilket innebär att denna metod är mest frekvent i de fall då aktiviteter tillhörande aktuell applikation skall startas. Enbart explicit exekvering har använts under detta projekt. 00 : Intent intent = new Intent(Aktivitet.this, NyAktivitet.class); 01 : startactivity(intent); Kodexempel 1. Explicit exekvering av aktiviteten NyAktivitet. Implicit Intent innebär att en referens till en given klass saknas. Det är således upp till Androidsystemet att avgöra vad Intent-objektet skall användas till, detta sker genom information deklarerad i Manifest.xml (se Rubrik 5.6). Denna typ av exekvering utgör det stöd för interaktion mellan olika applikationer som finns i Android, där såväl interna, system- som tredjepartsapplikationer ingår. Exempel på förekomsten av sådana Intent:er hos Android är de som meddelar angående status för internetuppkoppling, batterinivå, sms-hantering och inkommande telefonsamtal. Det finns också stöd för att skicka extra data mellan aktiviteter med hjälp av Intent:er. Här används metoden putextra, vilken tar två argument. Det första argumentet utgör en referens till den data som skickas med i form av en textsträng. Det andra argumentet är den typ av data som skickas. Spelet använder sig av denna metod för att vidarebefordra de val som spelaren utför i huvudmenyn. 5.4 Androids Användrgränssnitt och XML Programmering inom gränssnitt-ramverket kan utföras på två olika sätt. Antingen kan dispositionen för användargränssnittet i de olika aktiviteterna och menyerna skapas med hjälp av ren Java-kod, där man bearbetar de olika gränssnitts-komponenterna representerade som objekt. Alternativt kan XML-filer användas, en aktivitet eller meny laddar då den XML-fil som definierar tänkt disposition som ett fönster. 19

27 Användargränssnitt och interaktion Ett fönster utgörs av vyer, den primära byggstenen i ett användargränssnitt på Android. Mer specifikt definieras en vy som en datastruktur, vars egenskaper utgör parametrarna för dispositionen och innehållet för en särskild rektangulär area i fönstret(41). Exempel på dessa egenskaper är dess vertikala höjd, horisontella bredd, färg, fokus och händelser vid beröring av skärmen inom den rektangulära area i vilken vyn ligger. Vyerna ordnas enligt en trädstruktur med en rot och en hierarki av vyer(39). Varje enskild vy agerar förälder till de vyer den innehåller, det vill säga de vyer som befinner sig ett steg längre ned i hierarkin och barn till den vy i vilken den existerar. Vyer kan struktureras på oändligt många sätt i relation till varandra, vilket ger utvecklaren möjlighet att skapa dispositionen för användargränssnittet enligt exakta premisser. Kodexempel 2 visar ett exempel på innehållet i en XML-fil med en hierarki av vyer. I detta exempel består roten i hierarkin av vyn LinearLayout, som täcker hela fönstret genom parametrarna fill_parent hos höjd- och breddegenskaperna. Roten har två barn, en textvy och en knapp. En beskrivning av de olika vyerna som existerar i Androids gränssnitts-ramverk följer nedan. 00 : <?xml version="1.0" encoding="utf-8"?> 01 : <LinearLayout 02 : xmlns:android=" 03 : android:layout_width="fill_parent" 04 : android:layout_height="fill_parent" 05 : android:orientation="vertical" > 06 : <TextView android:id="@+id/text" 07 : android:layout_width="wrap_content" 08 : android:layout_height="wrap_content" 09 : android:text="detta är en textvy" /> 10 : <Button android:id="@+id/button" 11 : android:layout_width="wrap_content" 12 : android:layout_height="wrap_content" 13 : android:text="detta är en knapp" /> 14 : </LinearLayout> Kodexempel 2. En hierarki av vyer som utgör en XML-fil. En vy kallad FrameLayout kan beskrivas som en vy utan specifikationer, den reserverar helt enkelt en rektangulär yta på skärmen för en ensam vy att befinna sig i. LinearLayout är en vy som organiserar sina barn antingen i rader eller i kolumner. En TableLayout organiserar sina barn i tabeller, vilket kan jämföras med en HTML-tabell. Den möjliggör flertalet undervyer att befinna sig på samma rad eller i samma kolumn. En vy som tillåter exakt placering av sina undervyer går under benämningen AbsoluteLayout. Den placerar undervyerna baserat på parametrarna för bildpunktsvärden. Detta resulterar i att utseendet kommer att bli olika beroende på vilken upplösning på skärmen aktuell telefon har. Ytterliggare en vy är RelativeLayout som positionerar undervyerna i relation till varandra. 20

28 Användargränssnitt och interaktion Vid skapandet av de gränssnitts-komponenter som ingår i aktiviteterna och menyerna i applikationen användes XML-baserad layout kombinerat med modifiering av vyerna i Java. I XML-filerna är LinearLayout i kombination med TableLayout de vyer som nyttjas mest i detta projekt. 5.5 Hierarchy Viewer Under skapandet av samtliga aktiviteter användes Hierarchy Viewer, vilken går att se i Figur 12, som ingår i Android Development Tools (se avsnitt 3.4), för att strukturera gränssnittskomponenterna efter den disposition som bestämts, samt vid de tillfällen då felsökning av gränssnittskomponenterna utfördes. Detta verktyg är designat för att visualisera dispositionen av vyerna, som de visas under exekveringen av en aktivitet(42). Exempelvis kan man fastställa hur mycket plats en specifik gränssnittskomponent tar, eller identifiera en specifik vy som inte är synlig på skärmen. Hierarchy Viewer presenterar vyerna enligt den trädstruktur de är skapade efter. Vid markering av en specifik vy, åskådliggörs samtliga egenskaper för denna vy och dess parametervärden. Dessa värden går ej att redigera, utan är endast till för att upplysa om vyns nuvarande tillstånd. Ett annat mindre fönster som ingår i verktyget presenterar ramarna för varje gränssnittskomponent. Ramarna är placerade efter Figur 12. Skärmdump av Hierarchy Viewer, ett layoutverktyg för XML-redigering hur de skulle placeras på skärmen hos en telefon. Då en vy markeras i trädstrukturen, skiftar ramen för aktuell vy färg i detta fönster. Syftet är att man lätt skall kunna identifiera vilken vy i trädstrukturen som befinner sig på en specifik position på skärmen. Med Hierarchy Viewer finns också möjligheten att studera dispositionen för aktiviteten bildpunkt för bildpunkt. Genom att markera vald area i ett fönster som förhandsgranskar innehållet på skärmen, presenteras samma area i närbild i ett annat fönster, i ett rutnät där varje ruta utgör en bildpunkt på skärmen. 5.6 AndroidManifest.xml En Androidapplikation måste innehålla en XML-fil kallad AndroidManifest.xml, som befinner sig i rotkatalogen hos applikationen(43). I filen deklareras bland annat de aktiviteter som ingår i applikationen, de händelser vilka aktiviteterna skall initieras genom och olika tillstånd. Exempel på tillstånd som kan ges är åtkomst till kamera på aktuell Androidenhet och Bluetooth, men även tillstånd till aktiviteter och andra komponenter som ryms inom den egna applikationen. I filen deklareras dessutom namnet på applikationen, den lägsta versionsnivå av Android som 21

29 Användargränssnitt och interaktion krävs samt vilka bibliotek som utnyttjas. Innehållet i AndroidManifest.xml representeras genom XML, se kodexempel 3. Rottaggen i XML-filen utgörs av <manifest>, inom denna tagg anges alltid en och samma länk som möjliggör användande av olika attribut och taggar i filen. Här deklareras även vilket paket som manifestet tillhör genom attributet package. Parametern versioncode anger den interna versionen för applikationen, den är således till för utvecklaren/utvecklarna att kunna skilja de olika versionerna av applikationen åt. Detsamma gäller för parametern versionname, som är synlig för användarna till applikationen. <?xml version="1.0" encoding="utf-8"?> <manifest xmlns:android=" package="com.crackedcarrot.menu" android:versioncode="1" android:versionname="1.0"> <uses-sdk android:minsdkversion="7" /> <uses-permission android:name="android.permission.bluetooth_admin" /> <uses-permission android:name="android.permission.bluetooth" /> <application android:icon="@drawable/applikations_ikon" android:label="@string/applikations_namn" android:theme="@android:style/theme.notitlebar" android:debuggable="true"> <activity android:name=".intro" android:label="@string/app_name" android:screenorientation="portrait"> <intent-filter> <action android:name="android.intent.action.main" /> <category android:name="android.intent.category.launcher" /> </intent-filter> </activity> </application> </manifest> Kodexempel 3. Ett exempel på AndroidManifest.xml och dess olika element. En applikation har från början inte tillstånd från operativsystemet att påverka andra applikationer eller att få åtkomst till hjälpmedel utanför dess egen omgivning(44). För att applikationen skall få detta krävs taggen <uses-permission>. I detta projekt används <usespermission> för att få tillgång till Bluetooth i spelet, samt för att få tillgång till möjligheten att spara data i minnet, vilket används för att spara ett pågående spel och spelets inställningar. I exemplet nedan syns två taggar för att få tillgång till Bluetooth: Android.permission.BLUETOOTH vilket krävs för att kunna utföra kommunikation över Bluetooth, till exempel att begära en anslutning, acceptera en anslutning och att skicka data över anslutningen. Den andra taggen, android.permission.bluetooth_admin, krävs för att 22

30 Användargränssnitt och interaktion kunna upptäcka andra enheter med aktiverad Bluetooth-funktion, samt för att ha möjlighet att ändra inställningarna för Bluetooth på aktuell Androidenhet. De komponenter som ingår i en applikation deklareras i taggen <application>. Här finns också parametrar för exempelvis ikonen, namnet som visas under ikonen, om ett specifikt tema skall finnas för samtliga aktiviteter som ingår, samt om det skall finnas möjlighet för debuggning. En av de nästlade taggar som finns i <application> är <activity>. Samtliga aktiviteter är deklarerade på detta vis. En av aktiviteterna skall agera startpunkt för applikationen, vilket kan jämföras med metoden main i Java. Detta görs genom att använda <intent-filter> för gällande aktivitet, med taggarna <action> och <category> som specificerar att det är just initieringen av applikationen som anges. 23

31 Implementering 6 Implementering Detta avsnitt beskriver de viktigaste klasserna som utgör spelet. Avsnittet tar även upp metoder för optimering av kod. 6.1 Spelmotor Spelmotor brukar vara benämningen på den del som hanterar mekaniken i ett spel, det kan vara allt från grafik till fysik och andra beräkningsmoment. I denna rapport särskiljs grafikdelen från spelmotorn och behandlas istället i avsnitt 6.2, Rendering. Spelmotorn syftar enbart på den kod som gör beräkningar på spelmekaniska objekt, allt från fienders rörelser, till tornens avståndsberäkningar. Under skapandet av spelmotorn bör man tänka flexibelt för att lätt kunna ändra befintlig funktionalitet, samt stödja eventuella funktioner som ännu ej är påtänkta. Spelmotorn körs i en egen tråd skild från resten av spelet och kommer att uppdateras så ofta den kan, dock max sextio gånger per sekund. Eftersom max sextio bilder ritas per sekund av grafikmotorn, går fler uppdateringar inte att visa på skärmen. Spelmotorns beräkningar är baserade på en central klocka. Beräkningar använder tidsdifferensen mellan två uppdateringar av spelplanen, vilket gör att oberoende av telefonens prestanda så kommer spelet alltid fortskrida i samma takt. Detta leder också till att spelmotorn fungerar väl i nätverkspel eftersom mycket dataöverföring går att undvika så länge klockorna är synkroniserade mellan telefonerna. Nedan följer de viktigaste klasserna som ingår i spelmotorn se Figur 13. Figur 13. Förenklat klassdiagram över de klasser som utgör spelmotorn. 24

32 Implementering GameLoop Denna klass är själva hjärtat i spelmotorn, och består av en loop vars huvuduppgift är att beräkna tidsdifferensen mellan uppdateringar och skicka den till Tower och Creature klassen. När spelmotorn först initieras kommer GameLoop att allokera all data som spelmotorn kommer att behöva under spelets gång för att undvika aktivering av garbage-collectorn under en spelomgång. Vid intitiering ladddas nästa nivå av fiender och därefter kommer loopen att köras tills alla fiender är besegrade och det är dags att ladda in nästa nivå eller spelaren har förlorat spelet. Om GameLoop jobbar snabbare än sextio uppdateringar per sekund kommer den automatiskt att sova för att inte göra beräkningar som ändå inte går att visa för andvändaren. GameLoop sköter också all kommunikation mellan spelmotorns olika delar och GameLoopGUI GameLoopGUI GameLoopGUI är en klass som får och agerar på information från GameLoop via asynkrona meddelanden förmedlade via Androids Message Interface. GameLoopGUI har ansvaret för vissa av de grafiska aspekterna i spelet och en del av interaktionen med spelet via knappar i nederkant på skärmen. Längst ner i grafikstacken finns grafikmotorn som implementeras i klassen NativeRender som målar upp spelplanen, de animerade djur som anfaller samt torn med mera. Ovanpå detta tillkommer GameLoopGUI med ett antal grafiska element, se Tabell 4 och Figur 14. Grafiska element Nivåinformation Ikon för den aktuella nivån Hur många djur som fortfarande lever Djurens totala hälsa Tillgängliga pengar En meny för val av olika torn som kan bygga, pausa, dubbel spelhastighet De dialoger som talar om för användaren att spelet är slut alternativt frågor om spelet skall avslutas Tabell 4. Grafiska element i spelet som hanteras av GameLoopGUI. Figur 14. GameLoopGUI-element rödmarkerade. 25

33 Implementering Sprite Creature, Tower och Shot ärver ifrån Sprite-klassen. Sprite-klassens uppgift är att representera ett grafikobjekt i grafikmotorn. Klassen består framförallt av koordinater för objektet, information om vilken bild som Spriten skall förmedla och antalet bildrutor grafikobjektet består av. Sprite innehåller också olika metoder för att förbättra funktionaliteten av spelmotorn. Till exempel funktion för skalning av ett grafikobjekt till ny storlek eller ändring av dess färger. Se Figur Creature Klass som definierar alla fiender som finns i spelet. Precis som nämndes i föregående stycke ärver denna från Sprite och får därför alla egenskaper som en Sprite har. Alla fiender följer ett godtyckligt antal fördefinierade vägpunkter genom varje bana. Creature-klassens huvuduppgift är att beräkna, med hjälp av sin hastighet och tidsdifferensen som den har fått av GameLoop, hur långt den skall förflytta sig. När en fiende Figur 15. Det synliga rutnätet, bakgrunden, samt markerade objekt är alla representerade av Sprite klassen. har kommit fram till en vägpunkt kommer den istället att försöka förflytta sig till nästkommande punkt. Detta kommer att fortsätta tills dess att något utav tornen har lyckats besegra denna fiende, eller spelaren har förlorat alla sina liv. Förutom att beräkna hur en fiende skall följa vägen sköter klassen också beräkningarna för sin egen rörelseanimation och hastighetsberäkningar samt hälsa och ljudeffekter Tower Tornen är spelarens försvar och den del av spelmekaniken som spelaren själv råder över. Klassen Tower representerar dessa torn och har som uppgift att precis som Creature-klassen berätta för grafikmotorn var tornet skall ritas ut, vilken textur tornet skall ha och så vidare. När spelaren väljer att placera ut ett torn på spelplanen kommer tornklassen att hjälpa till att kontrollera att det inte redan finns ett torn på vald plats eller att spelaren inte försöker bygga tornet på en väg eller annan otillåten plats. Tornklassen innehåller också flera sökalgoritmer vars uppgift är att hitta fiender inom skottavstånd till tornet, detta kan göras på tre olika sätt beroende vilken typ det aktuella tornet har. De tre olika typerna av sökalgoritm är: projektil, som träffar en fiende i taget, Area of effect, vilken träffar alla fiender inom viss distans från tornet och projektil med splitter, som träffar en fiende och alla i dess närhet. Gemensamt för dessa tre torntyper är att deras huvuduppgift är att skada och applicera sina specialförmågor på fiender. Dessa är retardation och skada över tid. I spelet representeras dessa av frystorn och gifttorn. 26

34 Implementering Shot Klassen består precis som Creature och Tower av en Sprite. Shot är skottet som ett torn kan avfyra. Skottet kommer precis som fiendeklassen att röra sig mot en bestämd punkt fast i skottets fall så är det en fiende istället för en vägpunkt. När ett skott träffar en fiende, kommer en explosion att animeras. Varje torn har aldrig mer eller minde än ett skott. När ett skott inte använts, ligger det dolt på samma koordinat som tornet. Klassen utför ingen skadeberäkning utan är endast en grafisk representation på spelplanen. Skottet står för de mest avancerade animationerna i spelet, beroende på torntyp som skjutit kan skottet representera allt ifrån giftmoln till kanonskott, kaststjärnor och elstötar Scaler Eftersom dagens telefoner använder olika skärmupplösningar, behövs metoder för att skala om de koordinater som spelmotorn använder för att göra sina beräkningar. Det togs därför beslut om att skapa en klass som är helt dedikerad till att sköta sådana omräkningar. Först togs beslut om att försöka välja en upplösning och använda den som måttstock vid skapandet av skalaren. Scaler-klassen innehåller olika metoder för att omräkna koordinater mellan olika upplösningar, kontrollera om punkter befinner sig på spelplanen och, kanske det viktigaste, att hjälpa till att avgöra var på spelplanen en position befinner sig. Spelplanen består av ett rutnät bestående av ett antal rutor, dessa kan antingen vara lediga och tillåtna för tornplacering, upptagna av ett annat torn eller otillgängliga Initiering av spelmotor En viktig fråga under projektets gång har varit hur spelmekaniska attribut såsom fienders hälsa, ett torns egenskaper och så vidare skall behandlas samt när och hur de skall matas in i spelet. Lösningen på detta problem blev att värden läses in med hjälp av flertalet hjälpklasser från textfiler. Tanken är att det skall vara enkelt att uppdatera, till exempel en specifik fiendes hälsa, utan att behöva ha någon kunskap eller förståelse för hur spelmotorn är programmerad. Spelaren kommer att stöta på flertalet val innan spelet startar såsom vilken karta, svårighetsgrad han vill att fienderna skall ligga på och dylikt; allt detta tillhör användargränssnittet, när spelaren har gjort dessa val kommer information relaterad till dessa val att läsas från filer. Kommande stycken behandlar de tre klasserna som laddar in all data innan en specifik bana börjar MapLoader Kartan inläses från textfiler innehållande bakgrundsbild, vägpunkter och hinder. Maploadern är också ansvarig för att skapa spelets rutnät för placering av torn. Klassen kommer att räkna ut vägen utifrån definierade vägpunkter och på så sätt se till att rutnätet initieras så att spelaren inte kan Figur 16. Rödmarkering illustrerar områden som MapLoader utesluter. 27

35 Implementering blockera fiendens färdrutt. Det finns även möjlighet att läsa in information om andra föremål förutom vägen till exempel kan klassen ta bort möjligheten att bygga torn på samma plats där det står ett träd. Se Figur TowerLoader Klassen läser precis som MapLoadern alla tornegenskaper ifrån textfiler. Klassen kommer att skapa en lista med alla möjliga torntyper och deras uppgraderingar. Spelmotorn använder sedan denna information som en mall när den skapar och uppgraderar torn WaveLoader Varje specifik spelnivå innehåller unika fiender med olika hälsa, snabbhet och andra egenskaper. Klassen laddar in information om all nivåer och som sedan kan läsas av spelmotorn vid behov. 6.2 Rendering En av de mest centrala frågorna i skapandet av ett digitalt spel är hur spelet skall representeras grafiskt för spelaren. Olika typer av spel och plattformar ställer radikalt olika krav och ger olika möjligheter. Ett Playstation 3 till exempel kan kopplas till en högupplöst TV och har hårdvara specialbyggd för avancerad 3D-rendrering och fysiksimulation medan mobiltelefoner traditionellt har hårdvara som är gjord för främst telekommunikation och i ett så litet format som möjligt. Androids API:er och den hårdvara som är vanligast på Android-telefonmodeller har helt styrt valet av renderingsteknik. I början av projektet så beslutades att all form av 3D-grafik var för tidskrävande att implementera och att den kompetens som krävs för detta saknades i projektgruppen. Detta beslut fick dock ändras på tidigt i projektet då det visade sig att Androids 2D-API:er har mycket dåliga prestanda-egenskaper på många av de vanligaste telefonmodellerna. Dessutom saknades stöd för ett flertal funktioner som hade underlättat utvecklingen vilket ledde till ett byte av ramverk(45) OpenGL OpenGL, ett ramverk avsett primärt för 3D-rendering, blev ett bättre alternativ eftersom det stöds av hårdvara på de flesta telefonmodeller. Detta gör att relativt avancerad grafik med god prestanda går att åstadkomma och fortfarande behålla en stor målgrupp för vår applikation. OpenGL för med sig en helt ny uppsättning problem. Främst på grund av att den underliggande hårvaran på de olika telefonmodellerna varierar kraftigt. Exempel på detta är att flera telefoner enbart stödjer texturer vars dimensioner i bildpunkter är en faktor av två. Detta gäller dock inte för alla telefoner och inte för emulatorn, vilket leder till ett inkonsekvent beteende. Flera olika metoder för att rita 2D-grafik med hjälp av OpenGL testades innan en lösning påträffades som både levererar bra prestanda-egenskaper och den funktionalitet som behövs för att uppfylla projektets krav; detta på så många modeller av Android-telefoner som möjligt. Detta var en mycket tidskrävande process som krävde mycket research och testning. 28

36 Implementering Den slutgiltiga implementeringen använder sig av Quads vilka består av rektanglar som i sin tur är uppbyggda av två trianglar med en textur ovanpå. Dessa lagras i Vertex Buffer Objects, en metod för att lagra så mycket som möjligt av renderingsdata direkt i videominnet för att på så viss undvika den kostnad som överföring ifrån RAM till videominne innebär. Quads:en ritas sedan upp på skärmen i djupordning, enligt den så kallade Painters Alghorithm Android Native Kit På Android så finns det två sätt att använda OpenGL, antingen genom Java API:er som i sin tur ropar på C-API:er eller direkt genom att använda Android Native Kit (NDK) som är ett tillägg till Androids vanliga utvecklingspaket. NDK gör det möjligt att programmera delar av en Android-applikation i C eller C++ och sedan använda sig av dessa delar från Java. Detta sker med hjälp av en del av Java-standarden som kallas Java Native Interface (JNI) som möjliggör metodanrop från ett javaprogram till ett bibliotek som är implementerat i ett annat språk. Detta exekveras utanför den virtuella maskinen direkt på datorns processor. Det finns dock begränsningar för vad som går att göra med NDK. För närvarande är det omöjligt att skriva en hel Android-applikation i endast C eller C++ eftersom stora delar av telefonens funktionalitet är omöjlig att nå. Till exempel går inte användarinteraktion att genomföra med hjälp av NDK utan måste implementeras med Java(46). Åtkomst till OpenGL från Java levereras via JNI och anrop till detta är mycket tidskrävande. Därför beslutades att flytta all OpenGL-kod från Java till ett C-bibliotek som i sin tur används genom JNI. På så vis undviks en mycket stor del av JNI-anropen och därmed tidskostnaden associerad med dem. Se Figur 17. Figur 17. Ovan Java-renderare. Nedan C-renderare 6.3 Multiplayer Spelet har stöd för flerspelarläge där maximalt två spelare, via den trådlösa kommunikationsteknologin Bluetooth, kan spela tillsammans. Detta avsnitt redogör för de delar som ingår i implementeringen av flerspelarläget. 29

37 Implementering Kommunikation över Bluetooth Bluetooth utvecklades av företaget Ericsson år Version 1.0 av Bluetooth-specifikationen publicerades år 1999 av The Special Interest Group, SIG, en sammanslutning av från början fem företag, vars huvudsakliga uppgift var att vidareutveckla och marknadsföra teknologin(47). Androidplattformen har stöd för Bluetooth och genom Application Framework finns det tillgång till Androids Bluetooth-API:er. Dessa API:er ger Androidapplikationer möjligheten att ansluta trådlöst till andra Bluetooth-enheter. Det Bluetooth-protokoll som användes i detta projekt heter Radio Frequency Communication, RFComm. I detta avsnitt behandlas de klasser och datastrukturer som krävs och ingår i applikationen för att upprätta en anslutning och hantera den över Bluetooth. Figur 18 visar ett klassdiagram över samtliga klasser som ingår i multiplayer-delen. Figur 18. Förenklat klassdiagram av de klasser som utgör flerspelarläget i detta projekt Verifiering av Bluetooth Som tidigare nämnts krävs en deklaration av tillståndet för att använda Bluetooth på enheten, vilket görs i AndroidManifest.xml. Innan kommunikation är möjlig måste en verifiering av att Bluetooth existerar på aktuell Androidenhet ske. Detta görs med ett anrop till metoden för att hämta Bluetooth-adaptern för enheten, getdefaultadapter(), se kodexempel 4. 30

38 Implementering 00 : BluetoothAdapter mbluetoothadapter = 01 : BluetoothAdapter.getDefaultAdapter(); 02 : if(mbluetoothadapter == null){ 03 : // Aktuell enhet stöder ej Bluetooth, meddela användaren 04 : } Kodexempel 4. Verifiering av Bluetooth på aktuell enhet. Om Bluetooth stöds av enheten är nästa steg att kontrollera om Bluetooth är aktiverad med ett anrop till metoden isenabled() på BluetoothAdapter-objektet. Metoden returnerar sant eller falskt. Om den returnerar falskt så startar en specifik Intent som ger användaren möjlighet att aktivera Bluetooth på enheten, se kodexempel : if(!mbluetoothadapter.isenabled()){ 01 : Intent aktiverabt = new Intent(BluetoothAdapter. 02 : ACTION_REQUEST_ENABLE); 03 : startactivityforresult(aktiverabt, REQUEST_ENABLE_BT); 04 : } Kodexempel 5. Aktivering av Bluetooth på aktuell enhet. StartActivityForResult förser i det här fallet användaren med en dialog som ber om användarens tillstånd att aktivera Bluetooth på enheten. Accepterar användaren detta aktiveras Bluetooth under tiden som applikationen fortfarande exekveras i bakgrunden. Om användaren ej godtar begäran om aktivering kommer Bluetooth ej att aktiveras och spelet kommer ej att köras i flerspelarläge. Processen för verifiering av Bluetooth sker på båda enheter som avser att ansluta till varandra, oavsett om de agerar server eller klient Server Vid anslutning av två enheter krävs att en av dem agerar server. Server-enheten öppnar en socket för Bluetooth som lyssnar efter en förfrågan från en annan Androidenhet att upprätta en anslutning. Socket-objektet fås genom metoden listenusingrfcommwithservicerecord- (NAMN, UUID), där parametern NAMN är en godtycklig textsträng. Parametern UUID, Universally Unique Identifier, är ett 128-bitars standardiserat format för en textsträng. Syftet är att göra information unik(48), i det här fallet socket-objektet för applikationen. Avsikten med ett såpass stort UUID värde är att konflikter med redan existerande UUID undviks. Servern är skapad som en egen tråd därför att den under anslutningsförsök från en klient blockeras(48). Då en anslutning har accepterats startas spelet i flerspelarläge, detsamma gäller för klient-sidan av anslutningen Klient Även klient-sidan är skapad som en egen tråd i det här fallet. Tråden erhåller ett objekt av typen BluetoothDevice som representerar den andra Androidenheten vilken klienten försöker ansluta till. BluetoothDevice används till att erhålla ett socket-objekt, likvärdig den på serversidan, genom metoden createrfcommsockettoservicerecord(uuid). Här är UUID exakt samma 31

39 Implementering identifierare som på server-sidan och är en förutsättning för att en anslutning mellan server och klient skall etableras. Klient-sidan för spelet i det här projektet söker i den lokala omgivningen efter en server att ansluta till. En alternativ implementering är att låta båda enheter agera server och klient. Sökningen sker då av båda enheter där den enhet som initierar anslutningen blir klient (48). Sökningen i den lokala omgivningen sker genom en så kallad BroadcastReceiver, som också identifierar tillgängliga Bluetooth-enheter och hämtar deras namn och Media Access Control adress, MAC-adress. MAC-adressen är enhetens fysiska adress, den är unik för varje enhet och existerar hos de enheter som kan ingå i ett nätverk(49). Möjligheten finns också att de två Androidenheterna är förenade sedan tidigare, sökningen är då ej nödvändig. Upptäckta enheter placeras i en lista på skärmen och kan med ett fingertryck på enhetens skärm direkt väljas av användaren. Kodexempel 6 visar hur en Bluetooth-enhet som redan är förenad med en klient läggs till i listan över tillgängliga enheter. 00 : Set<BluetoothDevice> forenadeenheter = 01 : mbluetoothadapter.getbondeddevices(); 02 : if(forenadeenheter.size() > 0) { 03 : for(bluetoothdevice device : forenadeenheter){ 04 : marrayadapter.add(device.getname() + /n + 05 : device.getaddress(); 06 : } 07 : } Kodexempel 6. Placering av en eller flera Bluetooth-enheter, som redan är förenade med en klient, i en lista som representerar tillgängliga enheter Upprätthålla en anslutning över Bluetooth När en anslutning mellan två enheter har upprättats, hanteras anslutningen av en klass kallad MultiplayerService. Denna klass är implementerad som en egen tråd och har till uppgift att skriva och läsa bytes som skickas över anslutningen. Detta görs via socket:ens InputStream och OutputStream(48). Läsningen på InputStream sker så länge tråden är aktiv. När en mängd bytes har tagits emot skickas de till klassen MultiplayerHandler. Denna klass tolkar inkommande bytes och uppdaterar olika variabler relaterat till multiplayer-matchen. Skrivning genomförs genom klassmetoden write(byte[] bytes), som skickar argumentet bytes på socket:ens OutputStream. Figur 18 visar klassdiagrammet för de klasser som ingår i paketet som etablerar och upprätthåller anslutningen över Bluetooth. 6.4 Highscore ScoreNinja är ett gratis highscore-system för Androidplattformen, som finns tillgängligt för utvecklare att använda(50). Systemet synkroniseras automatiskt över internet med en central server så att spelaren kan jämföra sina poäng med andra spelare. ScoreNinja har implementerats separat för varje bana i spelet. 32

40 Implementering 6.5 Prestanda och optimering Spelet ställer hårda prestandakrav och framtvingar därför vissa kodmässiga designval för att uppfylla dessa krav. Ett av de största problemen under projektet har varit att Androidplattformen är byggd på Java och hur Java hanterar minne. I de flesta fall är garbage collection (GC) smidigt för utvecklare eftersom det befriar dem från att behöva tänka på minnesallokeringar och att frigöra minne. I detta projekt har GC den exakt motsatta effekten. När Java-maskinen allokerar minne så tickar en räknare upp och när den når ett gränsvärde påbörjas GC, när den genomförs fryses processen. Tyvärr tar detta lång tid och desto längre ju mer data som har allokerats eftersom hela objektträdet måste traverseras. Under detta förlopp kan processen vara frusen i en halv sekund eller mer. Effekten av detta är att spelet hackar fram mellan varje GC, något som förstör interaktiviteten och totalintrycket av spelet. Lösningen är att inte allokera minne medan användaren interagerar med spelet och därmed undviks GC. Alla objekt som kommer behövas under en spelomgång allokeras innan spelomgången startar och återanvänds sedan under hela spelsessionen. Detta leder till att mycket energi läggs ner på minneshantering och mycket kod måste skrivas specifikt för att återanvända redan allokerat minne, vilket har varit en av de större felkällorna under projektets gång. I sin tur leder detta till kod av hög komplexitet och stor omfattning. Det inte bara den kod som har skrivits av projektgruppen som kan aktivera GC, mycket av de ramverk som Android består av gör minnes allokeringar när de används, även detta leder till samma problem med GC. För att komma till rätta med detta problem undviks stora delar av Java-API:erna. Framförallt Collections-ramverket eftersom det ofta allokerar minne även vid läsning, detta är ett stort hinder då data läses och uppdateras mycket frekvent i vissa klasser. Detta medför att det inte finns några färdiga container-klasser att tillgå istället måste egna konstrueras som därmed kostar mycket tid i felsökning och implementering. I de få fall då det har varit tillsynes omöjligt att arbeta runt ramverk som allokerar minne så minimeras användandet så mycket som möjligt, för att på så sätt aldrig nå gränsvärdet som gör att GC startar. Enligt Prunett, utvecklare på Google, så är metodanrop tidskrävande att göra i Java och speciellt då anrop till metoder i gränssnitt och ännu värre är JNI-anropen. Därför rekommenderar han att vid programmering av prestandakrävande applikationer försöka göra så få metodanrop som möjligt. Att skriva större metoder, samt använda publika variabler erbjuds som tänkbara lösningar(45). Baserat på detta har ett fåtal variabler som läses och skrivs ofta gjorts publika. 33

41 Testning 7 Testning Under den tid som hängivits åt kodning under detta projekt har testning på flera olika vis förekommit. Testningen har utförts fortlöpande på grund av projektets agila utvecklingsmetod, vilket har varit en nödvändighet för att ständigt anpassa utvecklingen och lösa de problem som uppkommit. I detta avsnitt redovisas de metoder och verktyg som använts för att testa mjukvaran för korrekthet och prestanda. 7.1 TraceView Traceview är ett program som låter användaren se hur lång tid ett metodanrop tar i millisekunder, samt hur många anrop som har utförts och vid vilka tillfällen dessa anrop har skett(51). Detta presenteras med en graf, se Figur 19. Programmet har zoom-funktion, så att man kan zooma in till den tidsupplösning man behöver för att få insikt i hur programmet beter sig. Figur 19. Skärmdump av Traceview under exekvering. Bilden visar hur olika trådar belastar processorn. Ett spel i realtid ställer ofta höga krav på prestanda, händelser från användaren måste hanteras utan dröjsmål och respons måste ges tillräckligt ofta för att användaren skall få upplevelsen av interaktivitet. Allt detta måste ske på ett sätt så att flytet i spelet behålls för att inte frustrera användaren. Det är av stor vikt att prestandan är konstant under spelets gång, oavsett vad användaren gör. Traceview hjälper till att lösa ett antal problem, se Tabell 5. Programmet ger detaljerade svar på alla dessa frågor baserade på verkligt beteende på den plattform som programmet skall köras på. Detta är till stor nytta då man skall identifiera och åtgärda prestanda-problem i kod. Svårigheter med att skriva snabba algoritmer för även triviala problem Det är problematiskt att förutsäga hur algoritmer presterar på olika hårdvara Hur algoritmer interagerar med varandra Kod skriven av en tredje part har okänd prestanda Tabell 5. Problem som Traceview hjälper till att lösa. 34

42 Testning 7.2 Test på Androidenheter För att veta att spelet fungerar och uppför sig som det skall så har fyra stycken mobiltelefoner från tre olika tillverkare använts som testgrupp. Två av mobiltelefonerna är privatägda, samt att gruppen i slutskedet fick låna två stycken HTC Hero av Chalmers. Eftersom spelet är skrivet för operativsystemet Android 2.1 så har modifikationer på Hero- och en privatägd Acer-mobiltelefon gjorts där operativsystemet byttes ut till Android 2.1. Den nyare versionen av operativsystemet är i skrivande stund på väg till de båda modellerna men fanns alltså inte officiellt tillgänglig under tiden då utvecklingen av spelet fortskred. Se Tabell 3 avsnitt för specifikationer för de olika telefonerna. 7.3 Testgrupp Från och med projektets start haft det funnits en testgrupp tillhands som fortlöpande har kommit med kritik och utlåtanden samt hjälpt till med balansering. En nackdel med testgruppen är att deltagarna har en personlig relation till projektgruppen vilket kan men inte nödvändigtvis resulterar i bristande objektivitet. Testgruppen har haft kontinuerlig tillgång till senaste versionen av spelet och har vid tillfällen fått utföra test av specifik funktionalitet men också fritt användande av applikationen. 35

43 Diskussion 8 Diskussion Grundmålet med projektet var att skapa ett roligt och tilltalande spel som samtidigt kunde köras på de flesta Android-telefoner på marknaden. Med facit i hand anser vi att detta mål uppfyllts trots att spelet inte är till hundra procent färdigutvecklat. Då projektrapporten skall lämnas in tidigare än redovisningen av slutprodukten anser gruppen att det fortfarande finns möjlighet att producera en färdig produkt. Avsnitten nedan behandlar viktiga punkter och moment inom projektet. 8.1 Val av spel Projektet inleddes med beslut om speltyp, bland annat nämndes racing, pussel, brädspel, turbaserad strategi, och till sist Tower Defence. Eftersom samtliga i gruppen både var bekanta med och tyckte om Tower Defence-spel så var valet ganska lätt. Dessutom såg ett Tower Defence-spel ut att vara ett av de mest genomförbara alternativen inom den givna tidsramen, utan att för den del vara trivialt. 8.2 Arbetsmetod Flera av gruppmedlemmarna har tidigare erfarenheter av Agiles systemutvecklingsfilosofi och har varit nöjda med utfallet av dess användning. Som gruppen såg på det så fanns det inte mycket annat som skulle fungera på ett såpass litet projekt som kandidatarbetet är. Det finns många andra metoder man kan tillämpa men de passar enligt oss bättre för större projekt med fler inblandade. En annan avgörande aspekt i beslutet att använda Agile är möjligheten att snabbt kunna styra projektet i en annan riktning om en ursprunglig idé visar sig problematisk. Detta beslut är gruppen mycket nöjd med eftersom projektet vid flera tillfällen fått byta inriktning och tack vare Agile så har tid och arbete sparats. 8.3 Utecklingsmiljö och verktyg Ett antal val gjordes vid beslutande om vilka utvecklingsverktyg som skulle användas till projektet. Detta avsnitt behandlar projektmedlemmarnas upplevelse av utvecklingsmiljön och dess verktyg Eclipse och Android ADT Tyvärr finns det i dagsläget bara en IDE som är integrerad med Android ADT - Eclipse. Denna IDE har visat sig vara välgjord och lättanvänd. En nackdel är dock att Eclipse tillsammans med Androids ADT är långsam och därför ibland frustrerande att arbeta med, speciellt vid arbete med grafisk design och gränssnitt. Vi erfor även en del mindre krascher och inkonsekvent beteende men efter att den senaste uppdateringen av Android SDK så löstes många av dessa problem. Trots ovan nämnda problem rekommenderas Eclipse till andra utvecklare då alternativet att utveckla utan integrationen mellan editor och SDK skulle leda till mycket extraarbete. Till exempel skulle bara skapandet av ett nytt tomt Android-projekt ta åtskilliga timmar utan Eclipse och Android ADT. 36

44 Diskussion Emulator Emulatorn har haft en fundamental roll under utvecklingen och har varit till stor nytta vid testning av spelet. Tyvärr är prestandan dålig speciellt vid uppstart och exekvering. Detta gör att det blir svårt att få en grundläggande uppfattning om hur en applikation presterar prestandamässigt. Då det tog lång tid innan gruppen fick tillgång till Android-telefoner så fick gruppen förlita sig på emulatorn, vilket gjorde det svårt att avgöra prestandan på vårt spel. Utöver detta är emulatorns implementering av OpenGL bristfällig och innehåller flera fel, vilket lett till både förvirring och onödig felsökning. Vidare så har det faktum att emulatorn saknar stöd för Bluetooth medfört att två telefoner varit upptagna vid testning av multiplayer. Emulatorn saknar även stöd för Android Market vilket försvårar implementering av tredjepartsprogram. Trots dessa brister är emulatorn tillräcklig att utveckla och testa delar av en applikation med, men ej under realistiska former. Vi kan således inte rekommendera utveckling för Androidplattformen utan tillgång till Android-telefoner för testning, speciellt inte realtidsspel Git Valet av Git som versionshanteringssystem har lämpat sig väl tillsammans med Agile-metoden i projektet. Tack vare Git är det enkelt att skriva och dela med sig av prototyper och experimentell kod utan att riskera konflikter i koden. I projektet har gruppen haft stor nytta av att kunna utveckla parallellt och sedan sammanföra ändringar. Figur 20 visar hur olika kodträd separerats och sammanförts över tid. Figur 20. Grafisk representation av historik i Git. Valet av Git har inte varit helt problemfritt, då bara en medlem var bekant med systemet sedan tidigare var det en hög inlärningskurva för övriga deltagare. Gruppen tycker ändå att det var värt ansträngningen då Git förmodligen kommer att användas i kommande projekt. 8.4 Grafik och formgivning Framställandet av spelets grafik, den grafiska designen samt formgivningen fortlöpte utan större problem. Uppdelningen av gruppen med en grafisk del fungerade väl, både när det kommer till subgruppens arbetsinsats samt kommunikationen med övriga projektgruppsmedlemmar. Samtliga gruppmedlemmar är nöjda över slutresultatet och tror att eventuella framtida kunder komma tycka detsamma. 37

45 Diskussion 8.5 Androids användargränsnitt Två alternativa metoder fanns att välja på vid utformning av gränssnittet. Antingen kunde ren Java-kod eller XML-filer användas. Alternativet att använda enbart Java-kod skulle innebära en förlust av den lättöverskådlighet som XML-baserad layout erbjuder och därtill utgöra en begränsning för komplexiteten av dispositionen för användargränssnittet. Likaså skulle enbart användning av XML-filer utgöra en begränsning, då vissa parametrar hos ett urval av vyerna ändras under spelets gång för att på så vis göra spelet mer interaktivt. Vad gäller val av vyer var LinearLayout och TableLayout de som lämpade sig bäst för detta projekt. De möjliggör positionering av varje gränssnitts-komponent exakt där man önskar på skärmen. AbsoluteLayout ger också den samma möjlighet, dock på bekostnad av kompatibiliteten med telefoner som har olika upplösningar, då den kräver att man anger exakta bildpunktsförhållanden. Därför användes inte denna vy i användargränssnittet. RelativeLayout är också ett alternativ, men strukturen på de olika gränssnittskomponenterna har varit alltför komplext för att låta denna vy utgöra basen för strukturen. Eftersom alla komponenter är relativa i sin position till varandra blir det mycket svårt att göra ändringar samt förutsäga hur gränssnittet anpassar sig till olika skärmupplösningar, varför denna vy ej heller har använts i projektet. 8.6 Java tillsammans med C För att optimera prestandan för applikationen skrevs renderaren i C och OpenGL då många JNI-anrop kunde undvikas. Figur 21 nedan visar på skillnaden mellan en renderare skriven i Java, en i C och antalet JNI-anrop för att skapa en bildruta. Figur 21. Överst renderare skriven i Java. Nederst renderare skriven i C Med hjälp av JNI kunde större delar av projektet skrivits i C eller C++, vilket förmodligen ökat prestandan ytterligare. Tyvärr så saknas kompetens inom dessa språk och var därför inte ett alternativ. 8.7 Trådkommunikation Google tillåter endast att en tråd hanterar användargränssnittet, den första tråden som startar applikation bär detta ansvar. Google har valt att begränsa interaktionen till denna tråd för att 38