Institutionen för datavetenskap
Department of Computer and Information Science
Examensarbete
Utvärdering av Gideros Mobile
avRobert Häll Olsson
LIU-IDA/LITH-EX-G--14/080--SE
2014-09-30
Linköpings universitet SE-581 83 Linköping, Sweden
Linköpings universitet 581 83 Linköping
Upphovsrätt
Detta dokument hålls tillgängligt på Internet – eller dess framtida ersättare – under en längre tid från publiceringsdatum under förutsättning att inga extra-ordinära omständigheter uppstår. Tillgång till dokumentet innebär tillstånd för var och en att läsa, ladda ner, skriva ut enstaka kopior för enskilt bruk och att använda det oförändrat för ickekommersiell forskning och för undervisning. Överföring av upphovsrätten vid en senare tidpunkt kan inte upphäva detta tillstånd. All annan användning av dokumentet kräver upphovsmannens medgivande. För att garantera äktheten, säkerheten och tillgängligheten finns det lösningar av teknisk och administrativ art. Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman i den omfattning som god sed kräver vid användning av dokumentet på ovan beskrivna sätt samt skydd mot att dokumentet ändras eller presenteras i sådan form eller i sådant sammanhang som är kränkande för upphovsmannens litterära eller konstnärliga anseende eller egenart. För ytterligare information om Linköping University Electronic Press se förlagets hemsida http://www.ep.liu.se/
Copyright
The publishers will keep this document online on the Internet - or its possible replacement - for a considerable time from the date of publication barring exceptional circumstances.
The online availability of the document implies a permanent permission for anyone to read, to download, to print out single copies for your own use and to use it unchanged for any non-commercial research and educational purpose. Subsequent transfers of copyright cannot revoke this permission. All other uses of the document are conditional on the consent of the copyright owner. The publisher has taken technical and administrative measures to assure authenticity, security and accessibility.
According to intellectual property law the author has the right to be mentioned when his/her work is accessed as described above and to be protected against infringement.
For additional information about the Linköping University Electronic Press and its procedures for publication and for assurance of document integrity, please refer to its WWW home page:
http://www.ep.liu.se/
Examensarbete
Utvärdering av Gideros Mobile
avRobert Häll Olsson
LIU-IDA/LITH-EX-G--14/080--SE
2014-09-30
Handledare: Erik BerglundTable of Contents 1 Inledning ... 1 1.1 Bakgrund ... 1 1.2 Syfte ... 1 1.3 Metod ... 1 2 Gideros ... 2 2.1 Box2d i Gideros ... 2 2.2 Lua i Gideros ... 2 2.3 Grafik ... 2 2.4 Ljud ... 2
2.5 Gideros Event system ... 3
2.6 Garbage Collector ... 3
2.7 Betalversionen ... 3
3 Vad bör en spelmotor innehålla? ... 4
3.1 Scene manager ... 4
3.2 Fysikmotor ... 4
3.3 Shader support ... 4
3.4 Views eller kamera ... 5
3.5 Automatisk skalning ... 5
3.6 Överföring till mobil och testning ... 5
3.7 Events ... 5 4 Spelbeskrivning – Gravell ... 6 4.1 Spelobjekt ... 6 4.1.1 Spelare ... 6 4.1.2 Målnod ... 6 4.1.3 Gravitationsnod ... 6 4.1.4 Repulsionsnod ... 6 4.1.5 Asteroid ... 6 4.2 Spelets mål ... 6 4.4 Poäng ... 7 4.3 Interface ... 7 4.4 Meny ... 8 4.5 Level editor ... 8
5 Erfarenheter från Gideros Mobile ... 10 5.1 Kamera ... 10 5.2 Minneshantering ... 10 5.3 Användarskapade events ... 10 5.5 Skalning ... 10 6. Resultat ... 12 6.1 Gideros ... 12 6.2 Spelet ... 12 7. Ordlista ... 13 8. Referenser ... 14
1
1 Inledning
1.1 Bakgrund
Det finns många olika ramverk att välja mellan för att utveckla spelapplikationer. De olika ramverken har olika fördelar till exempel om de har en inbyggd fysikmotor eller om de är gratis. I den här rapporten har jag valt att utvärdera Gideros Mobile. Gideros har en inbyggd fysikmotor, Box2D som har använts till flertalet populära appar och spel bland annat ”Angry Birds”[2]. Det finns också många applikationer utvecklade med Gideros till exempel ”Sudoku Genius”[4] och ”Battlebox”[5]. Jag valde Gideros att den har stöd för att testa applikationen direkt i mobiltelefonen utan att först kompilera och installera den, det är en stor fördel då det ofta kan ta lång tid att föra över en applikation till mobilen.
1.2 Syfte
Syftet med det här exjobbet är att utvärdera hur bra Gideros är som utvecklingsverktyg.
1.3 Metod
Jag kommer utveckla ett spel med Gideros Mobile. Grundidén till spelet kommer från min examinator Erik Berglund, under projektets gång kommer möten att hållas för att bestämma detaljerna i spelet. Med erfarenheterna från utvecklingen av spelet och genom att jämföra det med andra utvecklingsverktyg kommer jag utvärdera Gideros.
2
2 Gideros
2.1 Box2d i Gideros
Box2d är ett SDK för fysik i 2d spel skrivet i C++ av Erin Catto[1]. Det har använts i mängder av spel bland annat Angry Birds och Limbo[2]. Gideros har Box2D inbyggt i sitt ramverk, det underlättar användandet av Box2D men inte till någon större grad. Den största skillnaden är att man inte behöver omvandla koordinater från meter till pixlar, alla kordinater i Gideros anges i pixlar.
2.2 Lua i Gideros
Lua är ett scriptspråk skapat av ett team på Pontifical Catholic University of Rio de
Janeiro[3]. Som många andra script språk är Lua löst typat och funktioner kan returnera fler än ett värde. Lua har från början inget stöd för Klasser och arv men Gideros har sitt eget system för det. Klasser kan skapas med funktionen: Core.class(base) Där ”base” är basklassen som ärvs ifrån, om klassen inte ska ärva från något lämnas parentesen tom. Konstruktor till klasser skapas genom att definiera en klassfunktion med namnet init(), den kallas automatiskt när en ny instans av klassen skapas. Det går även att göra privata variabler och funktioner genom att definierar dem lokalt i samma fil som klassen. Ärvda
klassfunktioner kan skrivas över genom att definiera en funktion med samma namn.
2.3 Grafik
Allt grafiskt i Gideros har en gemensam basklass som kallas Sprite. Allt som målas ut på skärmen ligger i en trädstruktur med en basnod som kalla Stage. För att få en Sprite att målas ut lägger man till den som barn till Stage med hjälp av funktionen Stage::addChild, sprites kan också tas bort från stage med Stage::removeChild. Det går att lägga till, och ta bort, barn till alla sprites. När en sprite läggs till som barn till en annan kommer dennas position alltid att vara samma i relativt till den.
2.4 Ljud
Gideros har ett system för att spela upp ljud, först skapar man ett ljud objekt med
Sound::new(”filnamn”). För att spela upp ljudet används funktionen Sound::play som
returnerar en Soundchannel. Soundchannel kan användas för att spela upp ljudet, pausa, ändra tonhöjd med mera.
3
2.5 Gideros Event system
Gideros har ett inbyggt system för events med flera olika färdiga events så som:
TOUCHES_BEGIN som skickas när man rör skärmen, ENTER_FRAME som skickas när
en Sprite målas ut, med flera. Alla färdiga events skickas till alla Sprites som är barn till Stage. Det går även att göra egna events, men egna events skickas inte till alla Sprites istället måste man skicka eventet direkt till det objektet man vill ska ta emot det.
2.6 Garbage Collector
Lua precis som C# och Java använder en Garbage collector för att frigöra minne. Det vill säga allt som det inte finns någon referens till ska frigöras. Dock finns det några fall i Gideros där minne måste frigöras manuellt som kan leda till minnesläckor eller andra buggar.
2.7 Betalversionen
Det finns två betalversioner av Gideros[20], ”Indie” som kostar $149 per år och
”Professional” som kostar $449 per år. Det går också att få en rabatt om man är student, $79 per år. Professional är till för de som har intäkter på över $100,000 per år. Skillnaden mellan gratis och betalversionen är att på gratisversionen visas en skärm som säger att applikationen är utvecklad med Gideros Mobile när applikationen startas, koden krypteras inte och man får inte tillgång till nya funktioner som inte officiellt lagt tills i Gideros. En av dessa funktionerna är till exempel ”Ads Interface” som är ett sätt att lätt lägga till reklam i applikationen.
4
3 Vad bör en spelmotor innehålla?
Vad en spelmotor bör innehålla är ett ganska outforskat ämne. Det finns inga bra artiklar om hur man ska utvärdera en spelmotor eller ett spelutvecklingsverktyg. Som man kan se i artikeln ”The Case for Research in Game Engine Architecture”[7], som är en artikel som är ett ”call for reasearch” för vad spelmotorer bör innehålla. Istället har jag valt valt att utvärdera Gideros genom att välja ut några funktionaliteter som jag tycker att spelmotorer bör innehålla, förutom det mest grundläggande som att kunna måla ut en bild och spela upp ljud, och
jämföra Gideros mot två andra kända och etablerade utvecklingsverktyg för 2D spel. Corona som är ett annat utvecklingsverktyg för mobil och SFML som är ett utvecklingsverktyg för att göra multimedia program till pc och mac.
Funktionalitet Gideros Corona SFML
Scene manager Nej Ja Nej
Fysikmotor Ja Ja Nej
Shader support Nej Nej Ja
Views eller kamera Nej Nej Ja
Automatisk skalning Ja Ja Ja
Testning på mobil Ja Nej *
Events Ja Ja Ja
*SFML är inte till för mobilutveckling
3.1 Scene manager
Scene manager är ett system för att byta mellan olika scener i spelet, en scen kan till exempel vara menyn eller en bana i spelet. Corona har en inbyggd scene manager som de kallar för storyboard[10], Gideros och SFML har ingen inbyggd.
3.2 Fysikmotor
Fysikmotorn kollar på alla fysiska objekt i spelet och räknar ut alla krafter som uppkommer om de kolliderar med varandra. Både Corona och Gideros har integrerat Box2D som fysikmotor[8][9], SFML har ingen inbyggd fysikmotor.
3.3 Shader support
För att kunna utveckla avancerad grafik till sitt spel, som till exempel ljuseffekter måste man ha tillgång till grafikkortet. Det görs genom att skriva funktioner i shaders. Corona har viss shader support, det går att lägga till färdiga filter men inte skriva egna shaders[11]. Gideros
5 har ingen shader support nu, men det är under utveckling nu (2014-04-10)[12]. SFML har full shader support och det går att skriva egna shaders[13].
3.4 Views eller kamera
Spel är ofta större än bara skärmen man ser det på, som till exempel i Super Mario följer bilden efter Mario men världen är större än bara det man ser på TV:n. View eller kamerans jobb är att göra så man kan kolla runt i spelvärlden och att göra så man kan zooma. Gideros och Corona har inget inbyggt kamera system. SFML har ett avancerat view system där det går att visa flera olika delar av spelvärlden på skärmen samtidigt, det går till exempel att göra en minimap bara genom att göra en view som visar en liten och utzoomad version av spelet[14].
3.5 Automatisk skalning
Ett problem när man utvecklar spel är att skärmarna spelet ska visas på är olika stora, det är därför bra om utvecklingsverktyget har ett system för att automatiskt ändra storleken på spelet så man inte behöver ändra logiken när det spelas på olika hårdvara. I Gideros och Corona går det att ställa in automatisk skalning på olika sätt[15][16]. I SFML används View klassen[14].
3.6 Överföring till mobil och testning
Ett problem med testning när man utvecklar applikationer är att det ofta tar lång tid att föra över dem till mobilen. Både Gideros och Corona har en emulator som man kan testa
applikationen på, men vissa saker som multitouch, är svårt att testa på en emulator. Gideros har därför en applikation som kallas för Gideros Player som installeras på en mobil eller platta som applikationen ska testas på[17], i utvecklingsmiljön skriver man in IP till spelaren och sen skickas applikationen via trådlöst nätverk. Corona har inget snabbt sätt att testa
applikationen förutom via emulatorn. SFML är inte till för att göra applikationer så det går inte att föra över till mobil.
3.7 Events
Ett system för events används ofta vid spelutveckling till exempel för att se när en tangent trycks ner eller när något i själva spelet händer, som att spelaren tar upp en healthpack. Gideros, Corona och SFML har ett inbyggt event system[18]. Men i SFML går det inte att göra egna typer av events.
6
4 Spelbeskrivning – Gravell
Gravell är ett 2d spel som utspelar sig i rymden.
4.1 Spelobjekt
För att lättare förklara spelet går jag igenom de olika spelobjekten och förklarar vad deras funktion är.
4.1.1 Spelare
Spelaren representeras av en boll, det ska egentligen vara ett rymdskepp eller ett flygande tefat men exjobbet går inte ut på att måla texturer och jag är inte särskilt bra på det. Spelet går ut på att få spelaren att ta sig till målnoden.
4.1.2 Målnod
Om spelaren rör vid målnoden dras han till mitten av målnoden och banan är klarad.
4.1.3 Gravitationsnod
Gravitationsnoden drar till sig spelaren och asteroider om de är tillräckligt nära den, om spelaren rör mitten av noden försvinner den.
4.1.4 Repulsionsnod
Repulsionsnoden puttar iväg spelaren och asteroider om de är tillräckligt nära den.
4.1.5 Asteroid
Asteroider är spelets hinder. Om spelaren krockar med de tar spelaren skada, hur mycket skada beror på hur stor asteroidens är, hur stor hastighet spelaren har mot asteroiden och hur stor hastighet asteroiden har mot spelaren. Om spelaren tar tillräckligt mycket skada förlorar man och får börja om från början på banan.
4.2 Spelets mål
Spelets mål är att få spelaren att ta sig till målnoden. Det går inte att styra spelaren direkt, istället placerar man ut gravitations- och repuls-noder för att putta eller dra spelaren mot mål.
7 Noderna påverkar också asteroider så risken finns att man drar in dem mot spelaren och krockar med dem.
4.4 Poäng
När en bana är avklarad kommer det upp en score screen där hur mycket poäng man får för att klara banan räknas upp. Poängen beror på hur många gravitations- och repulsions-noder man har kvar och hur snabbt man klarade banan.
4.3 Interface
Bild på spelet
För att kunna placera ut gravitationsnoder gjorde jag ett grafiskt interface(längst ner på bilden ovan). Från interfacet kan man dra ut gravitations- och repuls-noder. Nere till höger sitter 3 knappar restart, meny och play som man förhoppningsvis förstår vad de gör genom att kolla på symbolerna, från början hade jag text på knapparna men det tog för stor plats.
Restartknappen startar om spelet på samma bana. Menyknappen växlar till menyn, det går att gå tillbaka till det pågående spelet från menyn eller starta ett nytt spel. Playknappen sätter igång spelet, från början är spelet pausat och ingenting i spelet rör sig, det går att pausa och sätta igång spelet när man vill under spelets gång.
8
4.4 Meny
Jag gjorde en ganska simpel meny med stora knappar, knapparnas storlek skalas beroende på hur stor upplösningen är på skärmen. Den första menyn som visas har bara 2 knappar, en för att komma till level select där man kan välja en bana att spela och en för att komma till level editorn.
4.5 Level editor
Menyn för att skapa nya, editera eller ta bort banor.
För att lättare kunna tillverka banor gjorde jag ett system där banor sparas i filer. Eftersom det fanns ett lätt sätt att läsa textfiler rad för rad i Lua sparas alla objekt som finns på en bana på en egen rad. Jag gjorde också en editor för att jag och de som spelar applikationen ska kunna tillverka banor lätt i spelet.
9 Level editorn
Som syns i bilden ovan drar man ut objekten man vill placera leveln från menyn längst ner på skärmen. Menyn går att skrolla i sidled, så det går att placera ut obegränsat med objekt på den. Knapparna som syns längst till höger visas bara när man har tryckt på knappen det står ”stuff” på. ”test” är för att testa banan, options öppnar en annan meny där man kan ställa in hur många gravitations- och repulsions-noder man startar med samt hur lång tid man tror att banan ska ta att klara. Tiden är till för att räkna ut poängen man får för att klara banan.
10
5 Erfarenheter från Gideros Mobile
5.1 Kamera
En av de första klasserna jag skrev till det här projektet var en kamera, kameran är till för att kolla runt i spelvärlden. Gideros har ingen färdig kameraklass, det har inte deras konkurrenter heller men jag tycker att det borde vara standard för spelutvecklingsverktyg eftersom spel ofta utspelar sig på ett utrymme som är större än skärmen man kollar på.
5.2 Minneshantering
Lua har en inbyggd garbage collector som frigör minnet för alla objekt som det inte finns någon länk till. Problemet är att om man använder events i en klass skapas det internt i Gideros en länk till den klassobjektet, därför måste man vara noga med att radera alla events när ett klassobjekt tas bort annars kommer inte minnet att frigöras.
5.3 Användarskapade events
Det går att göra användarskapade events i Gideros men de måste skickas till en viss event listener, till skillnad från de inbyggda eventen som skickas ut globalt till alla som lyssnar efter dem. Enligt dokumentationen i Corona[18] fungerar även deras användarskapade events på detta sätt. Jag tycker att det tar bort meningen med ett event, och blir istället som ett
meddelande som måste skickas till en viss mottagare. Att ha många events som skickas ut globalt skulle kunna dra ner prestandan om stage-trädet innehåller många sprites, men jag tycker att möjligheten att skapa globala events borde finnas.
5.5 Skalning
Gideros har flera olika sätt att automatiskt skala applikationen till olika upplösningar: No Scale – Top left: Skalar inte applikationen.
No Scale – Center: Skalar inte applikationen men centrerar den.
Pixel Perfect: Centrerar applikationen och skalar den med ett jämt tal som 1/3, 1/2, 2 eller 3.
Crop: Fyller skärmen genom att fylla den helt och klippa bort delar som inte får plats samtidigt som applikationen har kvar sitt bildförhållande.
Stretch: Sträcker applikationen så att den får plats på skärmen, behåller inte bildförhållandet.
11 Crop gick inte att välja till Gravell då det var viktigt att hela interfacet skulle synas på
skärmen. Stretch kan få det att se väldigt konstigt ut då vissa plattor eller mobiler är väldigt avlånga, Fit width/Height har samma problem som crop, vissa saker kan försvinna. Pixel Perfect gjorde att koordinat-systemet blev konstigt, jag försökte få interfacet att ligga i botten av skärmen men det låg alltid lite fel. Istället gjorde jag en egen skalning på allt i spelet som utgick från upplösningen på en iPhone 4.
12
6. Resultat
6.1 Gideros
Jag tycker att Gideros var lätt att arbeta med men på det stora hela är det likvärdig med andra verktyg som kan användas för gratis applikationsutveckling, Gideros största fördel är att det är så lätt att testa sin applikation på en telefon eller platta under utvecklingen. De gratis utvecklingsverktyg jag har kollat på är ganska lika och har alla grundläggande funktionerna som man vill ha för att skapa ett spel, men inte så mycket mer. Enkla sätt att visa en bild och spela upp ljud finns, plus lite annan funktionalitet beroende på vad dem som har gjort
verktyget känner för att implementera. Jag tror det beror på att Gideros som många andra gratis applikationsutvecklingsverktyg har ett ganska litet utvecklingsteam och det leder till att utvecklarna planerar att lägga till något som låter coolt men sedan ofta inte gör färdigt det och istället börjar jobba på något annat. Det kan man se om man söker efter en viss funktionalitet ser man ofta att utvecklarna skriver att det ska komma om några uppdateringar, som till exempel shader support som skrivs här av Gideros utvecklare i maj 2013[19] men fortfarande inte är implementerat. Men som så det ofta är med programmering så finns det personer som gör bra extra funktioner och förbättringar så man kan oftast lätt söka upp någon som har löst det problemet man har och använda dennes kod gratis.
6.2 Spelet
Gravell blev ett bra men ganska opolerat spel. Totalt finns det 8 banor att spela men det finns också en level editor för att tillverka egna banor. Det bör funka på både IOS och Android men det är bara testat Android och på IOS med hjälp av Gideros player. Mycket skulle kunna förbättras, till exempel skulle texturerna kunna målas om och en tutorial läggas till. Jag kommer inte jobba vidare på det då det ägs av mina examinator Erik Berglund men jag vet att några andra studenter jobbar vidare på det i ett annat exjobb just nu.
13
7. Ordlista
14
8. Referenser
1. Box2D. FAQ. URL: http://code.google.com/p/box2d/wiki/FAQ Hämtad: 2014-05-19
2. Wikipedia, om Box2d. URL: http://en.wikipedia.org/wiki/Box2d Hämtad: 2014-05-19
3. Lua. URL: http://www.lua.org/about.html Hämtad: 2014-05-19
4. Gideros Mobile, applikation. URL: http://giderosmobile.com/apps/sudoku-genius Hämtad: 2014-05-19
5. Gideros Mobile, applikation. URL: http://giderosmobile.com/apps/battlebox Hämtad: 2014-05-19
6. Corona Labs, storyboard. URL: http://docs.coronalabs.com/api/library/storyboard/ Hämtad: 2014-05-19
7. Eike Falk Anderson, Steffen Engel, Peter Comninos, Leigh McLoughin. (2008). The case for research in game engine architecture.
8. Corona Labs, fysikmotorn Box2d.
URL: http://docs.coronalabs.com/guide/physics/physicsSetup/index.html#setup
Hämtad: 2014-05-19
9. Gideros Mobile, fysikmotorn Box2d.
URL: http://docs.giderosmobile.com/reference/physics
Hämtad: 2014-05-19
10. Corona Labs, storyboard. URL: http://docs.coronalabs.com/api/library/storyboard/
15 11. Corona Labs, tutorial om shaders. URL:
http://coronalabs.com/blog/2013/10/17/tutorial-multi-pass-shaders-in-graphics-2-0/ Hämtad: 2014-05-19
12. Gideros Mobile, saker under utveckling. URL: http://giderosmobile.com/roadmap
Hämtad: 2014-05-19 13. SFML, tutorial om shaders. URL: http://www.sfml-dev.org/tutorials/2.1/graphics-shader.php Hämtad: 2014-05-19 14. SFML, tutorial om views. URL: http://www.sfml-dev.org/tutorials/2.1/graphics-view.php Hämat: 2014-05-19
15. Arturs Sosins. (2013). Gideros Mobile Game Development. Första utgåvan. Packt Publishing
16. Corona Labs, skalning. URL: http://docs.coronalabs.com/guide/basics/configSettings/
Hämtad: 2014-05-19
17. Gidero Mobile, överföring till mobil.
URL: http://docs.giderosmobile.com/deployment.html
Hämtad: 2014-05-19
18. Coronal Labs, användarskapade events.
URL: http://coronalabs.com/blog/2012/06/26/how-to-use-custom-events-in-corona/ Hämtad: 2014-05-19
16 19. Gideros Mobile, nyheter om shaders. URL:
http://giderosmobile.com/forum/discussion/3153/status-update-what-to-expect-when-you-are-expecting-opengl-es-2-
Hämtad: 2014-05-19
20. Gideros Mobile, priser för gideros. URL: http://giderosmobile.com/pricing
