Realtidsmultiplayerspel på IoT-backend

Linköpings universitet | Institutionen för datavetenskap

Examensarbete på grundnivå, 15hp | Datateknik

2018 | LIU-IDA/LITH-EX-G--18/008--SE

Realtidsmultiplayerspel på

IoT-backend

Real-time Multiplayer Game on IoT-backend

Joel Almqvist

Björn Detterfelt

Tim Håkansson

David Kjellström

Axel Löjdquist

Joel Oskarsson

Lieth Wahid

Alexander Wilkens

Handledare : Carl Brage Examinator : Kristian Sandahl

Upphovsrätt

Detta dokument hålls tillgängligt på Internet – eller dess framtida ersättare – under 25 år från publiceringsdatum under förutsättning att inga extraordinära omständigheter uppstår. Tillgång till dokumentet innebär tillstånd för var och en att läsa, ladda ner, skriva ut enstaka kopior för enskilt bruk och att använda det oförändrat för ickekommersiell forskning och för undervisning. Överföring av upphovsrätten vid en senare tidpunkt kan inte upphäva detta tillstånd. All annan användning av dokumentet kräver upphovsmannens medgivande. För att garantera äktheten, säkerheten och tillgängligheten finns lösningar av teknisk och admi-nistrativ art. Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman i den omfattning som god sed kräver vid användning av dokumentet på ovan beskrivna sätt samt skydd mot att dokumentet ändras eller presenteras i sådan form eller i sådant sam-manhang som är kränkande för upphovsmannens litterära eller konstnärliga anseende eller egenart. För ytterligare information om Linköping University Electronic Press se förlagets hemsida http://www.ep.liu.se/.

Copyright

The publishers will keep this document online on the Internet – or its possible replacement – for a period of 25 years starting from the date of publication barring exceptional circumstan-ces. The online availability of the document implies permanent permission for anyone to read, to download, or to print out single copies for his/hers own use and to use it unchang-ed for non-commercial research and unchang-educational purpose. Subsequent transfers of copyright cannot revoke this permission. All other uses of the document are conditional upon the con-sent of the copyright owner. The publisher has taken technical and administrative measures to assure authenticity, security and accessibility. According to intellectual property law the author has the right to be mentioned when his/her work is accessed as described above and to be protected against infringement. For additional information about the Linköping Uni-versity Electronic Press and its procedures for publication and for assurance of document integrity, please refer to its www home page: http://www.ep.liu.se/.

c Joel Almqvist Björn Detterfelt Tim Håkansson David Kjellström Axel Löjdquist Joel Oskarsson Lieth Wahid Alexander Wilkens

Sammanfattning

I denna rapport presenteras ett projekt för företaget Cybercom utfört av åtta studenter från Linköpings universitet. Projektet har gått ut på att utveckla ett realtidsspel som använder sig av ett existerande system för kommunikation mellan enheter. Spelet har utvecklats som en webbapplikation och innehåller flera olika spellägen. I det genomförda projektet har en modifierad, nedskalad variant av arbetsmetodiken Scrum följts och denna presenteras i rapporten. Utvecklingen har därmed varit iterativ och agil. Resultatet av projektet är en väl fungerande produkt som direkt skapar värde för kunden, men även tillåter smidig vidareutveckling.

Abstract

This report presents a project carried out for the company Cybercom by eight students from Linköping University. The aim of the project has been to develop a real-time mul-tiplayer game using an existing system for communication between different devices. The game has been developed as a web app that contains multiple game modes. The specific development methodology that has been used throughout the project is presented in this report. This methodology has been iterative, agile and followed a simplified version of the Scrum framework. The end result of the project is a well functioning product that directly creates value for the customer, but also allows for further development.

Författarnas tack

Vi vill tacka Cybercom för möjligheten att utföra ett intressant och givande projekt. Projekt-medlemmarna har fått ett mycket varmt bemötande och är tacksamma för den intressanta insikt vi har fått i organisationen. De praktiska möjligheterna i form av arbetsplatser upp-skattas även mycket och har på många sätt underlättat arbetet.

Ett speciellt tack vill vi rikta till Cybercoms IoT-grupp i Linköping som har varit mycket seriösa och hjälpsamma som kunder för projektet. Projektgruppen är mycket tacksam för alla de tips och idéer som vi har fått. Att få ta del av erfarenheter inom de tekniker som använts i projektet har många gånger sparat oss stora mängder tid och frustration.

Tack även till vår handledare Carl Brage för stöd genom hela projektet. Den respons vi har fått på dokument och presentationer har givit oss många nyttiga tips som vi kan ta med oss även utanför detta projekt. Kvaliteten på denna rapport har uppnåtts mycket tack vare all konstruktiv återkoppling från vår handledare.

Innehåll

2.2 Gruppens tidigare erfarenheter . . . 4

3 Teori 5 3.1 React . . . 5 3.2 Yarn . . . 5 3.3 Prettier . . . 5 3.4 Eslint . . . 6 3.5 PIXI . . . 6 3.6 Scrum . . . 6 3.7 Trello . . . 7 3.8 Git . . . 7 3.9 Github . . . 7 3.10 Travis . . . 8 3.11 Slack . . . 8 3.12 Latex . . . 8 4 Metod 9 4.1 Projektorganisation . . . 9 4.2 Utvecklingsmetod . . . 10 4.3 Dokumentation . . . 14

4.4 Metod för att fånga erfarenheter . . . 15

5 Resultat 16 5.1 Systembeskrivning . . . 16

5.5 Enkätresultat och kontinuerliga demonstrationer . . . 27

6 Diskussion 28 6.1 Resultat . . . 28

6.2 Metod . . . 30

6.3 Samhälleliga och etiska aspekter . . . 31

7 Slutsatser 33 7.1 Frågeställningar . . . 33

7.2 Måluppfyllelse . . . 34

7.3 Viktiga insikter . . . 34

8 Översikt över individuella delar 35 A Produktens miljöpåverkan av Joel Almqvist 38 A.1 Introduktion . . . 38 A.2 Teori . . . 39 A.3 Metod . . . 40 A.4 Resultat . . . 41 A.5 Diskussion . . . 43 A.6 Slutsatser . . . 45

B Agil Versionshantering av Björn Detterfelt 47 B.1 Introduktion . . . 47 B.2 Teori . . . 48 B.3 Metod . . . 49 B.4 Resultat . . . 49 B.5 Diskussion . . . 50 B.6 Slutsatser . . . 51

C Deepstream serialisering och rundturstid av Tim Håkansson 52 C.1 Introduktion . . . 52 C.2 Bakgrund . . . 53 C.3 Teori . . . 53 C.4 Metod . . . 55 C.5 Resultat . . . 56 C.6 Diskussion . . . 57 C.7 Slutsatser . . . 58

D Jest som testverktyg för spelutveckling av David Kjellström 60 D.1 Introduktion . . . 60 D.2 Bakgrund . . . 61 D.3 Teori . . . 61 D.4 Metod . . . 64 D.5 Resultat . . . 65 D.6 Diskussion . . . 66 D.7 Slutsatser . . . 67

E En jämförelse av React och Angular av Axel Löjdquist 69 E.1 Introduktion . . . 69

E.2 Teori . . . 70

E.3 Metod . . . 74

E.4 Resultat . . . 75

E.6 Slutsatser . . . 79

F Beroenden till färdiga paket i open-source Javascript-projekt av Joel Oskarsson 80 F.1 Introduktion . . . 80 F.2 Bakgrund . . . 81 F.3 Teori . . . 82 F.4 Metod . . . 85 F.5 Resultat . . . 87 F.6 Diskussion . . . 90 F.7 Slutsatser . . . 92

G Jämförelse mellan Scrum och Vattenfall utvecklingsmetodik i Studentprojekt av Lieth Wahid 93 G.1 Introduktion . . . 93 G.2 Teori . . . 94 G.3 Metod . . . 96 G.4 Resultat . . . 97 G.5 Diskussion . . . 99 G.6 Slutsatser . . . 100

H Undersökning av typning i Javascript av Alexander Wilkens 102 H.1 Introduktion . . . 102 H.2 Bakgrund . . . 103 H.3 Teori . . . 103 H.4 Metod . . . 104 H.5 Resultat . . . 105 H.6 Diskussion . . . 106 H.7 Slutsatser . . . 109 Litteratur 110 I Appendix 118 I.1 Testrapport . . . 118

I.2 Hexdumpar för RPC och events . . . 119

I.3 Algoritm för analys av projektberoenden . . . 122

Figurer

4.1 En skärmbild av gruppens Scrum-bräde för sprint 3 . . . 11

5.1 Överblick av systemanatomin för spelet . . . 17

5.2 Överblick av systemanatomin . . . 17

5.3 Överblick av systemets moduler . . . 18

5.4 Överblick av hur implementation av mittenkomponent kan ge ett ineffektivt da-taflöde . . . 21

5.5 Exempel hur visningen av instanser ser ut på kontrollen . . . 23

5.6 Skärm för att anpassa sin spelare innan anslutning till en spelinstans . . . 24

5.7 Skärmdump av kontrollen i spelläget Knockoff . . . 24

5.8 Skärmdump av UI:t i spelläget Dodgebot . . . 25

5.9 Skärmdump av UI:t i spelläget Knockoff . . . 26

5.10 Resultat från enkäten testpersonerna var tillfrågade att fylla i . . . 27

A.1 Statistik ifrån naturvårdsverket gällande utsläpp av växthusgaser . . . 42

C.1 JSON formatering . . . 54

C.2 Responstiden i jämförelse med antal objekt som skickas. . . 57

D.1 Ett test för att ta en snapshot på startmenyn i projektet . . . 63

D.2 Snapshot som skapats av testet i D.1 . . . 63

F.1 Beroenden i package.json för version 1.4.1 av paketet assert . . . 83

F.2 Exempel på grafmodeller över beroenden . . . 84

F.3 Databasen som har använts under undersökningen . . . 86

F.4 Histogram över projekt med maximalt 50 direkta beroenden . . . 88

F.5 Histogram över projekt med maximalt 1800 indirekta beroenden . . . 88

F.6 Histogram över projektens beroendedjup . . . 89

G.1 Vattenfallsmodellen . . . 95

G.2 De typiska stegen som följs i Scrum . . . 95

G.3 Resultat från frågeformuläret . . . 98

H.1 Kod som orsakat problem . . . 106

I.1 Exempel på manuellt test utfört . . . 118

I.2 Hexdump av event data för ett objekt . . . 119

I.3 Hexdump av event data för två objekt . . . 119

I.4 Hexdump av event data för tre objekt . . . 119

I.5 Hexdump av event data för fyra objekt . . . 119

I.6 Hexdump av event data för fem objekt . . . 120

I.7 Hexdump av RPC data för ett objekt . . . 120

I.9 Hexdump av RPC data för tre objekt . . . 121

I.10 Hexdump av RPC data för fyra objekt . . . 121

I.11 Hexdump av RPC data för fem objekt . . . 121

I.12 Resultat från frågeformuläret . . . 124

I.13 Resultat från frågeformuläret . . . 125

Tabeller

5.1 Medelvärden, median och standardavvikelse för resultaten av enkäten . . . 27 A.1 Antal operationer teamet gjort på Google drive . . . 43 A.2 Antal git push operationer som gruppen gjort mot huvudgrenen på Githubs

hem-sida . . . 43 F.1 Medelvärden, standardavvikelser och maxvärden för undersökta värden . . . 88

Definitioner

Cybercom Kortare variant av Cybercom Group, företaget produkten ut-vecklas åt.

Instans En spelsession som startas från UI-applikationen och spelare kan gå med i för att spela spelet.

IoT, Internet of Things Ett begrepp som beskriver den tekniska och samhälleliga ut-veckling då fler och fler saker blir uppkopplade mot inter-net.

Kontroll-applikation Applikation som körs på en mobil eller surfplatta och skickar styrningsdata till UI-applikationen.

Kursen Den kurs som detta projekt utförs inom, det vill säga kursen ”Kandidatprojekt i programvaruutveckling” med kurskod TDDD96 på Linköpings universitet.

npm, Node Package Manager En pakethanterare för Javascripts ekosystem.

npm-paket Ett paket med Javascript-kod som finns tillgängligt i npm. open-source Projekt som tillåter vem som helst att ladda ner, modifiera

och tillföra förslag av ändringar till en existerande kodbas. Projektet Processen att framställa en produkt åt Cybercom Group.

Denna produkt är ett spel som skickar sensordata från kontroll-applikationen till UI-applikationen via Cybercoms IoT-backend.

Sensordata Datan från en accelerometer som beskriver hur mobilen ac-celererar gentemot marken. Denna kan användas med avse-ende på gravitationskraften för att beskriva vilken riktning mobilen befinner sig i.

Spelläge En utökning av grundspelet som definierar speciella regler och spelmekanik.

Teamet, gruppen Det team av åtta studenter som tillsammans har utfört pro-jektet.

UI-applikation Applikationen som kör spelet och visar spelpla-nen.

1

Introduktion

Detta projekt utfördes som en del av kursen ”Kandidatprojekt i Programvaruutveckling” på Linköpings universitet våren 2018. Det genomfördes av en grupp studenter som läser till civilingenjör i datateknik samt civilingenjör i mjukvaruteknik. Denna introduktion är uppde-lad i fyra delar som tillsammans framför vad målet med rapporten är.

1.1

Motivering

Trenden IoT har blivit mer populär den senaste tiden [1], och fler aktörer har möjligheten att koppla upp sin verksamhet till internet. Utrustning kan kopplas till IoT av många olika an-ledningar, till exempel kan fabriker använda sig av IoT för att få en bättre överblick av slitaget på sina maskiner. För privatpersonen kan en mängd olika produkter kopplas till IoT, såsom ett kylskåp där innehållet kan ses genom en smarttelefon. En central del i IoT är hur slus-sandet av data sker, för det måste hamna på rätt ställe samtidigt som det ska gå snabbt. Hur snabbt detta system behöver vara för ett bra resultat är dock inte genomskinligt för en person som inte är insatt i området. Därför gavs gruppen uppdraget att skapa ett interaktivt system för att demonstrera responsiviteten hos Cybercoms IoT-backend. Detta system är ett realtids-spel där realtids-spelarens handlingar omgående påverkar dennes pjäs på realtids-spelplanen, samtidigt som datan går igenom Cybercoms IoT-backend.

1.2

Frågeställning

1. Hur kan ett realtidsspel som använder sig av Cybercoms backend implementeras så att man skapar värde för kunden?

2. Vilka erfarenheter kan dokumenteras från programvaruprojektet som kan vara intres-santa för framtida projekt?

3. Vilket stöd kan man få genom att skapa och följa upp en systemanatomi?

4. Hur kan kontinuerliga användardemonstrationer användas i utvecklingsfasen för att förbättra ett spels kvalitet?

1.3. Syfte

1.3

Syfte

Syftet med denna rapport är att dokumentera erfarenheter som teamet har fått genom proces-sen av produktens utveckling. Dessutom har rapporten som syfte att utreda hur utvecklingen av ett realtidsmultiplayerspel skapar värde för kunden, och eventuellt möter deras behov av att testa hastigheten samt skalbarheten hos kundens backend.

Projektets syfte är att skapa ett realtidsmultiplayerspel för att demonstrera hastigheten, re-sponsiviteten och skalbarheten på Cybercom IoT-backend vilket görs på deras begäran.

1.4

Avgränsning

Projektet utförs som en del av kursen Kandidatprojekt i Programvaruutveckling. Detta inne-bär att projektet har en begränsad tidsbudget på 400 timmar per gruppmedlem, det vill säga 3200 timmar totalt. Kursen innefattar obligatoriska seminarier, föreläsningar, workshops och dokumentskrivning som också är inräknade i tidsbudgeten. Projektet utför en testning av Cybercoms backend och därför är projektet direkt beroende av backendens funktionalitet.

2

Bakgrund

Projektet som har utförts har varit en del i kursen ”Kandidatprojekt i programvaruutveck-ling” som ges för studenter vid programmen civilingenjör i datateknik och civilingenjör i mjukvaruteknik vid Linköpings universitet [2]. Projektet har utförts på uppdrag av företaget Cybercom. Detta kapitel kommer ge en kort beskrivning av Cybercom samt ta upp gruppens erfarenheter från föregående studier.

2.1

Kundens syfte

Cybercom är ett nordiskt IT-konsultbolag som arbetar inom hela kedjan av uppkopplade lösningar. Företaget har ca 1300 anställda som arbetar mot både lokala och globala mark-nader [3]. Projektet ”Realtidsmultiplayerspel på IoT-backend” har drivits mot Cybercoms kontor i Linköping.

Ett av Cybercoms arbetsområden är Internet of Things. De arbetar med bland annat råd-givning, etablering och drift av system med IoT-lösningar [4]. I Linköping finns ett team som arbetar med en egenutvecklad IoT-backend. Detta är ett system som tillåter sammankoppling mellan uppkopplade enheter, server-tjänster och externa tjänster från andra leverantörer. Cybercoms motivation till projektet är att skapa ett verktyg för att demonstrera denna IoT-lösning. Med just ett spel i realtid vill man visa på effektivitet och responsitivitet i sin IoT-lösning. Spelet ska kunna användas för att demonstrera systemets realtidskapacitet för kunder. När Cybercom befinner sig på mässor vill man även kunna låta besökare vid sin monter testa spelet för att ge en mer minnesvärd upplevelse av företaget. Med detta vill man locka både potentiella kunder och nya anställda.

2.2. Gruppens tidigare erfarenheter

2.2

Gruppens tidigare erfarenheter

Samtliga gruppmedlemmar har erfarenhet från kursen ”Programutvecklingsmetodik teori” som ger en god inblick i storskalig programvaruutveckling i projektform. Från denna kurs har gruppmedlemmarna fått med sig kunskap om kravhantering, arbetsprocesser, design, testning och mjukvarukvalitet [5]. Dessa kunskaper har under projektet legat som grund för vidareutbildning inom både generella och rollspecifika områden.

Studenter i projektgruppen som läser programmet civilingenjör i datateknik har praktisk er-farenhet från projektkursen ”Konstruktion med mikrodatorer, projektkurs” [6]. Kursen har givit medlemmarna mer praktiska erfarenheter gällande planering och strukturering av pro-jekt samt arbete med dokumentation i större propro-jekt. Propro-jektet som utförs i ”Konstruktion med mikrodatorer, projektkurs” följer projektmodellen Lips [7], som ej är framtagen specifikt för mjukvaruutveckling. Fokuset i projektet från denna kurs är en kombination av hård- och mjukvara och följer, till skillnad från det projekt denna rapport berör, inte en iterativ arbets-process.

Studenter i projektgruppen som läser programmet civilingenjör i mjukvaruteknik har istället erfarenheter av mjukvaruprojekt från kursen ”Artificiell intelligens - projekt” [8]. Från denna kurs har det erfarits kunskaper om planering och rapportskrivning. Projektet i kursen utför-des i större grupper bestående av sex personer och följde en arbetsmetodik liknande vatten-fallsmetoden. Målet med projektet var att undersöka och applicera tekniker inom området av artificiell intelligens.

Inom de tekniska områden och tekniker som projektet berör har gruppen ingen direkt er-farenhet från tidigare kurser i utbildningen. Däremot har samtliga medlemmar en god pro-grammeringsvana som snabbt låtit dem ta till sig nödvändiga kunskaper för projektet. Vissa gruppmedlemmar har även erfarenhet av webbprogrammering genom projekt utanför ut-bildningen.

Från tidigare projekt har gruppens medlemmar tagit med sig positiva och konstruktiva erfa-renheter som tillämpats under det genomförda projektet. Att arbeta i mindre grupper på sam-ma plats var något som flera lyfte som en bra arbetsmetod, eftersom detta ansågs ge mindre missförstånd inom gruppen. För att samordna gruppens arbete hade flera gruppmedlemmar positiva erfarenheter med gemensamma scheman, vilket togs med in i detta projekt.

Projektgruppen har också erfarenheter från problematiska aspekter av tidigare projekt och har därför arbetat för att undvika dessa. Från projekt utan iterativ utveckling tyckte projekt-medlemmarna att många problem och därmed mycket extraarbete uppkom i slutskedet av utvecklingen. Detta ansågs kunna lösas genom att fokusera på att hålla utvecklingen iterativ och inkrementell. En annan viktig erfarenhet var att inte skriva all dokumentation som ett sista steg av utvecklingsprocessen. Istället har dokumentation producerats tillsammans med koden kontinuerligt genom projektet. Från tidigare grupparbeten fanns också idéer om hur gruppdynamik och kommunikation kan förbättras. En viktig aspekt som togs upp var att lyf-ta samarbetsproblem och irrilyf-tationsmoment tidigt och ordentligt diskutera igenom dessa för att kunna lösa dem.

3

Teori

I detta kapitel beskrivs grundläggande teoretiska begrepp och ramverk som följdes under projektets gång. Här beskrivs även essentiella programmeringsverktyg samt utvecklingsme-toden Scrum.

3.1

React

Ramverket React användes för att utveckla UI-applikationen samt kontroll-applikationen. Ramverket bidrar med färdig funktionalitet för att underlätta utvecklingen av hemsidor med Javascript. Detta genom att dela upp projektet i olika komponenter som hanterar logik och utseende för olika delar av hemsidan. Komponenterna kan ses som block av en hemsida som modulärt kan bytas ut mot andra komponenter. [9]

3.2

Yarn

Yarn är den pakethanterare gruppen har valt att använda. Den använder sig av samma paket som finns tillängliga för npm och skillnaden mellan dessa två är marginell. Yarn gör det enklare att lägga till och ta bort paket till ett projekt. [10]

3.3

Prettier

Prettier är ett verktyg för att formatera kod på ett standardiserat och lättläsligt sätt. Prettier går igenom koden och lägger till eller tar bort blanksteg och nya rader enligt förutbestämda regler. Syntaktiskt blir koden samma före och efter att Prettier körts, men läsbarheten har förändrats. Prettier tar även bort stilpreferenser som olika kodskribenter har då den alltid formaterar koden enligt samma regler. [11]

3.4. Eslint

3.4

Eslint

Eslint är ett program som definierar stilregler för hur Javascript-kod ska skrivas. Dessa stil-regler handlar om hur kod ska formateras och att följa bra programmeringspraxis. Eslint söker igenom koden efter rader som bryter mot de satta reglerna och påpekar alla fall där detta sker. Oftast integreras Eslint direkt in i utvecklingsmiljön för att ge varningar när ko-den skrivs. De regler Eslint efterföljer är bra praxis för kodning i Javascript och de går att ändra på efter behov. [12]

3.5

PIXI

PIXI är ett kraftfullt renderingsbibliotek för Javascript. Det erbjuder funktioner som att rende-ra geometriska former och bilder samt bidrende-rar med en uppdateringsloop för att rita ut objekt vid bestämda interval. PIXI är väldigt populärt och används av många stora företag såsom Google, Ubisoft och Spotify. [13]

3.6

Scrum

Scrum är en populär agil utvecklingsmetodik inom mjukvaruutveckling. Metoden är anpas-sad för en mindre grupp på 5-9 medlemmar. Scrum använder ett iterativt, inkrementellt till-vägagångssätt som är relevant för detta projekt då det tillåter ändringar att ske när det be-hövs [14]. I Scrum delas arbetet in i mindre iterationer, där varje iteration kallas för en sprint. En sprint kan vara 1-4 veckor lång. Varje sprint planeras vid dess början och då bestäms mål som ska vara färdiga vid sprintens slut. Efter en sprint utvärderas hur väl arbetet gick under föregående sprint samt vad som bör göras annorlunda till nästa sprint. Scrum har många inslag som är typiska för just Scrum. De som tas upp i denna rapport är följande:

• Scrum-bräde: Ett bräde med alla uppgifter som ska göras under en sprint, varje team-medlem kan sedan ta en egen uppgift och flytta den till rätt kategori i Trello beroende på hur det går i arbetet med den. Vanliga kategorier är: ”att göra”, ”pågående” och ”färdigt”.

• Produkt-backlog: En prioriterad lista av kundens önskemål för funktionalitet och egen-skaper hos slutprodukten.

• Sprint-backlog: En lista med nedbrutna uppgifter från produkt-backlogen som teamet åtar sig att leverera under en sprint.

• Sprintplanering: Under en sprintplanering går teamet igenom produkt-backlogen för att planera vad som ska göras under nästkommande sprint.

• Burndown chart: En graf som visar det kvarstående arbetet. Grafen hjälper teamet att ta reda på om de ligger bra eller dåligt till för att leverera de planerade uppgifterna. • Sprintutvärdering: I slutet av en sprint utvärderar teamet vad som har gått bra och/eller

3.7. Trello

3.7

Trello

Trello är en hemsida för att skapa och fördela uppgifter bland flera personer [15]. Det kan liknas vid en anslagstavla där lappar med uppgifter kan klistras på. Anslagstavlan i sig är uppdelad i kategorier som användarna själva kan skapa och modifiera. När Trello används för projekt kan dessa kategorier ha namn som ”att göra”, ”pågående” och ”färdigt”. Lappar fästs sedan vid den första kategorien ”att göra” och flyttas sedan till de andra när det anses passande. Varje lapp har sedan möjlighet att innehålla extra information, bland annat: vem som arbetar med den, en beskrivning av lappen samt en tidsuppskattning. Alla fält på en lapp bortsett från dess namn är frivilliga, och därav kan en Trello-lapp innehålla väldigt mycket, eller väldigt lite, information.

3.8

Git

Git är ett open-source decentraliserat versionshanteringsprogram som huvudsakligen an-vänds för kod [16]. Arbetsprocessen för Git börjar vanligtvis med ett centralt arkiv som varje utvecklare sedan klonar lokalt. Sedan skrivs förändringar in i detta lokala arkiv som sedan slås ihop med det centrala. Om en annan utvecklare försöker lägga till sina förändringar ef-ter en annan gjort ändringar uppstår en konflikt. Vid en konflikt nekas sammanslagningen tills utvecklaren tagit in förändringarna i det centrala arkivet till sitt eget lokala arkiv. Där får utvecklaren avgöra vilka rader som ska vara med i arkivet och först efter detta är gjort kallas konflikten hanterad. Först när konflikten är hanterad går det att slå ihop det lokala ar-kivet med det centrala. Många steg i denna arbetsprocess har specifika namn och de defineras nedan:

• Gren: En gren är en alternativ version av ett arkiv där förändringar kan göras utan att påverka ursprunget. En gren har en tydlig punkt när den bröts ifrån ursprungsgrenen. En gren kan finnas både lokalt och i det centrala arkivet och kan skapas av många anledningar. En vanlig anledning för att skapa en gren är för utveckla funktionalitet och sedan slå ihop grenen med ursprunget när funktionaliteten är färdig.

• Master-gren: Den första grenen som skapas i ett projekt kallas för master-grenen, van-ligtvis anses denna gren vara den officiella versionen av arkivet.

• Pull request: När en gren ska slås ihop med master-grenen görs detta genom att utveck-laren lägger en begäran för detta. Denna begäran måste granskas av en annan teamme-dlem innan sammanslagningen kan göras för att se till att master-grenen är stabil. En sådan begäran kallas för en pull-request.

• Push: När en utvecklare synkroniserar sina lokala ändringar mot ett externt arkiv, van-ligtvis mot det centrala arkivet.

3.9

Github

Github är en hemsida som integrerar Git och tillåter användare att lagra sin kod gratis, förut-satt att den är offentlig. Github erbjuder även en visualisering för många av Gits funktiona-liteter såsom en grafisk vy över hur koden förändrats över tid eller skillnaderna mellan två versioner. Github erbjuder även verktyg för att strukturera ett projekt såsom möjligheten att enkelt bjuda in medlemmar och ändra vilka rättigheter de ska ha. Dessa rättigheter kan vara allt mellan att inte ha tillgång till att utföra förändringar i vissa grenar, till att få ändra all kod i alla grenar. Github möjliggör också för integration med Travis på sin plattform. En vik-tig funktion är att tillhandahålla ett Git-repo på en server för att minimera risken av förlorat arbete vid eventuella datakorruptioner. [17]

3.10. Travis

3.10

Travis

En testningstjänst som erbjuder automatisering för projekt som använder Github. Travis är gratis för projekt som är open-source. Tjänsten används i kontinuerlig integration för att ex-ekvera tester på alla grenar innan de kan sammanfogas in i huvudgrenen. [18]

3.11

Slack

Slack är ett kommunikationsverktyg som ofta används professionellt inom IT och mjukvaru-utveckling. Funktionsmässigt är det ett chattprogram för datorer och mobila enheter. Slack tillåter utvecklingsteamen att ha olika kanaler som passar deras behov vilket hjälper till att organisera meddelanden. [19]

3.12

Latex

Latex är ett gratis typsättningssystem för att framställa dokument i pdf-format. Latex är en utbyggnad av Tex och fungerar genom att kompilera tex-filer till först aux-filer och sedan till pdf-filer. Till skillnad från textredigeringsprogram såsom Word ser inte användaren direkt hur det slutgiltiga dokumentet kommer att se ut. Istället skriver användaren dokumentet som kod för att senare kompilera ner denna till ett färdigt dokument i pdf-format. Latex är därmed ett väldigt kraftigt verktyg och används mycket i vetenskapliga rapporter och akademiska sammanhang [20]. Latex är i sig inte en textredigerare utan för att skriva dokument i Latex kan en specifik latexredigerare eller en vanlig textredigerare användas.

4

Metod

Det här kapitlet beskriver hur projektet har utförts samt de metoder och verktyg som använts för de olika områden projektet omfattade.

4.1

Projektorganisation

Teamet bestod av åtta teammedlemmar. Den utförda kursen inkluderade några förbestäm-da roller som skulle tilldelas till teammedlemmarna. Rollerna delades upp efter en intern valprocess vid projektets start. Rollerna är väldefinierade och dess ansvarsområden beskrivs nedan.

Teamledare – Alexander Wilkens

Teamledaren såg till att samtliga processer som utfördes under projektets gång följdes. Denna person representerade också teamet utåt och hade kontakt med handledaren. Om det behöv-des hade teamledaren sista ordet.

Kvalitetssamordnare – Joel Almqvist

Kvalitetssamordnaren ansvarade för arbetsprocesser som skulle hålla kvaliteten av projektet på en hög nivå. Samordnaren gjorde en budget av vad kvalitet fick kosta, samtidigt som han ansvarade för kvalitetsplanen.

Dokumentansvarig – Tim Håkansson

Dokumentansvarig ansvarade för samtliga dokument som teamet skulle producera. Denne var även ansvarig för gruppens dokumentmallar.

Arkitekt – Joel Oskarsson

Arkitekten ansvarade för arkitekturen av den tekniska delen av projektet. Denne ansvarade även för övergripande teknikval och hade det sista ordet på tekniska beslut.

4.2. Utvecklingsmetod

Utvecklingsledare – Lieth Wahid

Utvecklingsledaren ansvarade för den mer detaljerade designen av den tekniska produkten, ledde utvecklingsarbetet och såg till att resten av teamet hade något att arbeta med.

Analysansvarig – Axel Löjdquist

Analysansvarig ansvarade för majoriteten av kundkontakt och jobbade ständigt med att ta reda på kundens verkliga behov. Huvudansvaret för kravspecifikationen låg på denna roll. Testledare – David Kjellström

Testledaren beslutade systemets status genom att arbeta tillsammans med kvalitetssamord-naren för att testa att systemet uppnådde kraven i kravspecifikationen. Testledaren skrev även testplan och testrapport.

Konfigurationsansvarig – Björn Detterfelt

Konfigurationsansvarig ansvarade för generell versionshantering i projektet. Rollen arbetade mycket med utvecklingsledaren och dokumentansvarig för att bestämma vilka arbetspro-dukter som skulle ingå i en utgåva.

4.2

Utvecklingsmetod

Det här avsnittet beskriver utvecklingsmetodiken projektgruppen har följt. Detta innefattar hur olika metoder och verktyg har använts för att uppnå ett resultat.

4.2.1

Projektfaser

Projektet delades in i fyra olika faser som fokuserade på olika områden. Dessa presenteras nedan.

Förstudier

Första fasen under projektet bestod av att göra förstudier inför projektet. Detta inkluderar skrivandet av diverse dokument som beskrivs under avsnitt 4.3. Dessutom gjordes individu-ella studier om Javascript och olika bibliotek för att underlätta arbetet till utvecklingsfasen. I slutet av förstudierna gavs även en workshop av Cybercom om deras backend.

Utveckling

Under denna fas utvecklades större delar av produkten. Själva utvecklingen utfördes mesta-dels på Cybercoms kontor för att teamet lättare skulle kunna ställa frågor om funderingar som uppkom. En annan fördel var att teamet hade tillgång till en gemensam arbetsplats. Kvalitetssäkring

Under denna fas finslipades diverse funktioner för att ge användaren en bättre upplevelse när de använder produkten. Detta inkluderade buggfixar och verifiering av projektets krav-specifikation.

Efterstudier

4.2. Utvecklingsmetod

4.2.2

Scrum

Projektgruppen bestämde tidigt att utveckla med det agila ramverket Scrum med modifika-tioner. Grunderna för Scrum finns beskrivna i 3.6. Delarna från ramverket som valdes till projektet var sprintutvärdering, sprint-backlog, produkt-backlog, Scrum-bräde och sprintplanering. Resterande delar från ramverket valdes bort då projektgruppen tyckte koncepten kändes onödiga för projektet. Vid början av varje sprint samlades projektgruppen för att organisera en sprint-backlog från produkt-backlogen. Produkt-backlogen uppdaterades med aktiviteter kontinuerligt av alla medlemmar när en aktivitet upptäcktes. Projektet bestod av tre olika kodbaser. Varje aktivitet hade en eller flera tillhörande etiketter som beskrev vilka kodbaser aktiviteten berörde. Detta gjorde att ett gemensamt Scrum-bräde kunde användas för samt-liga kodbaser. Vid slutet av varje sprint utvärderades sprinten i form av ett kortare möte där varje projektmedlem kunde uttrycka sina åsikter kring utvecklingsprocessen.

Verktyget Trello användes för att organisera och representera ett Scrum-bräde under pro-jektets gång. På detta bräde fanns kolumnerna ”aktiviteter”, ”att göra”, ”implementeras”, ”väntar” och ”klar”. I kolumnen ”aktiviteter” hamnade alla aktiviteter som behövde utföras för att få en färdig produkt. Aktiviteter kunde läggas till i denna kolumn under en pågående sprint. Kolumnen ”att göra” fylldes på med aktiviteter som förväntades bli klara under en pågående sprint. Varje aktivitet tilldelades en prioritet, en tidsestimering och en beskrivning. Dessa attribut sattes under sprintplaneringen och hjälpte gruppen att belasta varje sprint med en rimlig mängd aktiviteter. I ”implementeras” hamnade alla aktiviteter som en eller flera projektmedlemmar arbetade med. I ”väntar” hamnade alla aktiviteter som påbörjats men stoppats på grund av andra prioriteringar. I ”klar” hamnade alla aktiviteter som blivit avklarade. Denna kolumn användes som en logg över vad som hade gjorts under en sprint och som underlag för sprintutvärderingar. En bild på en av gruppens Scrum-bräden kan ses i figur 4.1.

4.2. Utvecklingsmetod

4.2.3

Versionshantering

Git användes för att versionshantera koden. Git-repot lagrades på Github för att alla lätt skulle kunna ladda ner och ladda upp filer till ett centralt repo. Dessutom kan Github hantera diverse tester så att endast kod som går igenom våra tester kan laddas upp på master-grenen. Utöver det så fungerade master-grenen som en form av intern utgåva av produkten. Det vill säga att produkten skulle vara körbar och fungera som väntat i denna gren. För att ga-rantera detta laddades aldrig kod upp direkt till grenen utan det krävdes en pull request som godkändes av en annan projektmedlem. För att en pull request skulle bli godkänd läste granskaren igenom koden och testade relevanta områden för att garantera att det fungerade som det skulle.

4.2.4

Testning

Under förstudiefasen undersökte testledaren vilka verktyg som kunde användas för projektet samt hur hela testningsprocessen skulle gå till. Projektgruppen beslutade att verktyget Travis skulle användas för automatiska tester, men att även manuella tester skulle utföras. De au-tomatiska testerna användes främst för enhetstest medan de manuella testerna användes för mer komplicerade integrationstester.

De manuella testerna baserades på krav specificerade i kravspecifikationen. Efter att ett ma-nuellt test hade utförts skrevs en testrapport för det utförda testet. Testrapporten innehåller varje utfört steg i testet, dess förväntade resultat och det faktiska resultatet. Dessa tester ut-fördes främst vid projektets slut för att verifiera att de specificerade kraven uppfylldes. Travis är ett verktyg som kör förskrivna tester vid varje pull request eller push till en gren. Om dessa tester skulle misslyckas vid en pull request från master-grenen nekas integrationen. En push kommer alltid lyckas även vid ett misslyckat test, men Travis noterar att testet har misslyckats.

Huvudsyftet för de automatiska testerna var att se till att ingen felaktig kod fanns på master-grenen. Testerna kontrollerar att koden kompilerar, att det inte finns några Eslint-fel samt att de egenskrivna testerna uppfylls. Automatiska tester skrevs under utvecklingens gång. När ny funktionalitet implementerades skrevs även tester till denna.

4.2.5

Möten

Vid början av varje vecka hade projektgruppen ett möte för att diskutera vad som skulle hända framöver och där funderingar eller problem kunde tas upp och diskuteras. Dessutom hade projektgruppen ett handledarmöte varje vecka. På handledarmötet kunde generella frå-gor kring projektet ställas och vägledning gavs för diverse problem eller funderingar projekt-gruppen hade. Alla möten dokumenterades i ett mötesprotokoll som projektprojekt-gruppen formu-lerat.

En gemensam Google-kalender skapades där alla möten samt viktiga moment och deadlines lades till. Alla moment som lades till i kalendern ansågs vara obligatoriska för projektgrup-pen där alla medlemmar förväntades medverka.

4.2. Utvecklingsmetod

4.2.6

Kommunikation

Kommunikationen mellan externa parter och projektgruppen gick i huvudsak genom roller-na teamledare och aroller-nalysansvarig. Slack användes för både den interroller-na och exterroller-na kom-munikationen under projektets gång. En Slack-arbetsplats skapades, där enbart projektgrup-pen var medlemmar. Majoriteten av den interna kommunikationen skedde genom denna. Olika kanaler skapades på denna Slack-arbetsplats för att diskutera olika ärenden och hål-la kommunikationen strukturerad. Det fanns ytterligare en Shål-lack-arbetsphål-lats där både pro-jektgruppen och kunden medverkade. På denna arbetsplats skedde en del av den externa kommunikationen med kunden. Även denna arbetsplats var uppdelad i olika kanaler: frågor och allmänt. Tanken bakom kanalen frågor var att projektgruppen kunde fylla kanalen med frågor rörande utvecklingen och kunden kunde bearbeta frågorna när de hade tid. Kanalen allmänt användes för all övrig kommunikation. Den externa kommunikationen skedde även muntligt med kunden ute på deras kontor.

4.2.7

Enkät och demonstrationer

För att verifiera att produkten uppfyllde kundens förväntningar bestämde gruppen sig för att genomföra en enkätundersökning. I denna undersökning fick 20 personer testa att använda produkten och sedan fylla i en enkät gällande upplevelsen. De valda testpersonerna kom från två grupper, studenter slumpmässigt valda på Linköpings universitets campus och anställda på Cybercom. Dessa personer fick testa spelet i ungefär fem minuter innan de fick fylla i enkäten med nedanstående frågor. På varje fråga fick ett betyg ges mellan ett och tio där ett är helt emot och tio betyder att man instämmer helt.

(a) Jag tycker det var svårt att förstå spelets regler.

(b) Jag tycker att spelet kändes responsivt. (Spelpjäsen rörde sig på ett bra sätt efter dina rörelser)

(c) Jag tycker det var lätt att följa vad som hände på den stora spelskärmen. (d) Jag tycker spelet var kul.

(e) Jag tycker det var lätt att styra min spelpjäs.

Utöver testtillfällena med enkäten har också demonstationer för kunden förekommit. Dessa demonstrationer har både varit informella, i form av att snabbt visa upp vad som gjorts under exempelvis dagen, och formella. De formella demonstrationerna var presentationer till kund kring hur produkten såg ut. Kunden fick chans att både spela spelet men också ställa frågor kring implementation och design som ansågs vara intressant.

4.3. Dokumentation

4.3

Dokumentation

Det här avsnittet beskriver vilka verktyg som har använts för att dokumentera projektgrup-pens arbete samt vilka dokument som har producerats och deras syften.

4.3.1

Dokument

Nedan beskrivs alla dokument projektgruppen producerat. Projektplan

Projektplanen bestod av en beskrivning av projektet, resurser som teamet hade tillgång till, processer som användes och risker inom projektet. Dessutom beskrevs en aktivitetsplan som översiktligt tog upp alla aktiviteter som utfördes under projektet.

Kravspecifikation

Kravspecifikationen förtydligade vad som förväntades vara klart vid projektets slut. Doku-mentet fungerade som en överenskommelse mellan kunden och projektgruppen. Kraven spe-cificerade vilken funktionalitet, kvalitet och design produkten skulle uppfylla. Dokumentet utgjorde grunden för hur hela projektet skulle struktureras och utformas. Kraven var fram-tagna efter kundens önskemål och formulerade för att ligga till stöd för projektgruppens arbete.

Kvalitetsplan

Kvalitetsplanen definierade processer vars syften var att säkerställa att produkten höll en hög kvalitet. Kvaliteterna som var i huvudfokus var definierade i kravspecifikationen och var baserade på kundens önskemål.

Statusrapport

Statusrapporten var som en mindre projektplan för de olika iterationerna. Rapporten reflek-terade över hur allt förarbete hade gått, vad som skulle hända till nästa iteration samt vilka risker projektgruppen stod inför.

Systemanatomi

Anatomin för systemet beskrev hur systemet är uppbyggt på olika nivåer, såsom funktioner, mjukvara och hårdvara. Anatomin gav en större bild av hur systemet fungerade och beskrev vilken miljö det kommer befinna sig i.

Arkitekturbeskrivning

Arkitekturbeskrivningen detaljerade arkitekturen för systemet samt beskrev hur olika sub-moduler hängde ihop. Arkitekturens fördelar, nackdelar och möjliga utökningar förklarades även i dokumentet.

Testplan

Testplanen beskrev hur de olika delarna av produkten skulle testas och även hur man skulle följa upp på testerna.

4.4. Metod för att fånga erfarenheter

Gruppkontrakt

Projektgruppen producerade och undertecknade ett gruppkontrakt som skrevs vid ett tidigt stadie för att förtydliga vad som förväntades av varje gruppmedlem.

Tidrapport

Tidrapporteringen under projektet skedde i ett Excel-blad där varje teammedlem rapporte-rade den tid de har spenderat under en dag. Tiderna som skrevs ner fick inte överstiga två timmar och arbetspass som varade längre skrevs som två eller flera olika arbetstillfällen. Det-ta för att få en bättre bild av vad som har jobbats på under arbetspassen. I och med tidsrap-porteringen kunde även en burndown chart genereras för att få en bättre uppfattning om hur teamet låg till i tidsåtgång.

Mötesprotokoll

Under projektet hölls olika möten för att diskutera saker som kommit upp. Alla möten doku-menterades genom en mötesprotokollmall som skrevs vid varje möte.

4.3.2

Dokumentskrivning

Själva dokumentskrivningen utfördes i Latex, vilket gjorde det lättare att dela upp doku-menten i olika sektioner. Utöver Latex användes Google Drive för mer inofficiella dokument såsom mötesprotokoll, veckorapporter och seminarieförberedelser.

4.3.3

Dokumentlagring

Dokumenten som skapades under projektets gång lagrades på Google Drive för att både versionshantera de olika färdiga iterationerna av dokumenten, men även för att enkelt kunna se dokumenten om Latex inte fanns tillgängligt. Dessutom versionshanterades dokumenten under arbetets gång med hjälp av Git genom Github. Detta hjälpte dokumentskrivningen genom att hantera olika konflikter när olika personer skrev i samma fil.

4.4

Metod för att fånga erfarenheter

Då teamet bestod av studenter från olika program på universitetet och alla hade olika erfa-renheter om olika områden, vare sig det gäller spelprogrammering eller generell Javascript, behövdes det en struktur för att samla och ta nytta av varje projektmedlems kunskaper. För att uppnå detta samlade teamet in och skrev ner de olika kunskaperna som teamet hade och utifrån dessa hölls olika workshops för att få alla projektmedlemmar på ungefär samma nivå. Utöver det jobbade teamet i grupper om två till tre vilket underlättade arbetet då man lättare kunde utbyta erfarenheter. Dessa grupper växlades även vid jämna mellanrum så att alla kunde ta del av alla erfarenheter. Hela gruppen delade även med sig av problem och nya erfarenheter på de regelbundna mötena. Dessa antecknades i mötesprotokollen.

5

Resultat

Detta kapitel tar upp de resultat som projektgruppen kommit fram till under projektets gång.

5.1

Systembeskrivning

Projektgruppen definierade en tydlig design av applikationen innan implementationen på-börjades. Detta var för att försäkra sig om att applikationen skulle bli av hög kvalitet och eventuella designproblem skulle hittas tidigt i projektet.

5.1.1

Systemanatomi

Under iteration ett producerade projektgruppen en systemanatomi av applikationen som skulle utvecklas. Denna producerades utifrån de use-cases och krav kunden hade tillhan-dahållit. I figur 5.1 visas systemanatomin för spelet och i 5.2 visas den för hela systemet.

5.1. Systembeskrivning

Figur 5.1: Överblick av systemanatomin för spelet

5.1. Systembeskrivning

5.1.2

Moduler

Projektgruppen använde sig av den generella strukturen av systemet, kundens krav och sys-temanatomin för att skapa en mer detaljerad arkitektur. Figur 5.3 visar den övergripande strukturen av modulerna som finns i applikationen.

5.1. Systembeskrivning

Ansvarsområden

Varje modul i systemet har ett eget ansvarsområde. Nedan följer en förtydling av vad varje modul ansvarar för.

SpelGUI • Visa upp spelplanen

• Visa upp menyer

• Starta spel med specifika inställningar

Spelläge • Sätta upp regler för spelet

• Avgöra vilka resurser spelet ska innehålla

• Avgöra vad som ska ske vid olika tillfällen i spelet

Spel • Hålla koll på de olika spelarna

• Tillhandahålla grundläggande spelmekanik

Resursserver • Lagra vilka resurser som finns • Ladda in resurser

UI-kommunikation • Upprätta uppkoppling mot server • Förpacka data för kommunikation

Sensorläsare • Läsa av data från sensor

• Abstrahera sensordata till standardiserad form • Konfigurera sensor

KontrollGUI • Visa menyer för att gå med i spelinstans • Visa spelinformation om det pågående spelet • Tillhandahålla knappar på skärmen

Kontrollkommunikation • Upprätta uppkoppling mot server • Förpacka data för kommunikation

IoT-backend • Dirigera data mellan olika Kontroll-applikationer och olika in-stanser av UI-applikationen

5.2. Gemensamma erfarenheter

5.2

Gemensamma erfarenheter

Denna del tar upp diverse erfarenheter projektgruppen varit med om, både innan och under projektets gång.

5.2.1

Erfarenheter av systemanatomi

Systemanatomin som presenterades under 5.1.1 användes för att ge en enhetlig och heltäc-kande bild över hur det färdiga systemet skulle se ut. Arbetet för att ta fram själva systema-natomin var något som tog relativt lång tid. Nyttan gruppen har haft av systemasystema-natomin var liten jämfört med den nedlagda tiden att ta fram den. Den blev mer ett verktyg som kunde användas för att verifiera resterande arkitekturbeskrivningar. Gruppen känner att själva pro-cessen att producera anatomin var nyttigare än den resulterande bilden, då det skapade en öppen dialog om systemets helhet.

5.2.2

Tidigare erfarenheter

Alla av projektets medlemmar hade studerat mer än två år på respektive program innan detta projekt startades. På grund av detta hade alla haft möjligheten att medverka i några större projekt och var därför ganska vana vid hur arbetet gick till. Dock var det få som hade erfarenhet med webbutveckling och spelprogrammering, något som hade stort fokus i detta projekt. Detta var dock inget större problem då de mer erfarna kunde hjälpa resten att komma igång.

5.2.3

Nya erfarenheter

Under projektets gång har alla medlemmar fått använda sig av nya verktyg och metoder som de inte haft tidigare erfarenhet av. De projektmedlemmar som tidigare saknade erfarenhet inom webbutveckling och spelprogrammering har fått chansen att sätta sig in i dessa. För att förbättra denna process hjälpte de som redan var erfarna inom ämnet till med att svara på frågor och komma med tips och idéer. Under projektets gång tillkom en del nya paket och ramverk. Ett exempel på detta är PIXI, ramverket UI-applikationen använder för att rita ut spelet. Det var ingen i projektgruppen som hade jobbat med detta ramverk innan, så några i gruppen fick tillsammans sätta sig in i hur det fungerade och utbilda resterande vid behov. Det var även få gruppmedlemmar som hade tidigare erfarenheter med React och en del av de olika npm-paketen som installerades och användes i projektet.

5.2.4

Tidsbrist

I början av projektet hade gruppen bra tidsplanering och genomförde första iterationen i god tid. I början av iteration två satsade gruppen i huvudsak på utveckling och hade mindre fokus på dokumentskrivning. Det visade sig senare att vara en dålig prioritering. Konsekvensen av prioriteringen ledde till att det blev stressigt framåt slutet av iterationen vilket påverkade dokumentkvaliteten negativt. Gruppen noterade detta och ökade prioriteringen av att skriva dokument för de framtida iterationerna. Nästa iteration delades upp i en tydligare utveck-lingsfas och dokumentfas, vilket ledde till en bättre planering och fördelning av tiden. Denna planering följde med till nästa iteration också, vilket visade sig fungera bra. Gruppen kände att detta ledde till mer tid att fokusera på de utsatta aktiviteterna.

5.2. Gemensamma erfarenheter

5.2.5

Tekniska erfarenheter

Projektgruppen utvecklade applikationen med React. React saknar en tydlig struktur för hur data ska flöda genom applikationen, se E.2.5 för mer information. Projektgruppen märkte detta då flera lager av komponenter implementerades. Detta problem löser andra ramverk och bibliotek genom att erbjuda funktionalitet som specifikt hanterar dataflöden. Gruppen reflekterade över om ett bibliotek skulle användas för detta men beslutade emot att använ-da det. Det visade sig i senare delen av projektet att hanteringen av använ-dataflödet blev rörigare än förväntat. Gruppen hade använt sig av fler komponenter än vad som initialt hade tänkts. Detta ledde till att implementationen av nya komponenter som hamnade mellan redan exi-sterande komponenter blev svårare. Detta berodde främst på att data som tidigare skickats från komponent A till C nu behövde skickas från A till B och sen vidare från B till C, när kom-ponenten B introducerades mellan A och C. Detta ledde till att all data som tidigare skickades mellan A och C nu också behövde skickas till B, trots att det kunde vara data B inte använde sig av. En grafisk överblick kan ses i figur 5.4.

Figur 5.4: Överblick av hur implementation av mittenkomponent kan ge ett ineffektivt data-flöde

5.2.6

Erfarenheter med kundkontakt

Under projekts gång har gruppen haft en stor nytta av en nära kommunikation med kun-den. Tidigt bjöds kunden in i en Slack-kanal med samtliga medlemmar, vilket ledde till att kommunikationen blev mer personlig än om mail hade använts. Gruppen utnyttjade även kundens kontor och valde att arbeta där så mycket som möjligt. Kunden uppmanade till att ställa frågor vilket förtydligade diverse oklarheter snabbt och resultatet blev att gruppen blev mer produktiv. Den nära kundkontakten ledde även till en öppnare dialog kring skapande och verifiering av produktkrav. I projektets början formulerade projektgruppen krav till krav-specifikationen. Dessa krav togs fram genom Slack-kanalen och några möten projektgruppen hade med kunden. Slack-kanalen var väldigt användbar under denna process. Under senare delen av projektet har kunden fått flertalet demonstrationer av produkten för verifiering av att den följer deras krav och vision.

5.3. Testning

5.3

Testning

Många tester har genomförts under projektets gång. I huvudsak har de flesta tester genom-förts av personen som skrivit koden. Många strukturerade tester har även genomgenom-förts till-sammans för att koordinera att produkten lever upp till kravspecifikationen.

5.3.1

Jest

Under utvecklingen användes testverktyget Jest för att skriva de automatiska testerna. Beslu-tet fattades då gruppen bestämt att produkten skulle utvecklas i React då båda har utvecklats av samma företag för att fungera bra tillsammans. Ingen i gruppen hade tidigare erfarenhet av Jest, vilket ledde till att många tester tog lång tid att skriva och kan ha blivit mindre kon-ventionella. Mer om hur Jest fungerar och hur det skiljer sig från andra verktyg utvecklas vidare i bilaga D.

5.3.2

Travis

Travis har använts flitigt under projektets gång i och med att dessa tester har utförts auto-matiskt så fort en teammedlem lagt till sina ändringar i Git-repot. Detta ledde till att många kompilerings- och Eslint-fel kunde fångas utan att en annan teammedlem behövde kolla över dessa triviala fel. Genom att då ha kört dessa tester automatiskt minimerades den tid som spenderades på att verifiera koden och mer tid kunde då läggas på själva utvecklingen.

5.3.3

Manuell

Vid de tillfällena då manuella tester användes var det lättare för buggar att gå igenom till master-grenen. Detta på grund av att det fanns många olika tester för olika delar av produk-ten och alla dessa kunde inte testas manuellt för varje ändring som gjordes. Utöver det fick teamet problem när många manuella tester inte blev dokumenterade eller blev utdaterade på grund av att kodstrukturen ändrades. Vilket då leder till att mer tid spenderades på att skriva och uppdatera triviala tester. Anledningen till att alla tester inte dokumenterades var för att många är väldigt triviala, såsom att undersöka om en knapp tar användaren till rätt meny.

5.4

Produkt

Nedan följer de resultat teamet har tagit fram i form av den utvecklade produkten. Detta resultat relaterar till frågeställning 1. Produkten som har utvecklats kan delas upp i tre olika delar, som kan ses tidigare i figur 5.3. Dessa delar är en kontroll, ett UI och en service. Servicen implementerades som en del av Cybercoms backend.

5.4.1

Service

När kraven hade blivit framställda i kravspecifikationen var det tydligt att kunden ville ha ett system där flera spel kan spelas samtidigt. För att förtydliga innebär det att flera instanser av UI:t ska kunna vara igång samtidigt. Användaren ska ha möjlighet att välja vilken instans av UI:t som ska anslutas till. Detta implementerades med hjälp av en service i Cybercoms backend. Denna service registrerar när nya instanser av UI:t skapas eller tas bort. Servicen skickar vidare denna information till kontrollen. På så sätt vet kontrollen vilka instanser av UI:t som finns tillgängliga, vilket kan ses i figur 5.5.

5.4. Produkt

Figur 5.5: Exempel hur visningen av instanser ser ut på kontrollen

5.4.2

Kontroll

Kontroll-applikationen som har utvecklats är ett gränssnitt som används för att styra en spe-lare på spelplanen i UI:t. Det är tänkt att kontroll-applikationen ska köras på en mobil enhet. Den kan dock även köras på andra enheter, som en dator. Det första som visas i kontroll-applikationen är en välkomstskärm. Välkomstskärmen består av en välkomsttext och en knapp som avancerar till nästa vy. På nästa vy, som kan ses i figur 5.5, finns en lista över tillgängliga spelinstanser. Här finns även ett sökfält där det går att söka efter specifika spe-linstanser. Efter att en användare valt en instans visas en ny vy. På denna vy får användaren möjligheten att anpassa namnet och utseendet på sin spelare, som kan ses i figur 5.6. Det finns även möjlighet att slumpa namnet och hur karaktären ska se ut. När användaren är nöjd med utseendet hos sin spelare ansluter denna till spelsessionen genom Join-knappen. När Join-knappen trycks ansluter kontrollen till den spelinstans som valdes innan och en ny vy visas för användaren, se figur 5.7. Användaren styr sin spelare på planen genom att lu-ta mobiltelefonen. Användaren kan även använda eventuella spelförmågor till sin spelare i spelet genom knapparna på skärmen. Exemplet som visas i figur 5.7 visar vyn för spelläget Knockoff. Detta spelläge stödjer enbart en spelförmåga, Super Heavy, som användaren kan an-vända sig av. Anan-vändaren kan också se sitt valda namn, utseende och sin svarstid. Det visas även knappar för att kalibrera rörelsesensorn och att lämna spelet. Om en användare trycker på Leave-knappen går applikationen tillbaka till vyn med listan över instanser i figur 5.5.

5.4. Produkt

Figur 5.6: Skärm för att anpassa sin spelare innan anslutning till en spelinstans

5.4. Produkt

5.4.3

UI

Denna del av produkten ansvarar för att välja vilket spelläge som ska spelas, samt köra och visa spelet för alla användare. I en huvudmeny kan användare starta nya spelinstanser. För varje instans väljs spelläge, max antal spelare och ett namn på instansen. Därefter startas det valda spelläget och en ny vy visas. Spellägena som finns är fokuserade på en spelplan som ses ovanifrån där varje spelare styr en egen cirkel. Nedan i figur 5.8 och 5.9 kan man se två av de spellägen som finns att välja på. Båda spellägena går ut på att styra sin cirkel för att överleva spellägets hinder.

Spelet innehåller flera generella system för att kunna skapa olika sorters spellägen. Hante-ring av återskapande av döda spelare, poäng och inladdning av bilder är exempel på sådana system. Dessa implementerades på ett generellt sätt med många konfigurerbara parametrar. Dessa parametrar sätts till stor del av unika konfigurationsobjekt för spellägena. Detta för-enklar konfigurationen av de olika spelsystemen till endast några få parametrar. Spellägen implementerades även med ärvning mellan varandra. Detta gör det möjligt att utgå från ett existerande spelläge och skapa nya som bygger vidare på dess funktionalitet.

Figur 5.8: Skärmdump av UI:t i spelläget Dodgebot

5.4.4

Nätverk

För att användarna ska ha god möjlighet att styra sin karaktär behöver spelet svara responsivt på input från kontrollen. Responsivt i det här sammanhanget syftar på tiden det tar från att en användare lutar kontrollen tills att spelpjäsen flyttar på sig på UI:t. Detta var en utmaning för gruppen eftersom datan som skickas från kontrollen till spelet skickas över internet och därför påverkas av nätverkets svarstid. Eftersom spelet spelas i realtid är det alltså viktigt att användarens input också påverkar spelet i realtid. För att spelupplevelsen ska vara responsiv har gruppen därför jobbat mycket med att optimera hur mycket data som skickas via nätver-ket. En genomförd optimering för att minska mängden data som skickades från kontrollen var att enbart skicka data när sensorvärden uppdaterats. Sensorvärdena hade dock en väl-digt bra precision med många värdesiffror vilket resulterade i att data fortfarande skickades väldigt frekvent. För att lösa detta problem avrundades sensorvärdena till närmaste heltal. Detta reducerade mängden data som skickades avsevärt. Gruppen kalibrerade även hante-ringen av sensordatan på UI:t. Här fokuserades det på att få känslan av att styra en spelare

5.4. Produkt

bra. Denna kalibreringen skedde manuellt tills gruppen var nöjd med känslan att styra en spelare. I verkligheten betydde detta en styrning som direkt reagerar på ny input, men ock-så tar hänsyn till tidigare värden som tagit emot. Detta ledde till ett robust styrsystem som ger mjuka rörelser i spelet. Lösningen klarar även av eventuella nätverksstörningar utan att spelaren tappar styrningen.

5.5. Enkätresultat och kontinuerliga demonstrationer

5.5

Enkätresultat och kontinuerliga demonstrationer

Nedan presenteras resultatet av enkätundersökningen som beskrivs under 4.2.7, både i figur 5.10 och tabell 5.1. Detta resultat tillsammans med resultatet från de kontinuerliga demon-strationerna diskuteras senare under 6.1. Resultatet från demondemon-strationerna för kunden är tyvärr inte kvantitativt på samma sätt som enkätsundersökningen. Feedbacken gruppen fick från kunden användes istället direkt genom att fokusera på de funktioner produkten behöv-de för att uppfylla kraven. Demonstationerna gav en mer öppen dialog kring implementation och design av produkten och tillät gruppen att direkt implementera kundens önskemål i pro-dukten.

(a) _(b)

(c) (d)

(e)

Figur 5.10: Resultat från enkäten testpersonerna var tillfrågade att fylla i (a) (b) (c) (d) (e)

Medelvärde 3.5 7.9 7.9 7.9 7.1

Median 2 8 8 8.5 7

Standardavvikelse 3.1 1.5 2.2 2.2 2.6

6

Diskussion

I följande del presenteras olika tankar och idéer som uppkommit baserat på denna rapports innehåll och det genomförda projektet. De resultat som har uppnåtts väcker flera intressanta tankar och frågor. Det finns möjliga förbättringar till metoden som i efterhand har uppdagats. Arbetet existerar även i en samhällelig och etisk kontext som bör lyftas.

6.1

Resultat

Nedan följer diskussion kring det resultat som tidigare presenterats.

Tekniska val

Det fanns i det genomförda projektet många val som kunde leda till annorlunda resultat. Många teknikval beslutades om för att färdigställa produkten. En stor andel av dessa har tagits enligt önskemål från kunden och det är inte troligt att kundens värde skulle kunna öka om dessa inte följdes. I denna kategori faller användning av React samt att koden skrevs i ren Javascript.

Många av de tekniska val som gruppen har tagit relaterar till speldelen av produkten. Ett stort sådant var att skapa spelet som ett mer allmänt ramverk för olika spellägen istället för ett specifikt spel. Det är troligt att projektet hade förändrats mycket om det andra alternati-vet hade valts. Då ett av kundens viktigaste önskemål var att enkelt kunna vidareutveckla projektet bedömdes dock det mer generella valet ge mer värde. Val av bibliotek för spelet var också ett viktigt avgörande beslut för projektet. Flera alternativ diskuterades som till olika grad förlitade sig på färdiga paket för fysik, grafik och logik. Den slutgiltiga lösningen med PIXI har givit stora möjligheter att skapa det system som önskades och gav även mycket stöd i rendering av spelets grafik. Utan färdiga bibliotek hade arbetet troligen tagit alldeles för lång tid. Användning av många stora bibliotek kan istället introducera oönskade begränsningar på projektets struktur.

6.1. Resultat

Utökningsbarhet

Den slutgiltiga produkten innehåller några enkla spellägen som fungerar till fullo. Dessa krä-ver ingen vidareutveckling från kundens sida utan kan användas som tilltänkt efter lekrä-verans. Det är dock troligt att kunden vill introducera fler spellägen. En viss del av produktens värde ligger i hur hög utökningsbarhet som har uppnåtts för att underlätta denna process. Utförlig dokumentation har även skapats för att minimera tiden som krävs för att sätta sig in i syste-met. Med detta är förhoppningen att skapandet av nya spellägen ska gå mycket smidigt och inte kräva förståelse för implementationsdetaljer.

Systemanatomin

Det fanns genom projektet en viss förvirring och osäkerhet gällande arbetet med systemana-tomin. Ofta fanns stora skillnader i olika medlemmars uppfattning av hur anatomin skulle vara konstruerad. Det är möjligt att en otillräcklig förståelse för konceptet kan ha lett till att den framtagna modellen tappat mycket värde. Det är möjligt att svaret på frågeställning 3 kunde haft ett större värde om det fanns fler ingående erfarenheter av arbete med systema-natomier. Gruppen diskuterade även huruvida relevansen av systemanatomin kan förändras mycket mellan olika typer av projekt och utvecklingsmetodik. Det genomförda projektet be-finner sig på en hög abstraktionsnivå med liten hårdvarukoppling. Det är av intresse hur systemanatomins nytta skulle se ut i mer hårdvarunära projekt, men detta har inte under-sökts vidare.

Projektgruppens erfarenheter

Det är mycket troligt att resultat av projekterfarenheter har påverkats av att denna studie av processen har pågått parallellt. Gruppmedlemmarna har haft en medvetenhet om att projek-tet ligger till grund för detta arbete och även tagit del av seminarier som skapat en djupare reflektion. Detta delade fokus har troligen påverkat projektets utveckling. Det är dock troligt att utförandet av denna undersökningen parallellt är nödvändigt för att ge en tillräcklig insikt i projektet. Även om gruppens erfarenheter är att projektet ej kan anses till fullo representera typisk mjukvaruutveckling bedöms detta inte påverka resultaten i alltför stor utsträckning.

Testning

Testningen som gjorts under projektets gång har lämnat viss önskan efter mer. De flesta test har utförts direkt efter att koden som testas skrivits. Ofta har även samma person som skrivit koden testat den. Processen har alltså inte alltid varit så utarbetad som hade kunnat önskats. Detta berodde till stor del på avsaknad av ordentlig struktur från början och okunnighet från gruppens sida då få gruppmedlemmar var vana användare av automatisk testning.

En bit in i projektet påbörjades testningen ordentligt och ett antal automatiska tester började formas. Möjligtvis blev testerna inte optimala då tidigare erfarenheter av testning var bristan-de. En lärdom av detta är att påbörja testningen i ett tidigare skede för att verkligen komma igång med det, kanske till och med att testdriven utveckling vore ett bra alternativ [21]. Om man formar produkten efter testerna blir man tvungen att skriva tester och får som en slags checklista att bocka av när testerna klaras av.

Manuella tester är det som använts flitigast under projektets gång eftersom manuella tester går snabbt och gruppen vet väl sedan tidigare hur de ska genomföras. De flesta har skett in-officiellt av samma testare vilket kan vara en nackdel då testaren är partisk. Däremot uppstod inga uppenbara problem med detta. Hade projektet varit av större omfattning hade troligt-vis denna nackdel haft en större inverkan. Det finns ett par officiella tester som gjorts för att kontrollera att produkten lever upp till vad som är utlovat i kravspecifikationen. Exempel på