spacetrackers - linköping universityweber.itn.liu.se/~karlu20/courses/tnm094/reports/...ett exempel...

Linköpings universitet | Insitutionen för teknik och naturvetenskapKandidatarbete |Medieteknik

Vårterminen 2017 | LiU-ITN-TEK-G--17/014--SE

SpaceTrackersEtt sällskapsspel med markörbaserad tracking förmobila enheter

Jacob AnderssonMichaela RabeniusOskar GertJonna JohanssonElon OlssonViktor IgelandMattias Persson

Examinator: Karljohan Lundin Palmerius

Linköpings universitetSE-581 83 Linköping

013–28 10 00, www.liu.se

Sammanfattning

Denna rapport beskriver utvecklingsprocessen för ett virtuellt sällskapsspel för mobila enheter im-plementerat med hjälp utav tracking och nätverkskommunikation. Spelet utvecklades som en del avkursen TNM094 - Medietekniskt kandidatprojekt på Linköpings universitet för att utvidga redan exi-sterande spelkoncept med ny teknik.

Syftet med projektet var att skapa ett virtuellt sällskapsspel där spelarna kan flytta sina mobila enheteröver ett bord för att se olika delar av en virtuell spelvärld. Tanken var att återskapa känslan av ettklassiskt sällskapsspel trots användandet av digitala enheter. Spelet utspelar sig i rymden och måletär att beskydda Jorden från invaderande fiendeskepp. Spelarna kan flytta sina enheter över spelplanenför att lokalisera fiendeskeppen och skjuta ner dem och därigenom samla poäng. Spelet är slut närJorden förstörs.

Under projektets gång har projektgruppen arbetat utefter den agila utvecklingsmetodiken Scrum somfungerar väl för mindre utvecklingsteam. Gruppmedlemmarna delades in i olika roller, såsom Scrum-mästare eller produktägare. Arbetet har utförts i sprintar där särskilda uppgifter som tagits fram utefterkrav och behov skulle avklaras. Verktyg som exempelvis Trello tillämpades för att sätta upp backlog-gar för projektets sprintar och föra dokumentation över projektarbetet.

Spelet har utvecklats i spelmotorn Unity i programspråket C#. Gruppen använde sig av den nätverk-sarkitektur som redan finns i Unity. En enhet agerar som server och sköter spellogiken medan de andraenheterna är klienter som fungerar som spelarens fönster till spelvärlden. Spelet använder Augmen-ted Reality-verktyg som Vuforia för att implementera flyttbara enheter genom att låta framkamerornapå enheterna spåra en markör som är fäst i taket för att avgöra en spelares position i den virtuellaspelvärlden.

Rapporten diskuterar även spelets begränsningar och hur olika faktorer påverkar spelupplevelsen.Spelet ges en automatisk utmaningsfaktor genom att vyn över spelplanen är begränsad. Spelet ärupplösningsoberoende och blir därmed svårare att spela på enheter med en mindre skärm.

Den färdiga produkten är ett trackingbaserat sällskapsspel för Android-enheter där enheterna kanflyttas över en yta och dess position i spelet kontinuerligt uppdateras. De olika enheterna kan kommu-nicera och vet om varandras positioner via en server. Spelarna kan även plocka upp power-ups somtillfälligt hjälper dem under spelets gång.

i

Innehåll

Sammanfattning i

Figurer v

1 Inledning 11.1 Bakgrund . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Syfte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.3 Frågeställning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.4 Avgränsningar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.5 Spelidé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Förstudier och relaterat arbete 42.1 Augmented Reality - AR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.2 Nätverksmodeller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.3 Relaterade arbeten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.3.1 Ladybug - Sällskapsspel baserat på mobilkluster . . . . . . . . . . . . . . . 5

2.3.2 Ballpit - Sällskapsspel för mobila enheter med Augmented Reality . . . . . . 5

3 Utvecklingsprocess 63.1 Scrum: sprintar och poster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3.1.1 Backloggar och Trello . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3.1.2 Kundmöten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3.2 Tidsplan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3.3 Versionshantering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.4 Dokumentationsprinciper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.5 Testningsprinciper och QA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.6 Systemarkitektur och modellering . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

4 Implementation av spelet 124.1 Tekniska verktyg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

4.2 Nätverksarkitektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

ii

INNEHÅLL iii

4.3 Tracking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

4.4 Spellogik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

4.4.1 Fiendeskepp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

4.4.2 Object pooling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

4.4.3 Pathfinding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

4.4.4 Power-ups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

4.4.5 Poängsystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4.5 Implementation av grafik och spelmodeller . . . . . . . . . . . . . . . . . . . . . . 17

4.5.1 Effekter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4.5.2 Modeller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4.5.3 Färger och tema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

5 Resultat 195.1 Startmeny och lobby . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

5.2 Spelet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

6 Analys och diskussion 236.1 Arbetsprocess . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

6.2 Resultat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

6.3 Problem och hinder under arbetets gång . . . . . . . . . . . . . . . . . . . . . . . . 24

6.4 Begränsningar i trackingen och hantering av störningar . . . . . . . . . . . . . . . . 24

6.5 Begränsningar i spelupplevelsen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

6.6 Upplösningsoberoende . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

6.7 Arbetet i ett vidare sammanhang . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

6.7.1 Etiska frågor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

6.7.2 Vad detta projekt kan leda till . . . . . . . . . . . . . . . . . . . . . . . . . 26

7 Slutsatser 277.1 Tracking och störningar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

7.2 Spelupplevelse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

7.3 Skärmstorlekens påverkan på spelet . . . . . . . . . . . . . . . . . . . . . . . . . . 27

Litteraturförteckning 28

A Arbetsfördelning 30A.1 Elon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

A.2 Jacob . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

A.3 Michaela . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

A.4 Jonna . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

INNEHÅLL iv

A.5 Oskar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

A.6 Viktor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

A.7 Mattias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

Figurer

1.1 Illustration som visar hur enheterna kan placeras på spelplanen. . . . . . . . . . . . . . . . 3

3.1 Projektets produktbacklogg. Alla krav formuleras som poster och flyttas till lämplig spaltberoende på status. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3.2 Projektets sprintbacklogg. Uppgifter organiseras efter status. Färgmarkeringarna anger upp-gifter som utförts under enskilda sprintar. . . . . . . . . . . . . . . . . . . . . . . . . . 8

3.3 Första versionen av tidsplanen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.4 Reviderad tidsplan. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.5 Modell över systemets arkitektur. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

4.1 Illustration av hur enheterna kommunicerar i nätverket. . . . . . . . . . . . . . . . . . . . 13

4.2 Illustration av hur trackingen fungerar. . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

4.3 Översikt över spelets olika delar och hur dessa hänger ihop. . . . . . . . . . . . . . . . . 15

5.1 Skärmdump av spelets huvudmeny. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

5.2 Skärmdump på lobbyn. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

5.3 Skärmdump från spelet. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

5.4 Meteoriter och skepp som har genererats i spelet utav servern. . . . . . . . . . . . . . . . 21

5.5 Spelets Game Over-skärm. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

v

Kapitel 1

Inledning

SpaceTrackers är ett virtuellt sällskapsspel som utvecklats i spelmotorn Unity och som spelas medhjälp av ett antal flyttbara enheter, antingen smartphones eller surfplattor. Spelarna kan genom attfysiskt flytta sin enhet förflytta sig i spelvärlden. Mappningen av förflyttningen sker med hjälp avmarkörbaserad tracking. Denna rapport beskriver projektets genomförande, vilka metoder och verktygsom användes, samt diskuterar kring det slutliga resultatet.

1.1 Bakgrund

Spelmarknaden har vuxit sig allt större under de senaste åren, till stor del tack vare den tekniskautvecklingen. Teknik som exempelvis Augmented Reality (AR) och Virtual Reality (VR) har blivitalltmer vanligt och ger flera nya möjligheter vid spelutveckling, som att till exempelvis låta spelarenkunna påverka vad som händer i ett spel med hela sin kropp eller se världen på ett nytt sätt med hjälpav datorgenererade objekt. Dessa nya möjligheter öppnar dörren för utforskning av både gamla ochnya spelformat.

Idag har mobila enheter större möjlighet att stödja olika typer av teknik som inte var möjligt förnågra år sedan, vilket har gjort att flera nya spelkoncept har vuxit fram och tagit världen med storm.Ett exempel är Pokémon Go[1] som med hjälp av AR-teknik fångade människors intresse över helavärlden.

Den nya tekniken ger även möjligheten att expandera redan existerande spelkoncept, till och medta dem till en helt ny plattform. Ett äldre spelformat är sällskapsspel: spel man spelar tillsammansmed vänner i samma rum, exempelvis ett brädspel. Denna aspekt är ovanlig för dator-spel och and-ra digitala spel, där spelarna generellt befinner sig på olika platser även om de spelar tillsammansi multiplayer-spel, vilket skapar en helt annan typ av umgänge gentemot de traditionella sällskaps-spelen. Det kan därför vara utav intresse att kombinera dessa och på så sätt breda ut konceptet hossällskapsspel.

Detta projekt avsåg att utforska möjligheterna att kombinera känslan hos traditionella sällskapsspelmed modern teknik som AR för att utvidga det tidigare formatet till en ny plattform, i detta fallsmartphones och surfplattor. Projektet beställdes av Karljohan Lundin Palmerius i samband med kur-sen TNM094 - Medietekniskt kandidatprojekt under våren 2017 på Linköpings universitet. Vid pro-jektets början fastställdes krav från kunden angående spelets funktionalitet. Målet var att spelet skaha följande aspekter:

• Skapa gemenskap mellan spelare.

• Ha en viss turaspekt.

1

KAPITEL 1. INLEDNING 2

• Ett tydligt mål med vinst.

• En spelare ska kunna påverka de andra spelarna.

1.2 Syfte

Rapportens syfte är att redogöra hur arbetet genomfördes i projektet. Detta genom att bland annatbesvara ett antal frågeställningar. Projektets syfte var att skapa ett virtuellt sällskapsspel där ett flertalmobila enheter fungerar som fönster till samma spelplan och där spelarna ska kunna fysiskt flyttaenheterna för att förflytta sig i den virtuella spelvärlden. Ytterligare ett mål med projektet var attundersöka spelupplevelsen för spelet utefter både dess fysiska och tekniska begränsningar.

1.3 Frågeställning

Rapporten avser att besvara ett antal frågeställningar kopplade till projektarbetet och de problem somuppstod. Frågeställningarna täcker två olika nivåer: det rent tekniska samt användarupplevelse. Delyder som följande:

• Hur kan tracking implementeras för att uppnå målet med flyttbara enheter och kommer de be-gränsningar som finns med detta att påverka spelupplevelsen på negativt sätt? Hur bör systemethantera eventuella störningar?

• Hur påverkas spelupplevelsen av att spelarna är begränsade till att bara kan se små delar avspelplanen åt gången?

• Objekten i spelet bör vara lika stora på olika enheter oberoende av upplösning och skärmstorlek.Hur påverkas spelet av att enheternas skärmar kan ha olika storlekar?

1.4 Avgränsningar

Vid projektets början gjordes några medvetna avgränsningar för att förenkla arbetet. Projektgruppenarbetade mot en tänkt målgrupp. Målgruppen är kompisgäng, runt 25 år, som i vanliga fall kan tänkasig att spela ett vanligt analogt sällskapsspel och som samtidigt är intresserade av teknik.

Gruppen valde att främst utveckla spelet för operativsystemet Android för att undvika extra arbetemed att olika implementationer mellan olika operativsystem och eventuella problem med kompatibi-litet mellan olika versioner.

KAPITEL 1. INLEDNING 3

1.5 Spelidé

Vid projektets början togs flera idéer fram om hur spelet skulle se ut och fungera. Redan i ett tidigtstadie fanns idén att objekt ska kunna hittas genom att flytta enheter över spelplanen. Den slutgilti-ga spelidén bestämdes dock inte förrän senare under projektets gång då systemets möjligheter ochbegränsningar blev mer uppenbara.

Spelet utspelar sig i rymden på en cirkulär spelplan som användaren ser ovanifrån. De mobila en-heterna bör ligga på ett bord för bästa spelupplevelse. Spelet går sedan ut på att två till åtta spelaresamarbetar för att försvara en planet, placerad i mitten av spelplanen, mot utomjordiska fiender. Fien-derna dyker upp i spelplanens ytterkanter och rör sig in mot planeten för att attackera den. På grundav att spelarnas vy över spelplanen är begränsad måste de flytta runt sina enheter för att lokalisera fi-endeskepp. Spelaren förstör fiendeskeppen genom att trycka på dem på skärmen på sin mobila enhet.Det finns tre olika typer av fiender med olika egenskaper; bland annat hur stor skada de gör, hur de rörsig och hur svåra de är att bekämpa, alltså hur många gånger man behöver trycka på dem. Spelet tarslut när planeten förstörts av fienderna och därmed är målet med spelet att försvara planeten så längesom möjligt och för spelarna att hitta och förstöra fiendeskeppen i tid. I Figur 1.1 visas hur enheternakan att vara placerade i förhållande till spelplanen. Som Figur 1.1 också visar, agerar enheten i mittenserver och kommer att hålla spelplanens mittpunkt. Därmed flyttas hela spelplanen om servern flyttas.

Figur 1.1: Illustration som visar hur enheterna kan placeras på spelplanen.

Kapitel 2

Förstudier och relaterat arbete

Detta kapitel tar upp förstudier och tidigare arbeten som är relevanta för arbetet som projektgruppengjorde innan uppstarten utav projektet. Förstudierna gjordes för att utvecklarna i teamet inte var er-farna i teknikerna eller säkra på hur utförandet av projektutvecklingen skulle genomföras. Med merkunskaper om följande ämnen, underlättade det utvecklingen genom projektarbetet. De tidigare arbe-tena gav inspiration till spelets koncept och uppbyggnad eller använder samma eller liknande verktygsom de som sedan kom att användas i projektet.

2.1 Augmented Reality - AR

Augmented Reality (AR), även kallat förstärkt verklighet, är ett område som har utvecklats mycketunder de senaste åren både i forskningssammanhang och inom spelvärlden. Definitionen av AR är attden verkliga världen förstärks med datorgenererade sinnesintryck, exempelvis genom att ett datorren-derat objekt läggs till den verkliga världen med hjälp av en kamera. I en utökning av en studie överframstegen inom AR av Ronald Azuma[2], definierar författarna AR utefter följande aspekter:

• AR kombinerar verkliga och virtuella objekt i en verklig miljö;

• AR körs i realtid och är på något sätt interaktivt;

• AR registrerar objekt i tre dimensioner.

AR har flera olika användningsområden och kan upplevas med hjälp av flera olika verktyg, exempelvisgenom en HWD (Head Worn Display) eller genom en handhållen enhet, exempelvis en smartphoneeller en surfplatta. Normalt sätt när AR implementeras för handhållna skärmar används en inbyggdkamera för att låta skärmen fungera som ett fönster som överlagrar den verkliga världen med denvirtuella. Med hjälp av visuell tracking av en eller flera markörer med en känd storlek kan sedanposition och rotation för de virtuella objekten beräknas i förhållande till kamerans egna position ochrotation. Detta medför att om kameran förflyttas eller vinklas så visas objekten på skärmen enligtden förflyttning som har skett. Denna teknik används som grund för projektet, i och med att de olikaenheternas position och rotation måste följas för att avgöra vilken del av spelplanen som ska synas påden enskilda enhetens skärm.

4

KAPITEL 2. FÖRSTUDIER OCH RELATERAT ARBETE 5

2.2 Nätverksmodeller

2014 lanserade Unity en ny funktionalitet i deras utvecklingsmiljö, vilket gav stöd för enklare imple-mentering av multiplayerspel. Det Unity bland annat integrerade var ett högpresterande transportlagersom är baserat på nätverksprotokollet UDP (User Diagram Protocol) som ska ge stöd åt alla typer avspel, samt ett LLAPI och ett HLAPI (low- respektive high level application programming interface)[3]. För att förstå sig på hur data skickas mellan server och klienter var det relevant att undersökaskillnaden på nätverksprotokoll så som TCP (Transmission Control Protocol) och UDP. Utöver pro-tokollen, hur data skickas och mottags, används så kallade RPC-metoder (Remote Procedure Calls)som anropas från servern och som kallas hos klienterna. RPC-metoder använder UDP som protokollför att beskriva hur data ska skickas [4]. Detta beskrivs vidare i 4.2.

2.3 Relaterade arbeten

Sällskapsspel för mobila enheter är inte ett sedan innan orört område. Med hjälp av nätverkskommu-nikation mellan enheter kan ett spel som kan spelas av flera personer tillsammans skapas och medhjälp av moderna verktyg finns det nästan gränslöst många spelidéer som kan uppfyllas. Detta kapitelredogör för tidigare arbeten som använder samma eller liknande verktyg som projektet samt spel somhar liknande koncept.

2.3.1 Ladybug - Sällskapsspel baserat på mobilkluster

Spelet Ladybug[5] är ett tidigare kandidatprojekt i kursen TNM094 och var en stor inspiration tillprojektets spelidé och uppbyggnad. Ladybug är ett spel som använder ett flertal mobila enheter för attvisa olika delar av samma spelplan. En surfplatta eller mobil ligger i mitten av spelplanen och agerarsom server medan de andra enheterna är klienter som ligger runtom. Spelet går ut på att spelarna skaskjuta nyckelpigor från sin skärm in i munnen på en spindel som roterar runt serverenhetens mitt ochpå så sätt samla poäng. SpaceTrackers använder liknande grundkoncept som Ladybug och har tagitinspiration från dess systemarkitektur.

2.3.2 Ballpit - Sällskapsspel för mobila enheter med Augmented Reality

Ballpit[6] är också ett tidigare kandidatarbete inom kursen TNM094. Ballpit är ett mobilt sällskaps-spel som använder AR-teknik och verktyg för tracking som också användes inom SpaceTrackers. IBallpit har spelarna varsin boll som de kan styra med hjälp av touch-skärmen på sin enhet. Syftet medspelet är att spelarna ska försöka putta ut varandras bollar från en plattform tills endast en återstår.Spelarna kan se plattformen och bollarna genom att enhetens kamera spårar en markör. Grundprinci-pen för denna teknik är densamma som i SpaceTrackers.

Kapitel 3

Utvecklingsprocess

Det finns många metoder och teorier om hur man ska arbeta för att ett projekt ska fortskrida så brasom möjligt. Att använda en viss metodik i ett projektarbete har visat sig vara effektivt med avse-ende på till exempel tid, kvalitet och kostnad. Utvecklingsmetodik har flera steg, från planering tillunderhåll av den färdiga produkten. Shari Lawrence Pfleeger och Joane M. Atlee beskriver i Soft-ware Engineering[7] grunderna inom systemutveckling; systemarkitektur, systemmodeller och agilautvecklingsmetoder och vilken betydelse dessa har under ett projekts livscykel.

För ett mindre projekt finns det klara fördelar med att följa principer inom agil utveckling. Agilametoder lämpar sig för mindre utvecklingsteam och har en fördel i att det gör projektet mer robustmot plötsliga förändringar, exempelvis att kundens krav förändras.

3.1 Scrum: sprintar och poster

Gruppen valde att arbeta utefter principer inom utvecklingsmetodiken Scrum. I The Scrum Guide [8]beskriver Ken Schwaber och Jeff Sutherland Scrum som "ett ramverk för att utveckla och underhållakomplexa produkter". Inom Scrum delas arbetet upp i sprintar, en kort period på max 4 veckor inomvilken ett visst antal uppgifter ska utföras. I början av varje sprint definieras ett antal uppgifter somska genomföras under sprintens gång utefter de krav som är aktuella. Krav och uppgifter sparas ivarsin backlogg. Gruppmedlemmarna delas upp i roller som har olika ansvarsområden att uppfylla,såsom en Scrum-mästare eller en produktägare. Scrum arbetar både inkrementellt och iterativt, vilkettillåter teamet att utveckla spelet stegvis och ändå få ett konkret resultat i slutet av varje sprint.

Gruppen beslöt att låta en sprint vara två veckor lång, då själva tidsramen för projektet i sig var relativtkort. Två veckor gav tillräckligt mycket tid till teamet för att både sätta sig in i problemet och lösauppgiften. Att sprinten inte var för lång förhindrade även att utvecklaren spenderade längre tid påsamma område än som var nödvändigt vilket gjorde arbetet överlag mer effektivt.

Gruppmedlemmarna delades in i följande roller:

• Scrum-mästare, vars uppgift var att styra möten så att dessa höll sig till principer inom Scrum

• Produktägare, vars uppgift var att hantera kraven inom projektet.

• Kodansvariga, vars uppgift var att se till så att kodgranskning utfördes.

• Dokumentationsansvarig, vars uppgift var att se till att allt dokumenterades och sparades.

• Testansvarig, vars uppgift var att göra användartester och därefter ta fram ett resultat uteftertestets respons samt att se till att produkten testas kontinuerligt under projektets gång.

6

KAPITEL 3. UTVECKLINGSPROCESS 7

• Designansvarig, vars uppgift var att ta fram koncept för spelets utseende.

Inför varje sprint hölls ett sprintplaneringsmöte, där gruppen bestämde gemensamt vad som skullegöras under den aktuella sprinten utifrån de krav som var mest aktuella. Under sprintens gång höllsvid behov kortare sprintmöten för att tydliggöra för alla i gruppen hur arbetet låg till samt ge enmöjlighet till att fråga andra gruppmedlemmar om hjälp eller åsikter. I slutet av varje sprint höllsen kortare sprintreflektion, där gruppmedlemmarna tog upp vad som hade gått bra respektive dåligtunder sprintens gång och diskuterade kring hur problem som uppstått borde lösas. Sprintreflektionensammanföll ofta med sprintplaneringen.

3.1.1 Backloggar och Trello

Kravhantering och uppgiftshantering skedde med hjälp av backloggar: en produktbacklogg för atthantera kraven och en sprintbacklogg för att hantera uppgifterna under en sprint. Gruppen valde attanvända Trello för att hantera backloggarna. Trello fungerar som en kanbantavla där uppgifter ochkrav kunde skrivas upp på block som fungerar som virtuella post-it lappar. Anslagstavlorna kan delasin i olika spalter som blocken kan flyttas mellan. Gruppen hade två olika tavlor för krav och uppgifter.

I produktbackloggen, se Figur 3.1, organiserades alla krav, både från kund och från projektet tekniskabegränsningar. Behov, önskningar och krav kodades som så kallade poster[8]. I produktbackloggenställdes tre spalter upp: befintliga poster, aktuella poster och avklarade poster. Inför varje sprint tit-tade produktägaren på vilka krav som var aktuella och utifrån dem togs ett antal uppgifter fram somgruppen kunde arbeta med under sprinten. Uppgifterna sparades i sprintbackloggen.

Figur 3.1: Projektets produktbacklogg. Alla krav formuleras som poster och flyttas till lämplig spalt beroendepå status.

I sprintbackloggen, se Figur 3.2, ställdes fyra spalter upp för att visa olika uppgifters status: att gö-ra, pågående, färdiga och uppskjutna uppgifter. Uppgiftsblocken kunde sedan läggas under lämplig


spalt. När en uppgift påbörjades flyttades den till pågåendespalten. När en uppgift var klar kunde denflyttas till färdig-spalten. Detta tydliggjorde för gruppen hur arbetet låg till och vilka uppgifter somfortfarande behövde göras. Varje enskild sprint färgkodades så att det blev tydligt vilka uppgifter somskulle behandlas, samt vilka uppgifter som sträckte sig över mer än en sprint.

Figur 3.2: Projektets sprintbacklogg. Uppgifter organiseras efter status. Färgmarkeringarna anger uppgiftersom utförts under enskilda sprintar.

3.1.2 Kundmöten

Gruppen hade möten med kunden där krav och idéer diskuterades. Det första mötet hölls i börjanav projektet där kunden gick igenom sina visioner av det färdiga spelet och de krav som det skulleuppnå. Utifrån dessa idéer började gruppen att arbeta och bygga upp spelet. I mitten av projektetsgång möttes kunden och gruppen upp för en andra gång för att säkerhetsställa att spelets utvecklingvar på väg åt rätt håll och inte hade spårat iväg åt ett håll som kunden inte hade samtyckte till.

3.2 Tidsplan

Vid projektets start gjordes en tidsplan, se Figur 3.3. Tidsplanen tvingade gruppen att fundera kringvilka områden som borde behandlas i vilken ordning och visade även när gruppen borde arbeta ochvara klar med enskilda områden, såsom tracking eller spellogik. Gruppen ställde även upp ett antalmilstolpar för projektet som underlättade vid prioritering av uppgifter.

Tidsplanen gjorde det tydligare för gruppen hur projektet låg till och om mer fokus behövde läggas påett visst område. Tidigt upptäcktes det att några gruppmedlemmar kunde börja arbeta med områdensom vid projektets början hade lagts mycket senare i planeringen, detta då det inte fanns tillräckligtmed uppgifter till alla. Därefter har tidsplanen vid behov reviderats ett antal gånger under projektetsgång, se Figur 3.4. Genom att låta tidsplanen vara flexibel kunde gruppen arbeta mer effektivt.


Figur 3.3: Första versionen av tidsplanen.

Figur 3.4: Reviderad tidsplan.

3.3 Versionshantering

Genom att använda ett versionshanteringsverktyg kan utvecklare enkelt återställa äldre versioner av ettprojekt eller utveckla delar av projektet parallellt för att sedan sammanfoga de olika delarna. Detta ärfördelaktig då man kan lätt gå tillbaka om man har gjort fel och en utvecklare behöver inte potentielltstöra en annans arbete.

Inom projektet användes två olika verktyg för versionshantering. Inledningsvis använde gruppen sigutav Git tillsammans med plattformen Github[9] för att synkronisera projektet mellan varandra. Gittillät gruppmedlemmarna att arbeta i olika grenar så gruppen skapade olika arbetsgrenar beroende påområde, exempelvis tracking och nätverk, detta så att man kunde arbeta ostört utan att skapa konfliktermed andras kod. Det visade sig dock snabbt att Git och Github var krångligt att använda då det varsvårt att integrera Git med Unity på ett smidigt sätt.

Gruppen upptäckte senare att Unity har ett eget verktyg för versionshantering som kallas Unity Col-laborate[10]. Gruppen beslöt gemensamt att byta över till Unity Collaborate. En nackdel med UnityCollaborate är att det är ett verktyg som fortfarande är i beta-stadiet och det fanns ingen möjlighet tillatt jobba i olika grenar, vilket ibland kunde resultera i att ändringar som en gruppmedlem hade gjortskrevs över av någon annan. Trots detta fungerade versionshanteringen mycket bättre efter bytet dåCollaborate var enkelt att använda och fungerade smidigare än Git för projektet.


3.4 Dokumentationsprinciper

För att gruppen skulle kunna ha en överblick över projektets förlopp och få förståelse för projektetsolika delar utfördes dokumentation. Alla längre möten, såsom kundmöten och sprintplaneringsmötenprotokollfördes. All dokumentation i form av textdokument och protokoll lagrades på Google Drivedär teamet gemensamt kunde gå in och granska och redigera. Detta gjorde det möjligt för gruppen attgå tillbaka och se vad som sagts tidigare.

Dokumentation gjordes även i form av kommentarer i koden. Detta förenklade förståelsen för degruppmedlemmar som inte hade skrivit koden och underlättade vid kodgranskning. Inledningsvis pla-nerade gruppen att använda verktyget Doxygen[11] för att generera dokumentation av koden i formav html-filer för att strukturera upp de olika skripten och deras funktioner. På grund av detta skrevsalla kommentarer i XML-format. Dock så ansåg gruppen senare att det blev enklare att hålla kod-dokumentationen till endast kommentarerna i skript-filerna då Doxygen genererar ett stort antal filersom snabbt blev utdaterade då ändringar i skripten skedde kontinuerligt. Kommentarerna beskriverförst och främst skriptets uppgifter och därefter skriptets funktioner.

3.5 Testningsprinciper och QA

Inom systemutveckling talar man ofta om Quality Assurance (QA). QA handlar om att säkerställa engod kvalitetsnivå under utvecklingen och minimera de faktorer som kan påverka utvecklingsprocessenoch produkten negativt.

För att försäkra att en god kvalitetsnivå hölls i projektet utförde gruppen regelbundet granskningav varandras kod. Detta gav bättre återkoppling mellan gruppens medlemmar och strukturerade uppkoden så att den blev mer lättläst. Granskningen utfördes inte utav utvecklaren då det kan vara svårtatt upptäcka fel i sin egen kod. Kodansvariga hade huvudansvaret att se till att kodgranskningengenomfördes, antingen av dem själva eller av någon annan gruppmedlem. Granskaren gav feedbackpå koden till programmeraren och kom eventuellt med förslag på bättre sätt koden kunde skrivas.

Inledningsvis planerade gruppen att utföra ett antal användartester. Det visade sig sedan emellertid talång tid innan spelet kom till ett stadium där det var någorlunda spelbart, och därför blev användar-testerna bortprioriterade.


3.6 Systemarkitektur och modellering

Spelet spelas på flera enheter som kommunicerar med varandra. Därför gjordes en modell över hurdenna kommunikation fungerar och vilka delar som bör finnas på vilken enhet. Spelet består av en ser-ver och ett antal klienter (detta beskrivs ytterligare i 4.2), som ska kunna visa olika saker. Varje klientfungerar som en spelare och ska därför kunna flyttas och döda fiender. Servern hanterar huvuddelenav all funktionalitet, som exempelvis att generera och styra fiender. I Figur 3.5 visas hur funktionali-teten är uppdelad på server och klient och vad som kommuniceras mellan dessa. Genom att göra enmodell blev det tydligare för gruppen vilka funktioner som borde finnas på server respektive klient.

Figur 3.5: Modell över systemets arkitektur.

Kapitel 4

Implementation av spelet

Det här kapitlet tar upp implementationen av projektets olika tekniska delar. I följande underrubrikerbeskrivs de verktyg och metoder som använts i projektet och hur projektgruppen har förhållit sig tilldessa för att skapa detta projekt.

4.1 Tekniska verktyg

Gruppen valde att utveckla spelet i spelmotorn Unity [12]. Genom att använda en spelmotor där myc-ket funktionalitet, verktyg och material redan fanns tillgänglig, kunde gruppen fokusera på andrakrävande uppgifter, exempelvis trackingen, istället för att behöva bygga upp allting i spelet från grun-den. Då Unity även är plattformsoberoende lämpade det sig bra för projektet då gruppmedlemmarnaanvände sig av olika operativsystem. Unity valdes framför andra spelmotorer då gruppen ansåg att detverkade enklare att lära sig i jämförelse med exempelvis Unreal Engine. I Unity används skript för attbeskriva beteende på objekt i spelet. Dessa skript skrevs i programmeringsspråket C#.

För att implementera tracking i spelet användes Vuforia [13], ett API för AR-utveckling som finnssom ett bibliotek till Unity. Vuforias bibliotek innehåller både verktyg och kod för att implementeratracking direkt i Unity. Modeller i spelet byggdes i programmet Autodesk Maya och exporteradessedan till Unity. Mer om detta beskrivs i avsnitt 4.5.2.

4.2 Nätverksarkitektur

Gruppen bestämde sig tidigt i projektet för att använda en klient-server-arkitektur istället för en peer-to-peer-arkitektur som i många fall kan vara praktisk men svårimplementerat att använda. En peer-to-peer-arkitektur bygger på att alla enheter skickar uppdateringar till andra enheter direkt istället förtill en dedikerad server. De största anledningarna till detta beslut var att det då hade väckt ytterligarefrågor om vilken enhet som äger spelets data och hur detta ska valideras under spelets gång.

Unity har dessutom en fullständig och väldokumenterad implementation av en klient-server-arkitektursom var smidig att utgå ifrån. Eftersom servern, som är den enhet som placeras i mitten av bordet,även ska visa spelinnehåll agerar denna både klient och server samtidigt. Övriga enheter agerar enbartklienter i nätverket och kan själva inte påverka spelet utan serverns inblandning. Figur 4.1 visar en il-lustration av hur de olika enheterna kommunicerar i nätverket. En peer-to-peer-arkitektur låter iställetalla enheter kommunicera med alla. Programmet blir då allt mer beräkningstungt ju fler enheter somfinns i nätverket.

Den nätverksarkitektur som finns inbyggd i Unity, kallad Unet, bygger på att samma kod körs av

12

KAPITEL 4. IMPLEMENTATION AV SPELET 13

Figur 4.1: Illustration av hur enheterna kommunicerar i nätverket.

klient och server. Det som skiljer sig mellan servrar och klienter är istället hur koden exekveras. Iscenarion där klienterna vill kommunicera med servern anropas en så kallad kommandometod somdå enbart körs på servern. I motsvarande fall då servern vill kommunicera med klienterna anropasen RPC-metod som då enbart körs hos klienterna. Unet har även så kallade SyncVars som möjliggörautomatiskt synkroniserade instansvariabler mellan enheterna.

När någon i nätverket startar en server skapas en lobby där de anslutna enheterna kan se varandrai en lista. Andra enheter kan därefter ansluta till servern genom den IP-adress som presenteras påserverenheten. Innan spelet startas måste samtliga spelare bekräfta att de är redo. Denna lobby gårsedan att återvända till då spelet är slut, för att exempelvis lägga till fler spelare och starta spelet pånytt.

4.3 Tracking

Eftersom trackingen utgör en stor del av projektet lades mycket tid på att försöka hitta den bästametoden för detta. Grundtanken var att använda markörbaserad tracking, vilket blev den metod somtill slut användes i produkten, men även varianter av SLAM testades i ett tidigt skede. SLAM [14]bygger på markörfri tracking som också använder sig av bland annat gyroskop. Detta är en tekniksom ofta används för robotar och som är betydligt mer avancerad att implementera.

En markör kan vara vilken bild som helst, men optimala markörer har skarpa kanter så att kamerorkan analysera bilden och hitta många avläsningspunkter. I detta projekt användes en QR-kod (QuickResponse-kod). För implementationen av trackingen användes biblioteket Vuforia [13] som erbju-der ett flertal möjligheter för att genomföra markörbaserad tracking genom en Augmented Reality-kamera.

Figur 4.2 illustrerar hur trackingen implementerades. Kameran på mobilens framsida används föratt detektera markören. Mobilens position i förhållande till denna används sedan för att förflytta envirtuell kamera i spelet. Detta görs med hjälp av ekvation 4.1, där: cpos är den virtuella kameransposition, xpos är positionen för mobilens kamera, h är sträckan från enheten till den virtuella kameran,xscreen är avståndet från enhetens kamera till mitten av skärmen och xrot är enhetens rotation.


Figur 4.2: Illustration av hur trackingen fungerar.

cpos = xpos + h+ xscreen · xrot (4.1)

Eftersom enhetens kamera inte sitter mitt på skärmen, där spelets virtuella kamera utgår från, skapadesen lista med olika enheters kameraplacering i förhållande till skärmens mittpunkt. Listan användes se-dan till att förflytta den virtuella kameran till rätt position. Den virtuella kameran placerades 0,6 meteröver den virtuella spelplanen, detta för att det är ungefär i den höjden spelarens ögon kommer befin-na sig över enheten. För att sedan beräkna den virtuella kamerans synfält användes informationen omhur högt den virtuella kameran sitter, samt skärmens längd. Med hjälp av ekvation 4.2 beräknades denvirtuella kamerans synfält. lh är enhetens halva skärmlängd och h är även här den virtuella kameranshöjd.

kfov = 2 · arctan( lhh) (4.2)

Eftersom lh är olika för olika enheter leder detta till att den virtuella kameran också får olika stortsynfält på olika enheter. Detta leder i sin tur leder till att enheter med mindre skärm får en mindresynfält på den virtuella kameran och gör att användaren inte kan se lika stor del av spelplanen somen enhet med större skärm. Detta var något som gruppen medvetet valde att göra för att spelplanenskulle bli proportionerlig på alla skärmar.

4.4 Spellogik

I spelet krävs en del spellogik för att bland annat bestämma fiendens beteende och vad som händernär planeten förstörs. I Figur 4.3 ges en överblick över spelets olika delar och funktionalitet, samthur dessa påverkar varandra. Spelet har medvetet en enkel logik för att gruppen dels skulle kunnalägga mer fokus på nätverksdelarna och trackingen som ansågs vara mer krävande och dels för atten avancerad spellogik inte nödvändigtvis behöver betyda ett bättre spel. Gruppen ville dessutom gespelet en låg inlärningskurva utan komplicerade spelmoment.


Figur 4.3: Översikt över spelets olika delar och hur dessa hänger ihop.

4.4.1 Fiendeskepp

En stor del av logiken består av fiendeskepp och deras olika beteendemönster, som kan ses i Figur4.3. I spelet finns det tre olika typer av skepp som alla har samma mål: förstöra planeten som finnspå serverenheten i mitten. När planeten förstörs är spelet slut. Spelarna kan skjuta ned fiendeskep-pen genom att klicka på dem via skärmen på sin enhet. De olika skeppen rör sig alla mot planetenmen rör sig på olika sätt. För att förhindra att spelet blir för enformigt har fiendeskeppen även olikaattackmönster och varierande förmåga att överleva. De olika typerna är:

• Kamikaze:Dessa är smalare skepp som färdas med hög hastighet. De kan inte skjuta, och attackerar därförgenom att åka rakt in i planeten och explodera. Deras fördel är deras hastighet som är högre ände andra skeppens, vilket gör dem svårare för spelarna att hitta i tid. För att balansera detta ärde lättare att förstöra med endast ett klick. Eftersom de inte kan skjuta måste de dessutom ta sighela vägen fram till målet.

• Short Range:Dessa skepp kan skjuta på planeten, men endast från ett kortare avstånd. Detta gör det möjligtför spelarna att hitta dem och skjuta ner dem innan de hinner göra skada. I gengäld är de mertåliga och tar tre klick att besegra.

• Long Range:Precis som Short Range-skeppen kan dessa skepp också skjuta för att attackera, men på be-tydligt längre avstånd. Detta gör att de snabbt kan göra skada från det att de aktiveras i spelet.Dessa skepp är mer tåliga än Kamikaze men inte lika tåliga som Short Range och besegras medtvå klick.

4.4.2 Object pooling

Att kontinuerligt skapa och förstöra objekt, till exempel fiender som skapas och dödas, kan bli inef-fektivt och sakta ned spelet om det hanterar många objekt. För mobila enheter i synnerhet är detta ettproblem, eftersom de ofta har mindre kraftfulla processorer.


Processorns arbete förenklades genom att object pooling implementerades för att skapa instanser avfiender och skott. Object pooling innebär att ett antal objekt fördefinieras och lagras i någon form avresurspool, exempelvis en lista. Objekten är från början avaktiverade och finns därmed inte synligai spelet. När ett objekt, exempelvis ett fiendeskepp, ska existera på spelplanen aktiveras ett av fien-deskeppen som finns i poolen. Skeppet kan sedan agera enligt sitt programmerade beteende tills detavaktiveras. När skeppet sedan ska tas bort från spelplanen, avaktiveras det och återvänder till poolendär det sedan kan återanvändas. Att skapa ett visst antal objekt och sedan återanvända dessa om ochom igen besparar processorn en hel del beräkningar jämfört med om objekten kontinuerligt skapasoch sedan förstörs. En nackdel med object pooling är att det kan ta längre tid att ladda spelet eftersomdet är då alla objekt skapas och även att det kan ta mer minne än nödvändigt.

4.4.3 Pathfinding

För att få en variation i hur fiendeskeppen rör sig och ge dessa möjligheten att undvika hinder, skrevsett pathfinding-skript baserat på A* Pathfinding [15]. Algoritmen fungerar genom att dela upp spel-planen i ett rutnät och sedan ge varje rörelse i rutnätet en kostnad. Den kortaste vägen till målet är densumma av rörelser som ger den minsta totala kostnad.

För att alla skepp inte ska åka rakt fram skapades ett antal olika hinder, som är osynliga i spelet,vilket gör att fiendeskeppen kommer röra sig på olika sätt beroende på varifrån de kommer. För att geytterligare en variation till rörelsen roteras planet med hindren efter varje ny våg av fiender.

4.4.4 Power-ups

Spelarna har möjlighet att plocka upp så kallade power-ups som sporadiskt skapas under speletsgång för att få hjälp att besegra fiendeskeppen. Under spelets gång kommer meteoriter att uppstå påplanen. När spelarna förstör meteoriterna finns det en liten chans att de hittar en power-up. Power-upsen hamnar på spelplanen och alla spelare har möjlighet att använda dem när de vill. Dock börspelarna vara sparsamma och fundera på när de verkligen behöver använda dem, för att inte användadem i onödan utan spara dem till en krissituation. Power-upsen är sällsynta och spelarna måste därförkommunicera med varandra om när en power-up ska användas. Följande power-ups finns med i spelet:

• Stoppa tiden:Denna power-up fryser tiden i några sekunder och fienderna blir stationära och kan inte skjuta.Detta ger spelarna en möjlighet att döda ett stort antal fiender utan att planeten kan ta skada.

• Sakta ned tiden:Denna fungerar på liknande sätt som den föregående fast här saktas tiden bara ned istället föratt stanna helt. Detta ger spelarna mer tid till att döda fienderna innan de kommer för nära ochskadar planeten.

• En stationär artificiell intelligens som skjuter på fiendeskeppen:Denna artificiella intelligens (AI) skjuter en laser som gör skada per sekund på den närmastefienden. Om fienden dör byter den mål till nästa närmaste fiende. AI:n har en livstid på 30sekunder innan den försvinner.

• En bomb som gör skada på alla fiender i scenen:När denna power-up aktiveras skjuter planeten upp en raket i rymden som gör skada på allafiender i scenen.


4.4.5 Poängsystem

Spelet går ut på att samla poäng tillsammans med sina medspelare och överleva så länge som möjligtinnan planeten förstörs. Det finns dels ett poängsystem som delas av alla spelare i samma spelsessionoch ett individuellt poängsystem. De tre olika fiendetyperna ger olika mycket poäng och beroendepå hur snabbt fienderna dödas ges olika mycket poäng. Poängen ges enligt funktion 4.3 där m stårför det maximala antalet poäng som fienden kan ge, n för minsta antalet poäng som fienden kan ge,t motsvarar tiden i sekunder från det att fienden skapades och h är tiden i sekunder som det tar förpoängen nå hälften av sitt maximala värde. Ju längre tid fienden lyckas överleva desto mindre poängerhålls. Genom att förändra variablerna m, n och h är det möjligt att anpassa poängutdelningen förde olika fiendetyperna.

f(t) = (m− n) ∗ 0.9968∗t/h + n (4.3)

Varje spelare har en poängkoefficient, så kallad combo-koefficient, som kontinuerligt minskar mensom ökar då en fiende dödas. I samband med att fienden dödas multipliceras de erhållna poängen medcombo-koefficienten innan de resulterande poängen adderas till spelarens totalpoäng för spelsessio-nen. Spelaren får därmed fler poäng om många fiender dödas tätt inpå varandra, vilket gör att ett merstrategiskt tänk krävs av den som spelar. När spelsessionen är över och spelarna har förlorat summerassamtliga spelares poäng.

4.5 Implementation av grafik och spelmodeller

Nedan följer aspekter angående projektets utseende, färg och form.

4.5.1 Effekter

En del effekter såsom explosioner och eld från raketmotorer skapades med hjälp av Unity:s verktygför partikelsystem. Dessa explosioner använder sig av texturer importerade från Unity Standard Assetseftersom det skulle vara för tidskrävande att göra dessa själv. När ett fiendeskepp dör skapades enexplosion som varar i ett fåtal sekunder och sedan förstörs även denna.

4.5.2 Modeller

De objekt som används i spelet är gjorda i Autodesk Maya [16]. Maya är en programvara för datorgra-fik med verktyg att skapa bland annat modeller och animationer. Inledningsvis var tanken att spelarnaskulle kunna vicka på sin mobil och kunna se olika vinklar av spelplanen, och för att då få en känslaav djup i spelet valdes denna programvara för att skapa tredimensionella modeller. Denna funktio-nalitet blev senare bortprioriterad. Objekten texturerades genom att använda material där egenskapersom exempelvis färg, transparens och reflektionsegenskaper kunde justeras. Detta hade kunnat gjortsi Autodesk 3ds Max [17] , men då medlemmar i gruppen hade mer erfarenhet av att arbeta i Maya såvaldes denna programvaran naturligt till att modellera skeppen.

För att läsa in en texturerad geometri från Maya till Unity exporteras den som en FBX-fil, som dåinnehåller geometrin tillsammans med texturen. Detta gör det möjligt för användare som inte harMaya installerat på sin dator att läsa in modellen till Unity. Trots att det går att exportera 250.000polygoner i en FBX-fil, gjordes modellerna med så få polygoner som möjligt för att underlätta medberäkningarna på grafikkortet.


4.5.3 Färger och tema

För att hålla en gammalmodig känsla i spelet har gruppen använt kantiga former och typsnitt på texter.Främst sätter färgerna stämningen. Färgtemat är inspirerat från Nasas Hubbel-teleskopbilder på TheCrab Nebulasom hittades på tjänsten Colour Lovers [18]. Färgerna har dock modifierats en aning föratt få in en 80-talskänsla i spelet.

Kapitel 5

Resultat

Resultatet av projektet är ett trackingbaserat sällskapsspel anpassat för två till åtta spelare, där varjespelare använder en Android -mobiltelefon eller -surfplatta som ett fönster in i spelvärlden. Speletkräver att enheterna som används måste ha en frontkamera för att läsa av markören i taket. Väl inne ispelet samarbetar spelarna på en virtuell spelplan för att försvara planeten mot fiendeskepp, samtidigtsom de tävlar mot varandra genom att samla poäng.

5.1 Startmeny och lobby

Spelet är uppdelat i en meny, se Figur 5.1, där användaren har möjlighet att antingen skapa ett nyttspel eller gå med i någon annans spel. Väljer användaren att skapa ett nytt spel kommer enheten attagera som server (och är därmed inte en flyttbar spelar) och användaren tas till menyns andra del:lobbyn. När en enhet har satts igång som server kan andra spelare gå med i spelet via serverns IP-adress, vilket också tar dem till lobbyn. Andra enheter kommer automatiskt att hitta serverns adressvia det lokala nätverket, vilket innebär att spelarna inte behöver skriva in adressen manuellt. Väl ilobbyn, Figur 5.2, är det möjligt för andra spelare att delta i spelet genom att klicka på Join-knappenoch när alla är redo startar spelet, se Figur 5.3.

Figur 5.1: Skärmdump av spelets huvudmeny.

19

KAPITEL 5. RESULTAT 20

Figur 5.2: Skärmdump på lobbyn.

Figur 5.3: Skärmdump från spelet.


5.2 Spelet

När spelet startas börjar enheternas framkameror att spåra markören i taket och spelarna kan direktröra sig runt spelplanen, förutsatt att kameran har en klar vy av markören. Om kameran täcks ellerhindras från att se markören slutar enheten att tracka och den virtuella spelkameran står still tillsenheten igen kan se markören. Detta uppfyller kravet med flyttbara enheter.

Servern kommer direkt att börja generera och kontrollera fiender och andra delar av spellogiken, seFigur 5.4. Spelarna kan se alla objekt som befinner sig på spelplanen och kan klicka på objekt såsomskepp och meteoriter för att förstöra dem. Meteoriter genereras slumpmässigt över hela spelplanenoch det finns en liten chans att en power-up genereras med dem, vilket uppfyller kravet om att speletska ha en viss tur-aspekt.

Figur 5.4: Meteoriter och skepp som har genererats i spelet utav servern.

Fiendeskeppen genereras på kanten av en cirkel lika stor som spelplanen, detta för att ge spelarna mertid att hitta dem innan de når Jorden. Skeppen genereras i vågor och alla skepp i den aktuella vågen


måste förstöras innan nästa våg kan börja. Med varje våg ökar antalet skepp som genereras, vilketleder till att svårighetsnivån gradvis ökar. Alla skepp förutom Kamikaze måste dessutom ta sig runtde för spelarna osynliga hindren som beskrevs i 4.4.3, vilket ger upphov till varierade rörelsemönster.Skeppen attackerar genom att skjuta och ramma rakt in i Jorden, beroende på skeppets typ (sombeskrivet i 4.4.1), och kommer att fortsätta attackera tills de förstörs. Alla skepp tar olika antal klickför att förstöras och när ett skepp förstörs skapas en liten explosion.

Spelarna kan samla poäng genom att förstöra fiendeskepp. Varje spelare har varsin combo-mätare somfylls när spelaren förstör ett skepp och annars går nedåt. Combo-mätaren ger en bonus till spelarenspoäng om denne lyckas döda många fiender inom kort tid. Poängsamlingen ger ett visst tävlingsele-ment mellan spelarna även om de måste samarbeta för att överleva så länge som möjligt, och spelarnakan tävla om vem som fått mest poäng. När planetens hälsa når 0 exploderar den och en röd skärmsamt en lista över spelarnas high-score och deras slutgiltiga sammanlagda poäng visas på alla enheter,se Figur 5.5.

Figur 5.5: Spelets Game Over-skärm.

Kapitel 6

Analys och diskussion

Detta kapitel går djupare in på diskussion kring bland annat resultatet, utvecklingsmöjligheter medprojektet, begränsningar projektet har haft under arbetsprocessen samt andra aspekter värda att dis-kutera.

6.1 Arbetsprocess

Gruppen har arbetat agilt utefter Scrum i den omfattning som har känts lämplig. Eftersom ingeni gruppen tidigare hade arbetat med Unity eller någon av de andra verktyg som användes, blevinlärnings- och efterforskningsperioden längre än önskat. Gruppens brist på tidigare erfarenhet vi-sade sig flera gånger vara en stor nackdel som gjorde att vissa moment tog längre tid än vad sombehövdes.

I början av projektet undersökte och testade gruppmedlemmarna olika delar av spelet var för sig. Ettproblem som uppstod till följd av detta var att det fanns många delar som fungerade var för sig mensom sedan var svårare att sammanfoga. Det tog alltså lång tid att ta fram något som faktiskt kundeses som en produkt. På grund av att tiden var väldigt begränsad i detta projekt blev en del av mötenoch återblickar inte fullt så prioriterade som kodning och efterforskning. Ett annat problem var attprojektgruppen vid vissa tillfällen kändes för stor, därför var det ibland svårt att hitta relevanta ochkonkreta uppgifter till alla.

Trots att gruppen inte arbetat lika strikt enligt Scrum som det från början var tänkt, så har metodikenändå haft vissa fördelar. Genom att rita upp en detaljerad projektplan i inledningen av projektet meden tillhörande tidsplan klargjordes vad som behövde göras på ett effektivt sätt. Tidsplanen gjorde detlättare för gruppen att säkerställa att arbetet låg i fas och göra omprioriteringar av arbetsuppgifter omdetta krävdes. Trello gjorde det enkelt att dokumentera vad för uppgifter det är som ska göras, vad somgörs just nu och vad som är färdigställt. Med Trello har utvecklarna även kunnat meddela varandraoch skriva in kommentarer kring arbetsflödet och sprint-möten klargjorde dessutom vad övriga grupp-medlemmar arbetade med samt hur långt alla hade kommit med sina individuella arbetsuppgifter.

6.2 Resultat

Resultatet liknar den bild och vision gruppen hade vid projektets början. Alla komponenter finns där,men spelet fungerar inte felfritt. På grund av tidsbrist har inte alla delar integrerats så att de fungerartill 100%. Det finns också mindre detaljer som inte fungerar exakt som det ska, som att fiendeskeppkan ibland fastna på en vägg när de egentligen borde åka runt den.

23

KAPITEL 6. ANALYS OCH DISKUSSION 24

Spelet hade kunnat sett annorlunda ut om gruppen hade kunnat genomföra de användartester somfrån början var planerade. Idén bollades mellan gruppmedlemmarna och kund men testades inte fören annan publik, vilket var en stor nackdel för projektet. Den huvudsakliga anledningen till detta varatt en fungerande prototyp kom sent i utvecklingsprocessen och att väsentliga delar som exempelvistrackingen fortfarande fungerade dåligt. Dock så anser sig gruppen nöjda med det som ändå haråstadkommits.

Spelet har en tilltalande design och en funktionalitet som efterfrågades av kunden samtidigt som spelethar en låg inlärningskurva och är underhållande. Det diskuterades i början av projektet om huruvidatrackingen skulle vara för underutvecklad i allmänhet eller för avancerad för att uppnå det resultatsom förväntades. Detta visade sig dock vara felaktigt då det finns användarvänliga verktyg som ärtillräckligt bra för att skapa det spel gruppen hade vision för och det projektet resulterade i.

6.3 Problem och hinder under arbetets gång

Gruppen har stött på ett antal problem under projektets gång. Många av dessa problem kan spåras till-baka till gruppens oerfarenhet med Unity. Arbetet tog i många fall längre tid än vad gruppen planerat,då man var tvungen att ofta göra flera efterforskningar.

Ett större problem var nätverksdelen som byggdes med hjälp utav Unitys egna verktyg. EftersomUnet är ett så kallat hög-nivå-API så var det svårt att följa hur kommunikationen verkligen fungerade.Det var också svårt att veta hur alla delar borde skrivas i kod för att fungera på det sättet som detfrån början var tänkt. Det är många funktioner som beror på varandra så det kunde vara svårt att göraändringar. Det var problematiskt med funktionalitet som endast skulle fungera på antingen server ellerklient; servern kunde exempelvis visa saker som endast skulle finnas på klienten.

Andra problem som uppstod hade att göra med trackingen. Ibland kunde delar av trackingen somfungerat i tidigare versioner plötsligt sluta fungera till synes utan orsak. Det är möjligt att andra änd-ringar som gjorts i spelet kan ha haft en påverkan, vilket inte är optimalt. Det har också uppstått fleraproblem med rotationen: istället för att kameran roteras kring mittpunkten på skärmen när spelarensnurrar på sin enhet, roterar den runt en helt annan axel.

Ett stort problem under utvecklingsprocessen har varit det dåliga stödet för versionshantering i Uni-ty. Git, som gruppen använde under inledningen av projektet, var praktiskt för källkodsfilerna menfungerade dåligt vid ändringar i scener och liknande saker som gjordes direkt i Unity:s gränssnitt.Unity Collaborate, som gruppen så småningom gick över till, hanterade scenerna bättre än Git menhade dåligt stöd för konflikter vilket ofta ledde till att kod skrevs över av olika personer. Detta leddei sin tur att funktionalitet som redan implementerats kunde försvinna eller fungera dåligt. Under helautvecklingsprocessen var Unity Collaborate fortfarande i Beta-version, vilket troligtvis har varit enbidragande orsak till de problem som uppstod.

6.4 Begränsningar i trackingen och hantering av störningar

Trackingen begränsas av ett antal felkällor. Beroende på hur långt bort markören sätts blir påverkanfrån dessa felkällor större. Detta eftersom att kameran beräknar avstånd mellan flera punkter på mar-kören. När markören placeras längre bort blir dessa avstånd mindre och mindre, vilket kan leda tillfel såsom ojämn uppdatering av position.

En felkälla är att när en enhet vinklas uppfattas detta också som en förflyttning eftersom att trackingenavläses från en annan vinkel. Bara en liten vinkling av enheten kan leda till en stor förflyttning. Denenda lösningen som finns till problemet i nuläget är att låta enheterna ligga på ett bord så att de inte kan


vinklas av misstag. Detta är en begränsning då spelet skulle vara mer dynamiskt om spelarna kundehålla sina enheter i luften under spelets gång, men eftersom det är svårt att hålla enheten stadigt blirdet svårare att förflytta sig. En nackdel med denna lösning är att det finns risk att enheterna repas närde dras över bordet.

En annan felkälla är att trackingen kan utsättas för en del störningar. Störningarna består främst avatt kameran täcks, vilket leder till att enheten inte längre kan hitta markören och enheten slutar därförförflyttas. Detta är i synnerhet ett problem om man spelar på ett större bord där man behöver sträc-ka sig över för att se. En annan störning kan komma från tracker-markören själv. Den markör somgruppen använts sig av består av en bild som limmats fast på en bit kartong. Bilden i sig är utskrivenpå flera papper som har pusslats ihop, vilket leder till en viss ojämnhet i bilden. Då markören inte ärhelt rak så kan det uppstår jitter i trackingen, vilket leder till att även om enheten är helt stilla så kanspelaren ändå röra sig lite hackigt.

6.5 Begränsningar i spelupplevelsen

Faktumet att spelarna bara har tillgång till en liten del av spelplanen åt gången är en del av spelidén.Det ger spelet automatiskt en viss svårighetsgrad och utmaningsfaktor som förhöjer spelupplevelsen.Trots att spelet i sig inte är särskilt avancerat ger begränsningen av spelarens sikt att en mer kompli-cerad spellogik inte behövs, vilket förenklade arbetet för utvecklingsteamet.

6.6 Upplösningsoberoende

Att objekt ser lika stora ut oberoende på skärmstorlek samt upplösning löstes som nämnt i 4.3 genomatt förändra den virtuella kamerans synfält beroende på skärmens storlek. Fördelarna detta medförär att två enheter med olika skärmstorlekar som ligger bredvid varandra upplevs också ligga bredvidvarandra i spelet. Det kommer därmed vara omöjligt för två spelare att döda samma fiende eller seplaneten utan att placera sin enhet ovanför den enhet som för tillfället visar den delen av spelplanen.De negativa aspekterna av denna lösning är att enheter med små skärmar kommer att vara svårareatt spela med, just för att man ser en mindre del och inte har möjlighet att se lika många fiender påsamma gång.

6.7 Arbetet i ett vidare sammanhang

Som nämnts tidigare i avsnitt 6.2 finns det delar av spelet som inte fungerar exakt som det var tänkt.Med nyare teknik skulle det i framtiden kunna var möjligt att implementera spelet på ett sätt sominte behöver spåra en markör i taket, vilket skulle ta bort många av de felkällor som påverkar speletnegativt.

6.7.1 Etiska frågor

Det finns få paralleller som kan dras mellan spelets påverkan på etiska frågor och samhällsproblem.Det finns en minimal risk att produkten skulle kunna gynna kriminella organisationer och gruppen taringen politiskt ståndpunkt med hjälp av den.

För att motarbeta att en individs arbetsbelastning skulle bli för hög har gruppen alltid varit öppen föratt avlasta och hjälpa varandra under projektets utveckling. Gruppen tar även avstånd till all form av


diskriminering.

6.7.2 Vad detta projekt kan leda till

Likt spelet Pokémon Go:s stora genombrott [1], med sin unika nisch med sitt lättillgängliga spel iAR, är förhoppningen att även detta spel kan påverka framtidens spelutvecklare att tänka i nya banor,både genom helt nya idéer och genom påbyggnad av äldre spelkoncept.

Kapitel 7

Slutsatser

Idag är marknaden för mobila spel väldigt stor, men det är få spel som kan klassas som sällskapsspelpå det traditionella sättet: vänner som umgås och spelar tillsammans på samma plats. Genom att skapaett spel där alla spelare delar samma spelplan uppnår man ett annat typ av umgänge jämfört med omman spelar tillsammans online, samtidigt som att man med hjälp av teknik skapar fler möjligheter förhur spelet ska se ut som inte finns i traditionella sällskapsspel. I dagens läge där tekniken ständigtutvecklas hastigt är det bra att kunna bygga en brygga mellan det nya och det gamla för att kunna tadel av det bästa från två världar.

7.1 Tracking och störningar

Hur kan tracking implementeras för att uppnå målet med flyttbara enheter och kommer debegränsningar som finns med detta att påverka spelupplevelsen på negativt sätt? Hur bör sy-stemet hantera eventuella störningar?Tracking kan implementeras för att hitta en enhets position med hjälp av enheternas frontkameror somläser av en markör i taket. Denna information kan sedan användas för att flytta kameran i spelvärlden.Dock påverkas systemet mycket av störningar, såsom att kameran täcks och små vinklingar resulterari stora förflyttningar. I nuläget har systemet inget effektivt sätt att hantera dessa störningar.

7.2 Spelupplevelse

Hur påverkas spelupplevelsen av att spelarna är begränsade till att bara kan se små delar avspelplanen åt gången?Att spelarna begränsas från att se hela spelplanen är integrerat med spelidén. Begränsningen i vy geren automatisk utmaningsfaktor som gör att spelet kan vara enkelt och ändå vara en bra spelupplevelse.

7.3 Skärmstorlekens påverkan på spelet

Objekten i spelet bör vara lika stora på olika enheter oberoende av upplösning och skärmstor-lek. Hur påverkas spelet av att enheternas skärmar kan ha olika storlekar?Spelet har samma upplösning, oavsett skärmstorlek. Detta påverkar spelet genom att det blir svårareatt spela på en mindre skärm, då en mindre del av spelplanen syns.

27

Litteraturförteckning

[1] Mimi Billing Pokémon Go slår rekord - igen , Digital, 2016-07-26, hämtad: 2017-05-10http://digital.di.se/artikel/pokemon-go-slar-rekord–igengit

[2] Ronald Azuma, Yohan Baillot, Reinhold Behringer m.f, Recent Advances in Augmented Reality,HRL Laboratories, (2001)

[3] Erik Juhl, Announcing UNET – New Unity Multiplayer Technology, Unity Technologies, 2014-05-12, hämtad: 2017-05-10https://blogs.unity3d.com/2014/05/12/announcing-unet-new-unity-multiplayer-technology/

[4] Dave-Carlile , Do RPC’s use UDP or TCP?, Unity Community, 2013-02-16, hämtad: 2017-05-10http://answers.unity3d.com/questions/400441/do-rpcs-use-udp-or-tcp.html

[5] Joakim Deborg, Marcus Nygren, Mikael Zackrisson, Sebastian Piwell och Teodor Vik, Säll-skapsspel baserat på mobilkluster, Linköpings universitet, 2014-06-19, hämtad: 2017-06-11http://webstaff.itn.liu.se/ karlu20/courses/TNM094/reports/TNM094-2014-06_Sällskapsspel.pdf

[6] Sofie Khullar, Andreas Kihlström, Agnes Heppich, Jinwoo Yu, Martin Tran, David Johanssonoch Mikael Lindhe, Ballpit - Sällskapsspel för mobila enheter med Augmented Reality,Linköpings universitet, Juni 2016, hämtad: 2017-06-11

[7] Shari Lawrence Pfleeger och Joanne M. Atlee, Software Engineering, Fourth Edition, Interna-tional Edition, Pearson 2010

[8] Ken Schwaber och Jeff Sutherland, Scrumguiden, Den definitiva guiden till Scrum: Spelets reg-ler, Scrum.org och ScrumInc 2014, hämtad: 2017-02-05http://www.scrumguides.org/docs/scrumguide/v1/Scrum-Guide-SE.pdf

[9] The world’s leading software development platform: GitHub, GitHub (2008), hämtad: 2017-05-24https://github.com/

[10] Unity Collaborate, Unity Technologies (2004), hämtad: 2017-05-24https://unity3d.com/

[11] Doxygen - Generate documentation from source code, Dimitri Van Heesch, (2016), hämtad:2017-05-24http://www.stack.nl/ dimitri/doxygen/

[12] Unity, Unity Technologies (2004), hämtad: 2017-05-04https://unity3d.com/

28

LITTERATURFÖRTECKNING 29

[13] Vuforia - The World’s Most Widely Deployed AR Platform, PTC Inc (1985), hämtad: 2017-05-04https://www.vuforia.com/

[14] Cyrill Stachniss, Udo Frese och Giorgio Grisetti, openSLAM - Give your algorithm to the com-munity, OpenSLAM (2007), hämtad: 2017-05-10http://openslam.org/

[15] Amit Patel, Introduction to A* (2009), hämtad: 2017-05-07http://theory.stanford.edu/ amitp/GameProgramming/AStarComparison.html

[16] Maya, Autodesk Inc. (2017), hämtad: 2017-05-25https://www.autodesk.com/products/maya/overview

[17] 3ds Max, Autodesk Inc. (2017), hämtad: 2017-05-25https://www.autodesk.com/products/3ds-max/overview

[18] Evad ,Crab Nebula, colourlovers, 2008-04-30, hämtad: 2017-05-10http://www.colourlovers.com/palette/358927/Crab_Nebula

[19] Unity Technologies, Unity Network Lobby, Unity, 2017-04-03, hämtad : 2017-05-09https://www.assetstore.unity3d.com/en/content/41836

Bilaga A

Arbetsfördelning

A.1 Elon

Som utvecklare i detta projekt har jag bidragit med förstudier om hur man i utvecklingsmiljön Unityskapar en nätverksanslutning mellan flera användare och hur det ska gå till att integrera det i ettspel. Denna förstudie gjordes ihop med Jacob, men på varsitt håll för att förhoppningsvis upptäckaoch förstå sig på olika delar för att kunna lära varandra eller diskutera om något man har upptäckteller förstått sig på. Tillsammans skapade vi sedan en lobby med unity network lobby [19]. Utöverlobbyscenen har jag ansvar för hur det fungerar då spelarna förlorar. En game over-panel kommer dåatt visas, med totalpoäng, samt spelarnas individuella poäng. I lobbyn stod jag för färgval. Jag harockså stått för kodgranskning och salbokning genom projektet.

A.2 Jacob

Har tillsammans med Elon utvecklat nätverk- och lobbydelen som använts i projektet. Har även ut-vecklat verktyg för att automatiskt hitta andra spelsessioner inom samma nätverk. Utöver detta harjag även utvecklat spelets poäng- och combosystem, inklusive de animationer som dessa har i spelet.Andra saker jag har arbetat med är fiendernas livscykel. Min roll som projektledare och designansva-rig har varit att ha huvudansvaret för att arrangera möten, se till att gruppens gemensamma mål nåsoch att spelet blir visuellt tilltalande.

A.3 Michaela

Som utvecklare har jag arbetat och undersökt flera områden inom spellogik. Jag har skrivit kod förgenerera objekt och för object pooling. Jag har har även skrivit kod för att skeppen ska kunna skjutaskott, olika rörelsemönster och annat beteende. Inom Scrum har jag haft rollen som produktansvarighar därmed varit den som listat krav utefter prioritet så att gruppen kunde bestämma vilka uppgiftersom var aktuella för sprinten. Jag har även haft rollen som sekreterare och fört anteckningar understörre möten.

30

BILAGA A. ARBETSFÖRDELNING 31

A.4 Jonna

Började med att undersöka och jobba med hur fiendeskeppen skulle genereras och röra sig i spelettillsammans med Michaela, men på varsina håll. Gick därefter över till att designa och modellerarymdskeppen. Jag har haft rollen som kund- och kontaktansvarig.

A.5 Oskar

Har till en början jobbat med att förstå nätverkskommunikationen och få upp ett fungerande nätverkför att använda vid test. Detta nätverk används dock inte i den färdiga produkten. När testnätverketfungerade jobbade jag med att sätta ihop det med trackingen för att få en förståelse om hur detta gjor-des. Efter hand har jag i kommunikation med de som har gjort scripten satt ihop allt till ett fungerandeprojekt. Är också ansvarig för funktionen som hanterar den virtuella kamerans synfält, den slutgiltigatrackingen tillsammans med Viktor, hur server-enheten hanterar sin tracking samt spelets startupljud.I projektet har jag även rollen som kodgranskare tillsammans med Elon.

A.6 Viktor

Som utvecklare började jag med att undersöka flera olika metoder för tracking, för att där efter börjaimplementera trackingen. Den slutgiltiga trackingen implementerades tillsammans med Oskar. Ut-över trackingen implementerade jag rymdskeppens pathfinding (A* Pathfinding), den databas sominnehåller de olika enheternas mått och specifikationer, samt fixade rymdskeppens kollision. Jag haräven varit delaktig i att sätta ihop de olika delarna till ett fungerande projekt, men även att få de olikaspelfunktionerna att fungera över nätverket. Inom Scrum var min roll Scrummästare.

A.7 Mattias

Började med att arbeta med förundersökningen till trackingen samt med att sätta upp Vuforia. Sedanövergick jag till att arbeta med att få en fungerande touch input. När den var färdigställd blev mitthuvudansvar att göra power-ups samt att göra effekter så som explosioner. Min roll inom Scrum varTestansvarig, vilket innebär att jag ansvarade för att systemet testades och problem löstes innan dessablev för stora.

spacetrackers - linköping universityweber.itn.liu.se/~karlu20/courses/tnm094/reports/...ett exempel...

Documents