Simulering i Virtual Reality för prestations- och motivationsförbättring

Linköpings universitet | Institutionen för datavetenskap

Examensarbete på grundnivå, 15hp | Datateknik

Vårterminen 2017 | LIU-IDA/LITH-EX-G--17/041--SE

Simulering i Virtual Reality

för prestations- och

motivationsförbättring

Simulation in Virtual Reality for Performance and

Motiva-tional Improvements

Anton Dalgren

Cian Hjort

Gustav Kvist

Kevin Larsson Alm

Anton Mo Eriksson

Seth Ramström

Noak Ringman

August Uusitalo

Handledare : Rikard Nordin 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 admin-istrativ 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 upphovsmannenslitterä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 circum-stances. 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 unchanged for non-commercial research and 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

Anton Dalgren Cian Hjort Gustav Kvist Kevin Larsson Alm Anton Mo Eriksson Seth Ramström Noak Ringman August Uusitalo

Sammanfattning

Denna rapport behandlar det kandidatarbete som projektgruppen SurVive utfört under vårterminen 2017 vid Linköpings universitet. Arbetet gick ut på att i forskningssyfte, kon-struera en virtuell miljö för studenter att träna på krävande situationer. Rapporten syftar att diskutera och analysera både virtuell verklighets applicerbarhet på prestationsförbättring samt utvecklingen av den virtuella miljön.

Systemet som har utvecklats ska ge en säker och trygg miljö för användaren att praktis-era sin presentation. Vidare kommer relevant användardata illustrpraktis-eras på en hemsida för att tillhandahålla återkoppling på framförandet. Huruvida det utvecklade systemet egentligen bidrar till prestationsförbättring, kräver ytterligare forskning och användning.

Abstract

This report processes the software development project created by the project group SurVive during the spring semester of 2017 at Linköping University. The project involved in the purpose of research, construct a virtual environment in order to allow students to practice demanding situations. The report aims to discuss and analyze virtual realitys applicability on performance enhancement and the development of the virtual environment.

The system that has been developed will provide a safe and secure environment for the users to practice their presentations. In addition, relevant user data will be illustrated on a website to provide feedback on their performances. Whether the developed system really contributes to enhanced performance, requires further research.

Tillkännagivanden

Gruppen skulle vilja tacka Rikard Nordin för hans vägledning och hjälp med dekorering utav Akvariet. Tack till Dennis Petersson för all hjälp kring utrustningen i Akvariet. Gruppen vill även tacka Kristian Sandahl för en lärorik kurs och för hans hjälp med dokumentet ”Arkitek-toniska anteckningar”.

Innehåll

I

Gemensamma erfarenheter och diskussion

1

1 Inledning 2

1.1 Översiktlig beskrivning av projektet . . . 2

1.2 Motivering . . . 2 1.3 Syfte och mål . . . 3 1.4 Frågeställning . . . 3 1.5 Avgränsningar . . . 3 2 Bakgrund 4 3 Teori 5 3.1 Unity . . . 5 3.2 Node.js . . . 5 3.3 Scrum . . . 6 3.4 Flask . . . 6 3.5 MySQL . . . 7 3.6 eXtreme Programming . . . 7 4 Metod 8 4.1 Metoder & verktyg . . . 8

4.2 Utvecklingsmetodik . . . 8

4.3 Metod för att fånga erfarenheter . . . 9

5 Resultat 10 5.1 Systembeskrivning . . . 10

5.2 Gemensamma erfarenheter: Vilka erfarenheter har vi fått som är överförbara till framtida projekt? . . . 17 5.3 Vilka val har tagits för att simuleringen ska hjälpa personen att bli mer bekväm? 19

5.4 Hållbar utveckling . . . 19

6 Diskussion 20 6.1 Resultat . . . 20

6.2 Metod . . . 20

6.3 Vilka val har tagits för att simuleringen ska hjälpa personen att bli mer bekväm? 21 6.4 Gemensamma erfarenheter . . . 22

6.5 Arbetet i ett vidare sammanhang . . . 23

7 Slutsatser 25

II Individuella bidrag

26

A Skillnader i utveckling av REST-API i Node.js och Python 29 A.1 Inledning . . . 29 A.2 Bakgrund . . . 29 A.3 Teori . . . 29 A.4 Metod . . . 30 A.5 Resultat . . . 30 A.6 Diskussion . . . 32 A.7 Slutsatser . . . 35

B Versionshanteringssystem vid grupparbeten 36 B.1 Inledning . . . 36 B.2 Bakgrund . . . 36 B.3 Teori . . . 36 B.4 Metod . . . 38 B.5 Resultat . . . 38 B.6 Diskussion . . . 40 B.7 Slutsatser . . . 41

C Arbetsgruppens utveckling under ett projekt 42 C.1 Inledning . . . 42 C.2 Bakgrund . . . 42 C.3 Teori . . . 43 C.4 Metod . . . 44 C.5 Resultat . . . 44 C.6 Diskussion . . . 46 C.7 Slutsatser . . . 47 C.8 Figurappendix . . . 49

D Jämförelse mellan komponenter och arv inom spelutveckling 50 D.1 Inledning . . . 50 D.2 Bakgrund . . . 50 D.3 Teori . . . 51 D.4 Metod . . . 52 D.5 Resultat . . . 53 D.6 Diskussion . . . 57 D.7 Slutsatser . . . 58

E.2 Bakgrund . . . 59 E.3 Teori . . . 59 E.4 Metod . . . 62 E.5 Resultat . . . 62 E.6 Diskussion . . . 63 E.7 Slutsatser . . . 63

F Virtual Reality - Vad är verkligt 65 F.1 Inledning . . . 65 F.2 Bakgrund . . . 65 F.3 Teori . . . 66 F.4 Metod . . . 66 F.5 Resultat . . . 69 F.6 Diskussion . . . 70 F.7 Slutsatser . . . 70 F.8 Figurappendix . . . 72

G Testning vid spelutveckling i Unity 74 G.1 Inledning . . . 74 G.2 Bakgrund . . . 74 G.3 Teori . . . 75 G.4 Metod . . . 75 G.5 Resultat . . . 75 G.6 Diskussion . . . 77 G.7 Slutsatser . . . 79

H Påverkan av att skriva lokalt eller via molntjänster 80 H.1 Inledning . . . 80 H.2 Bakgrund . . . 80 H.3 Teori . . . 81 H.4 Metod . . . 82 H.5 Resultat . . . 82 H.6 Diskussion . . . 83 H.7 Slutsatser . . . 84 H.8 Figurappendix . . . 86 Litteraturförteckning 91

Figurer

3.1 Grafisk illustration av arbetsmetodiken Scrum [12]. . . 6

5.1 Illustration av systembeskrivningen för systemet. . . 11

5.2 Illustration av systemanatomin för systemet. . . 12

5.3 Grafisk miljö som ska efterlikna ett klassrum. . . 13

5.4 Student skapad i MakeHuman. . . 13

5.5 Grafisk miljö som ska efterlikna en föreläsningssal. . . 14

5.6 Grafisk miljö som ska efterlikna en föreläsningssal. . . 14

5.7 Arvsträd över olika beteenden, där pilar visar arv från grundobjekt till ärvande objekt. . . 15

5.8 Inloggningsfönster på webbsidan. . . 17

5.9 En tidig version av hur mätdata presenteras på webbsidan. . . 17

5.10 Demonstration av Git-arbetsflöde. . . 18

A.1 Filstrukturen över det färdiga Express-projektet. . . 31

A.2 Exempel på callback-hell där callback-funktioner är rödmarkerade. . . 33

A.3 Kodexempel där Promises används. . . 34

A.4 Kodexempel i Python för kommunikation med databas. . . 34

B.1 Centraliserade systemet . . . 39

B.2 Distribuerade systemet . . . 40

C.1 Enkätens frågor . . . 49

D.1 Exempel på system och komponenter i EKS. . . 52

D.2 Exempel på hur ett arvsträd kan se ut, där pilar denoterar arv i pilens riktning. . . 53

D.3 Exempel på arvsproblem med flera föräldrar, där pilar denoterar arv i pilens rikt-ning. . . 54

D.4 Exempel på arvsproblem som skapar redundans, där pilar denoterar arv i pilens riktning. . . 55

D.5 Exempel på hur ett arvsträd kan se ut när EKS används. . . 56

D.6 Exempel på ett problem med EKS: ökad komplexitet hos delade komponenter. . . 57

F.1 Skärmbild ur ”The Price of Freedom” . . . 67

F.2 Skärmbild ur ”NewtonVR” . . . 68

F.3 Svar på enkäten . . . 73

G.1 Exempel på ett testflödesdiagram . . . 76

Tabeller

Kodexempel

A.1 Kommando för installation av bibliotek för att skapa ett fungerande Express-projekt. . . 31 A.2 Kodexempel för att göra en inloggning med HTTP-anropet POST i Express. . . 31 A.3 Kommando för installation av biblioteket Flask . . . 32 A.4 Kodexempel för att göra en inloggning med HTTP-anropet POST i Flask. . . 32

Definitioner

Nedan listas de benämningar som används inom ramen för projektet. • Blender – En utvecklingsmiljö för avancerade grafiska objekt.

• Burn-down-graf – En graf som visar hur mycket arbete som genomförts kontra den estimerade tidsplanen.

• eXtreme Programming – Utvecklingsmetodik där bland annat parprogrammering in-går. Används ofta i samband med Scrum.

• Feature freeze – Ny funktionalitet får inte läggas till, endast bearbetning av existerande funktionalitet tillåts.

• Freemium – En affärsmodell som erbjuder en bastjänst gratis, men fler funktioner kan införskaffas med premiumprenumeration.

• Git – Ett versionshanteringsprogram för att hantera källkod och filer. • GitHub – Webbplats där kod versionshanteras med hjälp av Git.

• HTC Vive – VR-utrustning från HTC och Valve som består av ett headset, de två hand-kontrollerna och basstationerna.

• HTML – HyperText Markup Language, ett märkspråk som används för att skapa webb-sidor.

• JavaScript – Dynamiskt prototypbaserat skriptspråk.

• Kodinspektion – En person som inte varit med och skrivit en funktion kontrollerar koden för att se till att den följer kodstandarden.

• Learn to SurVive – Arbetsnamn för projektet VR-simulering för prestation- och moti-vationsförbättring.

• MakeHuman – Ett utvecklingsprogram för att skapa humanoida 3D-modeller.

• Master-gren – Den gren på GitHub som alltid bör ha fungerande och väl kommenterad kod.

• Mixamo – En tredjepart webbplats med färdiga animationer för humanoida 3D-modeller som går att ladda ner.

• MySQL – Databashanterare som använder sig av programspråket SQL, Structured Query Language, för att hämta och modifiera data i en databas.

• Parprogrammering – Två programmerare sitter vid samma dator. Den ena skriver kod och den andra hjälper till med kontinuerlig kontroll av koden som skrivs.

• Pull request – Begäran om att slå ihop sin egen gren med master-grenen. • Python – Generellt interpreterat programspråk.

• Scrum – Utvecklingsmetodik där man bland annat delar upp ett helt projekt i ett antal sprinter och arbetar med de uppgifter som är planerade att göras under den sprinten som pågår.

• Slack – En internetbaserad kommunikationstjänst.

• Sprint backlog – En lista av alla aktiviteter som ska blir klara under en sprint. • SurVive – Samlingsnamn för projektgruppen.

• Trello – En tredjepart webbplats som visualiserar en anslagstavla.

• Unity – Ett verktyg och utvecklingsmiljö för utveckling av grafiska applikationer som spel.

• Unreal Engine – Ett verktyg och utvecklingsmiljö för utveckling av grafiska applikatio-ner som spel.

• VR – Förkortning av virtual reality, vilket översatt betyder virtuell verklighet.

• Werkzeug – Är ett bibliotek som följer Web Server Gateway Interface standarden för Python.

• WYSIWYG – ”What you see is what you get” är en benämning för bland annat ordbe-handlare, som utnyttjar ett användargränssnitt för att kontinuerligt representera resul-tatet av dokumentet i sin utskrivna form.

Del I

Kapitel 1

Inledning

Detta dokument handlar om projektgruppen SurVives kandidatarbete. Projektet fokuserar på studenter och består av att skapa virtuella miljöer av situationer med muntliga presentatio-ner. Beställaren av projektet var Therese Kristoffer Publishing AB som ville utföra projektet ur ett forskningsperspektiv. Grundidén var enkel och bestod av att skapa ett sätt för studenter att öva och uppleva att man lyckas med krävande uppgifter. Med hjälp av HTC Vive har en simulering skapats och användarens beteende analyseras för att ge återkoppling efter simu-leringen.

1.1

Översiktlig beskrivning av projektet

Projektet ägde rum under vårterminen 2017 och är huvudmomentet i kursen TDDD96 Kandi-datprojekt i programvaruutveckling. TDDD96 är en obligatorisk kurs i programmet Civilingenjör i datateknik/mjukvaruteknik vid Linköpings universitet och är avsedd att fungera som en in-troduktion till organiserat projektarbete och uppgifter liknande de i arbetslivet. Produkten som har utvecklats är en VR-simulering för att motverka prestationsångest kring situationer i studentlivet som upplevs som krävande och stressande, som till exempel presentationer. Projektets omfattning är 400 timmar per person vilket resulterade i en omfattning på totalt 3200 timmar.

1.2

Motivering

I dagsläget känner sig många studenter nervösa och stressade inför att tala framför publik. Presentationer, redovisningar och tal ses som stressande situationer och är en fobi med stor omfattning [2]. Ett sätt att underlätta stressen och nervositeten är att öva på framförandet i en kontrollerad miljö. Detta kan göras med hjälp av VR och har visats fungera i andra applikationer, till exempel för att bli av med spindelfobi [3].

Det har visats av tidigare studier att prestationen blir bättre om situationen upplevts i VR. Bland annat så har en studie utförts på basketspelare vilket resulterade i att spelarna presterade bättre i verkligheten [4]. Det har också påvisats att VR-modellering av en resa genom rymden förbereder astronauter inför de mentala påfrestningarna rymden ställer på astronauten [5].

Slutprodukten av projektet gav användaren möjligheten att öva på sitt framförande där personen kan välja hur stor och levande publiken ska vara. Personen kan även ändra hur länge den ska öva för att förbättra sin prestation.

1.3. Syfte och mål

1.3

Syfte och mål

Projektet utfördes i utbildande avsikt och dess syften sammanfaller därför med målen från kursen TDDD96. Ett urval av dessa lyder att studenten, efter avslutad kurs, ska kunna:

• Använda sig av sina kunskaper inom programmering och datalogi för att lösa kom-plexa arbetsuppgifter.

• Formulera en kravspecifikation utifrån ett projektdirektiv. • Utföra ett projektarbete enligt en projektmodell.

• Planera ett projektarbete och dokumentera detta i projekt- och tidplaner. • Aktivt medverka till en väl fungerande projektgrupp.

• Ta initiativ och finna kreativa lösningar.

• Använda moderna utvecklingshjälpmedel för mjukvaruutveckling, samt känna till des-sa systems möjligheter och begränsningar.

• Utföra felsökning i stora mjukvaruprojekt med hjälp av moderna utvecklingsmiljöer. Detta medför att uppdelning av projektets arbetsuppgifter i första hand kommer motiveras av gruppmedlemmarnas roller och intressen för de olika uppgifterna, snarare än dess kom-petens att utföra dem effektivt.

Projektets syfte är att utveckla ett program för VR-simuleringar av muntliga presenta-tionsmiljöer för studenter. Detta för att ge studenter en tryggare miljö att öva på inför ansträngande presentationssituationer som kan stötas på under utbildningen. På så vis ska användaren bli bekvämare i just den situationen som återspeglas i simuleringen.

Produkten ska kunna redovisas och demonstreras i slutet av kursen TDDD96.

1.4

Frågeställning

Projektet medförde följande frågeställningar som skulle svaras på:

1. Vilka val har tagits för att systemet ska hjälpa personen att bli mer bekväm att hålla presentationer?

2. Vilka erfarenheter har vi fått som är överförbara till framtida projekt? 3. Vad har systemanatomin haft för inverkan på projektet?

1.5

Avgränsningar

Systemet kommer att, på kundens begäran, baseras på HTC Vive för att simulera miljöer för att hålla presentationer. Svenskt tal och skrift i simuleringen kommer att prioriteras över andra språk, såsom engelska.

Kapitel 2

Bakgrund

Bakgrunden till projektet ligger i att många individer i samhället går genom sitt liv med stress och ångest inför situationer som genomförande av en presentation framför kollegor eller andra människor [2]. Då situationer som dessa är svåra och krävande att öva på har SurVive blivit kontrakterade av Therese Kristoffer Publishing AB för att modellera ovan nämnda situation med fokus på studenter i en virtuell miljö. I den virtuella miljön finns det möjlighet för användaren att själv kunna öva i en säker miljö, där omgivningen ska kunna förändras i både storlek och interaktionsgrad. På så sätt ska användaren få uppleva och känna känslan av att lyckas med att hålla en presentation.

VR-modelleringar är ett oerhört nytt forskningsområde inom datavetenskapen, vilket gör att det är svårt att hitta forskning som beskriver hur miljöer ska modelleras. Det ser även ut att området är på väg att växa vilket är väldigt lovande inför framtiden för VR. Då priset för VR-relaterade produkter fortfarande är relativt högt för gemene person förutses det att när utbudet ökar kommer det bli billigare för gemene person att köpa VR-relaterade produkter. [6]

Kapitel 3

Teori

I det här avsnittet beskrivs arbetsmetodik, verktyg och ramverk som använts under projektets gång.

3.1

Unity

Unity är en plattform för att skapa spel och applikationer i 2D och 3D med stöd för VR. Plattformen inkluderar både en grafisk redigerare för miljöer och animationer samt ett kod-bibliotek för att skriva egen logik. Det går även att kompilera spel till flera olika plattformar så som Android, iOS, Windows och OS X. Unity:s utvecklingsmiljö är begränsad till Win-dows och OS X. Unity är idag en av de vanligaste spelmotorerna för att skapa mobilspel och fram tills det tredje kvartalet år 2016 hade cirka 5 miljarder Unity-spel laddats ner. [7] Vidare ställer Unity en mängd krav på hårdvaran för att kunna exekvera vad Unity beskriver som en generell produkt utvecklad i Unity. Kraven följer enligt nedan:

• Grafikkort – DirectX 9 shader modell 3.0 eller DirectX 11 med GPU funktionalitet på nivå 9.3. [8]

• CPU – Stöd för SSE2 (Streaming SIMD Extensions) instruktionsuppsättning. [9] Unity stödjer fortsättningsvis nedanstående operativsystem av version enligt nedan eller se-nare versioner:

• Windows XP SP2. • Mac OS X 10.8. • Ubuntu 12.04. • SteamOS.

Vidare till hur kraven för utveckling i Unity. Följande hårdvara krävs: grafikkort – DirectX 9 shader modell 3.0 eller DirectX 11 med GPU funktionalitet på nivå 9.3. [8] Sedan stöder Unity utveckling på operativsystemen Windows XP SP2 och Mac OS X 10.8 eller senare versioner av de uppräknade operativsystemen. [10]

3.2

Node.js

Node.js är en variant av JavaScript som är tänkt att användas för att exekveras på servrar. Den är baserad på Googles V8-motor där fokus ligger på att hålla hög prestanda med låg minnesförbrukning. Programspråket är eventbaserat och det ligger redan implementerat på språknivå till skillnad från andra programspråk där bibliotek måste användas för att kunna utnyttja den eventbaserade modellen. [11]

3.3. Scrum

3.3

Scrum

Scrum är en projektstyrningsmetodik, skapad av Jeff Sutherland och Ken Schwaber. Termen Scrum kommer ursprungligen från sporten rugby, där Scrum syftar till ett tillfälle där bollen ska sättas i spel. Allt detta har sedan översatts till en agil, iterativ samt inkrementell utveck-lingsmetodik.

Figur 3.1: Grafisk illustration av arbetsmetodiken Scrum [12].

Nedan kommer viktiga begrepp inom Scrum förklaras.

• Backlog – En prioriterad lista av aktiviteter för att underhålla, färdigställa och vidare-utveckla produkten.

• Burn-down-graf – Ett diagram som visar aktiviteter eller timmar kvar på projektet. • Dagligt Scrum – Ett möte som startar arbetsdagen och behandlar kommande och utfört

arbete.

• Sprint – Längden av en iteration.

Dessa termer ovan är några av de mest frekvent använda termer inom Scrum-relaterat arbete. Arbetsflödet i Scrum går ut på att man skapar en product backlog av alla aktiviteter som finns i projektet. Från product backlogen så skapar man en sprint backlog med de viktigaste aktiviteterna. En sprint pågår sedan i en till fyra veckor med dagliga små sprintar. Allt detta pågår till man har en fungerande produkt. Detta arbetsflöde har visualiserats i figur 3.1. [13]

3.4

Flask

Flask är ett mikroramverk till programspråket Python som är baserat på Werkzeug. Det är tänkt att användas som en enkel variant till en back-end för en webbplats. Direkt från installation av ramverket så finns det stöd för bland annat enhetstestning, REST-API, säkra kakor samt Web Server Gateway Interface[14].

3.5. MySQL

3.5

MySQL

MySQL är en relationsdatabas som använder sig utav det standardiserade programspråket SQL för att hämta och modifiera data [15]. MySQL är väldokumenterat och har öppen käll-kod.

3.6

eXtreme Programming

eXtreme Programming (XP) är en agil utvecklingsmetodik vars fokus ligger på produktivitet och att kundens krav gått till mötes. Hela processen går ut på att producera det kunden behöver, beställt och inget extra. Där stor flexibilitet för dokumentation har tillhandahålls för denna utvecklingsmetodik jämfört med äldre utvecklingsmetodiker så som vattenfalls-modellen. eXtreme Programming:s kärna ligger i dess utomordentliga förmåga att väva in testdriven utveckling som sitt främsta vapen för att utveckla högkvalitativ kod. En vital del av eXtreme Programming är parprogrammering, vilket går ut på att två utvecklare samar-betar vid samma dator, för att i sin tur producera mer lättläslig kod samt sprida kunskap mellan kollegor. [17] Vidare kräver också eXtreme Programming att utvecklarna använder sig av kodinspektioner för att säkerställa kvalitén på nyutvecklad kod. Kodinspektioner är nära sammankopplat med testdriven utveckling, då det tillåter automatiska enhetstester att exekveras och evalueras innan koden push:as till projektets repository. [1]

Kapitel 4

Metod

Detta kapitel beskriver hur arbetet förts framåt med hjälp av bestämda metoder och verktyg.

4.1

Metoder & verktyg

För hantering av grafik valdes spelmotorn Unity enligt följande resonemang:

• Unity fanns redan installerat på arbetsdatorerna och flera kontaktpersoner på institu-tionen hade erfarenhet av Unity.

• Unity har stöd för många olika VR-headsets, så som HTC Vive och Oculus Rift. • De flesta av projektgruppens medlemmar hade inte någon erfarenhet av spelmotorer

vilket gjorde att valet av spelmotor hade mindre betydelse.

Att arbetsstationerna som kunden bidrog med redan hade Unity installerat samt att gruppen kunde fråga kontaktpersoner om råd kring Unity bedömdes uppstartstiden för projektet minska. Detta bedömdes vara av särskild vikt då gruppen inte hade någon tidigare erfaren-het av spelmotorer, vilket annars skulle kunnat minska uppstartstiden.

För att välja utvecklingsmetodik så förespråkades det i en tidigare kurs att använda sig av agil utvecklingsmetodik såsom Scrum och eXtreme programming. En annan anledning till att välja dessa var att gruppen hade intresse för att testa dessa utvecklingsmetodiker. Flask var till en början det primära ramverk i projektet för att sedan bli utbytt mot No-de. Anledningen till att Flask valdes som ramverk var till en början på grund av tidigare erfarenheter av det från tidigare projekt. Detta val gjordes av bekvämlighetsskäl. Node kom in i projektet av intresset och engagemanget för att lära sig nya tekniker och ramverk. Det berodde alltså inte på att till exempel Flask var otillräckligt för de behov projektet ställde. Node och Flask är väldigt liknande varandra och förflyttningen från Flask till Node var väldigt smidig just på grund av detta.

Motiveringen som ligger till grund för användningen av MySQL var att projektgruppen hade tidigare erfarenheter kring MySQL.

4.2

Utvecklingsmetodik

Under förstudien bestämdes det att projektets utvecklingsmetodik skulle grunda sig i en lättare kombination av Scrum och eXtreme Programming. Fördelarna med metodikerna

4.3. Metod för att fånga erfarenheter

Programming valdes parprogrammering och kodinspektion som huvudsakliga metoder [16]. Denna kombination av utvecklingsmetodiker valdes att kallas sXream Programming, vilket uttalas Scream Programming.

Efter kontinuerliga möten med kunden togs en kravspecifikation fram och med hjälp av den kunde ett antal milstolpar definieras. Dessa bröts sedan ner i mindre aktiviteter som kunde tidsuppskattas och lades in i en tidsplan över tre iterationer. Eftersom Scrum använ-des så illustreraanvän-des en backlog i Trello.

För att behålla en struktur och säkerhet bland filerna har GitHub använts för versions-hantering. I GitHub har pull requests aktiverats för att få kodinspektioner att bli ett krav. Detta för att koden ska hålla hög kvalitet när den ska slås ihop med master-grenen. Utöver hög kvalitet ger kodinspektion en inblick i koden för gruppmedlemmarna som inte deltog i utvecklingen av den pull request:en.

Minst ett gruppmöte hölls varje vecka för att se hur arbetet gått sedan föregående möte samt vad som skulle göras inför kommande möte med hjälp av Trello-korten. Gruppens tidsåtgång med aktiviteterna lades in i en burn-down-graf för att se hur väl tidsplaneringen följs. Om problem och ovissheter inte kunde lösas snabbt via Slack gicks de igenom under mötena. Planerade möten, arbetstillfällen och övriga relevanta kursmoment lades in i en gemensam kalender.

4.3

Metod för att fånga erfarenheter

Med tanke på gruppmedlemmarnas olika kompetenser inom olika områden har flera utbild-ningsseminarier ägt rum för att lära ut kunskap till gruppen. Parprogrammering har också använts som verktyg för att jämna ut kunskapsklyftorna. Paren som jobbat tillsammans har skiftats med jämna mellanrum för att få erfarenhet av att arbeta med olika personer och för att få inblick i andras arbetsgång [17].

Vidare hade gruppen möten minst två gånger per vecka, där aktuella problem togs upp till diskussion. Fortsättningsvis fördes protokoll på dessa möten för att dokumentera besluts som fattas samt vederbörandes föregående och in planerade arbete.

En lättare variant av iterationsutvärderingar har också utförts av gruppen, dock inte på ett formellt möte utan mer i ett öppet klimat parallellt med det vanliga arbetet.

Kapitel 5

Resultat

I detta kapitel ges en översikt över vad som uppnåtts i projektet. Detta innefattar en be-skrivning av hur produkten har utvecklats, bebe-skrivningar kring frågeställningarna samt vad gruppen har gjort för att göra utvecklingen hållbar.

5.1

Systembeskrivning

Systemet består av två delsystem, simulatorn i Unity samt webbservern. Dessa behandlas i varsitt avsnitt i detalj om vad de är uppbyggda av och hur de fungerar.

5.1.1

Systemanatomi

I projektets början skapade projektgruppen en systemanatomi som en obligatorisk del av kur-sen TDDD96. Denna visas i figur 5.2. Anatomin togs fram för att strukturera upp systemets förmågor och beroenden, de användes som stöd för att skapa andra arkitektoniska doku-ment. Exempel på detta är figur 5.1, som skapades för att komplettera systemanatomin.

5.1. Systembeskrivning

5.1. Systembeskrivning

Figur 5.2: Illustration av systemanatomin för systemet.

Gruppen fick användning för systemanatomin främst som ett tidigt hjälpmedel i början av projektet för att få en gemensam uppfattning av vad systemet kommer att bero på och krä-va. Den användes även som ett hjälpmedel för att specificera krav som skulle uppfyllas och aktiviteter för att uppnå dessa krav. Aktiviteterna ersatte sedan systemanatomins roll som förmedlare av systemets struktur och implementation. Systemanatomin har således haft som inverkan att få samtliga gruppmedlemmar att snabbt förstå hur systemet skulle se ut.

5.1.2

Unity

Unity har bra stöd för funktioner som projektet behöver i form av att skapa grafiska VR-miljöer, hantera spelobjekt och verktyg som förenklar möjligheten till att utvinna mätdata. Det medför att Unity har blivit en grundpelare i projektet. I Unity har en grafisk miljö skapats med spelobjekt som kan förändras under sessionen och det har även skrivits kod för att samla in data över användandet av systemet.

Grafisk miljö

Den miljö som simuleringen utspelar sig i ska efterlikna ett klassrum, se figur 5.3. I klassrum-met finns föremål som alla är modellerade i Blender, så som projektor, klocka, bord, stolar, lampor och fläktar. Studenterna är skapade med hjälp av MakeHuman och där skapas även det ”skelett” som används vid animering i Unity. Exempel på en av modellerna som ska-pats med MakeHuman för simuleringen kan ses i figur 5.4. På samma sätt har två större rum skapats som är tänkta att efterlikna föreläsningssalar, se figurer 5.5 och 5.6.

5.1. Systembeskrivning

Figur 5.3: Grafisk miljö som ska efterlikna ett klassrum.

5.1. Systembeskrivning

Figur 5.5: Grafisk miljö som ska efterlikna en föreläsningssal.

5.1. Systembeskrivning

Interagera med miljön - Beteende

Beteende är det namn på hur studentmodellerna interagerar i den grafiska miljön. Saker som när, var och i vilken kontext olika animationer spelas upp klassas som beteende.

Figur 5.7: Arvsträd över olika beteenden, där pilar visar arv från grundobjekt till ärvande objekt.

Strukturen för hur olika studenter beter sig är organiserat i en trädstruktur som visualiseras i figur 5.7. Alla agenter som har klassen Ambient inkluderar grundläggande beteenden som till exempel blinka, hosta, klia sig. Mer specifika beteenden som till exempel att somna är begränsat till klassen Sovande.

Klassen Student designades som en agent, där en handling agenten kan utföra är till exempel en animering, att titta på spelaren eller att räcka upp handen. Dessa handlingar har i sin tur vikter som används för att skapa en sannolikhetsfördelning över alla handlingar. Varje gång en handling är utförd i sin helhet slumpas en ny handling fram utifrån sannolik-hetsfördelningen. Detta skapar då livscykeln för en handling, då denna procedur upprepas till simuleringen avslutas.

Det finns två olika typer av handlingar i systemet: animeringshandlingar och kodhandlingar. En animeringshandling spelar bara upp animeringen som tilldelats till den. Kodhandlingar kör den kod som definierar handlingen, till exempel att titta på användaren. Separationen av handlingarna behövdes då användaren kan flytta på sig i simuleringen medan handlingen för att titta på användaren körs. Ytterligare ett exempel på en kodhandling är handlingen att göra ingenting en viss tid, som används för att skapa mer levande beteenden genom att inte spela animationer hela tiden.

Animationer

För att minimera det annars tidsomfattande arbetet med att skapa animationer så importera-des en del av animationerna från Mixamo. Det är grundläggande animationer som till exem-pel att gå och att sätta sig ned. För de mer specifika rörelserna har egna animationer tagits fram med de verktyg som finns tillgängliga i Unity. Exempel på animationer som har skapats är att blinka, gäspa, nicka och lägga sig ner på bordet. Animationerna har sedan kopplats ihop med Unity och de beteenden de hör till.

5.1. Systembeskrivning

Interaktion

Interaktion i simuleringen använder sig av HTC Vive:s handkontroller och headset för att samla in följande data:

• Vad användaren tittar på.

• Vad användaren pekar på för objekt.

• Hur användaren rör på sina händer och huvud.

Det är denna data som sedan kommer att ligga som grund till statistiken av användandet. Exempel på statistik som systemet kan ge är hur ofta användaren svarar på frågor, hur mycket användaren rör på händerna samt hur stor andel av tiden som lades på att titta på olika saker. Data så som positionen på handkontrollerna och huvudet samlas in genom att först kolla om handkontrollen eller headsetet i fråga har rört sig över ett tröskelvärde. När användaren rör på sig kommer datapunkter samlas in tio gånger per sekund.

För att mäta vad användaren tittar och pekar på kommer både tiden som man tittade på typen av objekt samt antalet gånger man tittat på objekttypen sparas. Tiderna kan sedan jämföras med varandra och den totala speltiden för att ge en bild över vad användaren har interagerat med under sessionen. Systemet har stöd för att spara rörelsemönster för vissa objekt, till exempel att följa efter en student med blicken.

Nätverk

För att lagra data om användandet efter sessionens avslut så skickas data till databasen. För detta behövdes en nätverksmodul som kan hantera anrop till servern och ta emot svar från den. Modulen sköter inloggning av användaren och uppladdning av statistiken till servern och använder sig av HTTP-standarden för förfrågningar till servern. För att logga in, logga ut, skapa konto och skicka statistik används POST-anrop till servern. Anropen till servern har samma struktur som anropen från webbsidan. I vissa fall ska en presentation laddas in i simuleringen och då hämtas den från servern med hjälp av ett GET-anrop. Unity:s inbyggda bibliotek, Unity.Networking.UnityWebRequest, användes för samtliga HTTP-anrop. Personliga presentationer

En viktigt del av simulationen är möjligheten av importera en personlig presentation till si-mulationen. Där användaren kan praktisera sin egna prestation i simulationen för att maxi-mera förberedelsen för användaren.

5.1.3

Webbserver

En del i projektet var att kunna visualisera statistik från simuleringar. För att enkelt genom-föra detta samt representera den mätdata som erhålls, används en webbserver. Webbservern kan i sin tur beskrivas som två delar: en back-end och en front-end.

Back-end

Back-end består huvudsakligen av två delar: en MySQL-databas och ett skal skrivet i Node.js för anrop till databasen. Databasen innehåller information om registrerade användare och håller även koll på inloggade användare. Skalet används för att kunna ta emot anrop som sker när användaren interagerar med front-end och presenterar information ur databasen.

5.2. Gemensamma erfarenheter: Vilka erfarenheter har vi fått som är överförbara till framtida projekt? Front-end

Front-end består av en webbsida som är skriven i HTML och JavaScript. Beroende på vilken del av webbsidan som användaren interagerar med kommer olika data att skickas och erhål-las från back-end. Varje användare har ett eget konto på servern som används för att logga in och se data från olika sessioner. Inloggning på webbplatsen visas i figur 5.8 och en tidig version av hur data presenteras på webbsidan visas i figur 5.9.

Figur 5.8: Inloggningsfönster på webbsidan.

Figur 5.9: En tidig version av hur mätdata presenteras på webbsidan.

5.2

Gemensamma erfarenheter: Vilka erfarenheter har vi fått som är

överförbara till framtida projekt?

Detta avsnitt ämnas att presentera några av de erfarenheter som gruppen fått. Detta inklude-rar positiva erfarenheter kring arbetet samt några av de problem som gruppen stött på.

5.2.1

Teambuilding

Ett skäl till att gruppen fungerat så bra tillsammans har varit att gruppen känt sig som ett team. Detta tros ha påverkats av gruppens alla gemensamma aktiviteter vilket till exempel är grilldag, utelunch och tårtfika. Under projektet så har gruppen fått tillgång till en lokal vilket har blivit en naturlig samlingsplats för alla att arbeta i och har gjort att gruppen har kunnat dela erfarenhet och att be varandra om hjälp.

5.2.2

Animationer

Ett stort tekniskt bekymmer som uppstod under projektet vara animationer av 3D-modeller. Till en början visade det sig vara alldeles för tidskrävande att skapa alla animationer för hand, varpå några gratisanimationer från Mixamo användes. Det uppstod dock problem kring hur animeringssystemet i Unity fungerade, vilket ledde till att mycket tid i början av projektet las på att få animationer att fungera. Gruppen insåg även att arbetet för att få alla animeringar

5.2. Gemensamma erfarenheter: Vilka erfarenheter har vi fått som är överförbara till framtida projekt? att se perfekta ut skulle ta mycket mer tid än vad det kunde ge. Istället skapades en separat aktivitet för att förbättra animationerna senare i projektet, i mån av tid.

5.2.3

Sen ankomst

För att motverka sen ankomst infördes en kassa för fikapengar. Varje gång en person kommer sent utan god anledning till ett möte behöver den tillföra pengar i kassan. Reglerna var att om personen kommer mellan en och tio minuter försent får den en skuld på tio kronor. För varje ytterligare tio minuter sent ökar skulden med tio kronor med ett tak på 50 kronor per möte. Trots detta så har projektgruppen haft vissa problem med att flera personer kommer sent till möten. Vid flera möten togs det upp att gruppmedlemmar blev irriterade på personer som inte var i tid men trotts detta vid togs inte några åtgärder. Ur detta utvinns erfarenheten om att det är problematiskt med sen ankomst samt svårhanterat.

5.2.4

Datorproblem

Ett problem som uppstod under projektets gång var att det inte fanns tillräckligt många da-torer i arbetsrummet. Detta tillsammans med att en av simuleringsdada-torerna inte gick att använda på grund av störande fläkt vilket skapade brist av arbetsstationer i lokalen. Proble-met löste sig genom att några i gruppen hade bärbara datorer som klarade av att köra Unity och att alla inte behövde arbeta i Unity. Den erfarenhet som skapades av detta problem var insikten av att det finns ett maximalt antal personer som kan arbeta vid samma datorplats. Parprogrammering löste detta problem för de som satt vid de större skärmarna men inte för de som arbetade på laptops. Skärmarna på dessa upplevdes som för små för att sitta mer än en person kring.

5.2.5

Git

Under projektets gång har gruppens samlade och individuella erfarenheter kring Git förbätt-rats markant. Vid starten av projektet använde gruppen sammanlagt tre grenar för att arbe-ta på. Det som skedde vid försarbe-ta demonstrationstillfället var att all utvecklad funktionalitet skulle integreras ihop till en fungerande simulering. Det resulterade i sin tur att en demon-strationsförberedelse gren skapade. Den grenen blev sedan kvar efter demonstrationen som en sekundär master-gren som flera jobbade på. Detta gav upphov till att den grenen aldrig blev färdigutvecklad och stoppade då effektivt gruppens förmåga att utföra pull request. Det problemet hanterades genom att under en tvådagarsperiod införa en feature freeze och enbart bearbetat redan utvecklad funktionalitet till att nå en tillräcklig nivå för att bli accepterad in i master-gren via en pull request.

5.3. Vilka val har tagits för att simuleringen ska hjälpa personen att bli mer bekväm?

Händelsen resulterade i att gruppen hädanefter implementerade en bättre Git-användning. Där en aktivitet ur backlog:en som ska arbetas med grenas av från master-grenen till en aktivitetsgren för att sedan när aktiviteten är färdigställd slå ihop aktivitetsgrenen med master-grenen. Detta för att säkerställa att master-grenen är kontinuerligt uppdaterad med ny testad och kommenterad kod.

I slutskedet av projektet hade gruppen nått en bra mogenhetsnivå i Git-användandet och arbetsflödet som illustreras i figur 5.10. Figuren är färgkodad för att tydligare beskriva hur olika grenar hör ihop. Gula pilar representerar en utcheckning av en gren till en annan och svarta pilar att man slår ihop aktivitetsgren till submodulgrenen. Detta arbetsflöde är precis det som beskrivs av Atlassian [18].

5.3

Vilka val har tagits för att simuleringen ska hjälpa personen att bli

mer bekväm?

Människorna i simuleringen är skapade för att vara lite ”dumma” men samtidigt levande. Tanken med att göra lite dumma studenter är att simuleringen inte ska vara för verklig. Om en simulering är för verklighetstrogen kommer användaren att upptäcka varje liten sak som avviker från den riktiga världen. Det är viktigare att skapa en levande simulering för att hjälpa personen att bli mer bekväm [19].

Ett försök att kunna hjälpa användaren att bli bättre är att samla in användardata under simuleringen. Den data som samlas in analyseras sedan och visas både i form av grafer samt uppmaningar som ska hjälpa användaren prestera bättre vid nästa tillfälle [20].

Alla personer är olika bekväma med att hålla en presentation. Därför kan simuleringen anpassas efter den svårighetsgrad som användaren vill ha. Personer som tycker det är krä-vande att hålla en presentation kan börja med en liten sal med få störande moment. När personen känner sig mer bekväm finns det möjlighet att öka storleken på rummet samt öka antalet störande moment. Moment som anses som störande är antalet frågor användaren får, antalet åskådare eller bakgrundsljud från till exempel fläktar.

5.4

Hållbar utveckling

Här listas några beslut som togs under projektets gång för att upprätthålla en god och hållbar struktur kring projektet:

• Stänga av datorerna och släcka lamporna när vi inte är i arbetsrummet.

• Maximal tid för användning och varna användaren när hen har suttit för länge. • Digitala manualer och inte fysiska vid stationen.

• Färre interaktioner mellan webbservern och Unity gör det mer energieffektivt. Dessa punkter är åtagande som gruppen har använts för att öka hållbarheten.

Kapitel 6

Diskussion

I detta kapitel diskuteras resultaten, metoderna samt hållbarhetsaspekten hos arbetet och produkten. Detta inkluderar diskussioner kring det egna systemet och metoden kring ut-vecklandet samt alternativ som är värda att betrakta.

6.1

Resultat

Presentationens bilder samt egna anteckningar skulle laddas in i simuleringen för att ge så bra stöd för en redovisning som möjligt. I nuläget konverteras en PDF av presentationen och anteckningarna till JPEG-bilder i simuleringen som sedan kommer att renderas, då Unity inte har stöd för att rendera PDF:er direkt. Detta kunde ha gjorts på ett annat sätt genom att istället för att konvertera PDF-filen så kunde man ha lagt ner mer tid på att hitta ett eller ut-veckla ett eget PDF-renderingsprogram som kunde användas i simuleringen. Konsekvensen av detta har varit att konverteringen från PDF till JPEG-bilder tar tid, vilket skulle behöva förbättras.

Ett annat val som gjordes i projektet var att systemet skulle visa användarens statistik på en webbsida, där användaren kan få råd om förbättringsmöjligheter. Ett annat alternativ hade varit att visa detta efter en session i simuleringen och ge råd om förbättringsmöjligheter. Varför en systemanatomi gjordes var på grund av att det ingick som obligatoriskt mo-ment i kursen TDDD96. Gruppen specificerade senare en systemöversikt som var mer detaljerad och som hjälpte ytterligare med att ta fram aktiviteter. Användandet av just en systemanatomi kan ha varit överflödigt, särskilt om man senare skapar andra dokument för att komplettera anatomin.

Vid leverans har majoriteten av kraven på systemet uppfyllts men det finns många för-bättringsmöjligheter. För att produkten ska bli bättre kan en större analys av användardata utföras. Då kan mer och, förhoppningsvis, bättre återkoppling ges till användaren. Simule-ringen kan göras mer verklighetstrogen genom att förbättra både ljud och grafik. På grund av okunskap och saknad av utrustning har ljudfilerna som spelas upp under simulering varierande kvalitet.

6.2

Metod

I detta avsnitt diskuteras de viktigaste metoderna som valdes att användas i projektet. Detta med fokus på vad för konsekvenser valet kom med uppföljt av en diskussion kring

alternati-6.3. Vilka val har tagits för att simuleringen ska hjälpa personen att bli mer bekväm?

6.2.1

Användandet av Unity

Ett av de tidigaste valen gruppen hade var valet av spelmotor. Gruppen visste att en spel-motor skulle behövas för att färdigställa kundens produkt och då stod valet mellan Unity eller Unreal Engine. Unity valdes som grund för simuleringen för att arbetsstationerna som kunden bidrog med hade Unity samt att en gruppmedlem hade erfarenhet av Unity.

När Unity valdes som grafikmotor så uteblev alla andra alternativ eftersom det är myc-ket omständligt att byta spelmotor för att man då behöver skriva om mycmyc-ket kod. Även om det är omständligt att byta spelmotor så ska det inte vara någon omöjlighet att byta till Unreal Engine [21]. Detta för att det finns flera likheter i uppbyggnaden och det medför att ett byte är möjligt. Att gå från Unity till Unreal Engine verkar vara det enda bytet av spelmotor som har en guide för hur man skulle kunna gå till väga. Det tyder på att andra spelmotorer har större skillnader och är betydligt mycket omständligare att byta till. Eventuella konsekvenser av att projektet är låst till Unity är dess beroende på Unity:s fortsatta utveckling av grafikmo-torn. Under utvecklingen av detta projekt utnyttjades Unity:s licensvillkor som innebär att spelmotorn kan används gratis för projekt med liten omsättning. Om Unity väljer att ändra sin hantering av licenser skulle det kunna innebära att projektet inte kan få någon vidare utveckling på grund att det inte finns pengar till en licens.

6.2.2

Skapandet av animationer

I nuläget är många av de animationer som används av studenterna inte så levande som hövs för att skapa en bra upplevelse. De animationer som laddades ner från Mixamo be-dömdes vara levande, men gruppens egna animationer var inte. Detta kan ge upphov till en konflikt i vad användaren kan förvänta sig. Ett alternativ till att göra alla animationer för hand vore att istället använda sig av Inverse Kinematics, vilket skapar animationen givet en startpose och en slutpose. Förutom att detta hade underlättat arbetet med animationer hade det gett ett mer konsekvent utseende hos studenternas beteenden. Detta tros kunnat öka hur levande studenterna i simuleringen upplevs. Det hade även kunnat ge en mer realistisk si-mulering, då Inverse Kinematics även kan användas för att se till att studenterna sitter ner på föremål i miljön.

6.2.3

Användandet av Node.js

Att använda Node för att skriva back-end var ett väldigt enkelt val. Det grundade sig i att projektgruppen ville prova ett nytt programspråk som ingen hade använt sig av tidigare, men samtidigt ett programspråk som inte är för okänt. Att använda ett nytt programspråk är nog inte det absolut bästa att göra om man vill uppnå resultat snabbt. Men då detta är i utbild-ningssyfte och vi vill lära oss nya programspråk och tekniker så valdes Node att användas för detta.

6.3

Vilka val har tagits för att simuleringen ska hjälpa personen att bli

mer bekväm?

Studenterna i simuleringen är skapade för att verka levande men lite ”dumma” eftersom det går åt mycket resurser för att ha realistiska modeller för studenterna. Det bedömdes att detta var alldeles för belastande för att vara en möjlighet. En hypotes har inom gruppen formulerats med hjälp av handledare understödd av Uncanny Valley-teorin [24] på följande vis: en vacker grafisk modell av studenterna skulle kräva mer utförlig interaktion mellan studenterna och användaren för att skapa en illusion av verkligheten. Enligt hypotesen skulle det inte tjäna något syfte att ha en realistisk grafik om miljön inte beter sig realistiskt. Det skulle leda till en konflikt mellan vad användaren ser och vad användaren förväntar sig

6.4. Gemensamma erfarenheter

hända. Att istället använda människoliknande modeller som verkar levande skulle det enligt hypotesen skapa en bättre upplevelse för användaren. Då förväntningar på hur realistiska studenterna i simuleringen beter sig kommer vara lägre.

Ett alternativ till de nuvarande modellerna och animationerna hade varit att satsa på mer realistiska modeller och animationer. Kravet för det blir att hårdvaran dels kan exekvera systemet med den ökade belastningen samt att animationerna ser mer realistiska ut. För att uppnå detta kan animationer skapas från rörelsemönster istället för att skapas för hand. Då skulle variationen hos studenterna komma ifrån att spela in många personers rörelsemönster och då inte bara baseras på modellens utseende.

Med hjälp av den data som samlas in kommer förbättringsförslag ges till användaren och statistik över användningen presenteras. Om förbättringsförslagen inte är rimliga, eller om statistiken som visualiseras inte förstås kommer det inte hjälpa användaren att se vad som kan förbättras med presentationen. Vidare är det viktigt att systemet genererar förbätt-ringsförlag som tolkas på ett passande sätt. Detta för att förmedla förbättringsförslag på ett konstruktivt sätt till användaren.

Simuleringen kan anpassas efter den svårighetsgrad som användaren vill ha genom att justera hur miljön ser ut. Användaren kan till exempel justera hur mycket publiken inte-ragerar med användaren, publikens storlek samt rummets storlek. Detta ger användaren möjlighet till att skapa lämpliga scenarion anpassade för användarens behov. Detta i jäm-förelse med att bara erbjuda ett scenario tros göra upplevelsen mindre ansträngande för användaren, då användaren har kontroll över hur scenariot ska se ut och hur det ska spelas upp.

6.4

Gemensamma erfarenheter

I detta avsnitt diskuteras några av de främsta erfarenheterna gruppmedlemmarna fått kring arbetet och utvecklandet av produkten som är överförbara till framtida projekt.

6.4.1

Sen ankomst

Tanken med en fikakassa var att den skulle motverka sena ankomster till viktiga händelser, men det är oklart hur bra det fungerade. Kassan innehöll mer än 1000 kronor vid projektets slut. Erfarenheter som kan dras av detta är att fikakassan behöver ha en annan struktur för att det ska motverka sena ankomster. En till anledning till att fikakassa inte fungerade så bra kan vara att när man kan betala för att man är försenad så har man redan blivit bestraffad och behöver därför inte känna någon skuld. Men om man inte behöver betala något så har man inte blivit bestraffad och kan då känna mer skuld.

En förbättringsmöjlighet hade varit att göra avgiften större, så att det skulle kännas vär-re om man kommer sent. En variation av detta förslag är att de första tio minuterna har en högre avgift än de övriga minuterna som överträds. Exempelvis skulle man kunnat ha en startavgift på 50kr de första tio minuterna följt av 10kr för varje extra tio minuter man är sen. Detta skulle kunna minska antalet förseningar som sker i början av ett pass utan att ge en i längden allt för stor avgift.

6.4.2

Varierande kunskapsnivå

6.5. Arbetet i ett vidare sammanhang

användes vid utveckling. Parprogrammering var tänkt att motverka detta, vilket det kanske gjorde, men inte i tillräckligt stor utsträckning. Parprogrammering utfördes inte hela tiden på grund av att det var praktiskt svårt tidsmässigt. Om gruppen hade varit mer flitig med par-programmering kunde båda de två problemen ha motverkats. Med mer parpar-programmering hade det blivit mindre tidsskillnad mellan gruppmedlemmarna samt att den genomsnittliga kunskapsnivå antagligen hade ökat.

Det fanns ingen underliggande tanke med att vissa arbetade mer tidigare i projektet än vad andra i gruppen gjorde. Utan något som inträffade för att några av projektmedlemmarna ville sätta igång hårdare i början än vad andra ville göra.

6.5

Arbetet i ett vidare sammanhang

Då samhället utvecklas och miljömedvetenheten ökar måste även mjukvarubranschen anpas-sa sig till desanpas-sa nya spelregler.

6.5.1

Samhällsaspekter

Systemet som utvecklats är tänkt att användas som ett utbildningsverktyg, en plattform för de som vill bli bättre på att presentera och redovisa inför en publik. Förhoppningen är att färre ska tycka att prata inför en publik är en krävande situation. Om fler finner sig bekväma med att tala inför andra får fler möjligheten att påverka allt från miljö och politik till att sälja produkter till kunder.

Systemet i sig kräver dock en beräkningskraftig dator förutom VR-headsetet i sig, vilket både kostar mycket och kan leda till en överkonsumtion av varor som inte kommer använ-das länge. Att systemet kostar mycket påverkar vilka som kan få möjligheten att använda det. Detta faktum förbättras om man kan få skolor, företag och kommuner att köpa systemet och att de sedan anordnar stationer med systemet istället för att varje privat användare behöver skaffa sig all utrustning som krävs. Detta hoppas även förhindra överkonsumtionen av utrustning som inte kommer användas senare, givet att en köpare som en skola eller ett företag, nyttja produkten mer effektivt.

6.5.2

Hållbar utveckling

Eventuella för- och nackdelar med de saker som togs upp under rubriken Hållbar utveckling under resultat kommer här att diskuteras.

• Stänga av datorerna och släcka lamporna när ingen är i arbetsrummet

Genom att stänga av datorerna och släcka lamporna efter ett arbetspass minskas ener-gianvändningen under utvecklingen. Många andra datorer på universitet stängs inte av när de inte används. Om det inte sitter någon vid datorn finns det inte någon an-ledning att den är på. Däremot kontrolleras stora delar av lamporna på universitet av rörelsedetektorer och det samma gäller lamporna i arbetsrummet. Intressant nog ver-kar rörelsedetektorn inte sitta i arbetsrummet utan i korridoren utanför. Det medför att lamporna i arbetsrummet tänds när någon går i korridoren om den inte stängts av med lysknappen.

• Maximal tid för användning och varna användaren när användaren har suttit för länge.

Genom att varna användaren för att ha spelat under en längre tid så kommer använda-ren att ta fler pauser. Detta tros förbättra koncentrationsförmågan och leda till en bättre träningsmiljö för användaren. Vilket kommer se till att användaren förbättras och blir mer bekväm i en snabbare takt. [22]

6.5. Arbetet i ett vidare sammanhang

• Digitala istället för fysiska manualer vid stationen

Genom att erhålla digitala manualer eller ha manualer på en webbsida så kommer ut-skrifter inte behöva göras. På detta sätt undviks behovet av att byta ut manualer när de blir för slitna eller när de blir utdaterade. Dessutom så sliter fysiska manualer mer på miljön då de skrivs ut på papper. Den kostnaden försvinner då genom att ha digita-la manualer eftersom att det inte behöver produceras papper och därmed inte bedigita-lasta miljön.

• Färre interaktioner mellan webbservern och Unity gör det mer energieffektivt Genom att ha färre interaktioner mellan webbservern och Unity så kommer projektet att förbruka mindre energi. Det kan ske genom att skapa större paket och skicka färre gånger istället för små paket och fler gånger. Under projektets gång används en server som var tillhandahållen av institutionen vilket då var en del av deras stor server. Det medför en energibesparing på cirka 10% när system konfigureras för att skicka mycket data vid få tillfällen. Trotts detta togs beslutet att skicka mycket data få gånger eftersom om system kommer i drift kan det ske på en extern server och då kan mer energi sparas. Eftersom när det inte kommer någon data kan serverns strömspararåtgärder användas. [23]

• Minska andelen människor som lider av social fobi

Ur ett social hållbart perspektiv har produkten som utvecklats en positiv effekt, fram-förallt under antagandet att produkten kommer i vida användning. Förhoppningsvis kommer användare av produkten att bli bättre och inte undvika att prata inför andra människor. Det innebär att fler kommer på ett bättre sätt att sprida kunskap i samhället och samhället blir mer upplyst. Produkten skulle kunna ha positiv effekt på kommuni-kation mellan enskilda människor också eftersom människor blir mer självsäkra.

Kapitel 7

Slutsatser

Produkten uppfyllde dess kravspecifikation och levererades till kunden efter några mindre justeringar. För att få systemet att hjälpa användaren med att bli bekvämare med att hålla presentationer utformades en publik som både känns levande med sina animationer och stel med sitt utseende, för att påminna användaren om att den är i en simulering. Användaren kan även välja storlek på publiken, hur mycket publiken interagerar med användaren och storleken på miljön för att ge användaren möjlighet att själv sätta svårighetsgraden på si-muleringen. Huruvida den färdiga produkten faktiskt gör skillnad för användare kan inte besvaras i denna rapport. För att kunna besvara denna fråga krävs en rapport som utvärderar användares presentationer före och efter de övat i simulatorn.

De viktigaste lärdomarna som gruppen tar med sig är:

• Tillgången till ett gemensamt arbetsrum och många gemensamma aktiviteter gör myc-ket för hur gruppen arbetar tillsammans.

• Om man har en straffavgift för att komma sent bör denna vara anpassad så att personer inte kommer sent, till exempel via högre avgift.

• Varierande kunskapsnivå i projektet kan jämnas ut genom att använda parprogramme-ring flitigt.

Systemanatomin har legat som grund för att formulera krav och aktiviteter och har använts som diskussionsmaterial när det gällde systemets design. Andra typer av dokument med liknande innehåll kan ha använts istället för en systemanatomi, som till exempel en system-beskrivning. Det viktiga med ett sådant dokument är att det finns och kan användas för att förmedla systemets design till alla i gruppen. Ett sådant dokument har för gruppen haft som inverkan att hela gruppen snabbt kunde förstå hur systemet skulle designas.

Sammanfattningsvis har en produkt utvecklats som förhoppningsvis kan hjälpa människor lindra sin fobi för presentationer. Projektet har medfört att medlemmarna i projektgruppen har införskaffat nya erfarenheter om områden mjukvaruutveckling i grupp, grafiska miljö-er för VR, utveckling av front-end och back-end samt utvecklingsmetodikmiljö-erna Scrum och eXtreme programming.

Som avslut på denna rapport önskar författarna att väcka intresse för området VR och framtida forskningsprojekt inom branschen.

Del II

7.1. Översikt individuella bidrag

7.1

Översikt individuella bidrag

Detta avsnitt beskriver kort vad de individuella bidragen kommer att behandla. A Skillnader i utveckling av REST-API i Node.js och Python

När utvecklingen av en webbplats ska göras så finns det många olika sätt att göra detta på. Denna del behandlar utvecklingen av ett REST-API på back-end sidan av webbplatsen. Vilket programspråk lämpar sig bäst för detta och vilka större skillnader finns det mellan dessa programspråk.

B Versionshanteringssystem vid grupparbeten

Det finns två stycken versionshanteringssystem, centraliserade och distribuerade, men vilket gynnar större grupparbeten? Detta individuella bidrag kommer att ge en överblick på dessa två system och sammanställa skillnaderna.

C En grupps utveckling under ett projekt

En projektgrupp är näst intill aldrig perfekt från början, utan den utvecklas under tiden grup-pens medlemmar arbetar tillsammans. Vissa grupper blir inte heller okej under ett helt pro-jekt. I detta bidrag gås det igenom hur just vår grupp utvecklas, från början till slut, i ett Scrum-liknande projekt.

D Jämförelse mellan komponenter och arv inom spelutveckling

För att kunna utveckla ett system som använder sig av Unity är det klokt att betänka designen av objekten som kommer att användas i simuleringen. Unity använder sig av en entitets-komponent-design istället för en traditionell arvsbaserad design. Alla i gruppen hade inte koll på vad detta innebar. Därför valdes det att skrivas om vad de är och vad de medför för arkitekturen och kodbasen samt hur de skiljer sig åt.

E Teamledarens roll i agil mjukvaruutveckling

I det här bidraget kommer teamledarens roll att diskuteras och analyseras genom projekts tre olika faserna; före, under, efter. Ett extra fokus på projektstyrningsteknikerna Scrum och eXtreme programming kommer även att inkluderas.

F Virtual Reality - Vad är verkligt

När man pratar om Virtual Reality, VR, så pratar man om virtuell verklighet. Det vill säga en virtuellt skapad värld som efterliknar den verkliga världen, men inte med samma konse-kvenser för hälsan som den verkliga världen kan ha. Men vad är det egentligen människor upplever som verkligt och hur lätt är det att lura hjärnan?

G Testning vid spelutveckling i Unity

Testning av mjukvara kan ske på många olika sätt. Unity har flera inbyggda verktyg som ska underlätta. Dessa verktyg beskrivs tillsammans med andra metoder som kan vara an-vändbara vid utveckling av grafiskt komplex mjukvara. Förslag hur testning utföra på när utveckling sker med grafikmotor Unity nämns.

7.1. Översikt individuella bidrag

H Påverkan av att skriva lokalt eller över cloud

På grund av att det ligger en sådan vikt i hur väl utförd projektets dokumentation är, är det viktigt att inte låta faktumet att hela gruppen deltar i skrivandet påverka kvaliteten på doku-mentet. Att se till att dokumenten upplevs som skrivet av en författare, även om det är flera individers bidrag. Enigheten i dokumenten är viktig för att läsaren inte skall behöva anpassa sig utefter skrivstilen som då kan skifta från stycke till stycke. Hur går man då tillväga för att enkelt skriva, korrekturläsa, och versionshantera dokument i grupper?

Bilaga A

Skillnader i utveckling av REST-API i

Node.js och Python

Författare: Anton Dalgren

A.1

Inledning

När en webbtjänst ska utvecklas kan det finnas många olika sätt att göra det på. Det vanli-gaste idag är ett system där tjänsten är uppdelad i två olika delar; front-end samt back-end. I det här kapitlet kommer skillnaderna mellan att utveckla ett REST-API i programspråken JavaScript samt Python för back-end delen att utredas.

A.1.1

Syfte

Syftet med denna rapport är att utveckla och visa på eventuella skillnader mellan de olika programspråken och ramverken som används för att utveckla ett REST-API, samt att reda ut vilket ramverk som passar bäst.

A.1.2

Frågeställning

1. Vilka större skillnader finns det mellan de olika programspråken? 2. Vilket programspråk lämpar sig bäst för utveckling av ett REST-API?

A.2

Bakgrund

Det finns idag många olika sätt att bygga ett REST-API på med många olika ramverk i väldigt många olika språk. Hur ska man gå tillväga för att välja ett ramverk som passar just det specifika projektet? Denna rapport kommer att behandla två olika sätt att göra detta på.

A.3

Teori

JavaScript är ett dynamiskt och svagt typat skriptspråk som körs i webbläsaren för att modi-fiera HTML-element vid anrop [25]. Node.js är baserat på JavaScript men har skrivits om till att kunna exekveras på en server istället för enbart i webbläsaren. Detta bidrar till att utveck-laren bara behöver kunna ett programspråk för att kunna arbeta hela vägen från back-end till front-end [11]. Likt JavaScript är Python också ett dynamiskt svagt typat skriptspråk som är skapat för ett användande inom generell programmering [26].

A.4. Metod

Begreppet RESTful Web Services används ofta inom webbutvecklingen. REST står för Re-presentational State Transfer, vilket är en IT-arkitektur för att beskriva maskin-till-maskin kommunikation. Inom en webbtjänst används ofta en back-end som är representerad i form av ett REST-API. Front-end sidan gör ett HTTP-anrop till back-end och får ett svar som oftast är av den struktur som ett JavaScript-objekt har, kallat JSON.

Tabell A.1: Exempel på HTTP anrop till ett REST-API innehållande studenter

Adress Metod Operation

/Student GET Hämtar alla studenter

/Student POST Skapar en ny student

/Student/<StudentID> GET Hämtar en specifik student /Student/<StudentID> PUT Uppdaterar en specifik student /Student/<StudentID> DELETE Tar bort en specifik student

I ett HTTP-anrop till ett REST-API används oftast de vanliga metoderna GET, POST, PUT och DELETE. Dessa metoder berättar för ett REST-API vad den ska utföra för operation på den inkommande adressen. I tabell A.1 finns ett exempel listat på vad ett REST-API gör vid de olika HTTP-metoderna till en specifik adress [27].

A.4

Metod

Denna rapport kommer att beskrivas mestadels med information från artiklar samt doku-mentation som beskriver hur de olika programspråken fungerar. Dokudoku-mentation kring de olika ramverken kommer att stå till grund för resultatet. Det kommer även att förekomma reflektioner kring vissa delar i de olika programspråken och ramverken som kommer att tas upp.

A.5

Resultat

Här kommer information om och skillnader mellan de två olika programspråken Node och Python, samt ramverken Express och Flask att presenteras.

A.5.1

Node.js

Node är baserat på Googles V8-motor som till största del är skrivet i C och C++ där fokus ligger på att hålla hög prestanda med låg minnesförbrukning. V8-motorn är tänkt att använ-das till att köra JavaScript i Google Chrome medans Node är tänkt att använanvän-das för att hålla igång serverprocesser.

För att köra parallella processer i Node används inte multitrådning som i många andra språk, utan det är ett eventbaserat språk som använder sig av asynkron I/O. Till skillnad mot andra programspråk när den eventbaserade modellen vill användas, så krävs bibliotek för detta, men i Node är det implementerat redan på språknivå [11]. Det gör att JavaScript passar perfekt till detta då det stödjer så kallade callbacks. Det är en funktion som är parameter till en funktion och körs när den funktionen är klar. Till exempel när en fil har lästs in från disk så körs funktionen som har blivit inskickad som en callback.