Forskning som som delvis inte behövs men kan vara bra att ha

Kandidatarbete i Medieteknik, 30 hp

Vårtermin 2013

Skapa en level- och karaktärsdesign för mobil plattformar

En studie om level- och karaktärsdesign, vid utvecklande av ett digitalt spel för mobila plattformar.

Jonas Bergendorff

Jimmy Johnsson

Handledare: Pirjo Elovaara & Jens Sjöberg

Examinator: Peter Ekdahl

Blekinge Tekniska Högskola, Sektionen för planering och mediedesign

Kontaktuppgifter:

Jimmy Johnsson

ymmij12@gmail.com

Jonas Bergendorff

jonas@bergendorff.se

 

Abstrakt

Det här projektet fokuserar på hur man kan konstruera ett digitalt spel menat för en mobil plattform, som exempelvis en smartphone. Mobiler är mycket mer begränsade än en modern dator och det är på så vis många fler restriktioner att tänka på under planeringen och utvecklingen. En del av det här projektet är att ta fram vilka just dessa restriktioner är för några. Syftet med projektet förövrigt är att få en djupare insikt i vad en utvecklare behöver tänka på när han eller hon vill utveckla ett digitalt spel för en mobiltelefon, vilka restriktioner som finns och annan relevant information, sammanfattat i så kallade metoder. Som en del av projektet så gjordes en studie omkring främst level- och karaktärsdesign, där information kring vad respektive designområde innefattar och vad utvecklaren kan behöva tänka på när denne vill applicera det i praktiken. En genomgående forskning kring vad som begränsar mobilernas kapacitet inom 3D-spel har också varit ett stort fokus, eftersom även det bästa spelet i världen är misslyckat om det inte går att använda på sin tänkta plattform. Allt material som uppkommit genom studien har fungerat som en bas till en produktion inom sagda ämne, där resultatet har blivit ett mobilspel till vilket ovan nämnda metoder har använts och nyttjats på ett för oss praktiskt sätt.

Nyckelord: 3D, karaktärsdesign, leveldesign, mobil plattform, smartphones, optimering, undersökning, Unity3D

Abstract

This project is focused on how to create a digital game meant for a mobile platform, such as a smartphone. Cellphones are much more limited in their capacity than a modern computer and because of this there are also a lot more restrictions to pay heed towards during planning and development. Part of this project is to discover just what kind of restrictions there is. Our goal with this is to get a deeper insight around what a developer needs to know about mobile game development when he or she is creating a digital game for smartphones, what limitation there is and other relevant information, summarized into so called methods. As another part of this project there is a study consisting mostly around level- and character design, with information regarding both topics as well as what a developer might need to know before trying to create an application. A thorough research about the limitation of cellphones regarding 3D-game development has also been a huge topic, since even the best game in the world is a failure if it is unplayable on the platform it’s developed for. Every piece of material created or found through this study has served as a basis for a production, where the result is a smartphone game in 3D using the above mentioned methods practically.

Keywords: 3D, character design, level design, mobile platform, smartphones, optimization, survey, Unity3D

Innehållsförteckning                                                                Sida

1. Inledning ………………………………………………………………

2. Problemområde …………………………………………………….

       2.1 Bakgrund ……………………………………………………………….

       2.2 Problemformulering ……………………………………………….

       2.3 Syfte ……………………………………………………………………….

       2.4 Tidigare forskning ………………………………………………….

                  2.4.1 Smartphones ……………………………………………..

                  2.4.2 Leveldesign ……………………………………………….

                  2.4.3 Karaktärsdesign ………………………………………..

                  2.4.4 Onlineenkät ……………………………………………

3. Tillvägagångssätt …………………………………………………..

       3.1 Introduktion …………………………………………………………..

       3.2 SmartPhones ………………………………………………………….

       3.3 Leveldesign …………………………………………………………….

       3.4 Karaktärsdesign …………………………………………………….

       3.5 Optimering …………………………………………………………….

                  3.5.1 Vad är Draw Calls? ………………………………………………..

3.6 Användartest …………………………………………..

3.7 GUI ………………………………………………………………………..

4. Reslutat och diskussion ………………………………………….

       4.1 Resultat ur analytiskt perspektiv ………………………

    4.2 Resultat angående produktion …………………………

    4.3 Reflektion …………………………………………..

5. Ordlista ………………………………………………………………..

6. Källförteckning …………………………………………………….

 

 

1. Inledning

Genom att fördjupa sig inom leveldesign och karaktärsdesign kan man skapa ett koncept, både tekniskt och visuellt, med mål att locka till sig så många som möjligt. Vi vill också göra ett mer utmanade koncept genom att göra det fungerande och logiskt för mobila plattformar, närmare bestämt en smartphone, som har ett mer begränsat användargränssnitt (kontroller, styrmöjligheter) jämfört med en konsol eller dator. Mobila plattformar har också större begränsningar inom hårdvaran, så de kan inte hantera lika krävande program som dagens datorer klarar av. Det här ställer ytterligare krav på utförandet då vi måste mer i detalj fundera på vad som ska finnas med i vår produktion och vad som inte kan ta med i vårt mobilspel.

 

2. Problemområde

I denna del förklaras uppkomsten av vår studie och vilket problem vi har arbetat emot för att ge svar på. Vi går också in på vad vårt mål med studien har varit och varför.

2.1 Bakgrund

Karaktär- och leveldesign har använts i många olika sammanhang genom tiderna, bland annat inom film, böcker och spel. Karaktär- och leveldesign har gått från att vara analogt till ett mer avancerat digitalt system under de senaste åren.

Med dagens teknologi och utveckling har mobiltelefoner börjat ta allt större plats på marknaden och applikationer till smartphones blir allt mer förekommande, eftersom hårdvaran uppgraderas och kan hantera mer krävande program. Dock är mobiler fortfarande betydligt klenare än vad dagens moderna datorer är.

Binder man samman karaktärsdesign, leveldesign och mobiltelefoner får man ett scenario där en produktion kan skapas, exempelvis ett digitalt spel. Begränsningarna är striktare än mot en dator, men har ändå utrymme till att utforskas på djupet.

2.2 Problemformulering

Vår frågeställning för vårt kandidatarbete lyder:

“Hur kan man skapa en level- och karaktärsdesign för en mobil plattform?”.

Det vi kommer behöva undersöka för att få svar på den här frågan är främst vad level- och karaktärsdesign är, innebär och hur man kan applicera det på bästa sätt i en digital produktion. Vi behöver även kolla hur man optimerar till en mobiltelefon för att få ett spel som fungerar och som kan flyta på smidigt till mobiltelefonen.

2.3 Syfte

Vårt syfte med detta kandidatarbete är att få en djupare förståelse inom karaktärsdesign och leveldesign, mer specifikt till smartphones. Spel och applikationer blir allt mer förekommande nuförtiden, då mobilerna blir starkare allt eftersom dess hårdvara förbättras. Nuförtiden klarar mobilerna att arbeta med 3D grafik.

Det är även varje spelutvecklares mål att så många plattformar som möjligt ska kunna hantera produktionen när den är klar. Detta medför att forskning omkring hur man kan optimera programmen på bästa sätt till just den plattformen som vi kommer jobba mot till mobilen.

 

2.4 Tidigare forskning

I det här kapitlet tas information som ligger som bas för vårt projekt upp, för att ge en djupare insikt i vad de olika delarna innebär. Vad är leveldesign och vad kännetecknar en karaktär? All relevant forskning som vi har använt oss av inom respektive områden kommer i det här kapitlet. Det finns även en del fakta om smartphones.

 

2.4.1 Smartphones

Smartphones har på senare tiden blivit allt vanligare bland vanliga människor och med mer flerkärniga processorer gör att smartphones blir allt bättre. Varför mobilerna behöver bli allt kraftfullare har bland annat med att fler program kommer till mobilerna som  behöver mer datakraft för att klara av att användas utan att det ska vara frustrerande jobbigt för mobilanvändare att behöva vänta på att mobilen ska bli klara. En annan faktor som gör mobilerna bättre hela tiden är att processorer blir allt mer strömsnålare, än vad de var för ett par år sedan. I och med att processorerna tar mindre ström kan man ha större processor och på så vi få mer datakraft till mobiltelefonen. Man uppskattar att omkring 30% av smartphones på marknaden har fortfarande bara har en kärna, där resten har två eller fler. I nuläget har mobilprocessorer dock inte fler kärnor än fyra (se bild 01). Att en processor har fler kärnor än en, kan ungefär förklaras som att produkten har fler processorer. En tvåkärnig processor kan hantera beräkningar mycket fortare än en enkelkärnig processor på samma hastighet, dock inte riktigt dubbelt så snabbt (Unity3D, 2013).

(Bild 01, Antal Processorer)

RAM-minnet i mobiler är också en viktig faktor när det gäller prestanda, i synnerhet för spel. En modern dator har stöd för upp till 512 gigabyte (GB) RAM (Savill, 2012). De flesta användarna brukar dock inte ha mer än 8 eller 16 GB RAM installerat. Gigabyte är en enhet för storlek på bland annat hårddiskar och RAM-minnen. När det gäller smartphones är det idag vanligast att ha med mellan 512 Megabyte till 1 GB RAM (se bild 02), med ett par modeller som har upp till 2 GB, vilket ändå är mycket mindre än hos datorerna. Megabyte (MB) är precis som Gigabyte en storleksenhet, där det går 1024 MB på 1 GB (athropolis, u.å).

(Bild 02, Storlek RAM-minne)

 

2.4.2 Leveldesign

Först och främst, vad är en level? Ordet level i spelsammanhang kan betyda flera saker. Det kan vara ett siffervärde för erfarenhetsnivå i främst rollspel, det kan röra sig om svårighetsgrader (“Difficulty level”), men det kan också betyda världen som ett spel, eller även en film, utspelar sig i. Kalla det bana, karta eller värld, vilket man vill. I det här sammanhanget rör det sig om en spelvärld.

Levels finns i flera olika typer och former. Det kan röra sig om stora öppna ytor (s.k. Open-Worlds) eller många mindre områden som binds ihop till en stor värld, med hjälp av olika transitioner. Det sistnämnda systemet var vanligare förr, då begränsningar i hårdvaran hos datorer och spelmaskiner begränsade hur stor värld som kunde hanteras vid ett och samma tillfälle, men det används fortfarande idag.

Vad är “Leveldesign”? Det är en ganska vag definition faktiskt, då den ofta tolkas på flera olika vis. Dess gemensamma nämnare är dock att målet blir en värld/miljö för spelet eller produktionen att utnyttja, som bidrar till produktionens handling.

“Level Design is all about the combination of widely varying individual elements, keywords, that compose a level.” (De Jong, 2008, 13).

Vilka element som kombinationen involverar skiljer sig från designer till designer, men i regel innebär det;

Gameplay (hur spelet beter sig)

Layout (hur ytan är formad)

Interaktion (vad spelaren kan interagera med)

Story (vad leveln vill förmedla)

Ljud och musik (vilken typ av ljudeffekter och bakgrundsmusik)

Ljus (var artificiellt och organiskt ljus ska vara)

Texturer och material (vilka färger och former som ska vara med på modellerna)

Effekter (var specialeffekter ska appliceras och varför)

Atmosfär och Immersion (känslan och atmosfären som ska förmedlas till användaren)

Optimering (hur leveln fungerar smidigast)

Leveldesign är ett stort område som inte avslutas i en handvändning, utan var och en av de här punkterna inkluderas i produktionen på ett eller annat vis. En skicklig leveldesigner behärskar de här komponenterna och lyckas balansera in dem så att de passar ihop med varandra. Ifall några av elementen inte är kompatibla med varandra (exempelvis partymusik på en kyrkogård) så bryter det oftast immersionen helt och leveln kan vara mer eller mindre misslyckad.

De Jong sammanfattar sitt system för design av levels på ett intressant vis, om sex så kallade pelare, där alla har sin beskärda del i en fungerande level.

Optimisering och Polering

Då alla aspekterna i en spelvärld hanteras i realtid så måste leveln vara så optimerad som den kan bli om den ska fungera smidigt. Minimera antalet polygoner på områden som syns minimalt eller inte alls (exempelvis baksidan av en byggnad som står utanför själva ”spelområdet”, etc) Ju fler polygoner, desto kraftfullare hårdvara för att kunna köras med bra hastighet.

Enkelt sammanfattat: Ifall en level inte är spelbar, faller hela spelet med den.

Polering innebär att man måste gå över sin level för att kolla varenda litet skrymsle att inga detaljer som kan bryta immersionen är fel. Exempelvis ska man inte kunna komma utanför världens utrymme, men man måste också se till att spelaren inte kan se detaljer som inte används inne i spelvärlden eller som inte är tänkta att spelaren ska se. De flesta levels satta på marknivå är ofta konstruerade på ett horisontellt plan vars kanter måste döljas på ett logiskt vis. I sådana situationer är det vanligt att designern använder sig av berg, byggnader, tät skymmande skog, ett hav och ibland även något så enkelt som ett högt staket. Detta för att levels simulerar en plats på vår eller andra planeter och där tar inte marken slut. En felaktigt placerad kollisonsbox är ett av de snabbaste sätten att få folk att stänga ner spelet och aldrig starta det igen.

Gameplay

Gameplay är allt om att få en level att både se och vara intressant och framförallt underhållande att spela, för det är vad spel är: Underhållning. Och det är just vad designen innebär, att mer eller mindre ”ge spelarna något engagerande som får dem att stanna kvar i spelet”. Världens vackraste öppna fält lockar inga spelare om det inte finns något intressant att göra på fältet. In med lite floder att simma i, ett par klippor att klättra på, ett par träd att gömma sig bakom och det är genast ett steg, om än litet, mot ett mer intressant fält.

Immersion

Den pelare som ur många spelares synpunkt är bland de viktigaste. Att kunna leva i världen som en av karaktärerna, i synnerhet i förstapersonsspel, är någonting som de flesta suktar efter, inte bara att kunna styra karaktären. Det här involverar dock inte enbart karaktärens relation till världen, utan även hur världen ser ut. Den måste vara logisk och, ifall den är baserad på en verklig plats, autentisk. Sätt en bil i vattnet på en strand och varje spelare kommer undra hur den hamnade där. Ifall det inte finns märken från hjul i sanden ut i vattnet, och kanske en avsvimmad förare som flyter i närheten, är det en sådan sak som är ett av de enklaste sätten att bryta immersionen på.

Visualitet

Som det låter, en värld måste se lockande ut. Även den mest intressanta världen snubblar på sig självt ifall den inte är något att titta på. Det här är en ganska svår pelare att spika till bra, då spelarnas åsikter är så många att spelutvecklare omöjligt kan göra alla glada när det kommer till vilken grafikstil och detaljnivå. En del spelare föredrar realistisk grafik in på minsta pixel, medan andra gillar en lite mer tecknad känsla.

Funktionell Design

Den här pelaren har med mekaniken och layouten att göra. En level måste gå att navigera runt på fritt inom sina satta ramar och varje objekt måste passa in och försöka förstärka existansen av andra objekt på kuppen. Ett exempel kan vara en bokhylla. En ensam bokhylla längs en vägg är knappt märkbar, men ifall designern slänger in lite böcker i den och kanske strör en del till på golvet framför blir bokhyllans existens genast mer tydlig.

Kombinationen

Sist, men absolut inte minst, kombinationen av de fem ovanstående pelarna. ”A level can have awesome gameplay, and awesome visuals, but if the two do not complement each other it still won’t work.” (De Jong, 2008, s.14). Den färdiga leveln är resultatet av alla aspekterna när alla pelarna passat ihop som ett blixtlås.

2.4.3 Karaktärsdesign

Vad kännetecknar en karaktär? Om man slår upp karaktär i Nationalencyklopedin så får man upp följande:

”karaktär (franska caractère, av latin chara´cter, av grekiska charaktē´r, eg. ‘det inpräglade’, av chara´ssō ’inskära’, ‘rista’), om person: läggning, personlighet, ett tämligen stabilt mönster av en individs egenskaper, såsom de avspeglar sig i individens förhållande till andra och till sig själv. Oftast räknas till karaktären personlighetens känslomässiga och moraliska egenskaper, medan intelligens och kroppsliga drag inte ingår. En snävare definition tar endast fasta på individens moraliska egenskaper (”han har god karaktär”).” (Nationalencyklopedin, 2013)

Karaktärsdesign hänvisar bland annat till utseende, förmågor och personlighet av en virtuell närvaro i bland annat spel. Detta kan vara allt från enkla karaktärer utan utveckling till mångsidiga, trovärdiga varelser i en verklighetstrogen miljö. De val som görs under karaktärsdesignen kommer att ha stor inverkan på spelet och eventuellt livslängden på en eventuell serie (Yates, 2012d).

När man skapar en karaktär finns de vissa saker som man borde tänka på. Den första man borde tänka på, när man ska skapar en karaktär, är för vilket sammanhang karaktären ska finnas. Man bör även titta på om andra människor har gjort liknade karaktärer (referenser) för att lättare kunna designa sin egen karaktär (Fields, u.å). Efter att man har kollat upp referenser och andra viktiga delar som till exempel vem karakraktären är för en, vad karakrären står för kan man börja göra prototyper som passar till sammanhanget (Yates, 2012b). Har man en bakgrundshistoria till karaktären kan man, när man har skapat sin prototyp, börja lägga in små element av vad karaktären har varit med om förr i världen. Ett exempel kan vara ett ärr på huvudet som visar att han kan ha varit med i krig. Det skapar en större bild av karaktären och storyn blir lättare att förstå sig på (Iconic characters, 2011, 28).

Till prototypandet borde man också tänka på lätta igenkännbara former på karaktären som kvadratisk, rund, avlång och så vidare (se bild 04, bild 05 och bild 06) (Iconic characters, 2011, 30).

(Bild 03, Massa och Former)

© John Nevarez

(Nevarez, 2011)

Formen får gärna vara dominant. Det gör att man lättare kan förknippa sig med massan. (se bild 03).

Skulle man nu inte bry sig om att bara ha ett fåtal massor eller former utan man har flera olika, kan detta leda till att fokusen försvinner helt från karaktärerna. Detta har att göra med att det finns för mycket för oss människor att fokusera på och det gör att vi har svårt att identifiera oss med karaktären.

Har man rätt massa och former kommer det att göra att fler människor kan tänkas gilla karaktären.

  Detta har med att göra att en människa kan se formerna och massorna på karaktären snabbt. Vilket kan leder till att man förstår sig på karaktären lättare. (Yates, 2012a.Yates, 2012b)

Men man får inte glömma bort att karaktären måste ha någon form av skelett i sig, även om det bara är enkla former. Man ska kunna tro att det är ett skelett fast att det kanske bara ger en liten illusion. Även om man kör med lätta former ska man kunna se små drag och förståelse inom anatomi. Formerna ska kunna förmedla hur karaktären rör sig. Formerna ska också göra att karaktären ser ut som att den är ”verklig”. Med verklig menas att karaktären ska ha sina mänskliga/djuriska drag som logiska kroppsdelar för rörelser (Yates, 2012a), men också exempelvis ögon för att uttrycka känslor och humör (se bild 04, bild 05 och bild 06).

Färgerna som man använder på sin karaktär är också väldigt viktiga. En färg kan förmedla ett dolt budskap samt att om man använder färgpaletten rätt, kommer karaktären sticka ut mer och se mer intressant ut än om man bara tar någon färg som man inte vet om de passar ihop eller som inte har något med berättelsen, karaktären eller miljön att göra.

Det är svårt att kombinera någon “supergullig” färggrann varelse i en dyster miljö (Yates 2012b).

 

(Bild 04, Kirby)

© Nintendo

(Masahiro, u.å.)

(Bild 05, Yoshi)

© Nintendo

(Shigefumi, u.å.)

(Bild 06, Mumintroll)

©Moomin Characters™

(Tove, u.å.)

Går man till åldersgruppen ungdomar har de ett annat synsätt på en karaktär. Där kan man vinna mer på att karaktären har en större detaljrikedom än om det hade varit en karaktär till ett barn som inte har lika lätt att se alla detaljerna utan har lättare för enklare former. Dock är det inte fel att ha simplare former för ungdomar också, då alla människor har lättare för att se en helhet med hjälp av lättare form.

 Vet man vilken åldersgrupp karaktären ska rikta sig mot, är det också bra att veta vilken målgrupp. Den grafiska stilen kan göra skillnad från perfektion till katastrof beroende på vilken målgrupp det rör sig om. Innan man börjar göra en karaktär bör man veta vilken typ av människor man har tänkt locka fram med hjälp av karaktären och veta vilken stil som lockar den gruppen av människor

(Yates, 2012b).

En sak som vissa karaktärsdesigners gör för att få sina karaktärer mer intressanta är att överdriva vissa delar på sina karaktärer. Om man ska överdriva vissa delar eller inte är något man själv får ta ställning till. Fördelen med att överdriva någon del är att karaktären förmodligen kommer ser mer intressant ut än om man inte gör det. Nackdelen är att om man överdriver för mycket kan det bli att karaktären blir mindre eller inte alls verklig. Ett exempel kan vara att man överdriver näsan genom att man gör en lång näsa. Karaktären kommer förmodligen att se mer intressant ut (se bild 05 och bild 06) men beroende på hur lång näsa man gjorde kommer karaktären att bli mer åt det satiriska hållet. Och det är inte alltid man vill att sin karaktär ska bli förknippad med satir (Yates, 2012d. Iconic characters, 2011, 31).

 Ett annat exempel är att överdriva karaktärens huvud, vilket ofta bidrar till att karaktären ser mer gullig ut. Tittar man på olika dockor ser man att det är väldigt vanligt att de har överdrivet stora huvuden. Detta är just för att dockorna ska se mer gulliga och sötare ut när man tittar på dem. (Iconic characters, 2011, 34)

(Bild 07, Varelser med liknande teman)

© Digital-Tutors

(Marshall, 2013)

Om din karaktär ska ha med sig en viss typ av djur eller liknande kan man få in dolda budskap som visar att karaktären är vän med djuret. Ett exempel kan vara att en krigare kan ha en fågel på sin axel. För att få betraktaren att lättare förstå att dessa är bra vänner, skulle man kunna låta krigarens rustning eller hjälm ha inslag av en fågel. Exempelvis kan det då finnas fjädrar fastsatta på hjälmen eller kan hjälmen vara vingformad på toppen. Karaktärer blir också lättare att känna igen om det finns någon speciell detalj som ingen av dina andra karaktärer har. (Iconic characters, 2011, 32)

Om du vill skapa teman med olika varelser eller att en grupp ska höra samman, kan det vara bra om varelserna eller grupperna har något gemensamt med varandra (se bild 07). Det blir då lättare att förstå att de hör ihop. Det är lättare att förstå att karaktärer hör till samma grupp om de har till exempel en gemensamt klädesplagg (Marshall, 2013).

 

2.4.4 Onlineenkät

Vi bestämde oss tidigt under projektets gång för att sätta igång med en undersökning, vars syfte var att undersöka vilken typ av spelare de svarande är och vad som tilltalar dem och inte, samt vilken sorts spel de gillar. Genom det här hoppades vi att kunna sätta ihop ett koncept till en digital spelproduktion där vi försöker ta med så mycket som möjligt av det som uppskattas och undvika det folk inte vill ha med till den mån det går, utan att göra spelkonceptet ologiskt. Naturligtvis kan man inte glädja alla, utan målet blir att kunna få med så många åsikter som läget tillåter.

 

Vi använde oss av FreeOnlineSurveys, en internetsida där man kan skapa undersökningar och med en länk leda andra till den. Vi började med att sprida ut länken bland våra egna kontakter, men skickade sedan ut den till hela BTH. När vi stängde ner undersökningen hade vi fått in strax över 400 svar, varav en del kom från lite här och var i världen. Detta innebar att vi även fick in lite åsikter från andra kulturer på samma gång. Alla svaren är i antagande att de som svarade var ärliga.

Undersökningen var utformad utefter tre grundpelare. Den första kretsade kring spelaren personligen och vilken typ av spel de föredrar. Den andra innehöll frågor om vilka element de uppskattade, vad för typ av spelare den svarande är och vilken typ av intryck han eller hon får av vissa spel. De här två pelarna är väldigt generella och inte speciellt fokuserade på just vår produktion, men vi kände att de kunde inbringa värdefull information kring vilka spelare det är som svarade. Då vi planerar ett mobilspel som går ut på att förstöra saker så är det lättare att få användbar feedback från spelare som spelar inom den genren. Den tredje pelaren hanterade frågor kring vår egna planerade produktion

Av de svarande var det en klar majoritet män, men vi hade en väldigt bred utsträckning mellan åldrarna, som gick mellan 17 och 52 år, med störst andel mellan 20 och 27 år.

Den första riktiga frågan i undersökningen handlade om vilken typ av genre spelaren föredrar. Action-Äventyr fick flest röster, strax före rollspel, shooters och pussel. Pussel var något vi ville se bland de vanligaste svaren eftersom det är det vi planerar att göra.

En generell, men ganska viktig, fråga från den andra pelaren var om huruvida spelarna föredrar att leva sig in i universumen eller om de bara spelar spelen utan att bry sig om sagda universum. Det var mer eller mindre 50-50 bland de här svaren, men motiveringarna menade främst att det beror på vilken typ av spel det handlar om. Många tycker om exempelvis rollspel på grund av dess möjligheter till immersion, att man spelar som sin karaktär och inte bara kontrollerar denne. Andra tycker att spelen är lättare att spela ifall man läser på lite om bakgrunden till spelet. Å andra sidan, de som bara spelar spelen motiverade sitt svar främst med att de spelar för en enkel kortare flykt från den riktiga världen eller att då spel inte är på riktigt, ansåg de att det var en onödig detalj att läsa sig in i det. En del föredrog intensiva spel, där man inte har tid att tänka på varför olika saker händer utan bara följer med instinktivt.

Vi avslutade den andra pelaren med frågor relaterade till grafik i spel. Dessa involverade vilken grafisk stil och tema spelarna föredrog. De flesta vill ha realistisk grafik, ju mer detaljerad desto bättre, men galna spel, glada spel och färgintensiva spel låg inte långt efter. Vi hade tänkt oss en relativt enkel stil, ett mellanting mellan realism och glatt så även här låg vi inom ramarna redan från början. Slutligen frågade vi också om vilken typ av miljö som tilltalar spelarna mest. Stora öppna fält var mest populärt, men stadsmiljöer och svävande öar i luften fick också många röster. Det här var en bra bekräftelse för oss, då vi planerar att ursprungligen bygga våra miljöer i en stadskärna, men med den här informationen får vi det lättare att skräddarsy ett tilltalande system av layouter och även miljöer utanför staden.

Den tredje pelaren involverade som tidigare nämnt frågor specifika för vår egna produktion, som i sin tur kommer bli ett spel för mobiler. Frågorna handlade främst om vilka element som spelarna vill se i ett mobilspel respektive absolut inte se. Svaren gick ganska mycket ihop med varandra, de flesta ville se ett originellt spel med tydliga, enkla kontroller och det skulle gå snabbt att ta fram och stoppa undan. Om spelet har Replay Value, alltså något som gör att spelaren vill köra om spelet efter att han eller hon klarat ut det, så är det mycket bra också. Andra förslag på element som spelarna ville uppleva var bland annat att det inte skulle finnas tidsbegränsningar, det skulle vara lätt att förstå vad spelet går ut på, svårighetsgraden skulle öka efter hand och att fokuset på spelet skulle vara på lösningen, inte metoden/uträkningen. Att spelet var socialt var också önskat, där spelare antingen kan interagera med andra spelare eller jämföra sig med dem via exempelvis achievements (framsteg, meriter) eller high scores. Vi avslutade enkäten med att fråga vilken smartphone som de svarande använde sig av, då vi ville se vilken plattform som hade potentiellt störst marknad, där majoriteten använde sig av Apple’s iPhone-modeller.

2.5 Mobiltelefon som spelplattform jämfört med spelkonsoller och datorer

Det första man bör veta om man ska jämföra en mobiltelefon mot en nyare spelkonsoll eller en modern dator är att spelkonsollerna och datorerna har betydligt bättre förutsättningar för att jobba med grafik. Däremot om man skulle jämföra en smartphone mot bärbara spelkonsoller som tex Nintendo 3DS eller Playstation Vita får man väldigt olika resultat.

Om man börjar att jämföra dagens spelkonsoller (Xbox 360, Playstation 3 & Wii U) kan man först konstatera att alla tre är relativt lika när det gäller prestanda. Wii U är dock väldigt nytt och det finns inte så mycket information för att jämföra dess spel med de andra konsollerna än.

Om man däremot jämför dessa tre konsoller mot en modern datorn kan man lätt konstatera att man kan få betydligt snyggare, bättre grafik och prestanda på en dator. Karaktärer och levels kan vara betydligt öppnare på grund av att processorerna och grafikkorten är så pass bättre än vad de är i dagen spelkonsoller och hårdvaran till datorer kan man uppgradera relativt fritt medan man får nöja sig med det som finns i den versionen av spelkonsoll man köper. Dock kan detta ändras snart när den nya generationens konsoller (Playstation 4 och Xbox One) kommer ut på marknaden.

Om man gör spel till datorn har man då som fördel att man inte i regel inte behöver ta lika mycket hänsyn till hur komplexa ens modeller är. Det finns ju alltid en gräns för hur mycket innehåll man kan få in i sina spel, men på moderna datorer är den generellt högre. Men finns det bra saker om något så finns det också lite mindre bra. Datorer körs på ett av flera operativsystem, där Microsoft Windows och Apple’s MacOS tillhör de mest använda, och det här är något man måste ta hänsyn till när man utvecklar ett spel till en dator. En annan nackdel med datorer är den utbytbara hårdvaran. Det är som tidigare nämnt en stor fördel att kunna uppgradera bara en pryl i datorn istället för att köpa en helt ny när det behövs, men i och med att det finns exempelvis så många olika grafikkort som i sin tur kommer från olika tillverkare, så blir det förr eller senare också konflikter mellan spelens programmering och vad hårdvaran kan leverera. Det här gäller inte bara grafikkort naturligtvis utan det gäller även processorer, RAM-minnen och även hårddisken. Detta gör att spel kan bete sig konstigt även om specifikationerna för ens dator egentligen överskrider vad som krävs för att kunna köra spelet, då spelen ofta är anpassade för exempelvis en grafikkortstillverkare och ibland till och med en specifik grupp av kort som just de har tillverkat.

Jämför man en smartphone med en konsoll eller dator så blir det dock en värre kontrast, då telefonerna hamnar långt efter i prestandan. Man kan uppnå kvalitetsgrafik på mobiler också, men det är väldigt många faktorer inblandade i den ekvationen, som storlek på texturer, hur många objekt som finns i scenen, vilka grafikfilter, vilken spelmotor et cetera. Oavsett vilket så ligger mobilerna i nuläget långt efter konsoller och datorer i den frågan.

Det blir istället betydligt intressantare att jämföra en smartphone mot handhållna konsoller, som Nintendo 3DS eller Playstation Vita. Dessa konsoller är i ungefär samma prestandaklass som smartphones, det beror lite på vilken smartphone det rör sig om.

Kollar man dock upp specifikationerna för Nintendo 3DS och Playstation Vita kan man väldigt lätt se att Playstation Vita har bättre prestanda än vad 3DS har. En iPhone 4S ligger i ungefär samma klass som Playstation Vita, men vi använde oss av föregångaren, iPhone 4, för vårt projekt, som är placerad mer åt 3DS när det gäller prestandan. (nowgame, 2012).

 

3 Tillvägagångssätt

Denna del tar det upp om hur vi gick till väga med vårt projekt samt vilka problem som uppstod och hur vi löste dem för att kunna göra vårt planerade spel till en mobil plattform, mer specifikt en iPhone 4. De tre största delarna i produktionen rör sig kring leveldesign, grafiskt användargränssnitt och hur man optimerar programmet så att det kan köras smidigare på en mobil.

3.1 Introduktion

Vi baserade en del av vårt projekt på de responser vi fick via vår onlineenkät. Utan denna enkät hade spelet inte varit i samma stil som det är nu, då vi gjorde en del val baserat på vad de svarande ville respektive inte ville ha med i spel, med måltanke att kunna göra något som så många som möjligt tycker om. Detta har lite att göra med att vi själva hade flera olika idéer av spel till mobilen.

Bara för att nämna något annat alternativ var vi väldigt mycket inne på att göra plattformspel inspirerat av Banjo-Kazooie(Rare, 1998), ett plattformspel i 3D med stora inslag av ibland råbarkad humor. Men i och med att vi hade många alternativ och att vi ville se vad andra vill ha för spel kom vi fort fram till att en enkät hade varit bra. För att bäst kunna få så många svar som möjligt så beslöt vi oss för att lägga upp enkäten på internet, via FreeOnlineSurveys, då det skulle göra det mycket lättare att nå fler svarande än att dela ut lappar på gatan. Av alla svar vi fick in så kunde vi dra slutsatsen att många av de svarande gillade spel där man kunde förstöra olika saker, vilket passade in med en av idéerna vi hade, nämligen ett demoleringsspel.

Detta lade grunden till vårt projekt, som är ett förstörelsespel inspirerat av spelet Angry Birds(Rovio Entertainment Ltd, 2013) (ett populärt mobilspel där man skjuter iväg olika fåglar mot skurkaktiga gröna grisar med en stor slangbella). Vi arbetade med hjälp av en stor mind map där vi skrev in allting som vi ville ha med (se bild 08), indelade i olika kategorier, för att allt eftersom kunna kryssa över det som är avklarat. Det här systemet kopplade vi samman med en prioritetslista där vi lade in innehållet efter hur viktigt det är.

Saker vi absolut inte kan vara utan, som kontrollsystem så att spelaren kan styra spelet på ett smidigt sätt och miljön hur miljön ser ut, ligger högt upp medan övriga saker, som exempelvis specialobjekt som spelaren får eller tappar poäng utav och eventuella slumpmässiga händelser, är inte lika viktiga och därför hamnade längre ner i listan.

Det här systemet strukturerade upp vårt arbete till den mån att vi aldrig satt utan saker att arbeta med, medan vi ändå slapp att spika in en massa deadlines utöver den slutgiltiga.

(Bild 08, Mind map)

3.2 SmartPhones

När man ska göra 3D spel till mobila plattformer är det bra att lägga samman alla sina modeller redan i modelleringsprogrammet man använder sig av, än att lägga ut varje objekt i 3D-motorn för mobilen. Detta bör man göra för att minska på de så kallade Draw Calls, som är ett av de större problemen för spelutveckling till mobiler (för mer information om Draw Calls, se 3.5.1 Vad är Draw Calls?). Om man lägger in varje modell i 3D-motorn kommer varje objekt du lägger in bli minst ett Call, ett för modellen och ett för texturen (se bild 15), såvida den inte delar textur med en annan modell. Men om du istället lägger ihop alla detaljerna till en enda modell i modelleringsprogrammet sparar man in ganska många Draw Calls, då hela modellen endast blir ett Draw Call och ett per textur som är involverad. Det blir fler polygoner på modellen i och med att du har många objekt i den och även om man ska begränsa dem också är det viktigare att få ner antal Draw Calls (De Jong, 2011a).

 

Beroende på vilken mobil man utvecklar för finns det vissa “soft limits”, eller rekommenderat maximum som det ungefär betyder, som man i regel ska försöka hålla sig under eller runt. För en iPhone 4 (se bild 09) ligger den här nivån på ungefär 100-120 Draw Calls för att spelet ska kunna fungera flytande (kernja, 2012). Nyare mobiler har generellt mer kraft i sig och kan hantera mer data än vad de äldre mobilerna klarade av. Men att göra spelen endast till de nyare mobilerna gör att man tappar en stor del av marknaden.

Många spelmotorer för 3D-spel har inbyggda verktyg för att konstruera exempelvis miljöer, men en del av verktygen kan vara ganska krävande för mobilerna. Ett exempel på det här är 3D-penslar som Unreal-motorn (UDK) använder. Detta har med att göra att alla objekt man skapar med hjälp av penslarna fungerar som varsitt objekt, vilket innebär minst ett Draw Call per objekt, istället för att binda ihop dem alla till en enda stor komplex modell, sen tillkommer ju texturerna på det. Komplexa modeller tar i regel mer RAM-minne per modell, men i gengäld blir de mindre krävande än separata objekt är, då processorerna får färre objekt att hantera samtidigt. RAM-minnet är ett minne som går snabbare för processorn att nå än hårddisken (De Jong, 2011b).

 

I vårt kandidatarbete skapade vi ett spel mot iPhones, mer specifikt iPhone 4 (se bild 09) och nyare. Valet av just iPhone kommer att betyda vissa begränsningar och man måste ha en dator med Apple’s operativsystem OS X.

(Bild 09, iPhone 4)

3.3 Leveldesign

Leveldesignen är den större delen av vårt projekt, även om den blir lidande på grund av mobilens begränsningar.

Vi försökte tänka efter det material och tips vi forskat fram tidigare, främst ifrån Sjoerd de Jong’s bok: The Hows and Whys of Level Design (De Jong, 2008), om hur man bäst kan lägga upp designen för att hålla den intressant. Den främsta och kanske mest tydliga strategin är ett landmärke, eller en unik byggnad som skiljer sig från de generella. Det här steget hjälper spelare att lokalisera sig, främst ifall spelen utspelar sig via många mindre levels eller områden, aningen mindre viktigt i stora öppna spelvärldar. Ifall en level är satt i exempelvis Paris så skulle Eiffeltornet i bakgrunden vara ett utmärkt landmärke för att tala om för spelaren att han eller hon befinner sig i Paris just nu, i antagande av att leveln i fråga är satt i en verklig miljö och inte en fiktiv.

   För vårt projekt valde vi att sätta en stor kupolbyggnad (se bild 10)  som vårt landmärke, då vi ville hålla våra levels fiktiva och inte göra några referenser till aktuella existerande byggnader. Detta var det smidigaste sättet att göra byggnaden unik jämfört med resten av byggnaderna. Den här kupolen kommer synas i alla levels som är satta i vår fiktiva stad utan namn från olika avstånd och vinklar, för att orientera spelaren.

(Bild 10, Kupolbyggnad)

När det gäller Sjoerd de Jong’s sex pelare är optimeringen den pelare vi fått lägga allra mest tid på. När det gäller leveldesignen och optimering, började vi med att överskatta kapaciteten hos mobilen och våra block var ursprungligen i flera olika former, lite i stil med blocken från de gamla Tetris-spelen (se bild 11).

(Bild 11, Komplexa byggblock)

Vi märkte dock fort att mobilen började protestera redan innan vi avslutat första våningen och då började vårt största arbete med att optimera spelet tills att vi kan få vårt koncept att fungera utan att behöva offra för mycket. I överlag beslöt vi oss för att inte använda de lite mer komplicerade formerna och istället använda oss av en kub och ett lite större block som består av två kuber som sitter ihop (se bild 12) och att hitta lösningar som på något vis hjälper oss att behålla de objekt vi vill ha med i spelet (se stycke 3.5 Optimering).

(Bild 12, Enkelt byggblock)

Ett annat stort område var den funktionella designen som nämnts tidigare (se 2.4.3 Leveldesign). Vårt spel går ut på att demolera en konstruktion där byggblocken kan flyga fritt om de får en hård nog smäll från rivningskulan och vi har en satt restriktion att ifall närliggande byggnader skadas får spelaren poängavdrag och ifall det sker upprepade gånger, förlorar spelaren automatiskt. Detta ledde till att vi fick tänka en hel del på hur vi placerade konstruktionen som skulle rivas och närliggande byggnader, då vi vill lägga en viss grad av fokus på att spelaren ska slå rätt typ av block med rätt kraft och då ska det inte innebära att blocken flyger på de närliggande byggnaderna speciellt ofta såvida spelaren inte slår till konstruktionen för hårt.

Det främsta arbetssättet vi använde för det här var att sätta byggnaderna på rätt avstånd från konstruktionen och även på vilken position i förhållande till konstruktionen. Har vi exempelvis en väldigt hög konstruktion med många block, är det inte funktionellt att placera en byggnad rakt bakom eftersom det kommer innebära att flera block med enkelhet träffar byggnaden oavsett hur försiktig spelaren är. Istället måste byggnaderna säras lite utan att det bryter trovärdigheten eller får konstruktionen som ska rivas inte vara så hög, vilket begränsar möjligheterna för mycket för att fungera praktiskt.

(Bild 13, Funktionell Design)

Hur fungerar det i vårt spel? Byggnaden som ska rivas är markerad i blått, med den vita pilen som visar vilket håll slaget kommer komma ifrån. Vid en smäll av lagom styrka kommer det mesta bråtet att landa ungefär inom den röda ytan, men om spelaren är lite för våldsam, kan bråte flyga på byggnaderna markerat i gult, vilket ger poängavdrag.

För att den funktionella designen för level ett ska vara funktionell valde vi att placera gatan mellan de två byggnaderna direkt bakom byggnaden, då den är ganska hög och de översta blocken måste kunna få en viss frihet när de faller. Level två hade inte riktigt samma problem, då den inte är lika hög. Där räckte det istället med att bara ha en gata emellan byggnaderna.

Det här tankesättet förbinder sig dock till att användaren spelar på vårt tänkta sätt, att slå tyngre block som metall och tegel lite hårdare, medans han eller hon är lite försiktigare när det gäller lättare block, som trä (se bild 13).

Gameplay och funktionell design hänger ihop speciellt mycket i vårt spel. Det spelaren kan göra är att styra upp vart kulan ska slå på byggnaden och bestämma hur hårt, sen tar spelmekaniken över i form av vad som händer när kulan träffar byggnaden. Vad gör vårt spelprojekt intressant dock?

Först och främst, det är ett spel i 3D, något som fortfarande inte är alltför vanligt till mobiler. Sen har vi också ett originellt koncept som endast är inspirerat från andra spel.

Vad går spelet ut på? Spelaren måste uppfylla ett av i nuläget två mål för att klara av en bana. Det ena är att spelaren måste uppnå en viss summa poäng för att klara av leveln. Det här uppnås genom att förstöra block, som tar skada när de slår i något och i slutändan går sönder helt och spelaren får en mindre poängbonus. Det finns också specialobjekt som hjälper spelaren ifall de blir träffade, men det finns också objekt som ger poängavdrag ifall block flyger på dem, så spelaren måste vara försiktig på samma gång. Det andra målet är att byggnaden måste rivas till under en viss höjd, och ingen del av byggnaden får nå över den här höjden. Oavsett mål, har spelaren ett visst antal svingar på sig att uppnå dem och eventuella kvarvarande svingar när målen är uppnådda ger en poängbonus.

Det här faller som tidigare nämnt ihop med den funktionella designen till den mån att spelaren måste kunna få slå till byggnaden hårt nog för att den ska rasa, utan att blocken riskerar att flyga in i närliggande byggnader ofta nog för att göra spelet ospelbart.

Visualiteten på våra levels är också en faktor vi funderat över, men de tidigare nämnda tekniska aspekterna har låst oss ganska mycket när det gäller det här området. Alla våra 3D modeller behövdes hållas enkla för att hålla polygonantalet nere och vi kunde inte applicera hur stora texturer som helst på dem heller på grund av det här. Normalt brukar vi använda främst tre olika texturer på varje objekt, en färgtextur, en normal map och en specular map. Färgtexturen är, som det låter, den som sätter färgen på modellen. Normal Maps motsvarar främst effekter i modellen som repor, gropar och bucklor, mer eller mindre en illusion av djup i modellen, och Specular Maps säger åt vilka delar av modellen som ska återkasta ljus och i så fall hur mycket. Dock fick vi ur prestandasynpunkt nöja oss med endast färgtexturen och genom den få till illusionen av djup via färg istället. Lite mer komplicerat att skapa, men det sparar viktig prestanda som sagt.

Immersionen är den av De Jong’s sex pelare som varit svårast att få till i vårt spel. Immersion handlar mest om spelarens förmåga att kunna leva sig in i spelet som en av karaktärerna (om spelaren styr en av dem). Det har också med att göra logiken i leveldesignen, att få den att verka trovärdig. Spelvärlden behöver inte vara realistisk, men den måste ha element som förklarar varför den inte är det för att behålla immersionen. I vårt fall handlar ju spelet om en stad och eftersom spelaren inte styr en karaktär så blev vårt fokus inom immersionen att få världen att verka trovärdig. Ursprungligen hade vi tänkt att ha karaktärer som gick på trottoarerna i staden och bilar som körde längs gatorna, men i och med våra problem med prestandan så blev det avsnittet mycket begränsat. Vad vi har fokuserat mest på istället är att fysiken i spelet, som är en av de tydligaste bitarna, att verka trovärdig. Detta genom att kunna ställa in så att blocken får olika vikt efter material och att blocken kan ta olika mycket skada innan de förstörs. I övriga fall så rörde sig immersionen mest om placeringen av de närliggande byggnaderna och utseendet på den byggnad som spelaren ska riva.

3.4 Karaktärsdesign

När det gäller karaktärsdesignen för mobilen arbetade vi med väldigt få polygoner jämfört med vad man brukar använda i vanliga modeller för dagens 3D spel till datorn. Vi hade flera olika insprationer. Dessa insprationer kom från flertal andra spel som vi tycker om och kan användas till vårat spel. Som den tidigare forskningen kom fram till är det bättre att ta och använda andras inspration och göra om det till något eget än att göra något helt nytt. Fåglen som finns i spelet är inspererat från kycklingen Cocco i Zelda: ocerina of time (neoseeker, u.å). Gubbarna som går hade från början tänkts använda inspration från det första spelet av Tomb Raider (Katie, u.å), men i och med att till och med den karaktären var för avancerad i och med att man knappt ser gubbaran jämfört med byggnaden blev det till sist bara några få kuber som man kan se på avstånd att de företsäller en karaktär. Vi kände att det är bättre att lägga den extra kraft på annat till mobilen. Vi skrev ett litet program för att testa hur många vertices (se bild 14) en iPhone 4 klarade av innan mobiltelefonen började få problem att hänga med. Den klarade rätt många vertices. Vertex i grafiksammanhang är ett hörn av en polygon.

(Bild 14, Vertexförklaring)

Första testet vi gjorde var bara med vanliga kuber, för att en kub tar minst prestanda (8 vertices). Mobilen klarade av mellan 200 och 250 kuber. Efter detta testade vi en av de karaktärerna vi har i spelet som ligger på runt 100 vertices. Mobilen klarade av ungefär 200 av dem samtidigt innan mobilen började få problem och gick långsammare än vad den egentligen skulle göra. Det var en ganska liten skillnad mellan att använda ett block på 8 vertices och en gubbe på 100 vertices faktiskt. Nästa test körde vi en karaktär på ungefär 12 000 vertices. Mobilen klarade av cirka 20 den här gången innan problem uppstod. Sista testet innebar en modell på lite över 100 000 vertices, där mobilen bara klarade av två av dem. De två sista testerna är mer vad en vanlig karaktär tar på ett normalt spel till datorn.

Bara för att se skillnaden på en iPhone och kraftfullare mobiler testade vi hur många kuber en Samsung Galaxy SIII klarade av. Samsung-mobilen har en fyra-kärnig processor jämfört med iPhone 4 som bara har en enkel-kärnig. Processor (CPU) är den del av hårdvaran som är avsett för att hantera beräkningar och det allmänna arbetet. Samsung-mobilen klarade av ungefär 600 kuber innan den visade något tecken på att börja sacka efter. Detta är ett bra bevis på att man måste veta vilken grupp av mobiler man vill att spelet ska kunna köra på. Vill man ha snyggare grafik blir det färre som kommer att kunna spela spelet.

3.5 Optimering

Kort efter att produktionen startade märkte vi att vi behövde skära ner en hel del på innehållet vi ville ha med, för mobilen hade svårt med att rita ut speciellt många objekt i scenen, även om de bara var stationära. Vi visste sedan innan att mobilerna var klena, men vi blev lite förvånade över hur klena de faktiskt var.

Det här ledde till att vi började arbeta med en ny metod: Hur man optimerar 3D spel för mobiler. Först och främst behövde vi ta reda på vad som är de värsta bovarna när det gäller spelutveckling till mobila plattformar, då vårt polygonantal i scenen var långt under den begränsning vi testat fram tidigare, vilket gjorde oss ganska förvirrade. Vad vi fick fram från det här var att det fanns en annan mycket viktig aspekt för prestandan, i synnerhet för den begränsade kapacitet som mobiler har, och det är så kallade Draw Calls.

3.5.1 Vad är Draw Calls?

Spelmotorer fungerar efter en liknande princip som videospelare gör, att en massa bilder ritas upp på skärmen efter varandra, fast de gör de på två olika vis. En videospelare ritar bara ut en massa bilder på skärmen i hög hastighet som inte kan påverkas på något vis. En spelmotor ska först skapa en bild som den sedan ritar ut, och det är här Draw Calls kommer in. Varje spelvärld i 3D är uppbyggd av många 3D-objekt som har sina respektive färgbilder på sig (så kallade texturer) och inför varje bild säger spelmotorn åt datorns huvudprocessor och grafikprocessor att det finns objekt och texturer som ska ritas ut och vilka dessa är. Det här är Draw Calls. Varje objekt är ett Call och varje textur är ett Call. (se bild 15)

(Bild 15, Objekt och Texturer)

Det här sker många gånger per sekund, bestämt av hur många bilder datorn kan generera. De flesta spel har en standardhastighet på cirka 60 bilduppdateringar per sekund (alltså 60 bilder genereras varje sekund) och vid varje uppdatering görs oftast väldigt många Draw Calls, i alla fall i ett ambitiöst projekt innehållande många modeller, texturer och effekter.

En modern dator klarar normalt av att hantera många Draw Calls för att dess hårdvara är mycket kraftfullare än mobilernas motsvarighet. För mobiler, eller mer specifikt iPhone 4 som vi arbetar emot, är nivån mycket, mycket lägre. En ungefärlig “soft limit” för mobilen ligger på omkring 100 Draw Calls, det beror lite på hur avancerade de aktuella objekten i scenen är. En mobil klarar alltså av att hantera ungefär 50 objekt i scenen, om varje objekt har en textur vardera, men ofta delar i alla fall vissa objekt textur. Det gör att det brukar kunna finnas några fler objekt än texturer (Unity3D, 2009. Unity3D, 2010).

Men det finns många andra faktorer som kan begränsa antalet objekt i scenen; vertices (se bild 14) och fysik på objekt exempelvis. Alla de här har precis som Draw Calls en negativ inverkan på prestandan i olika grad och bör också användas med försiktighet, i synnerhet när det gäller den begränsade kapaciteten på mobiler.

En vertex (vertices i plural) är den punkt där två eller fler kanter (edges) av en polygon möts (exempelvis har en kvadrat fyra vertices, en i varje hörn). Dessa punkter har alla tre olika koordinater i en 3D värld; x, y och z (vilka motsvarar dess position i två horisontella riktningar och i en vertikal), där alla har ett varsitt siffervärde. Ju fler vertices det finns i scenen, desto fler siffror måste programmet hålla reda på och tillslut hinner det inte med, utan programmet sackar efter och spelet eller programmet blir hackigt när det inte kan generera lika många bilder per sekund.

När det gäller fysik i spel så är det också en krävande faktor. Fysik motsvarar exempelvis gravitation och hur objekt beter sig ifall de är rörliga och kolliderar med varandra. Ju komplexare modeller, desto fler uträkningar måste programmet göra varje gång något händer med ett fysikpåverkat objekt och precis som med antal vertices så hinner det för eller senare inte med längre.

Hur löser man det här? Hur kan man göra för att få in det innehåll man vill ha i spelet, när kapaciteten är begränsad? I vårt fall tänkte vi om en hel del. Vi hade ursprungligen tänkt använda flera olika former på våra byggnadsblock, då alla skulle finnas i flera olika material, kan liknas lite med formerna på brickorna till Tetris, men vid de första testen protesterade mobilen ordentligt redan efter en byggnad med bara en våning och det var ju inte speciellt bra eftersom vi vill använda lite mer avancerade konstruktioner med flera våningar.

Istället forskade vi på ämnet och hittade ett system av programmeringsskript (Purdyjo.u.å.) som var skapat för just optimering i Unity. Vad de skripten gör är att de tar alla utvalda objekt och binder ihop det till ett enda objekt och likadant med objektens texturer. Med ett par undantag, främst ifall det resulterande objektet är mycket komplext, slipper programmet följaktligen att göra ett Draw Call för varje objekt och varje textur och istället har den bara ett stort objekt och en stor textur att rita ut, vilket effektivt drar ner antal Draw Calls för totalt alla valda objekt i scenen till två, ett för modellen och ett för texturen. Problemet med det här skriptet är att det fungerar bara för stationära objekt, alltså de objekt som inte ska röra sig, vilket inte rakt ut hjälper vår konstruktion, men det minskar ner antal Draw Calls för bakgrundsobjekten, så att man kan utnyttja en del extra till byggnaden istället och det är ett stort steg i rätt riktning.

Vi valde också att göra om våra block till simplare former. Istället för de mer komplicerade böjda formerna så körde vi bara på en vanlig kub och en modell som var två kuber ihopsatta ovanpå varandra (se bild 16).

(Bild 16, Optimerade block)

På det här viset så fick vi ner antalet vertices (se bild 14) en liten aning, men störst förändring kom från fysiken, som med dessa enklare formerna fick mycket mindre komplicerade uträkningar att hantera och på så vis flöt spelet på bättre.

En annan sak som gör en stor inverkan på mobilen är V-Sync. Program fungerar som så att det kontinuerligt uppdaterar kod och dess respektive variabler för att generera bilder, en så kallad bilduppdateringsfrekvens. Det här kan ske över tusen gånger i sekunden, beroende på hur stark maskin man har och vilket program som körs. Men skärmarna som resulterande bilder ritas ut på kan inte hantera så många bilder i den takten, de är begränsade av sin så kallade monitor refresh rate eller skärmuppdateringsfrekvens som det heter på svenska. Bland dagens skärmar är en skärmuppdateringsfrekvens mellan 50 och 120 vanligast, beroende på vilken typ av skärm det är.

Vad det här innebär är att programmet mer eller mindre ödslar kraft på att generera fler bilder än vad skärmen klarar av att uppdatera sig, för oavsett hur många bilder som den blir tillsagd att rita ut så klarar skärmen bara av att rita ut lika många bilder som dess skärmuppdateringsfrekvens antyder. Detta kan resultera i att bilder ibland ritas ut felaktigt på skärmen då den inte hinner rita färdigt den första bilden innan den blir tillsagd att rita ut nästa och resultatet blir en överlappning som kan se illa ut, i tekniska termer kallad Screen Tearing. V-Sync är ett system som synkroniserar bilduppdateringsfrekvensen med skärmuppdateringsfrekvensen och på så vis undviker man det här problemet. Nackdelen med V-Sync är att det kräver en aning av maskinen att göra de här extra beräkningarna för att få bort de extra bilderna, men i gengäld så slipper man felaktiga bilder och överlappningar (tomshardware, 2012).

För oss var det mer användbart att stänga av V-Sync då vår bilduppdateringsfrekvens redan var relativt låg och hade inte så stor inverkan på spelet i sig, medan det sparade värdefull prestanda.

 

3.6 Användartest

Vi gjorde ett användartest när vi kände att spelet var spelbart nog. Vi testade spelet på en relativt ung målgrupp, från vår egna ålder och ner till innan tonåren. Vi valde dessa målgrupper för att det är bland dessa som det är lättare för oss att hitta människor som spelar på mobiltelefoner. Med vårt test ville vi främst veta vad de tyckte var roligt och intressant med spelet, men också vad de tyckte var mindre bra så vi kunde försöka åtgärda det. Vi ville också veta om de tyckte spelet var för lätt eller svårt, som visserligen är en väldigt individuell fråga men man får ändå en hum av hur landet ligger.

Utav testerna fick vi reda på att vårt grafiska användargränssnitt var rätt svårt att förstå sig på om man inte tittade på vår hjälpsida som vi lagt in i applikationen. Speltestarna som inte läste den hade problem med att förstå sig på hur man skulle flytta kulan bland annat. För att få bort detta problem kommer funderar vi på att inkludera en träningslevel som ska kunna lära spelarna hur det går till istället för en sida, där tanken är att man ska klara av denna först innan man får tillgång till de riktiga utmaningarna.

Funderingar kring hur den kommer att se ut kretsar kring blinkande pilar som pekar åt de fyra riktningarna för att indikera hur man flyttar kulan. Efter att spelaren då har flyttat kulan så kommer avfyrningsknappen att tändas upp för att vägleda spelaren till denne och spelet ska därefter successivt leda spelaren igenom resten av proceduren genom olika former av indikationer.

En annan intressant del vi fick reda på av testet var att några ville att fler karaktärer skulle finnas på banorna efter att de upptäckte att man fick bonus av dem. De tyckte det var roligare att försöka vänta in karaktärena för att förstöra dem. Detta var dock inte hur vi ursprungligen hade planerat, då de här funktionerna var tänkt till bonusobjekt som inte behövs förstöras för att klara av banorna. Men med den här informationen så är det mycket möjligt att vi i framtiden konstruerar en level med fler rörliga mål än stillastående. Nu efter att flera har sagt detta har vi själva också upptäckt att det kan bli ett mycket roligage spel om vi lägger in fler gubbar som kan bli träffade av rivningsblocken.

När det gäller bonusar generellt ville spelarna se att man fick exempelvis poäng ifall man rev ner alla block som fanns på leveln, eller att man fick extra bonuspoäng ifall man klarade leveln på bara ett drag. Vi har visserligen redan insatt så att man får bonuspoäng om man har drag kvar när leveln är avklarad, men man kan ju alltid lägga till att man får lite mer ifall man klarar den på bara ett drag.

Vi upptäckte också att knapparna för att nollställa spelet och high score respektive inte bör vara på samma menysida som vi hade satt dem på inför testen. Det var väldigt många som tryckte på dem och rensade statistiken innan de startade spelet för att de ville se vad knapparna gjorde. Vi har ett par idéer på lösningar till det här som inkluderar att flytta knapparna till en annan menysida, alternativt att sätta in en bekräftelse där spelaren måste godkänna att de vill rensa statistiken innan det faktiskt sker.

Vi hade också ett par som tyckte spelet var för likt Angry Birds (Rovio Entertainment Ltd, 2013), en av våra inspirationskällor, men vi fick tyvärr inte så mycket svar på varför de tyckte så. Den enda parallellen vi har med sagda spel är just förstörelsemomentet, som visserligen är centerpunkten i vårt spel, men också mer eller mindre helt skilt från Angry Birds.

Vi hade också ett par som var lite kritiska mot att blocken försvinner när de har ramlat omkull. Som svar på det här hade vi två argument, där den ena var prestandarelaterad genom att då blocken försvinner så får telefonen ett objekt mindre att hantera och därför behåller funktionaliteten. Den andra punkten har med att göra hur spelet delar ut poäng och man får poäng genom att förstöra blocken. Vi har lite svårt att se en lösning på det här, men det är något vi kommer att fundera på.

 

De resterande som testade spelet tyckte däremot att spelet var väldigt kul. Det som spelarna tyckte var roligast var att få så hög high score som möjligt. Det dröjde inte länge förrän en spelare hade satt rekord, för att senare bli slagen och återvända för att ta tillbaka tronen. Tävlingen var ett faktum och det var ungefär det här vi siktade på för den sociala delen av spelet. När vi hade användartesten uppe så var statistiken dock bara sparad lokalt, men i framtiden har vi idéer på att försöka få upp poängrekord och dylikt på internet så att spelare lättare kan matcha sig mot varann.

3.7 GUI

GUI står för Graphical User Interface, eller grafiskt användargränssnitt, som är menat att underlätta för användaren att använda produkten. I vårt fall handlar GUI om knapparna i spelet, samt styrspaken (se bild 17).

När det gäller kontrollerna i spelet finns det lite saker att tänka på för att spelet ska fungera bra. Varje knapp eller bild man har i sitt GUI tvingar motorn till extra beräkningar. Med andra ord gäller det att inte ha för många knappar och spakar i spelet för då kan spelet få problem.

Det var väldigt mycket jobb med att försöka programmera knappar och styrspakar till en smartphone. En av anledningarna var att det knappt fanns någon vettig information på internet om hur man byggde upp ett knappsystem eller ett styrspaksystem. Den informationen som vi hittade var från forum där koden inte var den lättaste att förstå sig på, om den ens fungerade på det sätt vi behövde när det gällde knappar och styrspakar. Det bästa som vi kunde hitta var å Unitys hjälpsida, men det var inte helt bra heller för vi hittade inget som hjälpte oss att förstå hur man gjorde för att få ett fungerande system (Unity3D, u.å).

Istället började vi söka runt på Unity-relaterade forum och tillslut hittade vi ett instickningsprogram till Unity för just det här ändamålet. Det heter Easy Touch och var väl rekommenderat av andra som använt det tidigare (Hedgehog Team, u.å).

När vi hade installerat det här programmet tog det inte lång tid innan man hade fått fungerade knappar och styrspakar till vårt spel. Som bonus med programmet hade den även en funktion som gjorde att man kunde testa sina knappar och styrspakar i Unity med hjälp av sin datormus. Detta var väldigt användbart eftersom muspekaren kunde simulera ett finger i testsyfte på datorn, utan att behöva exportera spelet till mobilen varje gång vi ville testa ifall saker fungerade som de skulle.

Så klart fanns det andra program som också kunde göra liknande saker som Easy Touch, men priset och funktionerna som man fick här gör Easy Touch till de mer prisvärda programmen och det är något vi rekommenderar ifall vi blir tillfrågade.

(Bild 17, GUI)

 

4. Resultat och diskussion

I den här delen av texten kommer vi ta upp våra tankar och reflektioner från vårt projekt, bland annat vad vi tycker gick bra och vad som gick mindre bra. Vad har vi lärt oss? Vilken nytta kan vi och eventuellt andra ha av den här texten? Har vi själva uppnått det vi ville få ut av arbetet, både teoretiskt och via vår produktion?

 

4.1 Resultat ur analytiskt perspektiv

Vårt arbete grundade sig inom att vi själva ville fördjupa oss inom främst level- och karaktärsdesign. Det hela startade ganska smidigt med att vi båda ville hålla oss till varsitt av de här områdena och det passade väldigt bra då de båda är ganska omfattande och vi bara var två personer med en begränsad tid på oss samtidigt som det hela skulle varvas med en produktion.

Vi hade en vision av vad vi ville uppnå för vår slutproduktion. För att få reda på vad vi skulle välja för typ av spel valde vi att göra en onlineenkät som vi skickade runt till våra kontakter samt till hela skolans studenter. Det här fann vi till att vara en väldigt bra metod att nyttja eftersom det gav oss väldigt många svar och åsikter från olika håll. När vi beslöt oss för att låsa enkäten så hade vi fått in en bit över 400 svar, vilket var långt fler än någon av oss hade räknat med. När vi nu hade en del exempel på vad andra ville respektive inte ville ha kunde vi utesluta vissa idéer som vi hade planer på att skapa.

 

Vi valde att arbeta i spelmotorn Unity3D (Unity3D, 2005-..). Det är en relativt enkel motor att arbeta i och vi båda hade lite erfarenhet av det redan innan projektet började. Det här underlättade en del för oss eftersom vi båda är grafiskt lagda och saknar en stabil bakgrund inom programmering och då var det mycket smidigare att arbeta i en motor vi redan behärskade till viss del. Vi hade ett annat alternativ, Unreal-motorn (Epic, 1991-..). Den är en lite mer avancerad motor som tillåter lite mer avancerade funktioner, men vi valde Unity över Unreal Engine därför att vi har en mycket mindre erfarenhet av Unreal och bedömde att vi behöver den tiden till annat än att lära oss en ny motor bra nog. Vi tror också att om vi hade valt Unreal hade vi behövt vara fler personer i projektet, några som hade kunnat arbeta enbart med programmeringen eftersom vi själva inte kan motorn så bra. Unreal använder sig också av sitt egna programmeringsspråk, Unreal Script, som är baserat på C++, ett språk vi inte använt tidigare. Unity har istället flera andra alternativ, däribland C#, som vi båda känner till lite bättre och det var lättare för oss att arbeta med.

Slutligen så var man mer låst i Unreal när man vill göra en ny form av spel, medan Unity lättare låter en börja från ruta ett.

 

(Bild 27, Unity3D)

 

Under produktionen gång uppkom också ett annat stort område som fick en stor del av vårt arbete, vilket var hur man kan optimera sin applikation för att få ner prestandakraven på den. Det gjorde att vår text blev mycket mer teknisk istället för grafisk som vi ursprungligen hade siktat på, eftersom vi behövde undersöka kring optimering av spel till mobiler.

Vår största restriktion kretsade kring hur många olika 3D-objekt som mobilen kunde hantera samtidigt, vilket vi lyckades lösa någorlunda. Vi hittade ett mycket användbart tillägg på Unity Asset Store som inkluderade kod och skript för just det här ändamålet. Vad det gjorde var att det kombinerade utvalda objekt till ett enda objekt, vilket effektivt minskar antalet objekt i scenen. Problemet är bara att det här fungerar bara för stationära objekt så vi kunde inte utnyttja det för vår byggnad eftersom alla dess delar rör sig, men det hjälpte med i alla fall med bakgrundsobjekten.

 

Vad har vi då lärt oss i vår studie om karaktärsdesign? Förut när vi skapade karaktärer ville man för det mesta göra något som inte redan fanns, en ny typ av karaktär. Det vill man nu också, men nu vet vi att även om man vill skapa något nytt, är det bra att ha referenser på något liknade för att få karaktären att se mer naturlig ut. Vi kan nu att om man lägger dit små indikationer, dekaler, av vad karaktärern har varit med om tidigare blir det lättare för den som ser karaktären att veta vad han är för typ av person eller individ och vad han har varit med om under eller innan spelets förlopp. Nu när man skapar karaktärer vet man att det är bra att tänka på vilket sammanhang karaktären ska vara till och inte bara skapa något slumpmässigt. Det är också viktigt att visa ifall karaktärer hör ihop med varandra genom att de visuellt har någonting gemensamt, exempelvis att medlemmar från ett kriminellt gäng bär samma jacka eller att en krigare med sin bevingade kompanion har inslag av fåglar på sin rustning.

Med våra kunskaper som vi har fått inom karaktärsdesign har vi i vårt projekt använt inspirationer, som exempelvis kycklingarna från spelet The Legend of Zelda: Ocarina of Time, till att få fram hur vi vill att våra egna karaktärer ska se ut, i det här fallet våra fåglar som flyger runt i spelet. Varför vi valde just den fågeln finns det många bra argument för. För det första är den väldigt lågupplöst, det gör att vi kan ha med fler fåglar i vårt spel utan att mobilen ska få för stora problem att hantera dem. En annan bra sak med just den fågelmodellen är att den har en väldigt simpel form som lätt kan förknippas med en fågel, vilket var viktigt i vår produktion då våra fåglar bara syns i ett par sekunder åt gången och spelarna måste hinna uppfatta vad det är för något som flyger förbi.

Om vi nu har spenderat den tid på att studera karaktärsdesign, varför valde vi då ett demoleringsspel som går ut på att riva byggnader? Varför valde vi inte plattformspelet som vi också hade i tankarna? De svar som vi fick in av vår enkät indikerade att de hellre ville ha ett spel där de kunde förstöra saker och det är svårt att uppnå i ett plattformspel. Vi hade också ursprungligen planer på flera olika karaktärer i demoleringsspelet också i början, som korvgubbar på gatan, tjuvar i byggnaderna och dylikt. De flesta skulle fungera som bakgrundskaraktärer, men de skulle finnas där lite i symbios med rivandet, att man exempelvis skulle få bonuspoäng om man rev huset medan tjuven var därinne. Det hade gett karaktärsdesignen det utrymme vi velat, men det var här prestandaproblemen stoppade oss från att inkludera karaktärerna och vi fick hitta ett enklare sätt att använda karaktärer på.

 

När det gäller leveldesign så har det inbringat mycket informativ kunskap om saker som vi själva inte tänkt på tidigare. Saker som vi sett när vi spelat olika spel men inte tänkt på varför de funnits där, hur en leveldesigner utnyttjar ljus och form för att vägleda spelarna igenom levels. Vi har också hittat intressant fakta på hur man kan optimisera sin level och hur vissa små detaljer kan göra under för spelarens intresse och engagemang när denne befinner sig på banan. De här detaljerna kan handla om en tom bokhylla som ingen ser ursprungligen, men ifall den får en hög med böcker som står lite huller om buller så blir den genast mer tydlig.

Det är de här tankebanorna som har influerat vår produktion på olika sätt, i den mån det har kunnat. På grund av våra tidigare nämnda prestandaproblem så kunde vi inte ha med intressanta ljuseffekter eller liknande för att göra våra levels mer tydliga eller vägledande. I vårt fall var det främst placering av konstruktion och byggnader som det handlar om. Vilken uppbyggnad ska konstruktionen ha och hur närliggande byggnader ska stå i förhållande till konstruktionen för att spelet ska bli lagom utmanande? Den typ av tankar och frågor, alltså runt den funktionella designen, var viktiga för oss i vårt arbete.

Det är nu i efterhand som vårt arbete och forskningen bakom dem även börjat influera våra egna upplevelser i spel, för nu börjar vi se lite mer i banorna för designen bakom en level och på sätt och vis lär man sig en del av det också.

 

När vi binder samman de här två områdena så får vi ett system som vår visions betydelse, men då mobilernas kapacitet låste oss en del så kunde vi inte ha med alla karaktärer eller till viss grad mer komplicerade byggnader. Det här var innehåll vi ville haft med, men det var inte nödvändigt för att spelet skulle vara spelbart.

Om nu prestandaproblemen var så stora och tekniskt bromsande, varför valde vi ändå att hålla oss till iPhone 4 istället för att sikta på en nyare telefon? Varför valde vi ens att arbeta med telefoner och inte siktade på ett spel för datorer eller konsoller där vi kunde släppa loss lite mer?

Det finns flera svar eller motivationer på den frågan. Vi undersökte marknaden över vilken telefon som var vanligast och fick olika iPhones som den tydliga majoriteten bland de som svarade (se Tidigare Forskning, kap 2.4.4). Utav de som ägde en iPhone så hade de flesta en av telefonerna från den fjärde generationens iPhones eller den femte och det var den här informationen som var en del av motivationen för att använda just fyran. Apple’s telefoner är i stora drag likadana genom de senare generationerna, de använder exakt samma operativsystem så det är egentligen bara storleken på skärmen och hårdvaran som skiljer dem åt av det som är relevant för vårt projekt. Vi beslöt oss utifrån det här att arbeta mot fyran för att ett fungerande spel till den modellen fungerar även på nyare telefoner utan större problem eftersom de är så lika.

Det enda riktigt besvärliga med att arbeta med en iPhone är att man behöver en Apple-dator med OS X installerat för att kunna exportera spel till en iPhone. Man måste också antingen betala cirka 100 dollar (ungefär 650 kronor) för en licens eller att göra en jailbreak på mobilen, för att kunna arbeta med mot en iPhone vilket komplicerar det ytterligare. Lyckligtvis så hade vi både och, så för oss var det inget stort bekymmer, men för andra kan det begränsa smidigheten ordentligt.

Anledningen till att vi valde just en telefon att göra ett spel till och inte en dator eller konsoll har lite med den begränsade tiden vi hade på oss. Det tar lite längre tid att göra ett spel som känns komplett till en dator eftersom man kan och, i många fall, behöver få in fler detaljer i spelen, tid som vi kände att vi inte riktigt hade. Dessutom hade våra tidigare projekt alltid varit menade för en dator och vi kände lite personlig utmaning i att arbeta mot en ny plattform. Det var visserligen lite riskabelt med ovan nämnda tidsbegränsning att sikta på en annan plattform som ingen av oss hade kunskap om när det gällde att arbeta mot den. Men i och med att vi innan projektets start visste att kapaciteten var lägre så kände vi att tiden det skulle ta oss att göra den lägre detaljnivån skulle lämna en stor nog lucka för att hinna lära oss den nya plattformen på.

 

I slutändan av vårt resultat kan man konstatera att även fast vi har lagt betydligt fler timmar på vårt projekt än vad många andra kanske gjort, skulle man kunna lägga minst lika många till för att få vårt spel som vi hade tänkt oss från början. Det vi skulle vilja ha haft med, men som inte kunde komma med på grund av att vi inte hade tid eller kapacitet för är fler världar, fler bonusar, egna ljud och saker som man kunde se hända i fönstren på byggnaderna. Dock vet vi nu i efterhand att den sista punkten hade blivit problematisk hur vi än hade försökt, vilket vi inte visste i början. Varför hade det här inte gått då? Det hade inneburit att vi hade behövt göra de omgivande byggnaderna mer avancerade, så antalet vertices hade stigit vilket hade inverkat på prestandan. Dessutom så hade extra karaktärer påverkat resultatet.

Vårt färdiga spel blev dock en grundstomme för vad vi hade för vision i början av projektet. En ganska simplifierad version, men vi är ändå på rätt spår.

 

4.2 Resultat angående produktion

Vi valde att lägga upp vårt arbete efter en mind map, där vi satte ut alla moment som vi ville ha med i produktionen efter vad de behövde för att kunna implementeras i vår produktion. Vi tyckte att det här systemet fungerade väldigt smidigt för oss då det gav oss en relativ frihet att arbeta med produktionen. Vi hade vår lista med modeller och programmeringsfunktioner som skulle skapas och i och med hur objekten var placerade på minneskartan så såg vi tydligt vilka saker som behövde prioriteras och vilka som kunde skjutas på eller avvaras helt. Det här lämnade fältet fritt till att arbeta med objekten efter hand utan att ha en direkt tidsbegränsning hängandes över huvudet.

 

När produktionen väl startade var det just bristen på prestanda som var den största käppen i vårt produktionshjul, något som påverkat våra planer både inom leveldesignen och karaktärsdesignen. Det var främst här som funderingar och frågor kring vilka funktioner måste finnas med i spelet för att det ska fungera började diskuteras fram och tillbaka. Vad kunde vi undvara, antingen helt eller delvis? Det var ganska givet att vi behövde ha saker som mark och en byggnad att riva för att spelet skulle kunna spelas. Efter forskningen inom leveldesign så var det även ett par punkter till som var viktiga att ha med, byggnader omkring konstruktionen som skulle rivas bland annat. Spelet är satt i en stad och ett system av byggnader kan skapa illusionen av en mycket större stad även om inte hela syns i bild. Vi behövde dessutom ett sätt för oss att dölja horisonten. Det är inte meningen att spelarna ska kunna se slutet på världen, kanten där marken tar slut (se Tidigare Forskning, kapitel 2.4.2). Byggnaderna har även en annan roll för spelet i form av en restriktion, en utmaning. Spelaren ska riva konstruktionen utan att bråte flyger på de närliggande byggnaderna och skadar dem, lite i samma stil som rivningsarbeten i den verkliga världen.

Själva konstruktionen som skulle rivas var också en sak vi funderade mycket på i samband. Vi hade först tänkt oss byggnad som är konstruerad av lite avancerade former av byggblock, lite i stil med Tetris-blocken. Det såg väldigt bra ut i programmet, både visuellt och när det kollapsade, men vi fick ge upp den stilen när mobilen hade problem med hanteringen efter bara en våning. Istället fick vi tänka mycket i banorna kring hur vi kan simplifiera blocken och konstruktionen utan att offra för mycket av visualiteten. Vi skalade ner blocken till kuber och fokuserade på att låta dem dela texturer så gott det gick. Detta för att varje ny textur, oavsett storlek, orsakar påfrestning på spelmaskinen i olika grad. Det är ungefär på samma sätt som det populära spelet Minecraft är uppbyggt. Hela spelet består av en enorm mängd kuber staplade på varandra, men det finns mer eller mindre bara en textur per material som kuberna ska motsvara.

 

Vi hade också lite funderingar på hur vi skulle lägga upp vårt grafiska användargränssnitt så att det var tydligt men ändå lätt att förstå sig på. Vi hade en ursprunglig design som involverade en bild av en styrspak på ena sidan av skärmen, men våra användartester visade att speltestarna hade svårt att förstå att det var med den som man styrde spelet. Detta ledde till att vi fick tänka om en del av designen på gränssnittet och efter lite experiment så hittade vi en ny layout som vi fick lite bättre respons från. Den nya designen hade lite färre element på skärmen vilket också sparade in ett par Draw Calls.

 

För att sammanfatta så blev vår produktion i slutändan fundamentet av ett spel för mobiltelefoner, mer specifikt byggt för just en iPhone 4. Spelet är ett fullt spelbart demoleringsspel inspirerat av främst Angry Birds, ett annat mobilspel med liknande målkoncept. Den största skillnaden mellan spelen är att vårt spel är i 3D och att spelaren inte skickar föremål på konstruktionerna med en slangbella eller annan form av katapult, utan man använder en rivningskula istället. Spelaren får poäng genom att förstöra blocken som konstruktionen är uppbyggd utav och dessa är i olika material som är olika svåra att slå sönder och därför belönar spelaren med olika mängder poäng. För att vinna måste spelaren uppfylla ett av hittills två olika “mål”, antingen uppnå en viss poängsumma eller att ingen del av byggnaden överskrider en viss höjd. Spelaren förlorar ifall denne förbrukar alla tillgängliga försök han eller hon har tillgodo utan att uppnå målet för leveln eller om närliggande byggnader skadas för mycket.

 

4.3 Reflektion

Vårt beslut att slå oss ihop för att arbeta med två olika områden var något vi tyckte fungerade bra generellt eftersom vi kunde tackla två större områden utan att någon av oss fick för mycket att arbeta med. Det var ännu bättre att vi båda ville arbeta mot varsitt område, en med miljögrafik och att den andre med karaktärsdelen.

Detta gjorde det mycket lätt för oss att dela upp forskningsdelen till en början. När vi senare började arbeta med produktion så uppkom dock ett större bekymmer, att ta reda på mer information om mobiler och dess kapacitet. Vi blev lite överaskade över hur lite användbar information vi kunde hitta om just det här och det gjorde vår grund lite ostabil eftersom vi inte hade mycket att basera den på. Vi hade också problem att hitta fakta om hur man kunde få mobilen att känna av fler än ett finger på skärmen. Detta bekymmer tog lite tid att få ordning på.

Så länge att vi ett tag inte trodde att vi skulle lyckas göra ett mobilspel. När vi hade lyckast lösa detta stora bekymmer kom det fram ett nytt lika stort. Detta bekymmret var att mobilen var för klen för att göra de beräkningarna som vi ville att mobilen skulle göra. Problemt fick vi till sitt löst genom att en programmerare kom på ett nytt sätt för att minska på det som tog mycket datakraft. Vi gjorde om huset till änkla klossar och nu kunde mobilen hantera spelet bättre. Dock fick vi leta oss fram till många fler sätt för att få mobilen till att klara av spelet. Motivationen för hela projektet gick därför i vågor i och med att vissa veckor kändes det som att man inte hade lyckast göra någon nytta över huvet taget. Men när man lyckades lösa vissa problem blev arbetet roligt igen.

 

Vårt bästa scenario hade inneburit fler 3D-objekt i spelet, fler karaktärer, händelser och banor.

Det som gjorde att spelet inte kan bli som vi hade tänkt oss från början har med att göra att den mobilen vi skapade spel till hade för begränsad prestanda. En annan stor faktor som gjorde att spelet inte blev som vi hade tänkt oss från början har med att göra att vi inte var vana att programmera till mobiler. Vissa programmeringsdelar som vi inte trodde skulle ta så mycket tid att göra tog väldigt lång tid att få till. Några programmerings delar hade vi inte klarat om det inte var för vissa in- stickningsprogram. Tack vara att vi hittade vissa tillägg till Unity, som Easy Touch, kunde vi få vårt spel att röra sig på det sättet vi ville på en mobil.

 

Efter vårat kandidatarbete tror vi att vi kommer att ha väldigt stor nytta av allt vi forskade kring i kandidatarbetet. Vi vet nu ett av flera sätt hur man kan göra spel till smartphone, något som vi inte kunde förr. Det har vi stor nytta av när vi har slutat studerna på grund av att man alltid kan göra spel till smartphone om man inte har något annat för sig. Vi har nu en djupare förståelse om karaktär och leveldesign. Innan trodde man att man kunde tillräckligt om karaktär- och level design men nu vet man att det finns väldigt mycket forskning till varför ett spel ser ut som det gör. Det är knappt någon slump att spelen har de färgerna, byggnaderna, utseende på level och karaktärer med mera. Allt har en djupare planering än vad den som spelar spelet tror. Bara ett sådant litet sätt som att man tror man är i en “öppen” värd men i självaste verket finns det små element som gör att man går mot rätt håll, utan att man vet att den vägen är den rätta vägen. När vi nu hädanefter ska skapa en karaktär vet vi att massan och silhuetten är viktig att få rätt på innan man börjar att rita eller modellera en karaktär. Skapar man en karaktär utan att få silhuetten och massan rätt från början kommer man att få spendera många timmar för att få den intressant än om man gör dem rätt från början. Skulle man inte bry sig alls kan det resultera att man tycker att karaktären är väldigt trist eller att den ser helt konstig och ologisk ut.

Något man kan säga nu i efterhand är att mobilspel i 3D inte är det lättaste att utveckla. För oss var det mycket vi fick tänka om på, eller göra om, för att spelet skulle fungera bra på mobilen vi använde oss av och till följd blev forskning omkring optimering en väldigt stor del av vårt projekt. Det var visserligen både bra och dåligt, då vi faktiskt har lärt oss en hel del om det, men det satte också mer press på vilket innehåll vi skulle ha med och vilket vi kunde avvara.

När vi tänker tillbaka på vad vi hade för vision av spelet innan projektets början och hur det nu ser ut så kan vi nästan säga att det har blivit lite av ett annat spel än vi ursprungligen tänkt. Det är samma spel i kärnan, men visuellt så ser det rätt annorlunda ut mot vad vi hade i tankarna. Detta är också på gott och ont. Det positiva är att vi fick en vassare utmaning att arbeta mot jämfört med ett spel till datorer, vilket hade varit mycket lättare och vi hade inte lärt oss så mycket av det. Å andra sidan så blev visualiteten ganska simplifierad mot vad vi ursprungligen tänkt eftersom vi fick använda oss av mindre komplicerade modeller för att det skulle fungera, samt att vi saknade många av de små sidodetaljerna som karaktärer i byggnaderna, bilar på gatan och dylikt.

5. Ordlista

Applikation:           Program, förkortas ofta som app.

CPU:                      Datorns processor som beräknar och gör datahanteringar.

Draw Calls:            En signal som spelmotorn sänder till grafikprocessorn eller datorns

                              huvudprocessor varje gång någonting ska ritas ut på skärmen.

Förstapersonsspel:  Spel som spelaren upplever ur sin karaktärs synvinkel.

GUI:                      Står för Graphical User Interface. Detta är det grafiska       användargränssnittet som ska underlätta för en person att använda   produkten.

Hard Limit:            Ett absolut maximum som inte kan överskridas innan exempelvis en         dator eller ett program kraschar.

Identifiera:             Känna igen, igenkänna, likställa, styrka sin identitet.

Immersion:             Att kunna engagera sig helt åt, få en djupare inlevelse i.

Karikatyr:               Ett porträtt som överdriver eller förvränger delar på en person.

Polygon:                 En geometrisk form. En 3D-modell är uppbyggd av många ihopsatta       kvadrater exempelvis.

Processor:               Se CPU.

Smartphone:           En mobil enhet som används både som mobiltelefon och handdator

Soft Limit:             Likt Hard Limit, fast ett rekommenderat maximum istället. Det här kan   överskridas, men det brukar ge en negativ påverkan som exempelvis        färre bilduppdateringar i spelsammanhang.

Transition:              Övergång. Att något objekt transitionerar/övergår till en annan form.

Vertex:                   Den punkt på en polygon där två sidor (edges) möts. En kvadratisk         polygon har fyra vertices exempelvis, en i varje hörn.

Vertices:                 Pluralform av vertex.

Unity 3D:               En spelmotor för att konstruera spel i främst 3D.

 

6. Källförteckning

Alla bilderna som finns i vår text i kandidatarbetet har vi frågat om tillåtelse att få ha med i detta arbetet. Vi tacka alla som vi har fått kontakta och fått deras godkännande.

 

Apple. (2013). Licens. https://developer.apple.com/programs/which-program/ [2013-05-16]

 

athropolis. (u.å.). Memory & Storage. http://www.athropolis.com/popup/c-comp2.htm [2013-05-16]

 

De Jong, Sjoerd. (2008), The Hows and Whys of Level Design. 2nd Edition

 

De Jong, Sjoerd. (2011a). Unreal Development Kit 3 – iOS Mobile Game Production:

02 – placing meshes. http://eat3d.com/udk_mobile [2013-02-22]

 

De Jong, Sjoerd. (2011b). Unreal Development Kit 3 – iOS Mobile Game Production:

19 – The Ball 1. http://eat3d.com/udk_mobile [2013-02-22]

Epic. (1991-..). Unreal Engine 3 (UDK). http://www.unrealengine.com/udk/[2013-03-11]

 

Fields J., (u.å.). Alien Concept Design: Importance of using and gathering reference. [video]. http://www.digitaltutors.com/11/training.php?pid=682 [2013-02-22]

 

Galuzin A., (2011). Ultimate Level Design Guide.USA: Florida, Sarasota

 

Hedgehog Team. (u.å). EasyTouch [program] [forum].

http://www.blitz3dfr.com/teamtalk/index.php?board=2.0 [2013-11-16]

Iconic characters. (2011). Computer arts projects, Nr 156, ss. 26-37.

http://www.emagazinehub.com/Read/1121/view/Computer-arts-Projects-issue-156—November—December-2011 [2013-02-22]

 

    Katie F,. (u.å.). Katie’s Tomb Raider Screenshots [bild].

http://tombraiders.net/katie/screenshots/tr1/lara1.shtml [2013-11-13]

 

Kernja. (2012). Managing Drawcalls on Mobile Devices[blogg]. http://playbukketgames.com/?p=1420 [2013-05-16]

 

Marshall J., (2013). Create a GAME BOSS: Blocking out the character [video]. http://www.digitaltutors.com/11/training.php?pid=901 [2013-02-12]

 

Masahiro S., (u.å.).Bergsala. Nintendo. Kirby [Spel] [bild]. http://www.smashbros.com/en_us/characters/kirby.html [2013-02-28]

 

Nationalencyklopedin. (2013). karaktär. http://www.ne.se/lang/karaktär [2013-01-29]

 

neoseeker. (u.å.). Zelda: Ocarina of Time. Enemy of the Week – Cucco! [Tv-spel] [bild].

http://www.neoseeker.com/forums/50557/t1735920-enemy-of-week-cucco/ [2013-11-13]

 

Nevarez J., (2011). Massa och former [bild]. http://aauideationclub.blogspot.se/2011/12/artist-profile-16-john-nevarez.html[2013-02-28]

 

Purdyjo. (u.å.). Unity3D: Asset Store. Draw call Minimizer [program]. http://u3d.as/content/purdyjo/draw-call-minimizer/2FW [2013-05-16]

 

Rare. (1998). Banjo-Kazooie [Spel]. http://en.wikipedia.org/wiki/Banjo-Kazooie [2013-11-17]

 

Savil J., (2012). WindowsITPro. http://windowsitpro.com/windows-8/q-what-are-maximum-memory-limits-windows-8-editions [2013-05-17]

 

Shigefumi H., (u.å.). Nintendo. Bergsala. Yoshi [Spel] [bild].   http://www.smashbros.com/en_us/characters/yoshi.html [2013-02-28]

tomshardware. (2012). What is Vsync in gaming[forum]. http://www.tomshardware.co.uk/forum/358383-33-what-vsync-gaming [2013-02-10]

 

Tove J., (u.å.). Schildts förlag. Bulls Presstjänst AB. Mumintroll [bild].  http://www.bostream.nu/mynta/mumin/ [2013-02-28]

 

Rovio Entertainment Ltd. (2013). Angry Birds [Spel].

http://www.angrybirds.com/ [2013-02-28]

Unity3D. (2013). Mobile Hardware Statistics[blogg]. http://blogs.unity3d.com/2013/04/07/mobile-hardware-statistics-and-more/ [2013-05-16]

 

Unity3D. (2005-..). Unity3D [program].  http://unity3d.com/ [2013-05-16]

Unity3D. (u.å.). Unity Script Reference: input touches. http://docs.unity3d.com/Documentation/ScriptReference/Input-touches.html [2013-03-11]

 

Unity3D. (2009). What are Draw Calls[forum]. http://forum.unity3d.com/threads/27416-What-are-Draw-calls [2013-05-16]

Unity3D. (2010.) What’s the best way to reduce draw calls[forum]. http://answers.unity3d.com/questions/14578/whats-the-best-way-to-reduce-draw-calls.html [2013-05-16]

 

Yates I., (2012a). Character design: Anatomy [video].

https://tutsplus.com/lesson/what-is-a-character/ [2013-02-22]

 

Yates I., (2012b). Character design: Brainstorming [video].

https://tutsplus.com/lesson/what-is-a-character/ [2013-02-22]

 

Yates I., (2012c). Character design: Practicalities [video].

https://tutsplus.com/lesson/what-is-a-character/ [2013-02-22]

 

Yates I., (2012d). Character design: What is a character? [video].  https://tutsplus.com/lesson/what-is-a-character/