TVE 13 012 maj
Examensarbete 15 hp Juni 2013
Spelutveckling och lansering av applikation till Android
Joar Lind
Oskar Wåglund
Teknisk- naturvetenskaplig fakultet UTH-enheten
Besöksadress:
Ångströmlaboratoriet Lägerhyddsvägen 1 Hus 4, Plan 0
Postadress:
Box 536 751 21 Uppsala
Telefon:
018 – 471 30 03
Telefax:
018 – 471 30 00
Hemsida:
http://www.teknat.uu.se/student
Abstract
Spelutveckling och lansering av applikation till Android
Game development and launching of application for Android
Joar Lind, Oskar Wåglund
The goal of the project is to create a game application for Android. The major part of the game is coded in Java using Eclipse IDE. The result is a game called Valentine's Quest which can be downloaded from Google Play.
ISSN: 1401-5757, TVE 13 012 maj Examinator: Martin Sjödin Ämnesgranskare: Henrik Olsson Handledare: Sven-Erik Ekström
Innehåll
1 Inledning 5
1.1 Bakgrund . . . . 5
1.1.1 Android . . . . 5
1.1.2 Applikationer . . . . 5
1.2 Motivering . . . . 5
1.3 Målsättning . . . . 6
2 Teori 6 2.1 Utvecklingsmiljö . . . . 6
2.1.1 Android SDK . . . . 6
2.1.2 Eclipse . . . . 6
2.2 Språk . . . . 6
2.2.1 Java . . . . 6
2.2.2 XML . . . . 7
2.3 Program och tjänster . . . . 7
2.3.1 GitHub . . . . 7
2.3.2 Bildbehandlings- och ljudredigeringsprogram . . . . 7
2.3.3 ScoreLoop . . . . 7
2.4 Operativsystemet Android . . . . 8
2.4.1 Applikationens uppbyggnad . . . . 8
2.4.1.1 Aktiviteter . . . . 8
2.4.1.2 Manifest . . . . 8
2.4.2 Kompabilitet . . . . 9
2.4.3 Skärmupplösningar och skärmtätheter . . . . 9
3 Utförande 9 3.1 Spelidén . . . . 9
3.2 Aktiviteter . . . . 10
3.3 Programmering . . . . 10
3.3.1 Huvudmeny . . . . 10
3.3.2 Spelläge . . . . 10
3.3.3 Avslutningsskärmarna . . . . 10
3.4 Lansering . . . . 10
3.4.1 Betatest . . . . 10
3.4.2 Google Play . . . . 10
3.5 Arbetsmetodik . . . . 11
3.5.1 Programutveckling . . . . 11
3.5.2 Estetik . . . . 11
3.6 Spelrelaterade problem och lösningar . . . . 11
3.6.1 Skärmanpassning . . . . 11
3.6.2 Rendering . . . . 12
3.6.3 Ljud . . . . 13
3.6.4 Tråd . . . . 13
4 Resultat 14
4.1 Story . . . . 14
4.2 Aktiviteter . . . . 15
4.3 Programmering . . . . 15
4.3.1 Huvudmeny . . . . 15
4.3.2 Spelläge . . . . 16
4.3.3 Avslutningsskärmarna . . . . 17
4.4 Klassarkitektur . . . . 17
4.5 Lansering . . . . 18
5 Diskussion 18 5.1 Spelkänsla . . . . 18
5.2 Upplevelse . . . . 18
5.3 Helhetsintryck . . . . 19
5.4 Betatest . . . . 19
5.5 Svårigheter . . . . 19
5.6 Poängsystem . . . . 19
5.7 Buggar . . . . 19
6 Slutsatser 20 6.1 Målsättning . . . . 20
6.2 Projektets helhet . . . . 20
6.3 Marknadsföring . . . . 20
6.4 Utveckling till andra plattformar . . . . 20
6.5 Optimering . . . . 21
6.6 Förbättringsmöjligheter . . . . 21
6.7 Utvecklingsmöjligheter . . . . 21
Referenser 21
Populärvetenskaplig sammanfattning av projektet
Projektet grundas på en idé om att kunna producera och lansera en applikation utifrån begrän- sade resurser och kunskaper. Applikationen skall vara i spelformat och kommer att utvecklas till operativsystemet Android. Projektet klassas som ett programmeringsprojekt, men har fler moment som skapandet av grafik och ljud, samt implementering av en poängbaserad online-topplista. Även själva lanseringen till Google Play, vilket är Androids applikationsmarknad, är ett viktigt moment.
Spelet är ett plattformsspel, och storyn i spelet är klassikt äventyrsinriktat, med ett dussin olika nivåer inkluderat en slutstrid. Mysigt är ett av spelets ledord där temat är skogsmiljö och huvud- karaktären beskrivs som söt och gullig. Vidare är spelet i huvudsak självförklarande och bygger på typiska spelprinciper och moment som mången vana användare kan se och känna igen. Med highscore-funktionen erhålls en mer tävlingsinriktad framställning av applikationen, men alterna- tivet att spela utan denna skall även finnas. Applikationens namn är Valentine’s quest och går att hämta gratis från Google Play för innehavare av en Android-enhet. Spelet har fått positiva kommentarer och kan ses som en framgång, varför det kan sägas vara möjligt att med begränsade resurser och kunskaper producera och lansera en applikation.
1 Inledning
1.1 Bakgrund
1.1.1 Android
Apple iOS, Windows Phone och Android anses just nu vara bland de största öppna mobila ope- rativsystemen inom telefonibranschen. Just Android är känt för att vara ett relativt obegränsat system, både för utvecklare och användare, till skillnad från iOS. Detta gör utveckling till Andro- id enklare för ovana utvecklare. Android har en stor marknad av tillämpningsprogram, kallade applikationer. Den största delen av dessa finns tillgängliga online via Androids egna applikations- marknad Google Play. Antalet applikationer här var i mars 2012 över 400 000. Programvaran består av Java-applikationer som baseras på det objektorienterade programmeringsspråket Java. [1]
1.1.2 Applikationer
Användingen av smartphones har ökat avsevärt mycket de senaste åren, och med dessa också marknaden för applikationer. Ett av de större områdena är underhållningskategorin, och däri av- delningen spelapplikationer. Även här är utbudet brett och med detta varierande i populäritet.
Spel i mobiltelefoner har alltid haft en stor publik, från det klassiska Snake till det mer moderna Wordfeud, och det är givetvis ett ämne många talar om.
1.2 Motivering
Projektets tanke är att skapa och lansera en icke-kommersiell mobilapplikation i spelformat till Android-plattformen. Projektet innefattar att med programmeringsspåket Java från grunden ska- pa en mobilapplikation, och därefter publicera den på Google Play. Applikationen ska förutom själva spelet också handha en poängbaserad online-topplista, även kallat highscore från tjänsten ScoreLoop. Härigenom kan möjligheten att själv med begränsade resurser producera och lansera applikationer sedan undersökas.
1.3 Målsättning
Visionen är att få ut en fungerande spelapplikation på marknaden med tillhörande online highscore.
Självklart är spridningen av denna intressant, men inte det viktigaste. Det första och större delmålet är att få en inblick i enklare spelutveckling anpassat för mobila operativsystem och få ett större kunnande i programmeringstekniker. Det andra delmålet, lanseringen, är mer ett uppskattat och intressant moment för att få känna på hela utvecklingsprocessen från idé till användning av produkt.
Svårigheter finns först och främst i programmeringsdelen, att överhuvudtaget få ett fungerande spel.
Vidare problem ligger i lansering till Google Play samt implementering av highscore via ScoreLoop.
Intentionerna är att få med så många moment som möjligt i mån av tid och utan att göra spelet komplicerat. Det är alltid tilltalande med enkelhet, men samtidigt måste det vara tillräckligt utmanande för att vara underhållande. Tävlingsmoment med highscore gör det mer spännande och i viss mån beroendeframkallande. Målgruppen är människor i åldern 18-25.
2 Teori
2.1 Utvecklingsmiljö
2.1.1 Android SDK
Ett Software Development Kit (SDK) är ett utvecklingspaket, en mängd verktyg för utveckling, som möjliggör applikationstillverkning. Hos Android omfattar paketet allt ifrån bibliotek och debugger till dokumentation och emulator. Den officiella miljön till Android är Eclipse. [2]
2.1.2 Eclipse
I projektet skrivs all kod i utvecklingsmiljön Eclipse, som idag är en av de största Integrated Development Environments (IDE) som finns på marknaden. Eclipse kan användas till de flesta programmeringsprojekt och är speciellt användbar vid Java-utveckling. Programmet byggs upp av vyer (views) och perspektiv (perspectives) vilket gör att utvecklaren kan skräddarsy sin miljö helt efter vad den behöver. För att utöka sin miljö till det specifika projekt man jobbar på kan plugins laddas ner och sedan integreras i Eclipse. Android har tagit fram just en sådan plugin, Android Development Tools (ADT) plugin, och därför är Eclipse det självklara valet för Android-utveckling.
2.2 Språk
2.2.1 Java
Java är ett objektorienterat programmeringsspråk, att jämföra med andra språk som till exempel C, C++ och C#. Javaprogrammet och dess kod utgör grunden i spelets mekanik, såsom hante- ringen av knapptryckningar, själva fysikmotorn, beräkningar, och uppritandet av bilder. Java är objektsorienterat, där varje objekt beskrivs med en klass som innehåller instansvariabler och me- toder. Instansvariablerna definerar klassens egenskaper, och metoderna är det som används för att se och ändra på instansvariablerna. För att förtydliga kan man jämföra med människan. En människa, objektet, har ett antal egenskaper som vikt, längd och ålder. Det som vi med andra ord kan kalla instansvariabler. Genom att utföra något som att äta, växa, sova och prata kan vi se och förändra vissa av dessa instansvariabler. Detta är några av våra metoder. På samma sätt som det finns kopplingar och relationer mellan människor, kan det finnas kopplingar och relationer mellan
klasser. Klasser kan också ärva från varandra. Dock är instansvariabler och metoder specifikt för varje klass, på samma sätt som att en viss människas längd inte är någon annan människas längd.
2.2.2 XML
XML (eXtensible Markup Language) är ett märkspråk, vilket innebär att det används för for- matering av data som sedan kan presenteras för användaren. I Android är XML en central del i skapandet av layouter och skrivs med hjälp av taggar se figur 1.
<Button a n d r o i d : i d ="@+i d /my_button "
a n d r o i d : l a y o u t _ w i d t h =" wrap_content "
a n d r o i d : l a y o u t _ h e i g h t =" wrap_content "
a n d r o i d : t e x t =" @ s t r i n g / my_button_text"/>
Figur 1: Ett exempel på XML-kod för en Android-knapp
2.3 Program och tjänster
2.3.1 GitHub
Github är ett webbhotell, ett lagringsutrymme i likhet med molntjänsterna SkyDrive och Dropbox, för mjukvaruutvecklingsprojekt. Denna tjänst är kostnadsfri för projekt med öppen källkod, vilket innebär att vem som helst kan ta del av arbetet. Tjänsten vidhåller även fortlöpande statistik av användandet och tjänar som slutförvar eller liknande backup-lager. Användandet i sig sker genom skapandet av ett repositorium, till vilket själva projektet “laddas upp” och som sedan håller i alla trådar. Till detta “nät” kan flera användare anslutas, vilket underlättar samarbeten på distans. Projektet delas upp i olika grenar under tiden det bearbetas lokalt, och kan vid senare tillfälle sammankopplas. Vid grenuppdelning används “commit”-funktionen för egen uppladdning, vid sammankoppling “push” och vid nedladdning “pull”. När projektet sammanfogas från olika källor kallas det för “merge”. GitHub används vanligtvis i ett terminalläge där kommandorader skrivs in för att sköta arbetet. I Eclipse kan man dock använda GitHubs plugin EGit för att underlätta arbetet med ett grafiskt användargränssnitt. [3]
2.3.2 Bildbehandlings- och ljudredigeringsprogram
Gimp är ett fritt bildbehandlingsprogram och har använts för att skapa alla bilder i applikationen.
Audacity är ett fritt ljudredigeringsprogram och har använts till att skapa och redigera spelets tema, samt alla övriga ljudeffekter.
2.3.3 ScoreLoop
ScoreLoop är en tjänst som startades 2008 och idag ägs av mobilföretaget BlackBerry. Tjänsten tillhandahåller ett flertal tjänster för att skapa ett nätverk i sitt mobilspel som sträcker sig över de största plattformarna, alltså Android, iOS, Windows Phone med flera. ScoreLoop’s SDK erbjuder enkelt tjänster så som att ladda upp till och ner från en topplista som ligger på deras servrar. I spelet är ett av målen att ha en online highscore som ska inspirera spelarna att tävla mot varandra, och ScoreLoop är perfekt för detta ändamål. ScoreLoop sköter automatiskt ranking utifrån de poäng
som laddats upp vilket innebär att de listor som laddas ner redan är färdigsorterade och klara att presenteras för spelaren.
2.4 Operativsystemet Android
2.4.1 Applikationens uppbyggnad 2.4.1.1 Aktiviteter
En applikation i Android’s operativsystem byggs upp av så kallade aktiviteter (activities). Vanligt- vis består en applikation av flera aktiviteter som applikationen sedan växlar mellan allt efter behov.
Det är till exempel vanligt att en applikation har en huvudmeny och sedan någon körning som ska visas för användaren och då kan det vara lämpligt att göra två aktiviteter av dessa. Aktiviteterna kommunicerar med varandra med hjälp av “intents”, som kan föra med sig information från en aktivitet till en annan. Varje aktivitet måste också ha en layout att visa för användaren.
Då det ligger i en smartphone’s natur att applikationer hela tiden snabbt ska kunna startas och stoppas krävs det att utvecklaren hanterar aktiviteterna på rätt sätt, vilket löses med hjälp av så kallade “Callback-metoder”. Varje aktivitet bör definiera ett antal metoder som kallas av operativsystemet då den vill ändra applikationens tillstånd, vilket kan innebära uppstart, fortsätt- ning, pausning, nedstängning eller till och med omedelbar förstörelse av applikationen. Genom att utnyttja callback-metoder som onPause(), onStop() och onResume() kan utvecklaren förhindra att data går förlorad då telefonen till exempel blir uppringd eller stängs av på grund av lågt batteri.
För att illustrera hur detta går till brukar utvecklare tala om Android’s “Activity Lifetime Cycle”
vilket visas i figur 2.
Figur 2: Ett flödesdiagram över aktiviteternas livscykel [4]
2.4.1.2 Manifest
En viktig del av applikationen är dess manifest, som definierar olika egenskaper och rättigheter som applikationen innehar. Manifestet måste läsas av operativsystemet innan något annat utförs så att koden kan exekveras på rätt sätt.
2.4.2 Kompabilitet
Till skillnad från iOS ökar antalet enheter som kör Android veckovis, vilket innebär att utvecklare ständigt måste tänka på att anpassa sina applikationer till samtliga av dessa. Alla enheter har en version av operativsystemet, men vilken version det är varierar enormt från telefon till telefon.
Versionerna delas in i olika “API-nivåer”, där API står för Android Package Index, och det finns för tillfället 17 sådana. Sedan 2009 delas även API-nivåerna in i kodnamn som satts i bokstavsord- ning. Alla versioner i API-intervallet 11 till 13 går till exempel under namnet Honeycomb. Under utvecklingen av en applikation är det viktigt att ha dessa versioner i åtanke och målet är att skapa en applikation som kan köras på så många versioner som möjligt. I applikationens manifestfil defi- nieras detta intervall av nivåer som klarar av att köra applikationen. För att utöka kompabiliteten för applikationen kan det vara tvunget att särbehandla vissa enheter under vissa moment av exe- kveringen. Detta sker oftast då en metod har förbättrats avsevärt i en API-nivå, men utvecklaren även vill att lägre API-nivåer ska kunna utföra momentet med en sämre metod.
2.4.3 Skärmupplösningar och skärmtätheter
När en applikation utvecklas till Android är det viktigt att tänka på anpassning till alla tänkbara skärmar på marknaden. Skärmarna varierar från de minsta telefonerna med 240*320 pixlar upp till de nyaste läsplattorna med upplösningar upp mot 1920*1200 pixlar. Skärmarnas olika tätheter, det vill säga pixlar per längdenhet, innebär också att 50 pixlar på en telefon inte definierar en lika stor fysisk sträcka som på en annan telefon. Android delar in skärmtätheterna i olika grupper vilket till viss del underlättar arbetet för utvecklaren. Dessa grupper kallas ldpi, mdpi, hdpi, xhdpi och xxhdpi, där dpi står för “dots per inch” och de föregående bokstäverna betyder “low”, “medium”,
“high” och så vidare. Grupperna definierar dock inte en exakt skärmtäthet utan bara ett ungefärligt område.
3 Utförande
3.1 Spelidén
Att spelet ska vara lätt att ta åt sig och mycket självförklarande är nyckelord i projektet. Därför kom spelidén att bygga på det populära och välkända plattformsformatet, mycket att likna med Super Mario-spelserien. För att vara tilltalande har allting en mysig känsla, med en skogsmiljö, lustiga ljud, trivsam melodi och aningen humoristiska inslag. I spelet finns en huvudrollskaraktär Valentine, och tankarna om denne bör dras mot ord som söt, gullig, som ett moln, livrädd och med röst i falsett, men modig när det gäller. Valentine har en pistol som han kan skjuta fiender med och kan också utföra en specialrörelse där han accelererar snabbt nedåt för att stöta bort fiender, kallad “dash”. Spelet innehåller en tutorial för att lära känna spelets funktioner, tiotalet banor och tre typer av motståndare för att ge möjlighet till större omfång och story i spelet, samt en finalkamp mot antagonisten. Detta speglar en välkänd storyuppbyggnad som flertalet mer vana användare bör känna igen. Huvudkaraktärens vapen ska ej kunna laddas om utan istället ha överhettningstillstånd, även detta ett välkänt system för spelapplikationer. Detta innebär att vapnet hettas upp när Valentine skjuter och slutar fungera under en tid om överhettningsmätaren går över en viss gräns. Utöver detta finns även ett poängsystem som beräknar poängen efter varje bana, vilket grundas på spelarens bantid, hälsa och antalet eliminerade motståndare.
3.2 Aktiviteter
Applikationen utgörs av aktiviteter som representerar olika stadier i spelet, till exempel olika me- nyer och dylikt. I detta spel behövs en huvudmeny, en spelskärm, samt avslutningsskärmar för vinst och förlust på en nivå. Från huvudmenyn ska spelskärmen nås, och från spelskärmen ska avslutningsskärmarna kunna nås, men spelaren bör även kunna gå tillbaka till huvudmenyn. Från avslutningsskärmarna ska spelaren kunna fortsätta spela eller gå till huvudmenyn.
3.3 Programmering
3.3.1 Huvudmeny
I aktiviteten som ansvarar för huvudmenyn skapas en huvudklass som styr vad som händer i menyn och dessutom håller i alla ytterligare objekt som behövs. Menyn har rörlig grafik och har därför layout uppbyggd på java-kod. Denna meny innehåller också ScoreLoop-komponenten vilken sköter highscore-hanteringen.
3.3.2 Spelläge
Likt huvudmenyn skapas en java-baserad huvudklass som styr spelet och uppdaterar samt renderar dess komponenter. Den här klassen blir den största klassen kodmässigt då spelaktiviteten är den huvudsakliga delen av spelet.
3.3.3 Avslutningsskärmarna
I avslutningsskärmarna behövs inte så mycket kod förutom de XML-layouts som används. Den enda koden här är den som utför förflyttningar tillbaka till övriga aktiviteter samt laddar upp poäng till servern.
3.4 Lansering
3.4.1 Betatest
Som brukligt vid utveckling av spel lämnas applikationen ut en tid innan den läggs upp på mark- naden. Detta för att få testas av en större grupp användare, ett urval vars feedback kan ge ap- plikationen en sista utvecklingsskjuts innan lansering. Detta inkluderar ett test av ett större antal enheter, möjlighet till buggtest, highscore-funktionen duglighet och hur spelet i övrig uppfattas.
Testpersonerna ligger i målgruppens åldersspann.
3.4.2 Google Play
När betaperioden är avklarad och spelet känns färdigt lanseras det på Android’s applikationsmark- nad Google Play. Detta moment innebär en smärre kostnad för projektet. Eftersom Google Play erbjuder uppdatering av applikationer kan även eventuella buggar åtgärdas efter release vilket idag är ett vanligt tillvägagångssätt för spelutvecklare.
3.5 Arbetsmetodik
3.5.1 Programutveckling
Spelet skapas i utvecklingsmiljön Eclipse IDE med hjälp av Android’s ADT plugin och GitHubs plugin Egit. Båda projektdeltagarna befinner sig på samma ort under utvecklingen för att förenkla kommunikationen. Arbetet delas upp allt efter behov och GitHubs merge-funktion avänds sedan när det anses rimligt, med andra ord när programmet för tillfället fungerar som det ska. Arbetsmetoden är inte planlagd i detalj, utan när ett delproblem löses diskuteras och angrips nästa steg. På detta sätt tas små steg hela tiden varefter applikationen växer mer och mer. Då större problem uppstår läggs all kraft på att lösa det som ett lag, istället för att låta problemet sakta ner projektet. Arbetet fokuserar också på att så snabbt som möjligt skapa något som går att testa, med vad som ofta kallas
“trial and error”-metoden. Bland det första som skapas är till exempel klassen för huvudkaraktären och klassen för marken. I nästa steg blir det då lättare att testa metoder som att gå på marken och senare att kunna hoppa. Baserat på detta utformas spelets mekanik först, och därefter läggs mer och mer grafik och ljud på i efterhand. Filer som inte har ingår i repositoriet, som till exempel bilder och ljud under arbete, delas över en nätverksanslutning för att påskynda arbetet.
3.5.2 Estetik
Den estetiska delen av projektet innehållande bilder och ljud är en viktig del, trots att projektet i första hand klassas som ett programmeringsprojekt. Detta mycket därför att det bidrar till helhets- intrycket och är något som självklart eftersträvas i slutprodukten. Arbetet delas upp där den ena har hand om grafik och den andre ljud. Ansvaret ligger främst i att skapa något som fungerar, och sedan gemensamt diskutera huruvida denna skapelse kan accepteras eller bör redigeras. Därför tas gemensamma beslut även här, trots uppdelningen av arbetsbördan. Vid skapandet av grafik och ljud används Gimp och Audacity.
3.6 Spelrelaterade problem och lösningar
3.6.1 Skärmanpassning
I avslutningsskärmarna är det inte essentiellt att alla komponenter framträder exakt likadant på olika enheter, men när spelet och huvudmenyn visas är målet att se till att alla komponenterna fyller ut hela skärmen och ges exakt lika mycket relativt utrymme på skärmen för att ge en så rättvis upplevelse som möjligt. Detta löses genom att upprätta en tänkt skärm som spelet körs i och sedan skala denna skärm till enhetens skärm. Då alla skärmar inte har samma aspect ratio, alltså förhållandet mellan skärmbredd och skärmhöjd, görs en uppskattning av det genomsnittliga värdet, vilket visar sig vara 1,55. Detta värde tas fram som medelvärdet av det minsta samt det största kända värdet på dagens enheter. För enkelhetens skull definieras skärmen som 155*100 pixlar. När spelaktiviteten startas tas två konstanter scaleX och scaleY fram och definieras som kvoterna mellan den verkliga skärmens storlek och den tänkta skärmens storlek. Sedan skapas alla bitmappar utifrån dessa två konstanter samt en storlek i den tänkta skärmen. Se figur 3.
För att interaktionen med spelaren ska fungera måste även all input i form av pekrörelser på skärmen skalas ner till den tänkta skärmen vilket görs med samma två konstanter. Detta sätt att lägga upp spelet på medför att det alltid är exakt samma referenssystem som spelet körs på, och att skalningen endast påverkar grafiken.
Figur 3: Hur skalningskonstanterna räknas ut
3.6.2 Rendering
Renderingen fungerar genom att en png-fil läses in via Androids klass BitmapFactory och skapar objektet Bitmap. Dessa bitmappar renderas sedan med varsin metod i ordningen de står skrivna i koden. Detta skapar flera lager vilka målas på varandra. Se figur 4.
I lager 1-8 har himmel, sol och fram till och med marken ritats ut. I lager 9 ritas huvudkaraktären ut och lager 10 blir resultatet av lager 1-9. Notera att huvudkaraktären i detta fall ritas över de tidigare ritade lagren, det vill säga kommer att röra sig framför stenen, trädet, himlen och även marken. Det går vidare att urskilja att trädet är renderat efter himlen men före marken. På detta sätt kan man välja i vilken ordning man vill att objekten ses.
Figur 4: Renderingen sker genom att komponenterna ritas en efter en vilket ger ett djup i bilden
3.6.3 Ljud
Android erbjuder mer än ett alternativ när det kommer till ljuduppspelning. De två klasser som har utnyttjats i projektet är SoundPool och MediaPlayer. Båda klasserna har för- och nackdelar och lämpar sig därför bäst för olika situationer. MediaPlayer är en klass som laddar ljuden till ett MediaPlayer-objekt och sedan spelar dem direkt vilket innebär att objektet inte tar upp något minne när det inte används. En liten fördröjning sker dock när ljudet laddas från hårddisken vilket innebär att snabb upprepning av ljudet inte passar sig. SoundPool har skapats för att hålla korta ljud i minnet. Eftersom ljuden bara laddas in en gång med SoundPool är klassen perfekt för att spela korta ljud ofta. Klassen rätt strama minnesgräns gör dock att längre ljud inte lämpar sig.
Många av de använda ljuden i spelet är korta ljud som kommer att spelas ofta och därför används i huvudsak SoundPool. Temat som hela tiden spelas i bakgrunden är dock längre och ska bara startas en gång per aktivitet. Därför passar sig MediaPlayer bättre i det fallet.
3.6.4 Tråd
För att spelet ska köras med en jämn hastighet används en tråd vars uppgift är att sköta tids- stegningen och uppmana spelet att utföra sina kommandon. Tråden försöker att exekvera all kod i spelet 25 gånger per sekund, vilket betyder att varje loop får ta 40 millisekunder. För att åstad- komma detta kan tråden sova där det behövs. Om tråden märker att den inte hinner med försöker
den att korrigera detta genom att tillfälligt minska arbetsbördan. Trådens arbete under en loop kan delas upp i följande delar:
1. Starta loop, ta tiden i millisekunder då arbetet påbörjas 2. Be spelet att uppdatera alla sina tillstånd
3. Be spelet att rendera alla sina komponenter
4. Stoppa tiden och avgör om renderingen slutfördes i tid 5. Om ja: Sov den kvarvarande tiden.
Om nej: Hoppa över renderingen i nästa loop.
Att uppdatera spelets tillstånd går relativt snabbt men renderingen kan ta mycket tid och därför är det den biten som hoppas över vid ett så kallat “lagg”, se figur 5. Att spelets tillstånd uppdateras ändå kommer att medföra att spelets hastighet bibehålls och att endast bilden hackar till.
Figur 5: Bilden visar ett tidsförlopp där bildruta 5 inte renderas för att hålla tidsschemat.
4 Resultat
4.1 Story
Storyn är i genren klassiskt äventyrsinriktat där huvudrollskaraktären Valentine lever i en vänlig värld fri från våld. En dag dyker det upp monster i världen och Valentine ger sig ut på uppdraget att finna svaret på dess uppkomst. I inledningen får Valentine hjälp av sin mentor för att kunna försvara sig mot fienden, och han ger sig sedan iväg ensam på sitt uppdrag. Under sin resa passerar han många olika platser och hinder, och slutligen anländer han slutmålet. Där möter han spelets antagonist, mentorn, som har släppt lös monstren och Valentine går in i slutstriden.
4.2 Aktiviteter
Spelet består av fyra aktiviteter som representerar de olika stadierna huvudmeny, spelskärm samt avslutningsskärmar. Användaren går mellan aktiviteterna enligt figur 6. De fyra aktiviteterna ärver från den egenskrivna klassen BaseActivity vars enda uppgift är att hålla spelet i horisontellt läge.
MainActivity visar huvudmenyn med hjälp av huvudklassen MenuPanel. Detta är applikatio- nens “launch-aktivitet” vilket betyder att det är den första aktivitet som visas när spelaren startar applikationen. Härifrån görs förflyttning till spellägesaktiviteten. GameActivity håller i spellä- get och kör spelet med hjälp av huvudklassen GamePanel. Förflyttningar kan göras tillbaka till MainActivity och dess huvudmeny, samt till avslutningsskärmarna beroende på spelets utgång.
LevelCompleteActivity visar en meny som innehåller ett sammandrag av spelarens prestatio- ner i den avklarade banan, och förflyttning hit görs vid avklarad bana. Härifrån kan förflyttning till MainActivity och GameActivity göras. Den sista aktiviteten är GameOverActivity och nås när användaren ej lyckas klara banan. Från denna aktivitet sker övergång till MainActivity eller GameActivity.
Figur 6: Aktivitetsschemat för spelet
4.3 Programmering
4.3.1 Huvudmeny
Java-klassen MenuPanel är huvudklass i MainActivity och ansvarar för huvudmenyn och vad som styr det som händer i respektive aktivitet och dessutom håller i alla ytterligare objekt som behövs. I menyn finns alternativen att gå till spelläge, inställningsmenyn eller highscore-listan. Se figur 7. Det första alternativet ger användaren en ny meny där bana väljs och spelet startar. I inställningsmenyn kan inställningar för ljud och effekter göras, samt att man kan sätta namn på enheten vilket blir det namn som syns i highscore-listan. Det finns även alternativet att stänga av poängfunktionen.
I highscore-listan ses toppnoteringarna samt all statistik för den användarens poäng. Här kan man bläddra mellan banorna och se andra användares bästa poäng, förutsatt att användaren har accepterat ScoreLoop-avtalet. Menyn har en levande bakgrund beståendes av Valentine och detaljer
från spelläget. MenuPanel innehåller flera underklasser och renderingsmetoder, vilka anropas i varje tidssteg.
Figur 7: Spelets huvudmeny
4.3.2 Spelläge
Java-klassen GamePanel är huvudklass i GameActivity och agerar spindeln i nätet som uppdaterar och renderar alla komponenter i spelet. Vid varje tidssteg sköter GamePanel spelet genom sin uppdateringsmetod, vilken i sin tur innehåller alla underklassers uppdateringsmetoder. Vid en uppdatering uppdateras alla objekt vilket kan innebära att de flyttas samt kolliderar med andra objekt. Om det finns tid körs också renderingsmetoderna i tidsteget, vilka även dessa är samlade i GamePanel, för respektive underklass. Figur 8 visar en sekvens i spelet.
Figur 8: En pågående spelsekvens i spelläget
4.3.3 Avslutningsskärmarna
Avslutningsskärmarna ger användaren alternativ om hur den vill fortsätta spelet. Den kan antingen gå till huvudmenyn eller spela samma bana. Om spelaren har klarat banan ges även möjligheten att spela nästa bana samt en sammanställning över prestationerna om denne har aktiverat detta i inställningarna och poängen laddas upp till servern. Dessa skärmar är uppbyggda av XML-layouts, då de inte har några rörliga objekt. Se figur 9.
Figur 9: Avslutningsskärmen efter en avklarad nivå
4.4 Klassarkitektur
Applikationen är uppbyggd efter schemat i figur 10. Här ses de fyra aktiviterna Main-, Game-, LevelComplete- och GameOverActivity samt huvudklasserna MenuPanel och GamePanel och dess underklasser. Utanför schemat finns även klassen Const som är en statisk klass med majoriteten av spelets alla konstanter. Detta gör det lättare att överblicka koden eftersom att alla konstanter finns samlade på ett ställe.
Figur 10: Klasschema över applikationens utformning
4.5 Lansering
Lansering till Google Play skedde 1 juni 2013 och spelet finns att hämta gratis.
5 Diskussion
5.1 Spelkänsla
Spelet uppfyller så pass många olika moment att det kan anses som ett fullständigt spel. Det innehar en kampanj med en tutorial, tio banor samt en finalkamp. Dessa varierar i längd, antal motståndare, svårighetsgrad och uppbyggnadsmässigt. Banorna innehåller också element som plattformar, skyltar som visar information, sluttningar i vilka man glider utför och animeringar i form av rörliga djur och himmel. Dessutom finns en förgrund och en bakgrund vilket möjliggör att huvudkaraktären och motståndarna kan gå framför och bakom detaljer i naturen som träd och stenar. Allt detta tillsammans ger en känsla av djup och ett mer accepterande intryck överlag.
5.2 Upplevelse
Poängsystemet och highscore-listan bidrar till ökat tävlingsmoment vilket kan ses som en lyckad tanke och är en av grundstenarna i applikationen, tillsammans med själva spelet. Spelidén och ut- formningen har grundats i hur ett spel i detta format bör vara och så många igenkänningsfaktorer som möjligt har lagts dit i detta syfte. För att nämna några är den första faktorn givetvis äventyrs- storyn, en annan kampanjuppbyggnaden med en begynnande tutorial och avslutande finalkamp, vidare till exempel styrspakarna som är i enlighet med många av marknadens styrfunktioner. Dessa faktorer gör att spelet blir lättare att ta åt sig, vilket var en av punkterna i spelidén.
5.3 Helhetsintryck
Det finns även en mängd detaljer som spelaren inte tänker på vid första anblick, till exempel springer Valentine in från vänster när startmenyn öppnas och rör sig olika beroende på vilken ny meny man väljer. Dessutom följer hans blick den fjäril som flyger runt i bakgrunden när han står still och vidare rör sig Valentines kropp upp och ner för att härma att han andas. Detta bidrar också till den trevliga känsla spelet ska utstråla.
5.4 Betatest
När spelet släpptes som beta var uppslutningen inte så stor som hoppats. Efter det som kunde ut- läsas från online highscoren kunde eller ville knappt tio spelare ladda upp sina poäng till highscore- listan, och ännu färre kom med förslag på förbättringar och tips på buggar. Detta berodde möjligtvis på den korta tidsperiod betatestet pågick, att försöksperioden låg olämpligt tidsmässigt eller att de utsedda inte hade fått tillräckligt med informationen om projektet. Det framkom dock att spelet kraschade på vissa enheter, och att andra hade problem med styrfunktionen. Dessa problem kunde till viss del lösas och därmed hade betaperioden ändå en meningsfull inverkan på projektet.
5.5 Svårigheter
Eftersom i stort sett alla moment i projektet är nya så har problem varit en del av vardagen. Det största problemet var implementeringen av GitHub, vilket försenade arbetet under några dagar.
Dock att ha GitHub fungerande var mödan värt och tiden som åtgick tjänades snabbt in när arbe- tet kom igång. Vidare har det varit mindre problem med programmeringen, till exempel moment med skärmanpassning och multitouch, men dessa löstes till stor del med hjälp av programmerings- forum på internet. Under arbetets första del användes endast en Android-enhet, samt en emulator för buggtestning. Detta fungerade tills att multitouchen infördes vilket omöjliggjorde vidare ut- veckling med emulatorer. Emulatorn var också i jämförelse med en riktig enhet långsammare i spelläget och spelet flöt inte på samma sätt. Detta kan möljigtvis berott på inställningarna, men det rekommenderas att använda riktiga Android-enheter från start.
5.6 Poängsystem
Poängsystem har försökts balanserats så att det ska löna sig att klara banan snabbt men ändå ta viss tid på sig att eliminera fiender. Att hålla sin hälsa hög är viktigt för en hög poäng vilket förhindrar att spelarna kastar sig rakt in i striden utan att avväga vad som bör göras. Denna metod skulle givetvis kunna balanseras ytterligare, men från highscore-listan kan man utläsa att de spelare som ligger i topp försöker eliminera de flesta fiender på så snabb tid som möjligt, vilket bör vara den mest lönande strategin.
5.7 Buggar
Spelet kan fortfarande innehålla buggar, men på grund av tids- och personalbrist kan inte detta ses över utan spelet släpps som det är. Om större buggar upptäcks efter lansering finns möjligheten att åtgärda och uppdatera applikationen.
6 Slutsatser
6.1 Målsättning
Projektet har resulterat i en fullgod produkt i from av en applikation i spelformat för systemo- perativet Android och har lanserats på Google Play. Spelet har byggts upp ifrån grunden med Java och Eclipse, och lagrats i Github. Alla bilder och merparten av ljud som syns och hörs är egenproducerade med bildbehandlings- och ljudredigeringsprogrammen Gimp respektive Audacity.
Det har också upprättats en online highscore som implementerats i spelet från tjänsten ScoreLoop.
Applikationen heter Valentine’s quest och går att ladda ner gratis från Google Play sedan 1 juni 2013. Angående spridningen av denna är detta lämnat åt framtiden att utvisa, men det som än så länge framkommit i kommentarsväg är övervägande positivt. Detta har inte bara inneburit att få inblick i hur marknaden fungerar från ett mindre perspektiv, utan även större kunnande i pro- grammeringstekniker. De uppsatta målen kan därför sägas vara uppfyllda och mycket av detta som presterats kan också användas som mall i liknande framtida projekt.
6.2 Projektets helhet
Produktens helhet är godtagbar i den mån att spelet är enkelt, men med tillräckliga variationer och element för att inte vara enkelspårigt. Detta tillsammans med highscore-funktionen gör att applikationen kan sägas vara klar att lanseras, vilket den också har blivit. Att skapa och lansera en applikation är tidskrävande men ses som fullt genomförbart, speciellt med en större personal.
Mycket hjälp finns att få via Android och självklart internet i övrigt. Möjligheterna är i stort sett oändliga och begränsas egentligen bara av individens eller gruppens tidsramar. Projektet har många gånger, för att inte säga hela tiden, stött på mindre problem, men har kunnat lösas eller kringgåtts på ett bra sätt. Implementeringen av highscoren och lanseringen till Google Play gick även utan större problem. Projektet har genomgått flera stadier och faser, från planering till program- och komponentutveckling och lansering, hanterandet av olika program och tjänster och i viss mån marknadsföring vilket har gett en helhet till begreppet applikationsutveckling. Projektet ses därmed som lyckat.
6.3 Marknadsföring
Sett till lanseringen så har den skett, men i tystnad. Vid ett eventuellt framtida projekt kanske det kan läggas större vikt vid marknadsföring via förslagsvis affischering eller reklamblad på offentliga platser. I nuläget sprids applikationen från mun till mun men detta begränsar spridningen markant om man ser det geografiskt. Dock var projektets mål denna gång inte att optimera spridningen, på grund av att detta inte ansågs vara nödvändigt.
6.4 Utveckling till andra plattformar
Spelet begränsas just nu av att det bara finns tillgängligt till Android. En release till till exempel iOS skulle ge fler användare chansen att spela. Planer på utveckling till någon annan av marknadens plattformar har cirkulerat men förkastats då tiden blev knapp och ytterligare kunskaper skulle behöva erhållas.
6.5 Optimering
Det som skulle kunna göras med den färdiga applikationen är att låta en så kallad profilerare undersöka om det går att optimera koden, och på det sättet minska arbetsbelastningen för telefonen samt i viss mån minska spelets storlek lagringsmässigt. En profilerare kör Java-programmet och analyserar prestanda för att hitta kodsegment som tar lång tid att exekvera. Dessa kodstycken kan annars vara svåra, för att inte säga omöjliga, att finna manuellt.
6.6 Förbättringsmöjligheter
I det här fallet är det svårt att utvisa om spelet kan förbättras nämnvärt. Såklart skulle placering av vissa objekt i spelet, som motståndare eller plattformar, kunna göras om men detta anses inte vara nödvändigt. Spelet genomgick en testperiod där ett tiotal spelare ändå fick testspela och komma med förslag på förbättringar, vilket inte skedde varför det inte heller lagts ned mer tid på detta.
6.7 Utvecklingsmöjligheter
Vad gäller utvecklingsmöjligheterna så finns det egentligen ingen gräns. Det som gjorde att ap- plikationen ansågs vara färdig var att tiden för projektet tog slut, men att det fanns tillräckligt spelmässigt för att verkligen kunna spelas på ett utmanande sätt. Tankar om fler element i spelet som till exempel dörrar och spakar vilka användaren kan interagera med kan ge spelet ytterligare dimensioner. Även antalet banor skulle kunna utökas, och få fler och nya detaljer som gör det mer verklighetstroget och naturligt. Ett annat alternativ till att göra spelet mer avancerat är att lägga in olika svårighetsgrader. Om man blickar vidare finns även möjligheten till ett Valentine’s quest II, alternativt ett uppdaterat Valentine’s quest.
Referenser
[1] Android (operativsystem), (7 maj 2013), Hämtad 19 maj 2013 från http://sv.wikipedia.org/wiki/Android_(operativsystem)
[2] Android software development, (14 maj 2013), Hämtad 22 maj 2013 från http://en.wikipedia.org/wiki/Android_software_development
[3] GitHub, (24 maj 2013), Hämtad 25 maj 2013 från http://en.wikipedia.org/wiki/Github [4] Bild av Android’s “Activity Lifecycle”, Android Developers, Hämtad 23 maj 2013 från
http://developer.android.com/images/training/basics/basic-lifecycle-paused.png
[5] Byron Kiourtzoglou, (15 juni 2011), Android Game Development Tutorials, Java Code Geeks, Hämtad 8 april 2013 från http://www.javacodegeeks.com/2011/06/android-game- development-tutorials.html
[6] ScoreLoop’s startguide, (10 februari 2011), Hämtad 10 maj 2013 från http://www.scoreloop.com/wp-content/themes/scoreloop/docs/main.html
