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 systemanatomin 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 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 genomfö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. Anvä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.