Sällskapsspel baserat på mobilkluster

LINKÖPINGS UNIVERSITET 19 juni 2014 Institutionen för Teknik och naturvetenskap TNM094 Medietekniskt kandidatprojekt Projektrapport Sällskapsspel baserat på mobilkluster Joakim Deborg Marcus Nygren Mikael Zackrisson Sebastian Piwell Teodor Vik Examinator Karljohan Lundin Palmerius

Sammanfattning I rapporten beskrivs hur ett sällskapsspel baserat på mobil-kluster utvecklats. Syftet var att utvärdera hur väl en sådan teknik fungerar till spel. Den tekniska lösningen består av att flera mobila enheter kopplas ihop till ett gemensamt koordinatsystem. I vår applikation kan en boll skjutas från en mobil och dyka upp på en annan mobil enhet, och ta hänsyn till tid och åt vilken riktning bollen skjutits. En server ansvarar för den gemensamma spelplanen. Servern har vetskap om var de mobila enheterna befinner sig i världen och var alla bollar befinner sig i både globala och lokala koordinater. Alla avstånd och storlekar i det globala koordinatsystemet är baserat på riktiga längdenheter. Genom att ha utvecklat en teknik och använt den tekniken till ett i slutänden väl fungerande spel kan det konstateras att den här slags teknik är väl lämpat för spelapplikationer. Google Android har uteslutande använts som utvecklingsplattform. Arbetet har gjorts till öppen programvara, och finns för andra utvecklare att ladda hem på GitHub 1 tillsammans med exempelspelet. Projektet är ett kandidatarbete inom utbildningen Civilingenjör i medieteknik på Linköpings universitet, Campus Norrköping. 1 https://github.com/cigg/game-on-mobile-cluster i

Innehåll Sammanfattning Figurer Typografiska konventioner i iv v 1 Inledning 1 1.1 Bakgrund........................................ 1 1.2 Syfte och frågetällning................................. 1 1.3 Avgränsningar...................................... 2 2 Mål 3 2.1 Ursprungliga mål.................................... 3 2.2 Hur målen uppfyllts................................... 3 3 Process 5 3.1 Utvecklingsprocessen.................................. 5 3.2 Projekteringsverktyg.................................. 6 3.3 Utvecklingsverktyg................................... 6 3.4 Rutiner och dokument.................................. 7 4 Systemprinciper 8 4.1 Medieteknik....................................... 8 4.2 Implementation..................................... 9 4.2.1 Klient-server.................................. 9 4.2.2 Flera koordinatsystem............................. 9 4.2.3 Gemensam klocka............................... 9 4.2.4 Mappning.................................... 9 4.2.5 Framställning av gemensam spelplan..................... 11 4.2.6 Animering................................... 12 5 Teori till praktik 13 5.1 Systemarkitektur.................................... 13 5.1.1 Spelramverk.................................. 13 5.1.2 Fysik...................................... 14 5.2 Trådar och serverkommunikation............................ 14 5.2.1 På mobila enheter................................ 14 5.2.2 På servern.................................... 17 ii

INNEHÅLL INNEHÅLL 6 Resultat och analys 18 6.1 Tekniken......................................... 18 6.2 Spelet.......................................... 18 6.2.1 Spelidé..................................... 18 6.2.2 Interaktion................................... 19 6.2.3 Grafisk profilering............................... 19 7 Diskussion 21 7.1 Tekniken......................................... 21 7.2 Spelet.......................................... 21 7.3 Testning......................................... 21 7.4 Kodgranskning..................................... 22 8 Slutsatser 23 8.1 Vad vi lärt oss...................................... 23 8.1.1 Systemutveckling................................ 23 8.1.2 Medieteknik.................................. 24 8.2 Frågeställningar..................................... 24 A Bilaga: Gruppens arbetsfördelning 27 B Bilaga: Bilder 29 iii

Figurer 3.1 Exempel på bräde för en sprint i Trello......................... 6 4.1 Mappning mellan enhet 1 (t.v.) och enhet 2 (t.h.).................... 10 4.2 Illustration över konstruktionen av tiles........................ 12 5.1 Systemarkitektur.................................... 14 5.2 Aktivitetsdiagram för spelet............................... 15 5.3 Tråd-fördelning på de mobila enheterna........................ 16 5.4 Tråd-fördelning på servern............................... 17 6.1 Bild på mittenplattan i spelet.............................. 19 6.2 Bild på spelet...................................... 20 6.3 Skärmbild från film av spelet på YouTube: http://youtu.be/srgzjn8ckmg...... 20 A.1 Statistik från GitHub.................................. 28 B.1 Skärmdump av inladdningsskärmen.......................... 29 B.2 Server Browser..................................... 30 B.3 Mappning........................................ 30 B.4 Skärmdump av en spelares skärm............................ 31 B.5 Skärmdump tagen efter att spelet avslutats....................... 31 B.6 Inställningsskärm för servern.............................. 32 B.7 Information om en klient på servern.......................... 32 iv

Typografiska konventioner Tekniska ord och ord relaterade till scrum använder sig av kursiv stil. Tabell 1 visar en lista över vanligt förekommande ord när scrum diskuteras. Vokabulär Stories Task Sprint Sprint 0 Stand-up Retrospektive Sprintdemo Definition of Awesome (DoA) Minimum Viable Product (MVP) Open-source Pusha Tiles Widget Tabell 1: Scrum-ordlista Förklaring En större uppgift som ska implementeras under sprinten En arbetsuppgift. Varje story består av ett flertal tasks Ett tidsintervall ( 1-3 veckor) då gruppen arbetar med förutbestämda stories En frivillig inledande sprint för planera och bekanta sig med tekniken Ett kort möte i början av dagen Ett utvärderande möte i slutet av dagen Kundmöte där gruppen visar vad som gjorts under en sprint Lyckas man med sprintens DoA har man gjort målen perfekt Det minsta man måste producera för att ha klarat målen Öppen källkod/programvara är gratis för andra att använda och modifiera Kommando för att publicera kod i versionshanteringssystemet Git Delbilder GUI element v

Kapitel 1 Inledning Rapporten beskriver hur ett sällskapsspel baserat på mobil-kluster utvecklats. Arbetet har utförts på beställning av Karljohan Lundin Palmerius, Ph.D. i vetenskaplig visualisering på Linköpings universitet. Kundens önskemål var att projektgruppen skulle utveckla en teknik för att tillåta flera mobila enheter att kopplas ihop till ett gemensamt koordinatsystem, och parallellt producera ett spel baserat på tekniken. I det färdiga spelet kan flera spelare koppla upp sig mot en server, och efter en kartläggningsfas i realtid skjuta in bollar från sin mobiltelefon till en surfplatta som placeras emellan spelarna. Bollarna kan kollidera med ett mål (som ger poäng) eller med varandras bollar (för att t.ex. hindra en annan spelares boll från att gå i mål). Denna rapport redogör för hur tekniken och spelet utvecklats. Den tar förutom tekniska detaljer upp bland annat arbetsmetodiken och vilka teorier som används. I resultatdelen presenteras slutresultatet i mer detalj. I ett agilt utvecklingsprojekt kan mycket förändras. Under arbetet har spelidén byts ut, funktionalitet tagits bort och lagts till, och många olika tekniker har testats på. I kapitlen Mål, Process, Teori och Teori till praktik sker en redogörelse för de mål, den process och de teorier som ligger till grund för arbetet. 1.1 Bakgrund I traditionella sällskapsspel är en viktig social aspekt den gemensamma fysiska spelplanen, vanligtvis i form av ett spelbräde. Hur skulle en digital motsvarighet fungera? Med hjälp av bättre prestanda och snabbare internethastighet finns förutsättningarna för att undersöka om fördelarna med traditionella och digitala spel kan utnyttjas i ett och samma spel. Projektet har utförts inom kursen TNM094 Medietekniskt kandidatarbetet, där målet är att applicera principer inom systemutveckling för att ta fram en medieteknisk produkt. Det praktiska momentet i kursen gav studenterna möjlighet att ansöka till ett av de tjugo presenterade projekten. Samtliga grupper har använt sig av agil utvecklingsmetodik (i detta fall metodiken Scrum), vilket kan läsas mer om i 3.1. 1.2 Syfte och frågetällning Kunden ville att vi med projektarbetet skulle undersöka hur man designar ett spel som går ut på att flera enheter samverkar genom att dela samma koordinatsystem. Kooridnatsystemet ska vara baserat på verkliga avstånd. Syftet var att utforma ett spel som utnjytjar tekniken och som kan fungera som 1

1.3. AVGRÄNSNINGAR KAPITEL 1. INLEDNING ett sällskapsspel. Kunden bad oss även utvärdera hur väl tekniken fungerar med spelet. Samt en utvärdering om hur den nya typen av spel fungerar och känns. Sammanfattat: 1. Designa en teknisk lösning för flera mobila enheter med ett gemensamt koordinatsystem baserat på verkliga avstånd 2. Skapa ett sällskapsspel baserat på tekniken 3. Utvärdera tekniken och spelbarheten 1.3 Avgränsningar Då kunden inte prioriterade flera plattformar så valde gruppen Android som utvecklingsplatform. De flesta i gruppen hade tillgång till Androidenheter och det är dessutom lättare att komma igång med utveckling till Android i jämförelse med ios som kräver en utvecklingslicens. Det sparade in mycket tid som kunde läggas på att utveckla mot de mål som kunden satt upp istället för att satsa på att det ska fungera på flera plattformar. Andra mål som fanns var att använda kameran på framsidan av enheterna för att positionera enheterna samt att använda peer-to-peer kommunikation. Vid användning av kameran på framsidan av enheterna skulle man kunna utnyttja strukturen i taket för att räkna ut hur långt och i vilken riktning enheten har förflyttats. Det hade lett till en dynamisk spelplan och möjlighet till att utveckla mer avancerade spel. Även om tekniken är intressant bedömdes ett kvalitativt spel baserat på statisk mappning vara mer prioriterat. Peer-to-peer -kommunikation (förkortat P2P) var även det ett mål som inte var så högt prioriterat. Fördelar med P2P är att spelet blir mer portabelt då enheterna kan kommunicera med varandra utan en gemensam server. Istället så har alla samma hierarkiska nivå och vem som helst hanterar kommunikationen. Med mer tid hade P2P varit väldigt intressant då det leder till enklare spridning av tekniken. Alternativet vi valde var istället klient-server -kommunikation (se 4.2.1). Diskussion har förts om att ha en server som är på dygnet runt och som alla med spelet kan använda. Det skulle krävas om vi väljer att bygga vidare och släppa applikationen på Google Play. 2

Kapitel 2 Mål Kunden gav mycket frihet till projektgruppen, gällande såväl spelidé som teknisk lösning. Det intressanta från kundens perspektiv var att skapa ett spel baserat på tekniken att kunna koppla ihop flera mobila enheter med varandra. På det första kundmötet konkretiserades kundens krav på den färdiga produkten, vilka dokumenterades i projektplanen. De gavs även olika hög prioritet. Kraven har kontinuerligt legat till grund för produktutvecklingen. För varje sprint har nya delmål satts upp, vilket kan läsas mer om i 3.1. Det primära målet för projektgruppen har varit att uppfylla dessa krav. Det har även funnits vissa gruppspecifika milstolpar, som har haft med gruppdynamik eller principer inom systemutveckling att göra. 2.1 Ursprungliga mål Dessa krav hade kunden: 1. Gemensam spelplan 2. En vinnare ska kunna utses 3. Det ska finnas en tur-aspekt 4. Det ska finnas en skicklighets-aspekt 5. En spelare ska kunna påverka en motspelares situation 6. Tydlig grafisk profilering Utöver dessa fanns följande önskemål: 1. Dynamisk spelplan som anpassar sig efter enheternas positioner 2. En 10-åring ska kunna spela spelet 2.2 Hur målen uppfyllts Arbetet med produkten påbörjades efter en vecka då gruppen hade en så kallad sprint 0. Fokus låg på att testa på Android-utveckling, utvärdera bibliotek samt undersöka hur svårt det skulle vara att genomföra kundens krav och önskemål. 3

2.2. HUR MÅLEN UPPFYLLTS KAPITEL 2. MÅL Redan efter två veckors arbete demonstrerades tekniken med gemensam spelplan för kunden, via ett enkelt spel. Efter det har spelet och tekniken utvecklats och förbättrats parallellt, med en ny demonstration för kund i slutet av varje sprint. Efter varje sprint har gruppen tillsammans med kund satt upp nya mål, baserat på vilken funktionalitet kunden har ansett vara mest essentiell. Då målen har varit konkreta så har kunden kunnat prioritera dessa och kommunicera både vad kunden anser är minsta möjliga funktionalitet och vision för varje mål. 4

Kapitel 3 Process I denna sektion presenteras utvecklingsprocessen samt de verktyg som används för att organisera och utveckla projektet. 3.1 Utvecklingsprocessen I projektet har vi arbetat med en agil utvecklingsmetodik [1] som grund. Den agila metoden har baserats till stor del på Scrum. I Scrum ingår sprints, stories och tasks, vilka har använts under hela arbetet. Egna anpassningar av utvecklingsmetodiken har gjorts för att passa projektet, detta även under projektets gång. Huvudfokuset har inte varit att följa alla teorier utan att testa på olika för att se vilka utvecklargruppen är bekväm med. En sprint är en bestämd tidsperiod, två till tre veckor i vårt fall, där vi arbetar med produkten. Varje sprint börjar med en sprintplanering, där vi bestämmer vad som ska göras. Under sprintplaneringen formuleras sprintmål med hjälp av begreppen MVP (Minumum Viable Product) och DoA (Definition of Awesome). De förklarar hur långt vi känner att vi bör komma och hur långt vi vill komma i arbetet under tidsspannet för sprinten. I början och slutet av sprinten sker kundmöten för att uppdatera kunden om vad som ska göras och vad som har gjorts, i form av ett sprintdemo. Sprinten avslutats med att vi utvärdera vår arbetsmetodik. Vid sprintplaneringen används en whiteboard och post-itlappar för att översätta kraven på produkten, från alla intressenter, till stories. Stories förklarar konkret vad en intressent ska kunna göra med produkten. Dessa stories bryts sen ner till tasks. En task är en uppgift som utvecklarna behöver göra för att uppnå en story. Dessa diskuteras och prioriteras med lite hjälp från de tidigare nämnda begreppen MVP och DoA. När sprintplaneringen är färdig digitaliseras vår scrum board via projekteringsverktyget Trello, så att vi inte är beroende av en fysisk plats. Under sprinten tar utvecklare ansvar för olika tasks efter intresse och behov. I bilaga A visas fördelningen mellan medlemmarna utifrån intresse. Om flera personer har samma intresse bildas grupper. Till en början fanns det två generella grupper, en för spelet och en för serverkommunikationen. Men längre in i projektet har de områdena gått in i varandra mer och mer och de grupperna har mer eller mindre lösts upp. Vilket ansvarsområde man tar på sig kommuniceras vid gruppmöten och över Trello. Vad som har gjorts presenteras i början på gruppmöten, stand-ups, och i kommentarer på GitHub 1. Om man själv har ansvarsområdet kan utvecklingen ske enskilt, ifrån gruppen. Om man jobbar i en grupp kan man använda parprogrammering eller dela upp arbetet ännu mer. Kodgranskning och testning har diskuterats kontinuerligt under projektets gång. På grund av gruppens ovana inom områdena har det primära målet varit att prova på olika strategier för att arbeta med kodgranskning och testning. På så vis har erfarenheter och slutsatser inför kommande projekt kunnat dras. Kodgranskning och testning har haft störst fokus under projektets första halva. Efter det har kodgranskning och testning i högre grad används då det ansetts särskilt relevant. 1 https://github.com/cigg/game-on-mobile-cluster 5

3.2. PROJEKTERINGSVERKTYG KAPITEL 3. PROCESS 3.2 Projekteringsverktyg Trello har använts som det primära projekteringsverktyget. GitHub har använts för att dela kod, och Git har använts för versionshantering av kod. Google Drive har använts för att skapa gemensamma mötesprotokoll och samarbeta kring projektplan och tidsplan. Google Kalender har använts för att samordna arbetstider. Figur 3.1: Exempel på bräde för en sprint i Trello 3.3 Utvecklingsverktyg Vi har valt att ha Google Android som utvecklingsplattform, utifrån gruppens budget och resurser. Det är den största mobila plattformen och utvecklingsmiljön är god via verktyg som Android SDK och Eclipse. Med Eclipse som utvecklingsmiljö får man tillgång till många användbara verktyg för Android-utveckling. Mycket information om applikationens tillstånd och prestanda får man som är användbart i testning och felsökning. Utvecklingen har skett på både Windows och Mac. Ett Javaprogram som heter Physics Body Editor 2 har använts för att dela in bilder i polygoner. MATLAB har använts för att dela in stora bilder till mindre. 2 http://www.aurelienribon.com/blog/projects/physics-body-editor 6

3.4. RUTINER OCH DOKUMENT KAPITEL 3. PROCESS 3.4 Rutiner och dokument Varje dag har börjat med en stand-up där varje person har fått säga vad den arbetade med sist, dennes arbetsuppgift under dagen samt om det är något som blockerar arbetet. Om det är en blockering som beror på okunskap om vad som ska göras i projektet, arbetsuppgift under dagen eller att man ser ett problem med någon lösning, hålls ett möte direkt efter stand-upen för att räta ut frågetecknen. Dagen avslutas med ett retrospective. Det är ett möte där man diskuterar vad som gjorts bra, vad som inte fungerat och vad man bör tänka på i framtiden. Precis efter ett sprintdemo har vi ett mer omfattande retrospective där vi utvärderar hela sprinten. För att se om vi lärt oss något går vi genom listan av förbättringar från föregående retrospective. Tack vare dessa möten har vi snabbt lärt oss av våra misstag och vi har samtidigt sett till att de inte upprepas igen. Hantering av dokument så som sammanfattningar av sprintdemon och retrospektive har skett genom Google Drive. Alla får snabbt tillgång till allt och informationsspridningen har fungerat bra. För kod valdes GitHub då alla jobbat med det tidigare och haft goda erfarenheter. Det har även i detta projekt fungerat väldigt bra. Något alla i gruppen har blivit bättre på är att snabbt pusha sin kod till GitHub för att på så sätt minimera de konflikter som kan uppstå i koden. 7

Kapitel 4 Systemprinciper I denna sektion presenteras de systemprinciper projektet har behandlat. Sektionen är indelad i i två kategorier som presenteras nedan: Medieteknik och Teknisk lösning. Kategorin om medieteknik kopplar projektet till de teorier som är relevanta till vår utbildning. Där tas även upp vad vi har använt från utbildningen i projektet. Teknisk lösning förklarar de algoritmer, formler och ekvationer vi använt och tagit fram för att lösa olika problem i projektet. 4.1 Medieteknik Under många delar av projektet har vi tagit hjälp av tidigare kunskaper från utbildningen. Grundläggande Java-programmering och matematik har hjälpt mycket. Men stora huvuddelar av projektet var nytt för många i gruppen. Bara ett fåtal har skrivit en mobil-applikation eller ett spel. Ännu färre hade gjort ett spel till en mobil enhet. Spelidén har utvecklats utifrån ett samarbete mellan kund och utvecklare. Utvecklarna har utgått från tidigare erfarenheter som spelare. De har tänkt på vad de själva anser är ett bra spel och vill ha med, ingen större forskning har gjorts i hur man får ett bra spel. Androids utvecklingshemsida 1 användes för att alla i gruppen skulle få tillräcklig erfarenhet för att inleda utvecklingsarbetet. Gruppen testade under sprint 0 att få upp prototyper som studsande bollar på skärmen och enkel klient-server -kommunikation, som förberedelse inför det kommande arbetet. För att få ett spel användes ett spelramverk för spel på Android-applikationer som är gjort av företaget Kilobolt, LLC 2, som är baserat på Beginning Android Games [2]. Kilobolt har guider på hemsidan som går igenom hur man gör ett spel för Android. Mycket av den grafiska utritningen på de mobila enheterna kommer från detta ramverk. Ramverket har även bidragit till en struktur av implementationen på spelet. Strukturen beskriver var, när och hur saker ska göras i spelet. Funktionalitet har adderats till ramverket för att kunna få spelet vi har idag. För att bestämma hur spelet ska se ut och upplevas för användaren har egna erfarenheter spelat en stor roll. Tidigare kurser som Kommunikation och användargränssnitt och Design har hjälpt oss att tänka på mer på våra användare. Fokus har varit att få en design och ett utseende som användarna gillar och kan använda. Det kan gälla saker som att kunna starta spelet för första gången utan förkunskaper men även att spelet ska se enhetlikt ut genom att ha ett grafiskt tema. 1 http://developer.android.com/training/index.html 2 http://www.kilobolt.com/day-7-creating-an-android-game-from-start-to-finish.html 8

4.2. IMPLEMENTATION KAPITEL 4. SYSTEMPRINCIPER 4.2 Implementation 4.2.1 Klient-server Kommunikationen mellan enheterna sker genom klient-server-kommunikation. En klient kan efterfråga data och servern skickar då det till klienten. Klienten behöver inte veta vad som händer på servern utan bara vara beredd på att ta emot ett svar ifrån den. När förfrågan och svar skickas är det viktigt att detta görs efter reglerna i ett kommunikationsprotokol. Båda parter vet strukturen på deras indata men inte mer än så. Bryts reglerna i protokollet kommer data inte gå att tyda av klienterna och det som skickades går inte att läsa. 4.2.2 Flera koordinatsystem Väljer man att sin enhet ska behandlas som en mittenenhet kommer det globala koordinatsystemet få sitt origo placerat i enhetens vänstra nedre hörn. Enhetens lokala koordinatsystem utgår ifrån översta vänstra hörnet och används för att rita ut användargränssnittet och objekt på enheten. Bollarnas position skickas från det globala koordinatsystemet till det lokala för utritning. För att positionera spelarnas enheter använder vi oss av vektorer för att räkna ut hur långt de ska transformeras i det globala koordinatsystemet. 4.2.3 Gemensam klocka Med en gemensam klocka avses en klocka som det går att ta tiden på från åtminstone två olika ställen och som ger samma resultat. För att kunna samordna händelser som sker på enheterna kan det vara lämpligt att en gemensam klocka finns till förfogande. Tiden det tar för ett paket att skickas från en enhet till servern räknas ut genom att skicka iväg ett paket från en enhet till servern. Paketet innehåller den lokala tiden för när det skickades iväg från enheten. Väl framme på servern jämförs tiden som servern har, den globala tiden, med enhetens lokala tid. Skillnaden, t s, mellan enhetens lokala tid, t 0, och serverns globala tid, t 1, räknas ut i enlighet med ekvation 4.1. På motsvarande sätt kan tiden för hur lång tid det tar för servern att skicka ut ett paket till respektive enhet räknas ut. t s = t 1 t 0 (4.1) Genom att addera enhetens lokala tid med skillnaden t s fås den globala tiden. Denna information kan exempelvis användas vid mappning av koordinatsystem och annan tidsberoende kommunikation. 4.2.4 Mappning Med mappning menas en konvertering från ett koordinatsystem till ett annat. För att skapa en gemensam spelplan behövs ett globalt koordinatsystem. Givet eller bestämt är att det globala koordinatsystemets origo och axlar sammanfaller med huvudenhetens. Givet är också längdenheterna för det globala koordinatsystemet, tum, och enheternas upplösning och punkttäthet, antalet bildpunkter per tum. Utifrån dessa givna attribut går det sedan att räkna ut positioner, hastigheter och vinklar i det globala koordinatsystemet. Målet med mappningen är att hitta Enhet 2s position och rotationsvinkel i det globala koordinatsystemet, det vill säga punkten P 5 och vinkeln θ 3. Själva utförandet sker i två steg, där Steg 1 utförs genom att ett finger sveper över en redan mappad enhet, Enhet 1, i riktning mot den enhet som ska mappas, Enhet 2. Detta genererar punkterna P 1 och P 2 på Enhet 1, se Figur 4.1. 9

4.2. IMPLEMENTATION KAPITEL 4. SYSTEMPRINCIPER Figur 4.1: Mappning mellan enhet 1 (t.v.) och enhet 2 (t.h.) För att hitta den sökta positionen P 5 i globala koordinater behöver först P 3 lösas ut, för då kan P 5 lösas ut ur ekvation 4.2. P 0 P 5 + P 5 P 3 = P 0 P 3 (4.2) Eftersom Enhet 1 har en given punkttäthet, position i globala koordinater (P 0 ) och rotationsvinkel i förhållande till det globala koordinatsystemets positiva x-axel (θ 0 ) blir det trivialt att mappa punkten P 2 från Enhet 1s lokala koordinatsystem till det globala koordinatsystemet. Fortsätts svepet med fingret i Steg 1 från Enhet 1 ända fram till Enhet 2 inleds Steg 2, vilket innebär att positionerna P 3 och P 4 erhålls i Enhet 2s lokala koordinatsystem. Om tiden det tar att svepa fingret från P 2 till P 3 känns till och om medelhastigheten och dess riktning däremellan kan konstateras skulle det gå att räkna ut punkten P 3 i globala koordinater och således också den sökta positionen P 5. Nu nyttjas kommunikationen med servern för att kunna lösa tiden det tar att svepa mellan P 2 till P 3, t. Det finns två sätt att göra detta på, det ena innebär att servern startar ett tidtagarur då den pingas av Enhet 1 vid tidpunkten då det svepande fingret befinner sig över punkten P 2 för att därefter stoppa det då den pingas av Enhet 2 då det svepande fingret befinner sig över punkten P 3. Detta sätt förutsätter eller snarare approximerar att enheterna kan kommunicera och bearbeta informationen som upptas under samma tid. Det andra sättet att ta fram t på tar hjälp av en gemensam klocka, vilket istället innebär att servern får den gemensamma klockans tid direkt levererad till sig från respektive enhet. Det enda som saknas nu för att räkna ut P 3 är vinkeln på vektorn P 2 P 3 i det globala koordinatsystemet samt medelhastigheten över P 2 P 3. Eftersom Enhet 1s vinkel θ 0 i det globala koordinatsystemet är given blir vinkeln arg( P 2 P 3 ) = θ 0 + θ 1, där θ 1 = arg( P 1 P 2 ) = atan( y/ x). Detta ger att P 3 kan räknas ut i enlighet med ekvation 4.3 och 4.4. 10

4.2. IMPLEMENTATION KAPITEL 4. SYSTEMPRINCIPER P 3x = P 2x + v m cos(θ 0 + θ 1 ) t (4.3) P 3y = P 2y + v m sin(θ 0 + θ 1 ) t (4.4) Medelhastigheten v m över P 2 P 3 kan uppskattas med ett någorlunda bra resultat i enlighet med ekvation 4.5 ifall användaren drar sitt finger med så när som på en konstant hastighet. Här är v1 = P 1 P 2 t 0 v m = v1 + v2 2 (4.5) och v2 = P 3 P 4 t 1 där t 0 respektive t 1 är tiden fingret befinner sig på respektive enhet. Slutligen kan Enhet 2s vinkel θ 3 räknas ut enligt ekvation 4.6. θ 3 = θ 0 + θ 1 θ 2 (4.6) Vår implementation av den här algoritmen möjliggör att flera enheter kan mappas efter varandra med endast ett långt svep över alla enheterna i fråga. Eftersom algoritmen är relativt generell så går det nämligen att mappa andra enheter i förhållande till andra mappade enheter, det vill säga att huvudenheten endast behöver beröras vid mappning av den första spelenheten. 4.2.5 Framställning av gemensam spelplan Att rendera en bild i storleksordningen kring 5000x5000 pixlar sätter stora krav på enhetens prestanda. Detta medför att extra hänsyn behöver ges till minnesåtgång vid rendering på handhållna enheter. Denna utmaning löste vi genom att dela in den stora bakgrundsbilden i ett antal delbilder, så kallade tiles. Av dessa små bilder gallras sedan de bilder ut som berör enheten i fråga, det vill säga de bilder som kommer ses på enhetens skärm. Hur denna process går till redogörs i stora drag nedan, då exempelvis användningen av trådar samt skalningarna som beror på skärmens, respektive bakgrundsbildens punkttäthet utelämnas. Givet är enhetens position P 1 och vinkel θ 0 i det globala koordinatsystemet. Likaså är bakgrundsbildens position, P 0, given och därmed också alla tiles positioner. För enkelhetens skull låter vi också vinkeln på bakgrundsbilden vara lika med noll, alltså är sidorna på alla tiles parallella med någon av det globala koordinatsystemets koordinataxlar. Först gallras de tiles som överhuvudtaget kan tänkas beröras av enhetens skärmyta ut, se de tiles som är rödmarkerade och som befinner sig till höger i Figur 4.2. Detta görs genom att först skapa en cirkel med enhetens diagonal som diameter och vars centrum överensstämmer med enhetens. Sedan utses de tiles som berörs av cirkeln, i praktiken handlar det om att jämföra hörnpunkterna från kvadraten som omsluter cirkeln med alla tiles. För att ytterligare begränsa antalet tiles som behöver renderas transleras de tiles som blivit utvalda tillbaks med vektorn P 0 P 2 följt av en rotation med vinkeln θ 0. Detta för att lätt kunna se om en tile befinner sig på skärmen genom att i bakgrundsbildens lokala koordinatsystem kontrollera om någon av delbildernas hörnpunkter befinner sig inom den rektangel som representerar skärmytan och som numera har sina sidor parallella med koordinataxlarna i det globala koordinatsystemet. Detta ger oss nästan alla de tiles som blivit grön-markerade. Det saknas nämligen en delbild, då de tiles som inte har någon hörnpunkt innanför ramarna för rektangeln, men som ändå syns på skärmen, 11

4.2. IMPLEMENTATION KAPITEL 4. SYSTEMPRINCIPER Figur 4.2: Illustration över konstruktionen av tiles ännu inte har tagits med. I det här fallet gäller det den gröna delbilden som befinner sig längst upp till vänster. För att också kunna ta med dessa tiles utförs en linje-linje kollisions-analys mellan de linjer som spänner upp de kvarvarande rödmarkerade delbilderna och rektangeln som representerar skärmytan. Kvar att rendera blir sedan endast de tiles som kommer synas på skärmen, vilket sänker minnesallokeringen. De slutgiltliga tilesen ritas sedan ut till en bitmap som exakt täcker skärmen. Denna bitmap fungerar sedan under spelets gång som en framebuffer som kan ritas ut med samma lätthet som en bild. 4.2.6 Animering Animationerna som äger rum i de Widgets som finns med i spelet bygger antingen på linjär, cosinus eller bikubisk interpolering. Varje Widget implementerar en updateringsfunktion och en ritfunktion, fast det animationshanteraren som tar hand om all interpolering av de värden som ska animeras. Detta medför att vi kan skapa allt från följsamma animeringar av exempelvis ett objekts position till blinkande texter. 12

Kapitel 5 Teori till praktik För att omvandla de tekniska teorierna till tekniska lösningar i vårt projekt så var vi tvungna att se till att vi hade en bra systemarkitektur som inkluderar ett ramverk samt en serverdel som hanterar kommunikationen mellan enheterna. Kraven som sattes på ramverket var att det inte skulle vara komplicerat att använda och samtidigt tillräckligt komplext för att kunna skapa det vi ville. Att systemet ska klara av ett skalbart projekt där vi iterativt gör spelet mer avancerat var också viktigt. 5.1 Systemarkitektur I projektplanen finns det en beskrivning på systemarkitekturen vi strävat efter. Nedan presenteras hur den till slut blev. Den övergripande arkitekturen är en klient-server-arkitektur. Servern är skriven i Java och kan köras på en vanlig persondator. Information förs över med hjälp av överföringsprotokollet TCP. Servern står för den gemensamma spelplanen och vet var alla mobila enheter är i den globala världen (spelplanen). Det gör att den kan översätta alla positioner från globala värden till lokala, och tvärtom. Den mobila enhetens position får den från den ovannämnda mappningstekniken. Servern har även ansvar för bollarna och målet. Med hjälp av fysikmotorn JBox2D uppdaterar den bollar och målet i den globala världen. Den uppdaterar hela tiden vinkeln för målet till mittenplattan. Om hastigheterna för bollarna ändrats skickas ny information ut till de berörda mobila enheterna. Om en boll hamnar i målet tas den bort och poängen uppdateras. Servern håller även koll på poängen för alla spelare och skickar ut det till enheterna. Klienten är på den mobila enheten och är en Android-applikation. Då det även är ett spel använder vi oss av ett spelramverk. Det finns två olika typer av enheter. En är mittplattan, på den finns målet. De andra är spelare. Båda används gemensamt för att mappa och ta reda på var i den globala världen spelarna är. Båda har även en lokal bollista som uppdateras lokalt. Om en hastighet ändras, som vid en krock, informerar servern om det och hastigheterna ändras sen på bollen i den lokala bollistan. Spelarna kan lägga till bollar i sin lokala värld som sen skickas till servern för att läggas till i den globala världen. Spelramverket används för utritning av bakgrund, bollar och mål. Figur 5.1 visar en övergripande bild över hur systemet fungerar. Den visar var externa ramverk, som JBox2d och Kilobolt, används. Aktivitetsdiagrammet, figur 5.2, under visar mer tydligt i vilken ordning allt händer. 5.1.1 Spelramverk Vi använde oss av ett generellt spelramverk till Android som gör att vårt spel kan interagera med Android på ett smidigt sätt. Det innebar för oss att vi inte behövde skriva lika mycket av den grund- 13

5.2. TRÅDAR OCH SERVERKOMMUNIKATION KAPITEL 5. TEORI TILL PRAKTIK Server JBox2D Client Kilobolt Framework Implementation Game Figur 5.1: Systemarkitektur läggande kod som krävs för att göra en app till Android, utan vi kunde istället satsa mer på andra viktiga delar så som serverkommunikation och speldesign. Vi utgick från ett spelramverk som skapats av företaget Kilobolt, LLC. Det finns tillgängligt för alla att ladda ned och använda på deras hemsida 1. På hemsidan finns det även steg-för-steg-instruktioner och förklaringar till hur ramverket fungerar. Ramverket utgick i sin tur från en bok om spelutveckling som heter Beginning Android Games [2]. Spelramverket innebär en arkitektur som kan delas in i tre olika delar. 1. Spelets gränssnitt 2. Implementation av gränssnittet 3. Spelets källkod I spelets gränssnitt finns abstrakta komponenter som kommer utgöra spelet, till exempel ljud eller grafik. I dessa komponenter skapas de variabler och egenskaper som instanser av varje komponent kommer att ha men de definieras inte. I implementationen definieras de funktioner och variabler som är skapade i gränssnittet. Implementationen bygger ovanpå det skelett som gränssnittet är. Spelets källkod består av de egna klasser som utgör själva spelet. I dessa klasser anropas funktioner som finns definierade i implementationen för att interagera med Android, till exempel för att spela upp ett ljud eller rita en bild på skärmen. 5.1.2 Fysik Att beräkna objekts verkan på varandra vid en kollision med en fysikalisk korrekthet kan vara avancerat. För att kunna ha bollar och andra objekt som rör sig och kolliderar med varandra på ett trovärdigt sätt användes fysikmotorn JBox2D 2. JBox2D är en fysikmotor för spel i två dimensioner. JBox2D är en modifierad version av Box2D som är gjort i C++ så att det kan användas på ett system som använder sig av Java. 5.2 Trådar och serverkommunikation 5.2.1 På mobila enheter Huvudtråden som startar upp spelet övergår till att ta hand om spelets uppdateringar, rendering samt utgående TCP-kommunikation. När applikationen startas upp skapar denna tråden två nya trådar, Asset 1 http://www.kilobolt.com 2 http://www.jbox2d.org 14

5.2. TRÅDAR OCH SERVERKOMMUNIKATION KAPITEL 5. TEORI TILL PRAKTIK User Player Middle Server Välj spelartyp Rita ut bakgrund Rita ut bakgrund och mål Skapa målet på server Dra finger över skärmen. Dra finger över skärmen. Räkna ut position Skicka position Updatera bakgrund Starta spel Starta spel Skapa boll Skicka boll Gör om till globala koordinater Uppdatera lokala bollar Uppdatera lokala bollar Lägg till bollar på servern Uppdatera bollar Kollisinshantering Träff på mål Med boll eller kant av mål Ta bort boll från device Ta bort boll från server Uppdatera bollens hastighet Uppdatera poäng Uppdatera målets rotation Dela upp bollarna till devicerna Skicka uppdaterade hastigheter och poäng Skicka mål rotation Uppdatera bollarnas hastigheter Uppdatera bollarnas hastigheter Rita bollar Rita bollar Rita poäng Rita poäng Rita målet med uppdaterad vinkel Figur 5.2: Aktivitetsdiagram för spelet Loader och UDP Receiver, se 5.3. Asset Loader-tråden startas upp först efter att de bilder som krävs av inladdningsskärmen laddats in. Detta för att Update/Render-tråden ska kunna uppdatera och visa inladdningsskärmen under tiden alla andra tillgångar laddas in i Asset Loader. Parallellt med att Asset Loader skapas, skapas även en tråd för att skanna efter servrar. Denna tråd representeras av UDP Receiver. UDP Receiver skapar sedan en till tråd UDP Sender. UDP Receiver är en tråd som tar emot data från inkommande servrar som vill identifiera sig själva, så att enheten i fråga vet om att servern finns. Servrarna som har identifierats visas sedan i Server Browser så att användaren kan välja att koppla upp sig mot den. 15

5.2. TRÅDAR OCH SERVERKOMMUNIKATION KAPITEL 5. TEORI TILL PRAKTIK Figur 5.3: Tråd-fördelning på de mobila enheterna UDP Sender är en tråd som skickar ut paket på en viss IP-adress via Multicast, som i sig baserar sig på UDP-protokollet och därför skickar Datagram-paket. När servrar som hör till denna applikation får ett sådant paket analyserar dem innehållet i meddelandet för att se om det är en autentisk enhet som försöker kontakta servern på denna IP-adress. Själva skanningen pågår i en sekund och under denna tid skickar UDP Sender ut cirka 20 paket, detta eftersom UDP-protokollet inte garanterar att ett paket kommer fram till den tänkta mottagaren. Trådarna, UDP Receiver och UDP Sender, avslutas när skanningen av servrar är klara. När Asset Loader och skanningen av servrar (UDP Receiver och UDP Sender) meddelat Update/Render om att de kört klart och efter att inladdningsskärmen visats i två sekunder går Update/Render över till att visa Server Browser. Denna skärm gör det möjligt för användaren att välja vilken server den vill koppla upp sig mot. Då en server är vald skapas en ny tråd TCP Receiver som kopplar upp sig mot servern via TCPprotokollet. Denna tråd tar sedan under spelets gång hand om de inkommande paketen från servern. När ett paket tas om hand placerar TCP Receiver paketet i en cirkulär buffer (en kö) och meddelar tråden Incoming Server Communication om att ett nytt meddelande tagits emot. Efter Incoming Server Communication blivit notifierad bearbetar denna tråd alla paket som finns i den cirkulära buffern, för att sedan vänta på att bli notifierad igen, vilket sker genom tillståndsvariabler (på engelska: Condition Variable). För att Update/Render ska kunna ta del av den information som Incoming Server Communication tagit emot så används designmönstret Singleton på en klass vid namn SharedVariables. Denna klass figurerar som en global klass som gömmer undan synkroniseringen av gemensamma variabler, trådar emellan. Synkronisering sker med hjälp av atomiska variabler och mutex-lås. SharedVariables underlättar också för utvecklarna något enormt, då klassen är global och därmed också tillgänglig överallt i källkoden. 16

5.2. TRÅDAR OCH SERVERKOMMUNIKATION KAPITEL 5. TEORI TILL PRAKTIK 5.2.2 På servern På servern skapar huvudtråden (på precis samma sätt som för de mobila enheterna) en UDP Receivertråd, se 5.4. Enda skillnaden är att denna tråd alltid hålls aktiv för att kunna ta emot förfrågningar om identifiering när som helst. När en identifieringsförfrågan kommit in startar UDP Receiver en till tråd, UDP Sender. Detta är en tråd som under en sekunds tid skickar ut meddelanden innehållandes serverns identifieringsinformation och status. På servern finns också en TCP Receiver-tråd som tar emot förfrågningar om att skapa anslutningar via TCP-protokollet. När en anslutnings skapats förs den anslutningen över till en ny tråd (Client incoming communcation) som tar hand om och bearbetar den inkommande serverkommunikationen för enheten som anskaffat den här anslutningen. Med andra ord så får varje enhet varsin Client incoming communication-tråd på servern. Figur 5.4: Tråd-fördelning på servern Update/Outgoung communication to all devices-tråden tar hand om globala uppdateringar som behöver göras och utgående serverkommunikation. För varje loop (servern körs med en tickrate på 128 gånger på sekund) uppdateras bland annat fysikmotorn och enheternas lokala boll-listor, samt skickas även den information som behöver skickas till respektive enhet ut. 17

Kapitel 6 Resultat och analys Frågeställningen var hur ett spel designas där flera mobila enheter delar samma koordinatsystem och spelar tillsammans. Projektet har bestått av två tätt sammankopplade delar, spelutveckling och teknisk plattform. Baserat på den teknik som utvecklats har ett spel skapats som utnyttjar tekniken och visar på potentialen hos plattformen. 6.1 Tekniken De stora tekniska problemen som har lösts för att skapa spelet presenteras i denna del. Servern har ansvar för den gemensamma spelplanen. Den vet var de mobila enheterna befinner sig i världen och även var alla bollar befinner sig i både globala och lokala koordinater. Alla avstånd och storlekar är baserat på riktiga längdenheter. Det betyder att alla storlekar är samma på alla enheter och att avstånden mellan enheterna i den virtuella världen är samma som den verkliga. Det är nödvändigt för att få det att se ut som samma boll åker över de olika skärmarna. Hur mappningen går till presenteras grundligt i 4.2. 6.2 Spelet I nedanstående rubriker förklaras noggrannare spelet som producerats. De ursprungliga kraven för spelet var att flera spelare ska kunna spela samtidigt, det ska finnas en skicklighets- och en turaspekt, det ska gå att störa varandra och det ska finnas en grafisk profilering. Dessa krav är goda grundidéer för att göra ett spel roligt och vi har försökt vidareutveckla och konkretisera dessa idéer. 6.2.1 Spelidé Spelet går ut på att man ska skicka bollar från sin mobil eller surfplatta till ett mål på en gemensam spelplan. Den gemensamma spelplanen befinner mitt emellan spelarna och är helst en surfplatta eftersom den har en större skärm än en mobil. På den gemensamma spelplanen finns det ett mål som spelarna ska träffa som visas i 6.1. Målet roterar och öppningen är inte hela tiden riktat mot spelare, vilket gör det svårare för spelaren att träffa. Det går att: Skicka bollar från sin mobil mot mål på den gemensamma spelplanen 18

6.2. SPELET KAPITEL 6. RESULTAT OCH ANALYS Figur 6.1: Bild på mittenplattan i spelet Träffa ett mål på den gemensamma spelplanen, om öppningen är riktad mot dig Rotera målet genom påverkan från din boll som studsar på målet. Om målet träffas fås en poäng. Spelaren med flest poäng då omgången är slut vinner. 6.2.2 Interaktion Bra kontroller och återkoppling för ens handlingar krävs för att få en känsla av att bollen gör det man vill. Vid saknad av bra kontroller och återkoppling kan spelet kännas ofärdigt och vara frustrerande att spela. Bollarna i vårt spel skjuts iväg då man drar fingret över skärmen och släpper. Vi har försökt göra det på ett sätt som känns bra för spelaren genom att använda oss av en algoritm som kollar på den bana som fingret har rört sig i innan det släppte skärmen. Att ha med en viss galenskap i spelet, till exempel genom att kunna retas och störa varandra gör spelet roligare. I vårt spel går det genom att skjuta på varandras bollar och genom att rotera målet i mitten. 6.2.3 Grafisk profilering Det är viktigt att spelet ser ut som ett spel och har en tydlig grafisk profil. Därför är det bra att bestämma tema och vilken stil spelet ska ha. Detta kommer bestämma hur exempelvis knappar, karaktärer, bakgrundsbilder ser ut. En tydlig grafisk profilering genom hela spelet gör att spelet känns välpolerat. Under utformningen av användargränssnittet så har vi haft i åtanke att man som spelare ska få samma förutsättningar och upplevelse av spelet. Till menyer har ett mer traditionellt gränssnitt valts då vi tror att det känns bäst för spelaren. För att skapa en bra användarupplevelse tror vi det är viktigt att man som spelare ska kunna komma igång direkt. Antal tryckningar på skärmen bör därför vara minimerat. 19

6.2. SPELET KAPITEL 6. RESULTAT OCH ANALYS Figur 6.2: Bild på spelet Inspiration till UX/UI (User Experience och User Interface) har kommit ifrån gruppmedlemmarnas upplevelser av de mest framgångsrika mobilspelen som Angry Birds, Cut the Rope och Candy Crush. Genom att göra ett enkelt och gulligt UI kommer spelet tilltala många och vi når ut till en bred målgrupp. Det vi insett är att alla dessa spel är utvecklade av otroligt begåvade människor. Det vi enades om var att felfria kontroller gör ett framgångsrikt spel. Figur 6.3: Skärmbild från film av spelet på YouTube: http://youtu.be/srgzjn8ckmg 20

Kapitel 7 Diskussion Det ursprungliga syftet med projektet var att utveckla en teknik för spel på flera skärmar och dessutom göra ett spel som använder sig av den tekniken. Genom att ha gjort detta kan vi kungöra att en sådan slags teknik fungerar och det går att använda på ett bra sätt till spel. 7.1 Tekniken Det absolut viktigaste målet var att ha en gemensam spelplan på flera skärmar som är godtyckligt placerade i förhållande till varandra. Den mappningsteknik vi valde att använda för att avgöra deras relativa positioner, genom att dra ett finger från en skärm till den andra, har visat sig fungera bra. Då vi mäter det faktiska avståndet mellan två skärmar blir felet oftast inte mer än 1-2 centimeter. Felet beror snarare på exaktheten i själva rörelsen som personen som utför mappning gör och inte felberäkningar i algoritmen. Det går helt enkelt inte att dra ett exakt rakt streck med fingret och hålla en exakt konstant hastighet. Huruvida mappningen är tillräckligt bra är svårt att avgöra och det beror självklart på hur stor noggrannhet den tillämpning som använder sig av mappningen kräver. I vårt spel tycker vi att mappningsresultatet är tillräckligt bra, och om resultatet är för dåligt går det att göra om mappningen för att göra ett nytt och förhoppningsvis bättre försök. 7.2 Spelet Alla ursprunliga mål som fanns rörande själva spelet är i någon mån uppfyllda. Det går att enkelt starta en spelomgång och det är tydligt med ett poängsystem vem som leder spelomgången. Efter spelet är slut utses den spelare med mest poäng till vinnare. Att träffa målet i mitten är svårt och därigenom uppstår en skicklighetsaspekt. Ett mål var även att ha en turaspekt som finns i spelet eftersom rotationer och kollisioner kan leda till att man träffar en boll och får poäng på ett oavsiktligt och slumpartat sätt. Spelet som finns just nu är en enkel idé som har stora utvecklingsmöjligheter för att göra det roligare. Trots det har spelet visat sig vara engagerande och spännande för alla som spelat det. Vid testning visade det också att vårt mål om att en 10-åring ska kunna klara av spelet uppfyllts. Vi diskuterade idéer som skulle ge spelare mer möjligheter att påverka sin och andras situation i spelet, bland annat genom att använda power-ups. Vi hade tyvärr inte tillräckligt med tid till att utveckla dessa idéer. Med en fungerande teknik har vi dock visat att det går att göra spel på det här sättet, det är bara tiden som hindrat oss från att göra ett mer välutvecklat spel. 7.3 Testning Ett viktigt moment inom agil utveckling är testning [3]. Det är genom testning man konkret kan visa att alla målen är uppfyllda. Ett hjälpmedel är automatiska tester. En testansvarig utsågs som under 21

7.4. KODGRANSKNING KAPITEL 7. DISKUSSION sprint 0 skrev ett automatiskt test för att se om detta kunde gynna gruppen. På grund av att det tog lång tid och att gruppen var oerfaren inom området så har detta nedprioriterats efter sprint 0. Endast ett till automatiskt test har skrivits då det ansågs passa väldigt väl för uppgiften. Men i projektet har denna typ av testning haft låg prioritet. Många olika metoder har diskuterats och planer för testning framställts. Problemet har varit att implementera det som diskuteras. Detta beror på ett stort fokus på utveckling och en ovana att jobba med testning hos utvecklarna. Testning i form av att köra programmet har ansetts räcka för det mål som systemet har. Eftersom många mål handlar om en känsla för spelarna och spelbarhet kan de bevisas vara uppfyllda på det sättet. Vid slutet av varje sprint har kunden fått testa på spelet och ge kommentarer på kvalitet och funktionalitet. Dett har ansetts mycket värdefullt. Många test har även gjorts inom gruppen, enskilt och med varandra. Fokus har då oftast varit att testa en specifik implemenation. Vid vissa tillfällen har även personer utanför gruppen fått testa spelet. I slutet av projektet hölls en testkväll, för att se om de mål som fanns för projektet uppfyllts och samla åsikter om den grafiska profilen. Det största problem gruppen har stött på som kan ha lösts med testning är regressionsproblem. Problem där lösningar som fungerat tidigare i projektet inte längre gör det. Men dessa problem har varit små och enkla att lösa. 7.4 Kodgranskning Kodgranskning ansågs fungera bäst för gruppen genom parprogrammering eller att be en annan gruppmedlem läsa igenom koden då man delade samma rum. Även kodgranskning på distans har testats till viss del via GitHub, men ej ansetts ge så mycket. Ingen process har hittats som gruppen ansett tjäna sig tid på, därför blev kodgranskning aldrig en del av den agila processen. 22

Kapitel 8 Slutsatser Vi hoppas att det här är tekniken som ska skapa framtidens sällskapsspel. Mobilspelande är idag mycket populärt och detta projektarbete uppmuntrar till att göra mobilspelande mer socialt. Det är fortfarande mycket att göra och vi har endast börjat utvecklingen genom att testa tekniken till Android. Vi hoppas att andra utvecklare ska ta till sig detta och fortsätta så att vi får se fler spel med flera skärmar och kanske till och med över olika plattformar. Det har varit mycket lärorikt att utveckla en teknik genom att parallellt bygga en produkt. Det gör att vi under projektets gång har fått arbeta för att tekniken ska gå bra att använda för applikationsutveckling. Vi hoppas att andra som vill använda underlättas av att vi redan stött på och löst många av de problemen som uppstått. Projektet är open-source och finns tillgängligt på GitHub. Utvecklare inom spel och andra områden uppmanas testa på tekniken för egna idéer för mobilapplikationer. 8.1 Vad vi lärt oss I den här delen presenteras vilka lärdomar som gjorts inom systemutveckling respektive medieteknik. 8.1.1 Systemutveckling Samtliga i projektgruppen har tyckt att det varit nyttigt och lärorikt att arbeta med agil utvecklingsmetodik. Det har varit ett roligt sätt att arbeta jämfört med vattenfallsmodellen. Arbetet har varit mer målinriktat och iterativt än tidigare projektarbeten i skolmiljö. Det har också varit motiverande att veta att erfarenheten av att jobba agilt med hög sannolikhet kommer att komma till nytta i arbetslivet. Projektarbetet har givit såväl praktisk erfarenhet och teoretisk grund inom systemutveckling. Att arbeta med mobil spelutveckling har känts passande i förhållande till de lärdomar som arbetet skulle ge. En viktig lärdom är att det går bra att inte veta allt i förväg, och experimentera med olika lösningar allt eftersom. Det har varit mycket fördelaktigt att ha en person som redan i början av projektet kunde agil utvecklingsmetodik väl, så att bra processer fanns på plats på början och att inlärningskurvan då inte blev lika hög. Särskild nytta har vi haft av att tidigt få en bra struktur på våra scrum boards i Trello. Det gav ett bra ramverk för arbetet inom varje sprint. I projektet var det mycket ny kunskap som behövde hämtas in för att kunna påbörja projektet, till exempel saknade gruppen tidigare erfarenhet av Android-utveckling. För gruppen hjälpte det mycket att ha en vecka att förbereda på via sprint 0, för att kunna lära sig det mest essentiella och prova på tekniken innan projektet startar på riktigt. Att arbeta agilt har varit helt nytt för oss, och i framtida projekt använder vi oss gärna återigen av sprintformatet för att ge utvecklingsarbeten en struktur. Att dela in ett givet tidsintervall i stories och tasks har gett en god överblick. 23

8.2. FRÅGESTÄLLNINGAR KAPITEL 8. SLUTSATSER Stor vikt har i projektet lagts på att kunden hela tiden ska veta vad den kan förvänta sig för resultat av gruppen. Detta har i huvudsak skett genom planerade avstämningar och öppna diskussioner om produktens framtida utveckling. Väldigt få gånger har det därför hänt att kunden känt att gruppen inte uppfyllt förväntningarna eller att gruppen byggt något annat än vad som efterfrågats. Gruppen hade tidigare erfarenhet av att programmera i Java, vilket tillsammans med ramverket vi använde har gjort produkten smidig att utveckla till. Git som versionshanteringssystem användes bättre och bättre allteftersom en fungerande struktur hittades för hur verktyget skulle användas på bästa sätt. Efter varje sprint har vi haft ett retrospective då vi utvärderat arbetsprocessen i gruppen. Det har gjort att vi kunnat uppmärksamma problem tidigt, och i många fall löst dem. Det vi tyckt varit svårast att hitta struktur för är att introducera test, kodgranska varandras kod, samt dokumentation. I framtida projekt skulle vi även vilja ha starkare koppling till systemarkitekturen då vi programmerar, då det gör att man som utvecklare får bättre överblick. 8.1.2 Medieteknik För att överhuvudtaget kunna utveckla en mobilapplikation var vi tvungna att lära oss grunder i apputveckling. Vi utnyttjade Android SDK (Software Development Kit) som är en samling utvecklingsverktyg för att göra applikationer till Android. Android SDK är skrivet i Java. Det var nödvändigt att använda någon slags nätverkskommunikation i projektet vilket var helt nytt för alla i gruppen. Vi har lärt oss hur kommunikationen i ett klient-server-system fungerar. En viss kunskap om spelutveckling och speldesign har varit viktigt i projektet. Vi har lärt oss grunderna i spelutveckling och om de komponenter som gör ett spel roligt. Vi har även insett vikten av att ha en bred kompetens i gruppen. Att ha kunskaper inom olika områden så som design, programmering och projektledning har visat sig vara användbart. En viktig kunskap vi kommer ta med oss från det här projektet är att använda befintliga ramverk och bibliotek. Vi upplevde att det ramverk och den fysikmotor vi använde fungerade bra och var väldigt lätt att integrera i vårt egna projekt. På så sätt sparade vi också mycket tid och kunde fokusera på andra viktiga delar i projektet. Uppfinn inte hjulet igen! 8.2 Frågeställningar Frågenställning 1: Designa en teknisk lösning för flera mobila enheter med ett gemensamt koordinatsystem baserat på verkliga avstånd Den tekniska lösningen som utvecklats i projektet kräver att alla mobiler är uppkopplade på samma nätverk samt en dator på samma nätverk som är en server. Servern bestämmer positionerna på de mobila enheterna med hjälp av användaren. Spelarna drar med fingret över enheterna, från en enhetet till den andra. Med hjälp av information från mobilerna, som skärmstorlek och uppläsning, samt information från steget ovan, som hastighet och riktning, räknar server ut vart enheten befinner sig i den verkliga världen. Enheten placeras på samma avstånd i den virtuella världen, på servern, så servern kan skicka ut rätt information till rätt enhet på ett smidigt sätt. Frågenställning 2: Skapa ett sällskapsspel baserat på tekniken Ett spel har skapats som kräver flera mobila enheter. För det första krävs en mittenplatta. Den utgör mitten av spelplanen, på den finns en spindel som ska äta upp bollar som spelare skickar till den. Om en spelare missar munnen men fortfarande träffar spindeln börjar den rotera. På så sätt ändras målet och spelare som sitter på en annan vinkel har chansen att göra mål. Varje spelare har en egen enhet som de skickar bollar ifrån. Innan spelet börjar måste man mappa sin enhet. Det görs genom att dra fingret över två enheter på spelplanen, på så sätt kan spelare sitta runt om mittenplattan (spindeln). Många mål på projektet handlade om spelet och vad som krävs för att det ska vara ett spel. Alla mål 24

8.2. FRÅGESTÄLLNINGAR KAPITEL 8. SLUTSATSER är uppfyllda vilket indikerar ett spelbart spel. Frågenställning 3: Utvärdera tekniken och spelbarheten Utvärderingen kommer mest från utvecklingsteamet som provat på tekniken/spelet. En liten del kommer från en testkväll med personer utanför. Tekniken som utvecklats fungerar och uppfyller de krav som projektet hade. Det finns några svagheter. Den största svagheten är att den baseras på mänsklig input. För en perfekt mappning krävs det att en person drar fingret med konstant hastighet och rakt. Det är väldigt svårt för en människa. Trots den svagheten fungerar mappningen bra och har oftast bara en felmarginal på runt en centimeter. När man skickar över en boll från en skärm till en annan så ser man den inte hela tiden och en centimeters skillnad är svår att märka. Ett större problem är om det blir fel i vinkeln på mobilen. Ingen felmarginal har tagits fram men om det blir fel är de små, endast några grader. Detta problem löstes lätt genom att välja en bra bakgrund, i vårt fall ett spindelnät. Eftersom bakgrunden går ut över alla enheter kan man lätt vrida mobilen så den passar in. Om mappningen inte lyckats eller man vill byta position är det lätt att gå igenom mappningssteget igen. Spelet som utvecklats fyller alla de krav ett spel har på sig och fungerat bra med tekniken som utvecklats. Vi ser att det fins stor möjlighet att skapa andra typer av spel med samma teknik. 25

Litteraturförteckning [1] Robert C. Martin och Micah Martin, Agile Principles, Patterns, and Practices in C#, Pearson 2007 [2] Mario Zechner och Robert Green Beginning Android Games, Second Edition, Apress 2012 [3] Robert C. Martin, Clean Code: A Handbook of Agile Software Craftmanship, Pearson 2009 26

Bilaga A Bilaga: Gruppens arbetsfördelning Intressenter: Joakim Deborg (EMPX) - Nätverk, mappning Marcus Nygren (marcusnygren) - Agil-expert, produktägare, spel Mikael Zackrisson (Cigg) - Spel Sebastian Piwell (SebbPiwell) - Nätverk, spel Teodor Vik (teodorvik) - Grafik, Scrum master Karljohan Lundin Palmerius - Kund, teknisk handledare 27

BILAGA A. BILAGA: GRUPPENS ARBETSFÖRDELNING Figur A.1: Statistik från GitHub 28

Bilaga B Bilaga: Bilder Figur B.1: Skärmdump av inladdningsskärmen 29

BILAGA B. BILAGA: BILDER Figur B.2: Server Browser Figur B.3: Mappning 30

BILAGA B. BILAGA: BILDER Figur B.4: Skärmdump av en spelares skärm Figur B.5: Skärmdump tagen efter att spelet avslutats 31

BILAGA B. BILAGA: BILDER Figur B.6: Inställningsskärm för servern Figur B.7: Information om en klient på servern 32