­­­Run Baby Run

Tobias Beck Petersen – Topet14

Else Teresa Møllebæk – Elmoe13

Introduktion

Vi har dette semester udviklet et pointbaseret løbespil. Dette spil har et babytema indover, da der i samspil med babyer, er mange passende objekter som kunne benyttes som forhindringer, score, boost og så videre. Spillet spilles ved at skal nå så langt som muligt, dette gøre men ved at hoppe over og dukke sig for forhindringer, samtidig med man samler point. Måden man skal hoppe på er ved at benytte accelerometeret i telefonen.

Vi ville gerne skabe et spil som vi selv ville have lyst til at spille, men som også kunne være et lidt tidsfordrivende spil. Det skulle være muligt at sidde med den højeste highscore, for at der er det konkurrencemindede aspekt med.

For at lave vores spil har vi benyttet os af de forskellige frameworks som xcode tilbyder SpriteKit[1], CoreMotion[2] som er elementer vi har benyttet os af for at skabe et underholdende spil. Måden vi har forsøgt at gøre det underholdende på var ved at teste og undersøge hvordan vores testpersoner i første omgang spiller spillet, interagere med platformen og om de synes det er sjovt. Derefter har vi justeret så meget vi har kunnet nå og testet igen.

Målet var at skabe et godt og sjovt spil, der giver mening i interaktionen med det og som er underholdende.

 

Metode

Brainstorm

Igennem vores brainstorm, tænkte vi i begyndelsen på hvilke elementer spillet skulle indeholde, derefter fandt vi nuværende apps, som matchede bedst med vores idé. Apps som vi fandt var blandt andet Temple Run[3] og T-rex Dino Game[4]. Dette var løbespil hvor man skulle undgå forhindringer og indsamle point.

Vi ønskede at spillet skulle benytte sig af accelerometeret for at figuren skulle hoppe og dukke sig og at man skulle kunne benytte kameraet til at tage et billede som spillet ville kunne bruge som baggrundsbillede.

Konceptuelle Design

Her gik vi i dybden med hvad app’en skulle kunne. Vi tegnede et layout af hvordan spillet skulle se ud. Og diskurede interfacet. Vi startede med at være på en simpel stickman der skulle hoppe over bokse og dukke sig under dem imens han løb som kan ses på Figur1. Vi synes hurtigt at det ville ligne et kedeligt spil som vi ikke selv ville have interesse at spille, så vi forsøgte at tænke i andre baner, men samme mechanics[5].

Vi overvejede forskellige temaer som vi kunne benytte og som indeholdte objekter i samme kategori der kunne benyttes – heraf fandt vi på babytemaet. På Figur 2 og Figur 3, er der tegning af hvordan vi designede dette nye tema. Herefter lavede vi en bedre prototype af hvordan spillet skulle se ud som kan ses på Figur 4. Dette var hvad vi fremlagde i klassen for at visualisere vores idé. Den indeholder de samme elementer og mechanics som i den første idé, dog er elementerne udskiftet med lignende men passende baby objekter.

 

Prototype

Vores første protype er den der ses på Figur 2 og Figur 3, disse gav os vores udgangspunkt for projektets tilblivelse og gav os alle de funktioner som app’en skulle indeholde.

Evaluering

Denne prototype fandt vi hurtigt ud af blev for ambitiøs, det ville ikke være muligt for os med den tid vi havde at tilføje alle de objekter og funktioner som vi ønskede skulle være med. Herfra tog vi de vigtigste mechanics med videre og valgte de vigtigste elementer som skulle være i en endelig prototype.

 

Endelige prototype

Figur 5 ses den færdige prototype af startsiden, på denne side er der en stor startknap der fylder en stor del af skærmen, dette gør den fordi der ikke skal være mange steps i at starte processen. Det skal være ligetil og til at forstå. I øverste venstre hjørne kan man se et podie med 1. 2. og 3. plads, dette vil give mening for brugeren at dette er highscore. Øverst i højre hjørne er der en ”Møtrik” der er indstillinger og det er et ikon der ofte bliver brugt for at tilgå indstillinger. Nederst i venstre hjørne er der et kamera, det viser at man skal kunne gå ind i kamerafunktionen på telefonen og indstille skærmen. Baggrunden for startskærmen er selve spillet, dette er det for at når man trykker på start, så har man allerede et overblik over spillet.På Figur 6 kan man se playeren/Babyen i gang med et hop, dette er den vigtigste funktion i spillet. Man bruger accelerometeret til at hoppe.

 

Figur 7 ser vi et billede af hvad der sker når man dør i spillet. Spillet stopper og der kommer tekst op der fortæller at spillet er ovre, grundet af man er død. Den fortæller også at man skal trykke for at komme tilbage til startsiden. Dette er ikke meget anderledes fra så mange andre spil, det er ofte sådan man strukturerer sit spil, så dette giver ofte meningen for brugeren.

Figur 8 ser vi et billede af spillet i gang, her kan man i øverste venstre hjørne og øverste højre hjørne, se ens nuværende score til venstre og den ultimative highscore til højre. Man får point for hver obstacle man kommer forbi og dette skal tælles så man ved hvor mange point man har i løbet af spillet. Grunden til man kan se den ultimative highscore til højre er for at man ved hvad man skal ”slå”. Dette skaber et konkurrenceelement som ofte ses i spil, som flappy birds der var en kæmpe succes.

 

Evaluering

Vi testede spillet på vores nærmeste omgangskreds løbende og til sidst i forløbet. Vi testede det første gang da der ikke var tilføjet point og highscore endnu. Der opstod meget forvirring omkring styremetoden af spillet og mange mente at hoppe funktionen ikke passede særlig godt til spillet. Man ønskede at hvis man bare bevægede telefonen lidt, så skulle spilleren hoppe.

Da vi testede spillet til sidst, opdagede vi at point og highscore fungerede rigtig godt, det blev en konkurrence imellem de spillende. ”Hvem har highscoren på 37?!” vi oplevede at folk ønskede at have den højeste score i spillet, men ligeså snart man havde den, så mistede man lidt konkurrenceelementet, altså spillet fungerede bedst hvis man skulle slå hinanden frem for at slå sig selv. Overordnet set synes vores testpersoner at spillet var sjovt og underholdende.

 

Use-case diagram

Vi har lavet et Use-case diagram der viser hvordan brugeren navigerer rundt i spillet. Diagrammet kan ses på Figur 9. Til venstre på figuren ser vi personen tilgå forsiden som giver brugeren 4 valgmuligheder, fra disse kan de hver især tilgå nogen bestemte ting, eller til sidst gå tilbage til forsiden.

Det er smart at benytte sig af sådan et diagram, især i den tidlige designfase. På den måde giver man sig selv et overblik over hvad app’en skal indeholde og man skaber en logisk interaktion i app’en. Alt i diagrammet skal man interagere med ved at klikke på det med fingeren, men i spillet spiller man med bevægelse af telefonen.

 

Objekt diagram

Figur 10 kan man se vores objekt diagram, her er nogle eksempler på nogle af vores classes, samt deres metoder. F.eks. så har objektet player, en jump metode, og en metode der spiller sammen med obstacles objektet, i form af collision detecter. Denne er til for at give jump metoden et formål. Samtidig er der også et sammenspil mellem moving ground og player. Da moving ground bevæger sig som den gør, så behøver vores player ikke bevæge sig.

 

Mechanics

For at finde nogen passende mechanics, var vi nødt til at tænke på hvad der var muligt. Eftersom vi har en del erfaring med mobilspil, så tog vi bare vores egen erfaring og fandt frem til mechanics.

For at skabe det spil vi gerne ville ende ud med, så vi det nødvendigt at der skulle være en karakter som kunne styres til at hoppe.

Vores vigtigste mechanic i spillet er derfor hop, det sætter grundlaget for spillet og det er det som spillet går ud på.

 

Implementation

Måden vi har skabt vores spil på, er ved at finde forskellige YouTube videoer omkring programmering med SpriteKit indeholdende de mechanics vi ønskede skulle inkluderes. Inden vi gik i gang med dette spil, havde vi ingen erfaring med programmeringssproget Swift, tilføjelsen SpriteKit eller programmet xcode. Så for at komme godt i gang med projektet, blev YouTube brugt. YouTube blev brugt på den måde at forskellige tutorials blev fundet frem, og de der var relevante for den ide vi sad med, blev brugt. Eftersom vi ingen erfaring havde med Swift, blev YouTube tutorials fundamentet for vores projekt. Men efter vi fik skabt grundstenene for vores spil, så havde det også givet os erfaring for Swift, og vi kunne herefter se bort fra disse tutorials, og arbejde videre på vores projekt, uden hjælp fra disse tutorials.

Classes

Vores spil er bygget op ved hjælp af classes, inde i disse classes definere vi de metoder som er relevante for lige netop denne class. Vores karakter har en class, vores forhindringer har en class og vores jord har en class. Disse classes spiller sammen på en bestemt måde. Vi har classes med forskellige formål. Vi har f.eks. classes der har formålet at give objekter forskellige egenskaber, dette kunne være vores forhindringer. Vores forhindringer får deres egenskaber fra classen walls, og bliver derefter nemt kaldet fra classen wallGenerator. En anden class vi har, er vores hero class. Alt omkring vores hero kommer fra denne class, udseendet, position og den fysiske egenskaber.

 

Methods

Methods er funktioner som, i vores spil, er forbundet til en vis mechanic. Disse methods bliver brugt til at skabe en vis opførsel i spillet. Derfor er der også mange methods i vores spil, og det ville blive for uoverskueligt at skulle nævne og forklare dem alle sammen. En af vores essentielle metoder er under vores moving ground class.


Vores ground objekt er dobbelt så bred som skærmen, når den  har bevæget sig halvvejs, så vil den resette sin position, og køre denne sekvens igen og igen.

 

Properties

Properties er den simpleste made at håndtere konstanter og variabler på. Ligesom Methods, så bruger vi dem igennem hele spillet på forskellige måder. Lige fra bevægelsen af alle objekter på skærmen, til størrelsen af disse. Det er dog ikke disse properties der får f.eks. bevægelsen til at fungere. Men det er properties der bestemmer hvordan bevægelsen er, hvor hurtig den er. F.eks. vores hoppe metode. Denne metode indeholder properties, som afgør hvordan hoppet kommer til at fungere, hvor hurtigt eller langsomt karakteren hopper. Dette ses overalt i vores spil, også på jorden, som karakteren bevæger sig på. Hastigheden af denne og størrelsen, bliver bestemt, og kan ændres i dennes properties.

 

Resultater

Brainstorm

Efter vi havde lavet vores brainstorm, fandt vi ud af at et spil med disse mechanics ville være sjovt for brugeren. Dette kunne vi blandt andet se ved at der i forvejen er spil magen til vores.

 

Konceptuelle design

Det konceptuelle design gav os en idé af hvordan vi ligesom ville udforme spillet, hvilket tema og hvordan det kunne laves. I det konceptuelle design havde vi dog på daværende tidspunkt ikke særlig stor viden omkring Ios programmering, hvilket har resulteret i at vi har satset på at få lavet mere end hvad vi reelt kunne nå med den givne tid.

 

Endelige prototype

Vi fandt ud af at vores spil krævede en del justeringer. På grund af den tidsmæssige begrænsning havde vi ikke tid til at få testet vores spil i samspil med udviklingen. Der skulle justeres på accelerometeret sådan at spillet føles mere naturligt at spille. Der var mange ting der skulle have foregået i samspil med eventuelle brugere at spillet. Der var også mange ønskede funktioner vi ikke fik nået at implementere.

 

Kode

For at kode igennem dette semester har vi benyttet os af forskellige tutorials der har haft elementer eller de mechanics vi ønskede at implementere.

Udseendet på karakteren valgte vi at prioritere, det var vigtigt at spilleren lignede en baby, ellers ville der ikke være nogen elementer i spillet der refererede til vores babytema. Karakteren er skabt igennem SpriteKit, som er et framework til Xcode. Igennem SpriteKit blev farver, størrelsen af karakteren og positionen af karakterens objekter bestemt. Herunder ses et eksempel på dette.

Her ses det hvordan Både kroppen, og ansigtet af karakteren bliver lavet, både farve og position, og til sidst bliver disse tilføjet til viewet. Dette gøre med mange elementer som spiller ind i karakterens udseende.

toJump

Jump metoden er det noget af det mest essentielle i dette spil, da det er denne mechanic hele spillet er centreret omkring. Spilet er, som sagt, en endless platformer hvor spillerens mål er at hoppe med karakteren, så denne undviger forhindringer, dermed er det vigtigt at denne mechanic eksisterer. Herunder ses koden for vores jump.

Her bliver kreeret tre variabler, som hver indeholder metoder der bliver brugt til at udføre hoppet. Først hvordan karakteren hopper op, herefter et delay og til sidst hvordan den falder ned igen. Her bestemmes det hvor hurtigt hoppet skal være, hvor højt der skal hoppes og hvor lang tid delayet skal være, før karakteren falder mod jorden igen. Til sidst laves jumpSequence, som bestemmer hvilken rækkefølge dette sker i.

Accelerometeret

Accelerometeret blev hurtigt implementeret, heri fik vi 3 forskellige akser som ændrede deres værdi alt efter hvordan man holdte telefonen.

Vi valgte at indstille hoppet ud fra x-aksen sådan at man skal vende telefonen på en bestemt måde hvorved spilleren så hopper. Ved kun at have indstillet det med x-aksen er det ikke så nemt eller ligetil for en spiller at hoppe, dette ville kunne justeres ved at bruge mere tid på at aflæse accelerometeret og dets værdier.

For at kunne få adgang til accelerometeret, skulle frameworket coremotion importeres. Igennem dette framework fik vi adgang til metoder som gjorde det muligt at måle telefonens værdier, på de forskellige akser, og derigennem fastsætte en grænse, som når overskredet, ville aktivere vores jump metode.

Obstacle generator

Sammen med hoppet er vores obstacle generator også et af de vigtigste elementer, der er ingen grund til at hoppe hvis der ikke er en grund til at hoppe. Samtidig ville der uden disse forhindringer ikke være nogen måde at tabe spillet på, og ødelægge hele oplevelsen ved spillet.

Udseendet og opførslen af vores wall, er konstrueret i en class kaldet MWall, som hentes ind her, dernæst fastsættes positionen af objektet walls. For at det ikke blev for forudsigeligt for spilleren, og for at give lidt variation, har vi tilføjet en tilfældigheds faktor, som afgør om en der skal tilføjes et wall objekt, eller ej.

Point og Highscore

Point og Highscore skulle tilføjes for at skabe det konkurrenceprægede element, her skaber man det element, som gør at flere vil have spillet for at slå hinandens rekorder. Samtidig giver det også spilleren lyst til at spille igen og igen, uden point, ville denne lyst forsvinde.



Først lavede vi to labels, et label som skulle vise ens point, og et andet label som skulle vise den nuværende highscore. Disse blev begge to lavet ud fra classen RBRPointsLabel. Der skulle gives point efter hver forhindring man hoppede over, for at det kunne ske, var det nødvendigt at kunne tracke den nærmeste forhindrings position.

For at gøre det, lavede vi et array, og hver gang en forhindring blev tilføjet til spillet, blev denne også tilføjet til arrayet.

Herefter lavede vi en variabel wall, som repræsentere den første wall i vores array, altså den næste som spilleren skal forsøge at hoppe over, og dennes position. Hvis spilleren har formået at hoppe over den første forhindring, fjerner vi den fra arrayet og kalder herefter metoden increment på vores pointlabel. Increment er en metode vi har defineret i vores RBRPointsLabel class:

Hvis man så taber, og man har slået rekorden, så vil highscoren blive ændret til ens nuværende point, det sker på følgende måde.

 

 

Link BitBucket

https://bitbucket.org/Argantork5/runbabyrun/overview

Link Youtube video

https://www.youtube.com/watch?v=Y44fpvI2wdU

 

Konklusion

Vi kan konkludere at vi har skabt et spil, det indeholder ikke alle de elementer som vi ønskede det skulle, men det er muligt at se vores vision i det spil vi har skabt.

Vi har lavet et spil der fungerer og som indeholder nok spilelementer til at være funktionsdygtigt.

Vi har igennem dette projekt fået et større kendskab til swift og xcode, og lært om hvordan man kan kreeret et spil i swift. Samtidig vi har fået et større kendskab til swift især hvordan SpriteKit fungerer.

Perspektivering

Diskussion

Vi har skabt et spil der er hen af den retning som vi ønskede, overordnet set krævede det mere tid og mere viden om swift at skabe vores første vision. Dette kunne man have sat sig mere ind i for at opnå det ønskede resultat.

Med software er det aldrig helt til at vide hvor lang tid tingene tager at lave, derfor ville det være svært for os at have en reel idé om hvor lang tid de forskellige ting ville tage.

Der er nogen problemer i og med det ikke er ligetil for brugeren at få spilleren til at hoppe, der er et lille delay som gør det svært at koordinere hvornår man skal hoppe i forhold til hvor forhindringen er.

Vi fik ikke nået at implementere kamerafunktionen i app’en, vi havde ikke nok tid eller erfaring, så dette blev nedprioriteret til fordel for de mechanics der ville få spillet til at fungere.

Der er ikke noget lyd i spillet endnu, det havde vi ikke tid til. Lyd er et vigtigt element i spil, det er her standarden og følelsen i spillet bliver sat, for mange brugere er lyden ekstremt vigtig.

Vi fik heller ikke tilføjet forskellige sider som vi ønskede at få, vi ville gerne have en highscore side, en indstillinger side og en side til kamerafunktionen

Vi ville gerne have tilføjet flere elementer inden for vores babytema, men på grund af manglende tid, er det ikke der vores fokus har været, dette er dog ærgerligt, da vores vision ikke bliver ført ud sådan som vi havde tiltænkt os.

Udseendet af babyen blev okay, vi kunne nemt have tegnet en baby og animationer til dette, men valgte at gøre det på denne måde. Babyens udseende er vi tilfredse med, da det er i ”lav kvalitet” hvilket passer meget godt til at det netop er en baby. Vi kunne dog med fordel have gjort det på andre måder, der ville have gjort den flottere. Vi ønsker jo at brugeren af spillet skal kunne se med det samme at det er en baby.

 

Videre arbejde

Hvis vi havde mere tid, ville vi gerne tilføje flere elementer til vores babytema, for at skabe vores Run Baby Run spil.

Vi ville justere accelerometeret sådan at man kunne spille spillet uanset hvilket retning man holder telefonen og sådan at det er nemmere for brugeren at hoppe i spillet.

Vi ville tilføje point, for at skabe noget ekstra i spillet, eventuelt nogen point som man ville kunne bruge til at åbne op for boost eller udseende af babyen, for på den måde at personificere sit eget spil.

Vi ville tilføje flere sider, forskellige sider som brugeren ville kunne tilgå, sådan at der er andre funktioner i app’en end bare spillet og samtidig skabe et overblik for brugeren.

Overordnet set ville vi også gerne teste spillet noget mere, indtil videre har vi ikke fået testet det på mange og dem vi har testet på har været folk i ens omgangskreds, dette er ikke et optimalt testgrundlag.

Vi ville tilføje lyd dette ville vi gøre via AudioKit formentlig med tutorials. Vi ville tilføje en lyd til når spilleren hopper og eventuelt en grædende baby når spilleren dør.

Senere hen i processen var planen at der skulle testes vores spil, og derefter udvikle spillet ud fra disse test.

 

[1] SpriteKit: https://developer.apple.com/spritekit/

[2] CoreMotion: https://developer.apple.com/documentation/coremotion

[3] Temple Run: http://temple-run2.com/

[4] T-rex Dino Game: http://apps.thecodepost.org/trex/trex.html

[5] Mechanics: https://en.wikipedia.org/wiki/Game_mechanics

 

Leave a Reply