5. Semester Projekt Datamatiker Artificial Intelligence og Multiplayer UCN Mathias Fjord Christensen og Rasmus Winther Jensen

Transkript

1 5. Semester Projekt Datamatiker Artificial Intelligence og Multiplayer UCN Mathias Fjord Christensen og Rasmus Winther Jensen

2 University College Nordjylland, Teknologi og Business Datamatiker DM76 Rapportens omfang: 53 Sider, ord. Projektdeltagere: Mathias Fjord Christensen Rasmus Winther Jensen Vejleder: Istvan Knoll Resume: Dette projekt omhandler udvikling af Multiplayer og Artificial Intelligence til et spil, der er udviklet i samarbejde med Dechdroid. Multiplayer delen lykkedes delvist, mens den Artificial Inteligence lykkedes. Afleveringsdato: Underskrift: Mathias Fjord Christensen Rasmus Winther Jensen Side 2 af 53

3 Indholdsfortegnelse Indledning... 5 Problemformulering... 5 Afgrænsning... 5 Målgrupper... 6 Idéudvikling af multiplayer delen... 7 Boehm s Diamant... 8 Size... 8 Criticality... 8 Dynamism... 8 Personnel... 8 Culture... 8 Planlægning Teknologivalg Risiko analyse Udviklingsmiljø Google Play Google Play Game Service Real-Time Transport Protocol (RTP) Client-Server og Peer-To-Peer Kommunikation med serveren JSON Bytearray Informationssøgning Arkitektur og krav Realtime spil Sprint Første Scrum meeting Brainstorm User stories Planlægning af test Andet Scrum meeting Sprint Udvikling under sprint Side 3 af 53

4 Evaluering af sprint Scrum meeting Sprint Udvikling under sprint Evaluering af sprint Risiko analyse for AI Undersøgelse af muligheder for AI Genetiske algoritmer Utility funktioner Neurale netværk Q-Learning Plan til egen AI Sprint Udvikling af AI Første færdige iteration af AI Evaluering af sprint Undersøgelse af multiplayer-fejlen Alternativ til Google Sprint Udvikling af utility funktioner Evaluering af sprint Kodebeskrivelse Utility Funktioner Artificial Intelligence State Machine Personligheder Konklusion Perspektivering Referencer Side 4 af 53

5 Indledning I denne rapport vil man læse om udviklingen af multiplayer funktioner til et spil til Android enheder. Man vil læse om, hvordan projektet er blevet styret, hvilke teknologier der er blevet valgt samt andre overvejelser. Man vil også læse om udviklingsprocessen, og hvilke udfordringer der er forekommet undervejs. Spillet er blevet udviklet i samarbejde med firmaet Dechdroid. Dechdroid er et lille firma, der har specialiseret sig i at lave applikationer til Android. Virksomhedens rolle i dette projekt har været at oplyse om, hvilke funktioner de mener er væsentlige at have med, når et spil skal fungere over internettet. Spillet der bliver videreudviklet på, er lavet af gruppemedlemmet Rasmus, i hans praktikperiode på 5. semester. Spillet havde alle basisfunktioner, der gjorde det muligt at spille spillet ud fra de definerede regler. Der var en simpel AI (Artificial Intelligence), hvilket der også i rapporten vil blive arbejdet på at forbedre. Dechdroid havde ønsker til, hvad de kunne tænke sig at få udviklet til spillet. Først og fremmest ville de have implementeret multiplayer delen. Derudover ønsker de en forbedret AI, da de har fået kritik af denne til betatestningen. Projektet har spændt sig over tidsperioden fra den 11/ til den 15/ Problemformulering Dette er, hvad der vil blive arbejdet med i projektet: Spillet mangler multiplayer funktioner. Dette er væsentligt, da Dechdroid ønsker dette implementeret, før de kan sende produktet på markedet. AI'en skal forbedres, da den er for nem at vinde over. Afgrænsning De multiplayer funktioner der skal implementeres, er nogen der er bestemte af Dechdroid. De ønsker følgende: Der skal være mulighed for at 2 personer kan spille mod hinanden over nettet. Det skal være muligt at invitere en ven til et spil. Det skal være muligt at kunne spille mod fremmede. Det skal implementeres med Google Play Game Service. Google Play Game Service er en SDK, Google har lavet, der gør det muligt at udvikle realtime multiplayer funktioner til Android spil. Til AI'en var der kun 1 krav, hvilket var at den skulle være sværere at slå, ved ikke at opføre sig så statisk, som den gør på nuværende tidspunkt. Side 5 af 53

6 Målgrupper Formålet med at redegøre for, hvilke målgrupper spillet er henvendt til, er at kravene til spillet bliver mere præcise, samt at spillet kan få en større succes. Eftersom spillet er lavet som en android applikation, lægger det primært op til, at spillet er henvendt til android platforme. Dog er der understøttelse af ios på Google Play servere, hvilket giver anledning til, at målgruppen kan udvides til Apple-brugerne. Android og ios brugere har det tilfælles, at de har mulighed for at downloade applikationer til deres enhed, der både kan være en mobiltelefon eller tablet. Det er en meget bred målgruppe, eftersom tallene i Danmark siger, at 7 ud af 10 voksne har en smartphone, og op imod 44% har en tablet i husstanden. Det er derfor svært at pege på hvilke segmenter af befolkningen der er den egentlige målgruppe, da alle med enten ios eller Android er potentielle kunder. 1 Som kilden også fortæller, bruger smartphone brugere omkring 6,50 kroner per applikation, og på tablets er tallet 8,50 kroner. Disse tal giver et præg om, hvor prisen for spillet burde befinde sig. Dog nævnes det også at folk er tilbøjelige til at "nøjes" med en gratisversion af en applikation, hvor reklamer kommer frem, frem for at købe en version, hvor reklamerne er væk. Ifølge denne kilde 2, er kvinderne den type spillere, der spiller et spil i 10 minutter for at slappe af. Mænd spiller gerne flere timer ad gangen. Det giver en fingerregel, om hvorledes man henvender spil til mænd og kvinder, blot ved at styre hvordan tidsforbruget på applikationen skal være. Hvis kvinder bedst kan lide at spille således, at de laver få træk ad gangen, men har mulighed for at vende tilbage til spillet, når de lyster, er det væsentligt at overveje en funktion, der understøtter dette krav. På samme måde skal der til mænd være mulighed for at lave en funktion, der gør det muligt at have en længerevarende session af spillet. Ved at have denne information i baghovedet, er det muligt at gøre noget for begge køn, der gør spillet sjovt og naturligt at spille. Målgruppen for spillet er derfor, folk der ejer enten en ios eller Android enhed, de skal være villige til at betale for applikationer frem for at vælge en gratisversion, de skal være tilbøjelige til at købe udvidelser, og det skal være folk, der kan lide at spille på deres enheder. Ud fra kilder betyder køn ikke noget, da både mænd og kvinder bruger spil-applikationer. Det er svært at sætte en alder på, hvem målgruppen kan være. Selv børn har en købekræft, da der er mulighed for at børnenes forældre vil finansiere deres forbrug på apps. En ting de alle har tilfælles, er et behov for at "slå tiden ihjel". Dette projekt vil ikke beskæftige sig med det grafiske aspekt i spillet, derfor vil denne information blive brugt til at give spillet de funktioner det behøver, for at være succesfuldt. Derfor vil der ikke blive arbejdet på, hvilke visuelle elementer der skal til for at holde spillets udseende neutralt, så det ikke appellerer til det ene køn frem for det andet. Side 6 af 53

7 Idéudvikling af multiplayer delen Da multiplayer delen af spillet er, hvad dette projekt delvist vil omhandle, er det vigtigt at få planlagt det ordentligt, og få tingene på plads inden udviklingen går i gang. Da der er et hav af muligheder for, hvad et spil kan i multiplayer miljø, skal det laves ud fra, hvordan virksomheden vil have det til at fungere og bruge den bedst mulige løsning. Det forventes, at virksomheden har bedst indsigt i, hvad lige præcis denne applikation skal kunne, og hvilken målgruppe der skal rammes. Der blev lavet storyboards, hvor der blev tegnet forskellige scenarier, hvor man går fra at komme ind på startskærmen af spillet, til multiplayer delen, og hvad der sker bagefter. Det scenarie, der blev vurderet til at være det bedste, blev taget videre, og skulle danne basis for, hvordan navigation rundt i spillet skulle implementeres. Her ses vores storyboard. Der blev ikke taget højde for noget teknisk, kun krav fra virksomheden, og det flow som virker mest naturligt at gennemgå, når man er i en app. Måden hvorpå det bedste scenarie blev valgt, var blot ved at vurdere på, hvor få steps man skulle igennem for at nå ind i et spil, om det gav mening at have given information, der hvor det var placeret, og er det åbent for mulige udvidelser senere i fremtiden. Når der er udvalgt et storyboard, skal virksomheden godkende det, og først der, er det klar til at blive videreudviklet til en løsning. Der blev lavet et storyboard, der viste, hvordan hver eneste funktion skulle fungere. Det mentes at dette ville gøre det nemmere at udvikle iterativt, da man så kan udvikle på hvert step i et storyboard. Samtidig gør det det nemmere at dele arbejdet ud imellem gruppemedlemmerne. Side 7 af 53

8 Boehm s Diamant Boehm s diamat 3 er god til at fortælle hvordan dette projekt skal gribes an. Om det er velegnet at arbejde meget agilt, eller er det bedre at arbejde disciplineret (plandrevent). 4 Size Teamets størrelse er 2 mand. Når et team er så lille, er det velegnet til agile arbejdsmetoder, da det vil være for omfattende, hvis alt skal modelleres før udviklingen starter. Værdien dette punkt vil blive tilegnet, er tilsvarende antallet af gruppemedlemmer, altså 2. Criticality Der er blevet investeret i dette projekts fremtid. Der skal betales for brug af google play servere, og så er der allerede købt grafik andetsteds fra, for omkring kr. Hvor stort tabet vil være, hvis projektet i sidste ende mislykkes, er ikke til at sige, da det er fortrolig viden hos Dechdroid. Da spillet i sidste ende skal kunne generere penge for virksomheden, vil der også være et tab, hvis spillet har mangler. For at kunne komme med bedst mulig bud på, hvilken værdi der skal vælges, kræves der indsigt i virksomhedens økonomi, hvilket gruppen ikke har, og derfor må værdien baseres på et gæt. Værdien der bliver tilegnet i denne kategori bliver Discretionary founds. Dynamism Det kode som der allerede er, og som danner basis for spillets funktionalitet, er lavet så det understøtter spillets regler. Det forventes ikke, at spillet kommer til at udvikle sig så meget, at reglerne skal til at ændres. Skulle spillet dog en dag udvikle sig så meget at der skal være mulighed for at spille 4 spillere i 1 spil, kræver det en væsentligt større spilleplade. Hvis det sker, vil det kræve udvidelser i koden. Det vil ikke tage lang tid at gøre det, derfor får det værdien 10%. Personnel Da begge gruppemedlemmer stadig er forholdsvis nye kodere, passer begge i Level 1B gruppen, på vej op imod Level 1A, hvilket er bedst egnet til at arbejde plandrevent. Culture Projektet kommer til at være præget af kaos, eftersom målene i dette projekt kræver erfaring gruppen ikke på nuværende tidspunkt besidder. Den manglende erfaring kan blive et problem, hvis det viser sig, at der er meget, der skal indlæres før projektet kan fortsætte. Værdien 90%. Side 8 af 53

9 Som det kan ses på denne model, passer projektet til den agile fremgangsmåde. Noget andet der taler for, at der burde blive arbejdet agilt er, at når gruppen ikke er større end den er, kan det være svært at nå at få udviklet noget, hvis der skal arbejdes plandrevent. Det frygtes at mængderne af dokumentation vil tage for lang tid. Side 9 af 53

10 Planlægning Til at styre udviklingen er Scrum blevet udvalgt som inspiration til udviklingsmetode. Det er ikke muligt at anvende Scrum til fulde, da der er flere kriterier, der ikke kan opfyldes for dette. For eksempel er det et team på 2 der udvikler, og derfor giver det ikke mening at lave roller, som Scrum anviser. Dog giver det god mening, at der hver uge bliver holdt et møde, hvor der bliver gjort op med, hvor langt man er nået. Særligt når det ikke er sikkert, at udviklingen kun finder sted, når teamet er samlet. Derudover ses det som værende en god idé, at arbejde agilt, da dette projekt indeholder problemstillinger teamet ikke før har arbejdet med. Det giver den fornødne fleksibilitet, der er brug for, hvis det viser sig, at problemet skal løses på en anden måde end hidtil antaget. Fordelen ved at bruge en backlog, frem for en tidsplan til at styre arbejdsprocessen, er at den er fleksibel. Der kan hele tiden tilføjes nye tasks til backloggen, hvilket er en styrke, når det stadig er uklart, om der er blevet taget højde for alt. Ved brug af en tidsplan er det bedst, hvis man har erfaring med, hvad man skal til at arbejde med. En anden praksis der bliver anvendt fra Scrum er sprint. Det har før vist sig, at gruppens medlemmer arbejder godt i sprints. Det at der bliver opsat tasks fra user stories i et sprint, hvor user stories'ne gerne har noget tilfælles, så der hver uge er noget nyt at vise i forhold til produktet. Et sprint kommer til at spænde over en uge. Eftersom projektet skal afleveres den 15. januar 2014, ses der ingen grund til at sprint'ene skal vare længere, da gruppen frygter at lange sprints kan resultere i mindre effektive sprints, eftersom man har længere tid. Ved korte sprint kræves der er ny funktionalitet hver uge, hvilket gruppen mener, er den passende. De små inkrementelle udvidelser forventes også at være med til at nedbryde kompleksitet. Der vil blive anvendt Burndown charts, så gruppen kan følge hvor meget arbejde der er tilbage, versus den tid der er tilbage. Gruppen mener, det er et godt værktøj til at gå ind og se hvilke typer opgaver der forvolder problemer/forsinkelser, som så kan tages med i betragtningen til når næste sprint backlog planlægges. Til sidst i projektet er det muligt for udviklerne at finde ud af på hvilke områder der er sket forbedringer, og hvad der skal trænes i, hvis der en dag skal laves noget lignende. Helt overordnet, er der brug for at lægge en tidsplan, så det kan ses, hvornår udviklingen skal gå fra og til. Backloggen kan beskrives som en plan for udviklingen af produktet, hvor en tidsplan planlægger hele projektperioden. Der bliver også taget inspiration fra Kanban. Der er i gruppen enighed om, at det vil gavne at visualisere workflow, hvilket vil blive gjort igennem et Kanban-board. Dette skal bruges som en motivationsfaktor, samt information for teamet, så det kan ses hvordan projektet skrider fremad. Kanban lægger også op til, at man skal begrænse sig, så man ikke kan begynde at arbejde på for mange tasks ad gangen, da det kan være forvirrende. Derfor skal teamet sætte en fornuftig grænse for, hvor mange tasks der må være "in progress". Ved at gøre dette håbes der på, at det letter arbejdet for udviklingen, og man kommer fornuftigt igennem de nye udfordringer, ved at reducere støj. Der vil også blive inddraget praktikker fra XP, så som On site Customer da Dechdroid er kunden, der har et ønske der skal opfyldes, og udviklingen sker i samarbejde med dem. Den konstante kontakt med virksomheden gør, at forventningerne Dechdroid har, kan realiseres effektivt, og projektet forhindres i at tage retning imod noget Dechdroid ikke vil være med til. Side 10 af 53

11 Collective Code Ownership er en anden praktik. Da gruppen består af 2 udviklere, vil det ikke give mening at noget kode ikke er tilgængeligt for begge. Af samme årsag vil der i projektforløbet blive brugt et online repository BitBucket, så man som udvikler kan komme i besiddelse af ny kode hurtigt. Til sidst er der par programmering. Denne praksis vil så vidt muligt kun blive brugt ved de mest komplekse tasks. Dels for bedre at undgå skriveblokader, og for at begge udviklere får en forståelse for, hvordan man går fra problem til løsning. Derudover vil korrekt brug af denne praksis, give et pænere design af koden, og refactoring vil ske løbende. Arbejdet vil blive evalueret, justeret og optimeret hver mandag, på baggrund af Scrum meetings der vil foregå hver mandag. Er der noget i projektet der resulterer i et skrivestop, skal der arbejdes på at få problemet simplificeret ved at planlægge en løsning og effektivt få det løst. Hvis det viser sig at problemet er mere krævende end forventet, skal det overvejes, om det kan udskydes til et andet tidspunkt, eller om man skal vælge slet ikke at arbejde på det. Til at danne et billede af hvor effektivt der skal arbejdes, samt tilrettelægge sprints, vil princippet velocity blive brugt. På denne måde bliver sprints tilrettelagt ud fra estimater af kompleksiteten af user stories fra backloggen. Erfaring kræves dog, hvis man ønsker at opnå det bedste resultat, da estimeringen af kompleksiteten er afgørende. Eftersom meget er nyt i dette projekt, er det ikke realistisk at håbe på de første sprint har en ordentlig velocity. Derfor skønnes det, at de første sprint bliver ringe planlagt, men i takt med at der bliver dannet en forståelse for, hvor meget der skal til for at løse problemstillingerne, vil planlægningen være realistisk i forhold til, hvad der kan præsteres i en uges arbejde. Gruppen er blevet tilegnet sig en vejleder til projektet. Vejlederens rolle er at give inputs til, hvordan gruppen kan lave et fornuftigt projekt, og bør derfor konsulteres ofte, for at projektet holdes på rette kurs. Som udgangspunkt vil gruppen som udgangspunkt vedholde at have et møde hver uge som minimum. På den måde kan vejlederen holdes opdateret. Der ses ingen grund til ikke at tage mødet, eftersom en uges arbejde bør evalueres. Fordelen ved ikke at bruge UP eller lignende udviklingsprocesser er, at gruppen ikke skal bruge unødig tid til at redigere i diverse modeller. Gruppen er enig om at plandrevne udviklingsmetoder ikke er egnede, da chancen for at kunne planlægge arbejdet godt nok til at det er effektivt, ikke er god nok. En anden fordel ved scrum er, at det er muligt for gruppen at ændre på, hvad der skal arbejdes med. Hvis det viser sig at projektet skal udvide sig, kan man uden mange ændringer indføre tilføjelser til projektet. På den måde sikres det, at projektet kan styres fornuftigt, selvom der skal udvides. Side 11 af 53

12 Teknologivalg Dette kapitel beskriver hvorfor der bliver valgt de valg som der gør. Valgene vil være baserede på fordele og ulemper, og ud fra hvilken løsning der vil være den bedste i den givne kontekst. Bitbucket 5 bliver brugt til at hoste dette projekt. Det gør det nemt at udvikle, da koden er tilgængelig så længe, man kan forbinde til internettet. Det er en nødvendighed for gruppen at have koden tilgængelig på denne måde, da det ikke er sikkert at gruppen kan samles hver dag. Sourcetree bruges til revisionsstyring. Selvom gruppen har mest erfaring med Tortoise SVN, bruges Sourcetree, eftersom det anbefales at bruges sammen med Bitbucket. For at spillere skal kunne kommunikere med hinanden skal spillerne have mulighed for at sende informationer over linjen. Dette gælder både, når der skal sendes chatbeskeder til hinanden, men også når en spiller skal fortælle sin modspiller, hvilket træk han har foretaget. Googles API tilbyder metoden sendreliablerealtimemessage, der blandt andet tager et byte[] som parameter. Læser man på denne metode 6 kan man se, at metoden kan håndtere fejl. Metoden skal vide, hvilket spil der skal sendes til, og hvem af spillerne i spillet, der skal have beskeden. En ulempe ved at bruge byte[] er, at man kan risikere at sende flere gange, alt efter hvor meget data, der er brug for. Til gengæld sendes kun det nødvendige. Her sendes der altså med et Byte[], men det er også muligt at sende JSON objekter. Dette er dog ikke muligt i real-time mode, da JSON bruges til at kommunikere imellem server og web applikation, og i real-time mode, er serveren væk, da spillet vil køre over en peer-to-peer arkitektur. Fordelen at bruge JSON frem for byte[] er, at man kan sende objekter med kun en smule metadata, hvor et sprog som XML har meget metakode i forhold til egentlig data. Det er også muligt at bruge GSON, der kan serialisere og deserialisere Java objekter til og fra JSON. Ulempen ved at bruge GSON er, at det som udgangspunkt vil sende hele objektet, med mindre man håndterer det. Samme problemstilling står man overfor når man bruger JSON. Valget går til sidst på, at der skal sendes data ved hjælp af byte[]. Grunden til dette er, at der ikke ses nogen grund til at sende hele objekter over linjen hver gang, der bliver lavet et træk. På længere sigt, når multiplayer / onlinedelen af spillet bliver mere avanceret med flere funktioner, kan det være en fordel at bruge JSON eller GSON. Google Play Game Service anvendes som Backend til dette spil. Der er mange fordele ved at bruge denne service, og det sparer arbejde for udviklerne. Google Play Game Service tilbyder API'er der indeholder funktionalitet, der kan tages i brug hvis det ønskes. Google vil også tage sig af at hoste spillet. En ulempe ved at bruge servicen er, at den koster penge. Ud over Google, er der andre firmaer der har deres egne bud på applikationsmarkeder. Dog er de fleste begrænsede ved, at de ikke er tilgængelige i nogle lande. Dechdroid ønsker at kunne komme ud flest mulige steder, og derfor skal disse andre services ikke bruges 7 Side 12 af 53

13 Et andet alternativ til at bruge Google Play Game Service er at man selv skal til at implementere funktionaliteten, og have en server til at stå. Det er der ikke tid til, og da Dechdroid i forvejen har en aftale med Google, bliver deres Game service brugt. Udviklingsmiljøet der er valgt til dette projekt er Eclipse, med Android Development Tool (ADT) som plugin. ADT er udviklet af Google, og er anbefalet af Google, hvis man ønsker at udvikle en Androidapplikation. Derudover er de guides, Google har til hvordan man bruger deres API'er, henvendt til udviklere, der bruger ADT. Derfor er ADT det mest fornuftige valg. Alternativt kunne man bruge andre plug-in's, dog er det en chance man løber. Man kunne sagtens have brugt andre udviklingssprog. C# kan udvides med plug-in'et Xamarin, som efter undersøgelser, tilbyder det samme som ADT. ADT er valgt som udviklingsmiljø, eftersom det er hvad Google anbefaler, og der er guides tilgængelige. Efter at have set på hvad de forskellige plug-ins tilbyder, er gruppen kommet frem til det blot er en smagssag, om man foretrækker C# eller Java. Eftersom spillets logik i forvejen er lavet i Java, vil det der bliver udviklet i dette projekt også blive lavet i Java og ADT. Side 13 af 53

14 Risiko analyse Ved alle projekter vil der altid være en risiko. De risikoer vi, som udviklere, kan komme ud for, vil blive redegjort for i dette afsnit. Den største risiko ved dette projekt er, at udviklerne er uerfarne med at anvende Google Play og at lave et spil i Java. Så der skal undersøges en masse, der skal arbejdes hårdt og struktureret, hvis alt multiplayer skal fungere upåklageligt, når projektet er slut. En stor del af opgaven vil være at sætte sig ind i, hvad Google egentlig tilbyder igennem Game Service, og hvordan det bruges fornuftigt. En anden risiko er, at gruppens størrelse er på 2 mand. Om det er for stor en opgave der skal løses i dette projekt, vides ikke på forhånd. Eftersom Google Play anvendes, overlades serveransvaret til Google. Man har ikke selv ansvaret for sine servere, og det kan være en risiko. Hvis Google går ned, kan man kun vente på de løser problemet. En fordel ved at Google styrer serverne, er at det ikke er noget man skal bekymre sig om som udvikler, man skal stole på det fungere, som det skal. Da et krav til spillet er, at det skal fungere på Android platforme, ville en god måde at sikre dette krav være, at teste spillet på forskellige typer af Android enheder. Gruppen har 3 tablets til rådighed, hvor 2 af dem er ens. De er alle 10.1", og har samme styresystem, så alle tablets har nogle ligheder. En væsentlig forskel er, at den ene tablet er fra 2011, hvor 2 andre er fra Ved at teste på disse enheder kan det ses, hvorvidt der er afhængigheder af nye teknologier. Gruppen håber på, at selv den gamle tablet kan være med. Et succeskriterium er, at spillet som minimum virker på 2 ens tablets. Projektperioden kommer til at strække sig over jul. Der er en risiko for at begge gruppemedlemmer bliver forhindret i at arbejde i denne periode, og der kan derfor gå arbejdstimer til spilde. Gruppen er enig om, at der derfor skal arbejdes seriøst helt frem til jul, for at undgå tidspres. Samtidig vil der planlægges således, at de sprint der vil strække sig over samme periode vil blive lavet på disse forudsætninger, så det er muligt at gå ind og ændre i planen. Som beskrevet tidligere, kan det agile hjælpe med at omlægge processen hvis der kommer forstyrrelser i processen. Derfor burde gruppen kunne håndtere eventuelle problemstillinger, afhængigt af sværhedsgraden. Tidsplanen der er lagt, er estimeret højt. Det vil sige at der er taget højde for mange problemer. Så selvom der spildes meget tid med at klare problemer, vil tidsplanen holde indenfor en vis grænse. Side 14 af 53

15 Udviklingsmiljø Dette kapitel vil beskrive Libgdx, der er det valgte udviklingsmiljø. Libgdx er et spiludviklings framework, der tilbyder en API der virker på alle understøttede platforme, der er skrevet i Java, med C og C++ komponenter. I Libgdx er det muligt at lave spil til både desktop og Android ved brug af det samme kode. Det er cross-platform, hvilket betyder det er muligt at udvikle til flere styresystemer som eksempelvis Windows, Linux, Mac OS, Android og ios. Målet for Libgdx er 100% kompatibilitet imellem desktops og mobile enheder. Kun hastigheder må være forskellen. Libgdx gør det muligt at lave kode, skrive test og debugge applikationen på sin computer, og derefter kan man downloade den til for eksempel en Android enhed og forvente, det virker på samme måde som på computeren. Libgdx har den egenskab, at det kan abstrahere fra forskellighederne mellem desktopapplikationer og Android applikationer. Styrken ved Libgdx er, at udviklerne ikke skal bekymre sig om, der er forskelle i stabiliteten fra desktopversionen til Android versionen. Derfor kan man arbejde størstedelen af tiden på computeren, og teste om funktioner fungerer efter hensigten på Android enheder. Input håndtering kan Libgdx også tage sig af. Det kan abstrahere mellem input fra mus og touchskærm. Det vil sige, det samme sker, når man trykker på skærmen på sin mobile enhed, eller hvis man trykker med en mus. Frameworket tilbyder klasser, der letter meget af arbejdet, ved at håndtere low-level logik. Dog er det muligt for udviklere selv at gå ind og ændre på low-level koden, hvis der er behov for dette. Libgdx sigter efter at blive et framework frem for en spil-engine. På denne måde undgår man at tvinge udviklere til at følge retningslinjer. I stedet giver det mulighed for at lave varierede applikationer Side 15 af 53

16 Google Play Google Play er stedet, hvor spillet i sidste ende vil blive distribueret fra. Det er et valg Dechdroid har truffet, da de i forvejen har gode erfaringer med det. Derudover har Dechdroid også valgt, hvilket sprog det skal være i, nemlig Java, da det er et sprog de selv er bekendte med, og derfor er det ikke noget problem for dem at vedligeholde spillet i fremtiden. Ved at spillet bliver lagt ud på denne service, giver det mulighed for at anvende API'er fra Google, der kan lette arbejdet for udvikleren. Selvom det er Google, der står bag denne service, er det stadig muligt at programmere applikationen så ios platformen også kan bruge den, hvis der var behov for det, da Google play understøtter dette. Når man anvender Google Play, skal man være klar over, at man som udvikler for de produkter, der ligger på servicen, kun får 70% af omsætningen. Resten går til Google. Det er en stor andel der går til Google, dog skal man ikke bekymre sig om at distribuere app'en, da det nu er Googles ansvar. Google Play Store kan kun tilgås af kompatible Android enheder. Det vil sige at Apple i første omgang ikke kan blive tilbudt dette spil. Det vil sige, at hvis Dechdroid i fremtiden vil have spillet ud til Apple-brugere, skal der først og fremmest betales for nye udviklerlicenser, samt betales for anvendelse af App Store som distributionsservice. Om det så er en fornuftig løsning at bruge Googles API'er frem for Apples når en ios version skal ligge på App Store, er en problemstilling der skal tages op, til den tid hvor Dechdroid også vil lave ios applikationer. Skulle det nogensinde ske, at Dechdroid vil have spillet lavet til ios, kan man downloade plug-in et Xamarin til Libgdx, der kan lette meget af arbejdet. Google Play Game Service Google Play Game Service er en API, der bliver anvendt for at få spillet til at fungere online. Game Service API'en har funktionaliteten til at gøre spil "sociale". Denne service tilbyder implementering af real-time multiplayer, achievements, leaderboards og mulighed for cloud saving af spildata. Dette er funktionaliteter som man typisk finder ved andre spil apps. Denne API danner basis for funktionerne, der skal implementeres i spillet. Servicen er gratis, da den følger med Google Play, og ikke fungerer uden. Servicen har god dokumentation, og giver et billede af, hvordan man starter med at anvende funktionaliteten. Derfor menes det ikke, at det er tidskrævende at sætte sig ind i, hvordan den anvendes bedst. Der er ingen "færdige" eksempler på spil der anvender Google Play Game Service, så der er stadig udfordring i, hvordan man anvender API'en fornuftigt, dog estimeres det ikke til at være noget, der vil tage for lang tid. Services, der findes i denne service, er også cross-platform, så det er muligt at udvikle til ios med denne service. Side 16 af 53

17 Real-Time Transport Protocol (RTP) Dette afsnit vil beskrive den protokol, der bliver anvendt i Google Play Game services, til at forbinde til serveren. Denne protokol definerer et standardiseret pakkeformat, indeholdende lyd og billede, som kan sendes over et IP netværk. RTP bliver typisk anvendt i kommunikations- og underholdningssystemer, der kræver at der bliver streamet lyd og billede. RTP bliver brugt sammen med Real-Time Control Protocol (RTCP). RTP har ansvaret for at bære billede og lyd, og RTCP har ansvaret for at overvåge transmissionerne. Protokollen er bygget til real-time overførsel af stream data, og har derfor nogle egenskaber, der kan drages nytte af i denne sammenhæng. RTP kan håndtere typiske fejl, som for eksempel jitter og kan opdage, hvis pakker kommer ind i forkert rækkefølge. RTP bruger IP multicast, hvilket gør det muligt at sende data til multiple destinationer (kan være Android-enheder i denne sammenhæng). Dette kan anvendes, hvis spillet en dag tillader mere end 2 spillere ad gangen på samme spil. På den måde vil hver spiller kunne se, når der bliver lavet et træk i real-time. En vigtig ting at huske på, når programmet bliver lavet, er at selvom TCP er standardiseret til RTP, bliver det ikke brugt. Dette skyldes at TCP bruger flere kræfter på stabiliteten, og i når noget streamer, ønsker man timingen skal være præcis. Derfor er størstedelen af RTP implementeringer lavet på UDP. Dette betyder for projektet, at der muligvis skal laves fejlhåndtering, da pakker kan mistes. Client-Server og Peer-To-Peer I dette projekt er der behov for at kommunikere med en server. Det er en fordel, at det er en server, der har ansvaret for at forbinde spillere i spillet, have informationer om spillere, vide om andre spillere er online osv. En fordel client-server arkitekturen giver, er at det er muligt at have en tung eller let server, eller om det er klienten, der skal være den kloge. I dette tilfælde vil det være serveren der er den tunge, da serveren har ansvaret for det meste af funktionaliteten i projektet. Serveren bliver anvendt i det samme øjeblik en bruger logger på sin Google+ profil, da det er væsentligt for andre spillere at vide, du er online og kan spille et multiplayer spil. Kan man ikke logge på sin Google+ profil, vil man heller ikke kunne anvende noget af serverens funktionalitet. Det vil sige at applikationen vil være begrænset til kun at kunne bruge funktioner, der ikke kræver serverfunktionerne som eksempelvis singleplayer. Denne afhængighed kan gruppen ikke gøre noget ved. Ved client-server arkitekturen er der typisk single-point-of-failure. Går serveren ned, er der ikke noget der virker længere. Peer-To-Peer(p2p) fungerer på en anden måde. Et p2p netværk er en samling af en masse enheder, der hver kan betragtes som en node i netværket. Hver node kender nogle andre noder, og sammen danner de et netværk, hvor hver node har en relation til en anden. Her er der altså ikke behov for en egentlig server til at slå op i. En fordel ved p2p er, at det er hver node på netværkets ansvar, at holde lige meget information som de andre. Et stort p2p netværk vil være effektivt, da alle resurser er delt ligeligt ud. Side 17 af 53

18 For projektet betyder dette, at når en forbindelse bliver oprettet imellem spillerne, og de tilsammen opretter et p2p netværk, vil det lette arbejdet for serveren. Det gør det muligt at have mange spillere i gang samtidig, uden det vil belaste serveren. Havde alle spil derimod foregået på serveren, ville der være en kapacitetsgrænse for, hvor mange mennesker, der ville være i stand til at spille samtidig. Da der ikke kan være mere end 2 personer i samme spil, vil p2p netværket ikke kunne få meget gavn af at dele resurser. De 2 noder på netværket danner tilsammen en begrænsning for, hvor krævende spillet egentlig kan være, dog er det ikke noget der menes værende et problem. En ulempe ved p2p netværk er, at det er noderne der ejer netværket, forstået på den måde, at man ikke kan holde styr på, hvad noderne på netværket foretager sig. Kommunikation med serveren Dette afsnit vil afdække hvilke muligheder der er for at kommunikere med serveren. Der findes mange muligheder at kommunikere med en server. Det er hvad der skal sendes, der ligger grundlag for hvilken metode der bliver taget i brug. I første iteration, er målet blot, at der skal sendes ved 2 begivenheder. Når en spiller flytter på en af sine brikker Når der bliver slået med terninger JSON JSON er en mulighed. Da det er designet til at kommunikere imellem en server og webapplikation, ville dette være et naturligt valg. Sammenlignet med XML, har JSON ikke lige så meget metadata. Med dette menes der, at der skal meget data med i XML, for at sende information med. Ved JSON er det lige omvendt, og fylder derfor ikke nær så meget. JSON vil derfor ikke belaste serveren på samme måde som XML kan. Eftersom JSON kan det samme som XML, er lettere for maskiner at læse og fylder mindre, vil XML ikke tages til overvejelse. Google tilbyder biblioteket GSON, der kan sættes i forlængelse med JSON. GSON er i stand til at serialisere og deserialisere JSON til og fra Java Objekter. Dette ville gøre arbejdet med implementeringen af JSON som transmitteringsformat. GSON kan håndtere collections, generiske typer og nested classes. GSON navigerer igennem objektets træ, når der bliver deserialiseret. Dette ignorerer ekstra fields i JSON inputtet. Man kan lave sine egne måder at serialisere og deserialisere på, og derved styre processen. GSON gør det muligt at styre, hvad der bliver sendt. Hvis det bliver brugt rigtigt, vil det kunne reducere mængden af data, og kun få det nødvendige data med. Side 18 af 53

19 Bytearray En anden mulighed er at bruge bytearrays. Bytearrays indeholder kun det data programmet lægger ned. Skal dette bruges, skal man som udvikler være klar over diverse fejlscenarier og arbejde sig udenom disse. Man skal også overveje en syntaks, der skal bruges når der pakkes hos senderen, og parses hos modtageren. En fordel ved at bruge bytearray er, at det er nemt at lave. Eftersom forbindelsen en klient har til serveren er RTP, er det muligt der forsvinder pakker, men med fejlhåndtering kan man minimere dette problem. Valget falder i første omgang på at bruge bytearrays til at sende med. Dette vil dog blot være første iteration. Når tiden er kommet til at programmet er blevet tilpas stort, og der er krav om at sende mange informationer samtidigt, skal det implementeres således, der bliver brugt JSON. Informationssøgning For at finde den information der skal bruges for at løse problemerne i dette projekt, er det et mål at finde professionelle løsninger. Derfor er der krav til de kilder der bliver anvendt, som fx at sidens forfattere skal have en baggrund inden for et eller flere af de emner der arbejdes med. Eftersom spillet bygges på en Google server, vil det være oplagt at finde informationer omkring, hvordan der arbejdes med sådanne servere på Googles egne sider. Informationssøgningen vil foregå struktureret. Eftersom Google er en internettjeneste, er det antaget at størstedelen af information findes på internettet på Google s egne sider. På Google s egne Google Play sider er der basal information til, hvordan man kommer i gang med diverse opgaver. Ligeledes er der information omkring hvordan man kommer i gang med at lave multiplayer funktioner, der kører over Google Play servere. Derfor ville det være ideelt at starte med at finde informationer her. Derudover har Google deres egne youtubekanaler, hvor Google forklarer, hvordan deres services fungerer, og hvordan teorien er bag disse. Videoerne fra disse kanaler vil også blive taget med som valide kilder. Hvis der opstår problemer i udviklingen og der er brug for inspiration, vil der blive søgt på nettet efter projekter, hvor der også er brugt samme services, for at få inspiration. Gruppen forventer ikke det er nødvendigt at bruge tid på at finde bøger, der kan hjælpe med anvendelse af Googles frameworks. Hvis det viser sig, at der er problemer, der ikke er relateret til Google, kan det blive nødvendigt at finde bøger der kan hjælpe. Side 19 af 53

20 Arkitektur og krav Arkitekturen der bliver anvendt i dette projekt er delvis en client-server arkitektur. Når spillet lukkes op, vil det gå på Googles servere. Her findes der informationer fra brugerens Google+ profil, der er obligatorisk at have, hvis man ønsker at spille over nettet. Det gør det muligt som spiller at kunne se, hvem af sine venner der er online, som man så kan spille med, hvis man vil. Når man har inviteret en ven til et spil, bliver serveren altså brugt som look-up server. Kommunikationen imellem klient og server fungerer over REST API kald. Hvis en klient sender en anmodning til serveren om, at han vil starte et spil med nogle venner, sendes denne information til serveren. Serveren giver derefter besked til de pågældende venner, igennem en teknologi kaldet GSync, og deres venner får en notifikation på deres enhed. Hvis en ven vælger at acceptere, sendes der endnu et REST API kald til serveren. Derefter bliver klienten der har oprettet rummet oplyst om, at der er tilmeldt en ny person til hans rum. Når en klient tilsluttes netværket, vil Google oprette et Peer-To-Peer netværk imellem klienterne i rummet ved hjælp af XMPP og libjingle. Kan der ikke oprettes en direkte forbindelse til en klient, kan Google oprette forbindelse ved at bruge serveren som omgangspunkt. De forbundne klienter i Peer-To-Peer netværket bruger RTP til at sende beskeder til hinanden med. Er der en Firewall på netværket, vil beskeder alligevel komme frem, da libjingle har teknologier der kan trænge igennem en Firewall. Google siger at dette er gældende 92% af alle tilfælde. Er der en Firewall den ikke kan bryde igennem, bliver serveren brugt, hvilket skulle dække de sidste 8%. Når et rum er sat op, og spillerne er forbundet ordentligt, vil arkitekturen gå til at blive en peer-to-peer arkitektur. Her er det så spillernes ansvar at holde på alt informationen af spillet. Her vil der være en opgave i at finde ud af, hvilke informationer der skal sendes til hinanden. Skal det være alle spilinformationer, eller er der nogle enkelte informationer, der er tilstrækkelige. Forbindelsen må som udgangspunkt ikke afbrydes, da der ikke ligger noget funktionalitet, der kan genoprette forbindelsen. Når en spilsession stopper, vil peer-to-peer arkitekturen ophøre, og igen vil client-server arkitekturen blive brugt. Ved dette skift, er det muligt for hver enkelt spiller at uploade sine statistikker til Google. Det giver mening, at hver enkelt spiller skal sende disse oplysninger, da det kan være risikabelt at overlade dette ansvar til én person, da der kan opstå fejl. Der er også mulighed for at lave en forbindelse, hvor spillerne uden konsekvenser kan miste forbindelsen til spillet. Denne forbindelse bliver ved med at anvende en client-server arkitektur, hvilket gør det muligt at give serveren ansvaret for at gemme spildata. Side 20 af 53

21 Her ses et billede af 1. og 3. fase af arkitekturen. Her ses et billede af 2. fase af arkitekturen Eftersom det er Play Game service der står for at oprette Peer-To-Peer netværket, er der intet problem i disse skift. Et ønske til produktet er at kunne spille spillet, hvor det er muligt at miste forbindelse, og fortsætte med at spille når man har forbindelse igen. Her vil arkitekturen se således ud: Hver spiller forbinder til Google Serveren. Denne server tilbyder en cloud, hvori det er muligt at gemme spildata. Derved er det serveren der holder information om en spil session. Det er hver spillers ansvar at få fat i data om det rigtige spil. Hver gang der bliver lavet et træk, skal der uploades til serveren, der sørger for at få gjort data tilgængeligt ved at lægge det i cloud'en. Derved har en spiller, der ikke har haft konstant forbindelse til serveren mulighed for at hente informationer om spillet. Applikationen vil derefter starte en ny spilsession, der tager udgangspunkt i det hentede data. For at undgå at misbruge cloud'en, skal applikationen kunne slette spildata derfra. Dette skal ske hvis spildata ikke har været i brug længe, og når en spiller vinder. 11 Side 21 af 53

22 Her ses et flowchart over, hvordan processen er i et realtime spil. Som det kan ses, startes spillet, og derefter forsøges der at logge ind på Google+. Derfra kan man gå direkte ind i et spil (alt efter spillet) eller gå til spillets startskærm. Herfra er der så flere muligheder, som for eksempel quickgame og man kan sende en invitation. Som det kan ses tillader flowet, at man tager flere spil ad gangen, når et rum er sat op. De to forskellige flows i den gule farve viser henholdsvis scenariet, hvor man selv opretter et rum med inviterede, og hvor man tilslutter sig et andet rum. 12 Side 22 af 53

23 Realtime spil Der er mulighed for i Google's API, at sætte en realtime forbindelse op. Koncepterne bag et realtime spil er, at man sætter et "rum" op, hvor man har spillerne der skal spille sammen. Et rum indeholder flere spillere. En spiller har mulighed for at invitere andre til rummet. Der er flere faser i livscyklussen for et realtime spil. 1. Sign-in fasen Dette er fasen hvor spillere skal logge ind på deres Google+ profiler. Ellers er det ikke muligt for andre spillere at kommunikere med dem. 2. Rum oprettelses fasen Dette er fasen hvor rummet bliver initialiseret. Her kan kun spillere, der er logget ind på deres Google+ profil komme ind. Det er muligt for spillere at komme ind i et rum direkte, ved at acceptere en invitation. Der er også mulighed for at bruge en funktion kaldet "auto match". Den gør det muligt at komme ind i et vilkårligt venteværelse. 3. Acceptering af invitations fasen Spilleren der har inviteret til spillet, bliver automatisk tilmeldt rummet. Dem der er inviteret til spillet vil få en notifikation. Hvis man ikke er inde i spillet, vil man få en push-meddelelse, og dem der er inde i spillet, vil få invitationen præsenteret. 4. Forbindelsesfasen Denne fase starter idet spillerne kommer ind i rummet. Play game service sørger for at alle spillerne har en peer-to-peer forbindelse med alle andre i rummet. Hvis en spiller ikke kan få denne forbindelse, vil vedkommende blive smidt ud af rummet. Det er op til applikationen at håndtere dette problem. At der er et underlæggende peer-to-peer netværk, gør det muligt at gøre en af spillerne til host, der kan have flere rettigheder til spillet end andre. 5. Spille fasen Når det krævede antal spillere er forbundet til rummet, kan spillet begynde. Når spillet er i gang, kan spillere forlade rummet, men de vil ikke være i stand til at kunne forbinde igen. Ingen kan forbinde til spillet for at optage en tom plads. Når man er færdig med spillet, er det muligt at spille igen med de samme personer. Det kræver ikke at man lukker rummet ned, for at kunne genoptage et spil. 6. Nedlukning af rum Det er applikationens ansvar at smide spillerne ud af rummet, når spillet er ovre. Når der ikke er nogle spillere tilbage i rummet, vil sessionen ses som værende slut. Side 23 af 53

24 Sprint 0 Sprint 0 er hvor forarbejdet til udviklingen laves. Målet med dette sprint er, at udvikle user stories der skal danne basis for, hvad der skal arbejdes med. Dechdroid har afsat en dag, til at komme derud, hvor der skal brainstormes over mulige arbejdsopgaver. Når dette sprint er færdigt, skulle alt være tilrettelagt til, at gruppen kan begynde at udvikle i sprint 1. Første Scrum meeting Dækker over perioden: 11/11-15/11 Det første Scrum meeting gruppen havde, var som forventet ikke givende i forhold til, hvad der forventes at komme ud af de fremtidige møder. Til dette møde blev der snakket omkring den informationssøgning, der var foregået den første uges tid. Det var afklaret, hvad Google Play servicen kunne gøre for projektet, og hvad gruppen selv skulle sørge for som udviklere. Med denne information kan en Backlog fremstilles, og user stories kan også opstilles, eftersom Google Play Game Service giver en forståelse for, hvad der som minimum forventes af et spil med multiplayer funktioner. Ugens arbejde har også dannet rammerne for, hvordan projektet skal styres. Gruppen kom frem til at den første uge har haft fornuftige fremskridt, og snart vil det være muligt at planlægge selve udviklingen af produktet, samt disponere tid til møder, og revision af rapport og kode. Brainstorm Kort tid efter begyndelsen på projektet, blev der brainstormet. Idéen med dette var, at se om der ville komme inputs, der kunne præge projektet i en bedre retning. Brainstormen foregik sammen med Dechdroid. Dechdroid var oplyste om, at det hovedsageligt var multiplayer, der ville blive arbejdet med i dette projekt, så det var i den del brainstormen skulle tage udgangspunkt. Der kom en masse forslag frem, dog var det ikke alle, der var kode relateret, eller som havde noget at gøre med, hvad formålet med dette projekt omhandler. Mange af idéerne gik ud på at gøre spillet attraktivt for brugeren, såsom at man kan vælge forskellige skins og muligheder for æstetiske ændringer på komponenter på brugergrænsefladen. Andre idéer var eksempelvis lyde og spilfigurer med andre egenskaber end de 3 standard figurer. Ændringer af disse ledte til, at der blev enighed om, at noget af koden skulle omskrives. Som koden er fra start, er det ikke muligt at have flere forskellige typer af brikker, eller muligt at ændre på brikkernes udseende. Dog forventes det at logikken bag det, kan løses med simple objektorienterede praktikker. Andre ønsker, som eksempelvis det at afholde en turnering, kommer til at afhænge af, hvilke muligheder der er på den server, der skal afvikle spillene. Viser det sig, at serveren ikke understøtter noget, der kan bruges til at opsætte en online turnering, skal der undersøges alternativer. At lave turneringer anses dog for at være en stor opgave, da gruppen mener det vil tage for lang tid at tillære sig de nødvendige teknikker. Derudover vil testfasen ikke blive god, det vil kræve flere enheder at fuldføre en test. Side 24 af 53

25 Der blev derudover sat krav til funktionerne af online oplevelsen, hvilket giver et billede af, hvilke løsninger der skal bruges. For eksempel havde Dechdroid et klart billede af, hvordan de forventede processen bag at sætte et spil op med en ven, skulle foregå. De ønskede også, at brugerne af applikationen skulle have noget at blære sig med i spillet, for at vise hvor gode de er til det. De mener, at dette giver spillet længere levetid. Det var en øvelse, der ikke tog meget tid, og som har hjulpet arbejdet på vej. Selvom ikke alle forslagene vedrørte projektet, var de alligevel gavnlige, da det kan ses, hvad der skal være med i betragtningen. Resultaterne fra denne brainstorm giver i sidste ende anledning til, hvilke områder der vil blive arbejdet med i dette projekt. Senere i rapporten vil det fremgå, hvad der kom ud af brainstormen. (Se bilag 1, på cd'en, for at se billederne) User stories For at finde ud af hvad man skal beskæftige sig med i sprint, laver man user stories. User stories beskriver noget, der ønskes tilføjet til produktet. I dette tilfælde er det funktioner, der skal tilføjes til et program. User stories danner basis for de tasks, der skal arbejdes med. Derfor gælder det om at være omhyggelig med at nedbryde user stories, så hver enkelt task er nem at forstå. Følgende user stories er resultatet af et møde med Dechdroid, omkring de ønsker de havde til spillet. Både ønsker der vedrører multiplayer funktionerne, samt andre ønsker de mener, kan forbedre spiloplevelsen for den normale bruger. As a user, I would like to play the game with my friends Opdeles i følgende tasks: Make it possible to see online friends Make it possible to invite online friends Make it possible to respond to an invitation As a user, i would like to play against random people on the internet Opdeles i følgende tasks: Make it possible to see a list of random online people. Make it possible to invite the random person (ignore if the two aren't friends) As a User, I would like to change the difficulty of the computer opponent Opdeles i følgende tasks: Make it possible to change difficulty from the main menu. When a user has won a given number of times, the game should suggest a higher level of difficulty for the player. Side 25 af 53

26 As a User, i would like to change different elements of the game Opdeles i følgende tasks: Make it possible to change skins of the pawns in the game. Make it possible to change the look of the buildings of the game. Make it possible to change sounds of the pawns in the game. Make it possible to change equipment of pawns. As a User i would like to see my game statistics on a leaderboard that compares me to other players. Opdeles i følgende tasks: Create a leaderboard Make it possible to see my own placement on the leaderboard Make it possible to sort the leaderboard so a user can compare to friends only Define which statistics that are relevant to show on the leaderboard. Make it possible to list the leaderboard on different parameters (fx highest pointscore first, and lowest as the last). As a user, i would like to get points for my actions in the game Opdeles i følgende tasks: define which actions a user should get points for. Define which actions should reduce a users score. Make the score visible for the player Asa User i would like to play with people who are using mobiles and tablets. Opdeles i følgende tasks: Test on various android devices that the program still behaves as it should. Find out which system requirements is needed to support the game. As a user, i would like to have a real time multiplayer function. Opdeles i følgende tasks: Establish a connection suited for a constant connection between the players Make warnings for the player if he tries to disconnect from the game Somehow, give the player information about how real time gameplay has other rules about connection As a user i would like to have a turn based multiplayer gameplay (disconnects allowed) Opdeles i følgende tasks: Make it possible to resume a game if a player disconnects. Make notifications for the player when an opponent has made a move. Make it possible to have more than 1 game in progress As a user i would like to change the view of the game as i please (horizontal and vertical) Opdeles i følgende tasks: Make it possible to change the layout depending how the user holds his device. Create new assets so that when the stage is turned by 90 degrees, the stage looks like before. As a user i would like to have music in the game. Opdeles i følgende tasks: Give the game standard sounds, fx menu music and game music. Add sound effects to actions in the game. Side 26 af 53

27 As a user i want a ranking system, to show how much i play the game. Opdeles i følgende tasks: Make it possible to see which rank players are in. Make a ranking system, deffining when to raise in rank. Make it possible to use each players rank, to filter search when looking for an online opponent. Planlægning af test For at teste programmet bruger gruppen 2 forskellige Android tablets. Den ene er en gammel Samsung Galaxy 10.1 tablet, den anden er en Motorola Xoom. Motorola'en er en nyere model end Samsung'en, de har samme skærmstørrelse, og er opdateret til nyeste version af Android. Fordelen ved at bruge 2 forskellige tablets er, at det er muligt at se om applikationen fungerer på flere enheder. Derudover forventes det at der er funktionalitet, der er fornuftigt at teste manuelt. Her tænkes der på, når det skal testes om det er muligt praktisk at spille imod hinanden, og kommunikere på de ønskede måder. Det vælges at der ikke vil blive taget brug af test først princippet i første omgang. Dette skyldes at gruppen ikke tror, det kode der implementeres i løbet af projektet er egnet til test først. Eftersom det er Google's egen API og Server der anvendes. De funktioner som Google gør tilgængelige, forventes at fungere efter hensigten, og det skal overvejes, om det er noget, der er værd at teste. Andet Scrum meeting 25/11 blev møde nummer 2 med Dechdroid afholdt. Her blev der fremvist den funktionalitet, der skulle gøre det muligt for spillere at invitere andre til at spille. Der var nogle kommentarer til dette, eftersom der var ønsker om, at den samme funktionalitet skulle være tilgængelig, når man var inde i et spil. På den måde kan en spiller, imens man sidder i et spil og har lavet et træk, invitere andre til et spil, man kan tage senere, eller imens man venter på sin modspillers træk. Derefter gik snakken om spillevaner hos kønnene, der tidligere er blevet undersøgt i projektet. Kvinder spiller i cirka 10 min ad gangen (snacker spil), hvor mænd har større tendens til at spille i længere tid per gang. Det menes derfor at denne feature hjælper på de mandlige spillere med at nyde deres spil i længere tid, hvis det lykkes for dem at få flere spil op at køre, som de kan skifte imellem, når de ønsker. Derefter blev der snakket om, at der ud fra de undersøgelser der var gjort, var blevet klart at Dechdroid ikke ville have brug for at have en server til at stå. Alt serverfunktionalitet kan afvikles på Googles servere. Derefter blev der snakket om gruppens sprint. Gruppen var interesseret i, om Dechdroid mente, at de tasks der var lavet, tilsammen danner grundlag for en god oplevelse af spillets online muligheder. Eftersom Dechdroid selv har været med til at udvinde User stories mente de ikke, der var nogle mangler og heller ingen nye ønsker. Side 27 af 53

28 Sprint 1 Formålet med sprint 1 var at få invitationssystemet til at fungere. Derudover var der lagt nogle tasks ind omkring lyd, som blev betragtet som slack-tasks. Ved at kigge på Google's egne modeller for hvordan deres service skal bruges, er det tydeligt, at det er invitationssystemet, der skal fungere som det første. Der forventes at være udfordringer i dette, da der skal lægges kræfter i at sætte sig ind i, hvordan servicen skal bruges. Google har dog egne sider, hvor man kan læse om principperne. Arbejdsfordelingen i sprint 1 var således, at en sad og programmerede, imens en anden prøvede at læse fremad. Gruppen mente dette var en fordel, da det ville give mulighed for at fange eventuelle problemer i opløbet. Pair programming blev også anvendt, eftersom det at bruge denne service var nyt, og gruppen mente derfor, det ville være væsentligt at begge gruppemedlemmer var med på hvordan koden var opbygget. Der blev arbejdet i små steps, som det agile lægger op til, for at undgå at gå i gang med for store opgaver med nye problemer. Første skridt i sprintet var, at gøre det muligt at se sine Google+ kontaktpersoner inde i spillet. Det skulle være synligt, hvilke kontaktpersoner der er online, så man kan se, hvem man kan forvente at få et svar fra. Derefter skulle det være muligt at sende en invitation til en ven. Beskeden skal sendes til vennen, igennem Google Play, da Google kan pushe disse. På den måde bliver invitationen synlig med det samme, og derved opnås der samme funktionalitet, som man ser hos så mange andre applikationer. En anden ting der er planlagt i dette sprint, er at der skal sættes lyde ind i spillet. Dette anses som slack-tasks. Gruppen mener det ville være mindre smart at begynde på større opgaver, så derfor vil der ikke blive taget andre opgaver ind fra sprints. Kvaliteten af dette sprint skal afgøres i, hvor nemt det er at invitere en anden til spillet. Det skal gennemtestes, så der er taget forbehold for forskellige fejlscenarier, så det ikke crasher. Man må antage, at hvis spillet skal ud på et applikationsmarked, er der mange millioner af brugere der bruger, deres mobile enheder på forskellige måder, og derfor er det vigtigt. Udvikling under sprint 1 Udviklingen under dette forløb er gået som det var forventet. Google's guides har været meget nyttige, og det har været simpelt at få implementeret. De første par dage gik med at finde ud af hvilke a Google's guides der skulle bruges, hvordan mindre dele af programmet skal udvides, så de nødvendige af Google's funktioner kan tages i brug. De forskellige steps der har været at finde i guides, har været med til at udgøre, hvilke tasks der skal laves i sprints. Der er også beskrivelser til, hvordan man undgår diverse fejl, såsom at kalde ikke eksisterende rooms, og andre typiske fejl der kan opstå. Et mindre problem der opstod under udviklingen var, at guiden på intet tidspunkt nævnte, at der var behov for at lave et interface, hvis man ville have mulighed for at anvende API'en. Denne selvfølge var der ikke blevet tænkt videre over, og der gik nogle timer på at indse problemet. Løsningen blev først fundet efter at have fundet eksempler på nettet. Side 28 af 53

29 Gruppen havde forventet der ville være problemer med at logge ind på Google via spillet, da undersøgelser på nettet har vist, at et af de mest omtalte problemområder ved anvendelse af servicen, omhandler dette. Dog var denne tasks den første der blev løst. Nu er det muligt at bruge flere tjenester fra Google. Herefter blev der udviklet på at gøre det muligt for brugeren at se sine online venner i spillet. Dette var ikke anset for at være et problem, nu hvor brugeren kunne komme på Google, og ved at bruge guiden. Da dette så var klaret, var næste skridt at få sendt en invitation til en ven. Dette krævede ikke meget, ud over der skulle laves en knap i spillet, der kunne sende brugeren til en screen Google har lavet, der viser hvem man har fået invitationer fra. Denne screen havde gruppen ikke forventet værende tilgængelig, og den fjerner arbejdet i at selv skulle lave en skærm der kunne det samme. Efter at være i mål med disse tasks, var der kun slack tasks tilbage. Disse gik ud på at implementere lyde i spillet, hvilket var et ønske fra Dechdroid. Lydene var udleveret af virksomheden, og var hurtigt inde i spillet. Den sidste tid blev derefter brugt på at kigge på internettet efter, hvordan man laver en rigtig AI, og der var en simpel måde at komme i gang med dette. Det viser sig dog, at der ikke er nogen "rigtig" måde at gøre det på, og at når spilprogrammører skal i gang med at lave en ny AI, sker det typisk ved, at de skal starte fra bunden, og kun meget lidt kan genanvendes. Der blev læst på forskellige hjemmesider omkring AI, for at finde informationer på forskellige teknikker indenfor emnet. Evaluering af sprint 1 Målet ved dette sprint blev nået. Der var udfordring ved at lære at bruge API'en ordentligt, men da der nu er gået tid med at arbejde med denne, menes det at de følgende tasks der er meget API afhængige vil være nemmere at komme igennem. Slack-tasks blev også nået. Det menes, at det er nødvendigt at ændre på velocity, da det estimeres at næste sprint vil tage længere tid, og at det dette sprint 1, ikke har haft særlig høj velocity. De tilhørende tasks til sprint 2 er estimeret til at være mere komplekse end fra sprint 1, men da der er opnået erfaring med Google's API, forventes det at det vil passe fint. Dette betyder så, at det stadig vil være muligt at få skrevet rapport imellem kodningen. Arbejdet fungerer godt på denne måde, og derfor vil det tilstræbes at kunne gøre i næste sprint. Burndown kortet viser, at det hele gik som det burde. Dog kan det ses, at målet først blev nået til deadlinen. Det forventes at de næste sprint vil være færdige i god tid før deadlinen, da der er opnået større erfaring med API'en. Side 29 af 53

30 På denne graf kan man se hvordan vores burndown ser ud, den blå linje er den estimeret tid, og den røde er den faktiske tid. Som man kan se, har gruppen været med fra starten, og nåede i mål til sidst. På x-aksen ser man antal dage, og op ad y-aksen er resterende timer Ideal Aktuel Første uges sprint er på baggrund af dette, gået efter forventningerne. Der har været behov for at blive arbejdet på projektledelsen, da gruppen blev klar over, at der muligvis var behov for at omstrukturere projektplanen, hvis AI skulle laves. Dette har taget noget tid, og der har været behov for at diskutere, hvordan alt dette skal behandles. Under skriveblokader er tiden blevet brugt på at undersøge, hvilke muligheder der er for at lave en avanceret AI, for at være i forkøbet. Der blev ikke kigget på noget teknisk i denne omgang, da det viste sig at være et omfattende emne. Brugere af spillet er nu i stand til at invitere en af sine bekendtskaber til spillet. Google har ansvaret for, at der bliver pushet en besked ned til modtageren. Modtageren kunne dog ikke bruge invitationen til så meget, da spillet ville crashe, hvis man accepterede invitationen. Sprint 2 har fokus på at løse dette problem. Resultatet af dette har været et sprint, hvor alt er nået, tempoet har været fornuftigt, og der har ikke været for meget pres på. Derudover er der blevet taget forbehold for, hvad der skal gøres, hvis gruppen løber ind i et problem, der ikke kan løses, eller hvis multiplayer funktionerne er lavet for hurtigt. Scrum meeting 3 Til dette møde, der blev afholdt den 02/12, blev der præsenteret, hvad der var nået i sprint 1. Dechdroid var tilfredse med funktionaliteten til at invitere venner til spillet. Eftersom de ingen rettelser havde til det, der var blevet udviklet, blev der ikke oprettet nye tasks til backloggen. Bagefter blev de introduceret i de nye planer omkring inddragelsen af en forbedret AI som fokusområde. Dechdroid havde gerne set, at det var spillets design der ville blive arbejdet med, men de var forståelige overfor at det var bedre at lave noget teknisk udfordrende i stedet, da noget af det projektet har manglet er udvikling af egen funktionalitet. Side 30 af 53

31 Sprint 2 Formålet ved sprint 2 er, at der skal laves funktionalitet, der kan starte et spil op med 2 spillere, og de skal have mulighed for at kommunikere sammen under spillet. Derudover skal brugeren informeres om, hvilke regler der er, når man spiller real-time udgaven af spillet. Derfor skal brugeren få en advarsel hver gang vedkommende prøver at gå ud af spillet. Der vil ikke blive arbejdet med, hvad man kan gøre, hvis en bruger af en eller anden grund mister forbindelsen til spillet. Noget der skal undersøges i dette sprint er, hvordan man sender information til modspilleren omkring sine træk. Sidste sprint fungerede fint, og som skrevet før vil praktikkerne, der er blevet brugt i forrige sprint, blive genanvendt her, i håb om at det igen bliver en succes. Gruppen er klar over at dette sprint bliver sværere teknisk end forrige, og der er derfor enighed om, at der skal forventes at være dage, hvor der bliver arbejdet længere end andre, hvis der opstår et problem. Grunden til at gruppen estimerer disse opgaver til at være svære teknisk er, at der herfra ikke er meget funktionalitet tilbage, Google kan bidrage med. Så snart spillet er i gang skal gruppen selv lave funktionaliteten til spillets drift. Når spillet er slut, kan Google igen komme ind og hjælpe. For hvis man som spiller gerne vil have et spil mere mod sit bekendtskab, er det muligt igennem Google at genbruge det room som man er i, og genstarte det. På den måde skal man ikke igennem invitationsprocessen igen. Noget andet, der skal laves i dette sprint, er muligheden for at invitere tilfældige personer til et spil. Idéen bag dette er, at man bliver hooked op sammen med en anden, der også søger på en tilfældig person, og derved undgår ventetiden på, at en af sine bekendtskaber accepterer invitationen. Personerne, man finder igennem denne funktionalitet, er ikke nødvendigvis en, man er bekendt med i forvejen. Gruppen er blevet enige om, at der skal skrives omkring sprint 1 i dette sprint i fritiden. Der er intet krav om, at det skal være færdigt, der skal blot skrives kort om processen, så det ikke bliver glemt. Det er også aftalt, at der i fritiden skal kigges yderligere på, hvordan en fornuftig AI til spil skal laves. Det forventes, at der findes lektioner omkring emnet på youtube.com, eller projekter man kan downloade og lade sig inspirere af. Det forventes stadig, at der er gode chancer for, at multiplayer delen af spillet til sidst bliver hurtigt lavet færdigt, og derfor er det nødvendigt at se på, om der er flere emner, der kan udvikles på. Sprintet bliver hårdere end det første, men der satses på at estimaterne holder, og resultatet af planlægningen vil være fornuftigt. Succeskriteriet for dette sprint er, at der skal kunne startes et spil op med en ven eller en tilfældig, og kan spille det færdigt uden problemer. Hvis der ikke er tid til at kigge på at få en chat til at fungere, er det fint, da det ikke prioriteres højt i forhold til de andre opgaver i sprintet. Side 31 af 53

32 Udvikling under sprint 2 Den første task der bliver taget hul på her er, at der skal laves en forbindelse imellem 2 spillere. Google's guides viser også, hvordan man går til værk. Når forbindelsen er oprettet og brugerne er sammenbundet i samme room, vil spillet kunne gå i gang. Koden er nu så langt, at det er muligt at sende en invitation til en anden person, og det er muligt at svare på en invitation. Man kan enten vælge at acceptere eller afvise invitationen. Accepterer modtageren invitationen, bliver de sat i samme room, og spillet starter op. Spillet crasher, når det skal til at starte op, men det vil der blive arbejdet videre med i tasken, der omhandler dette. For ikke at gå i gang med en for stor bid, blev der forsøgt at sende beskeder imellem de 2 klienter når de er kommet i samme room. Dette skal anses som værende et forstadie til, hvad der kan blive en chat senere i spillet, så spillerne kan snakke in-game. Det er muligt at sende en besked imellem de 2 brugere, men lige nu fungerer det kun, så længe selve spillet ikke starter op. Der bliver nu arbejdet på at få styr på at få selve spillet startet op. Som udgangspunkt er der blevet debugget, og det viser sig at fejlen skyldes shaders. Eftersom libgdx fører sig selv som værende et framework, der er uafhængigt af platform, burde der ikke være noget galt med at bruge libgdx til at udvikle spillet. Den store undren går på, hvorfor der er problemer med shaders så snart det skal køre over Google Play Game Service. Den første mistanke går på, det er noget, der er overset. Der bliver brugt meget tid på at undersøge fejlen. Første var at søge på nettet efter folk med lignende problemer. Der var ikke meget held med at finde eksempler, der har samme problem. Der blev også søgt på den givne exception for at finde ud af, hvad den kan skyldes. Heller ikke det kom med en løsning. Evaluering af sprint 2 Sprintet blev ikke fuldendt. Gruppen løb ind i problemer med Google Play, da selve spillet skulle til at starte efter et room var oprettet. Programmet kan godt modtage beskeder ved modtageren efter de er kommet i samme room, hvor arkitekturen er gået over til Peer-To-Peer, og serveren er ikke længere indblandet. Hvad fejlen skyldes vides ikke præcist på nuværende tidspunkt, gruppen er bare klar over, at der er problemer med shaders, da det er, hvad der kan læses på exceptions i loggen. Eftersom der ikke kunne startes et spil, blev der heller ikke arbejdet med at lave advarsler til brugeren, hvis vedkommende ville prøve at forlade spillet. Det gik udmærket de første dage af sprintet, men da de sidste dage nærmede sig, begyndte fejlen at optræde. Der blev brugt meget tid på at løse dette problem men uden held. Igen blev pair programming brugt, dels fordi det var vigtigt kode der skulle skrives, og fordi der var behov for at begge kiggede på koden, for at løse fejlen. Dog var der perioder, hvor det ikke var nødvendigt, og i disse perioder blev tiden blandt andet brugt på at læse omkring AI og på at få skrevet rapport. Efter at have brugt mange mandetimer på at løse problemet uden held, besluttede gruppen sig for at lave om i planlægningen. Eftersom gruppen ikke mente, der var meget progression i at prøve at afhjælpe fejlen, blev multiplayer prioriteret ned, og AI blev taget op. Der var enighed om, at det ville være mest effektivt at lave på AI i stedet for multiplayer, hvor der var stor risiko for ikke at komme videre. Velocity var god indtil fejlen opstod, og burndown chartet så også fornuftigt ud. Derfor er der grund til at tro, at hvis fejlen ikke var opstået, ville sprintet være vellykket. Gruppen har valgt, ikke at fortsætte med Side 32 af 53

33 velocity, da der er frygt for at det vil være alt for misvisende, eftersom emnet er nyt. Det er udregnet, men det er ikke noget gruppen vil bruge til at styre processen med. På denne graf kan man se hvordan burndown grafen ser ud for sprint 2. Som man kan se, er den røde langt over den blå linje, hvilket betyder, at gruppen har været bagefter fra start, og ikke nåede i mål til sidst, dette skyldes at gruppen havde problemer med at få multiplayer delen til at virke Ideal Aktuel Der blev brugt tid på at gøre klar til AI, som noget af det sidste af sprintet. Der blev kigget på forskellige muligheder som for eksempel at bruge utility funktioner, genetiske algoritmer, neurale netværk og Q- learning. Her blev der blot kigget på, hvordan de virker, og der blev taget stilling til, om det var noget som gruppen ville arbejde med, da sværhedsgraden er på et højt niveau. Eftersom det blev besluttet, at der skulle fokuseres på AI i stedet for, skulle det afgøres om projektet skulle bestå af to delprojekter, eller et projekt med to emner. Valget gik på at det ikke skulle være to projekter, da der var tvivl om, hvorvidt det ville lykkes gruppen at komme videre med multiplayer funktionerne. Det er i stedet for valgt, at AI vil blive hovedemnet fremover, og multiplayer vil være noget der køre på sidelinjen. Sker der et gennembrud, kan multiplayer blive taget op igen for at forsøge at få noget, der fungerer efter hensigten. Dette er ikke noget Scrum anbefaler, men gruppen håber på, at det er et fornuftigt valg. Der skal laves om på backloggen, da prioriteter skal laves om, og der skal også laves uddybende tasks til AI. Efter at have snakket med Dechdroid om skiftet i fokusområdet, blev der aftalt at der ikke skulle bruges tid på virksomhedskontakt længere. Dette skyldes at AI ikke er et område, hvor Dechdroid kan komme med inputs, da det ikke er noget de har viden indenfor, og derved ikke ved præcist hvad de vil have. Dette vil have indflydelse på kvaliteten af produktet, eftersom der ikke længere et sæt af krav, der skal overholdes. Dog mener gruppen, det er nødvendigt, hvis tiden skal være til at lære teorien bag AI. Fremover skal der altså derfor bruges mere tid til at refactor koden, hvis der skal opnås kvalitetssikring. Side 33 af 53

34 Risiko analyse for AI Efter et møde med vejlederen, har gruppen fået øjnene op for et muligt problem. Efter at have arbejdet med Google Play Game Service, er det blevet klart, at der ikke behøves meget nyt funktionalitet, da Google's API'er giver meget. Derfor er der chance for at multiplayer funktionerne bliver lavet for hurtigt, eller ikke har nok teknik i sig, så der er behov for at projektet skal fokusere på mere end kun multiplayer. Dette afsnit vil beskrive hvordan det vil håndteres. Det er blevet valgt, at det skal være AI udviklingen, der skal kigges nærmere på, da det er et emne, der kræver udvikling, og i følge vejlederen, kan det endda være for kompliceret til at være muligt at få noget fornuftigt ud af at arbejde på. For at eliminere usikkerheden om det er for kompliceret eller for tidskrævende, skal der afsættes tid til at kigge på, om det at lave en AI er noget der kan gavne projektet. Eftersom gruppen er på to mand, er det et stort tab i arbejdskraft hvis blot den ene skal bruge tid på at sætte sig ind i, hvordan det skal udvikles. Derfor er det aftalt i gruppen, at det er noget, der skal arbejdes på udenfor normale arbejdstider, for at minimere tabet. Vejlederen fremlagde nogle muligheder for, hvordan en AI kan laves. Nogle af mulighederne er komplekse, men giver en velfungerende AI, mens andre er nemmere at anvende, men muligvis er svære at få til at fungere. Ud fra denne kilde 13, er der ikke en "universel" måde at lave AI på, da formålet er ekstremt afgørende for, hvordan den skal laves. Det er derfor sjældent at en AI kan genbruges. Dette kan tyde på, der er mange parametre, man skal have styr på. Hvis projektet går i retning af, at der skal laves en AI, vil der blive taget stilling til følgende: Efterfølgende sprints. Hvilke user stories skal tages ud for at gøre plads til AI udviklingen? Skal der bruges nye praktikker for at komme i mål? Det forventes at nye udfordringer kommer til, da det er en ny opgave. Skal tidsplanen ændres? Det er muligt, at det bliver nødvendigt at lave sprint ene længere, da det stadig er usikkert, hvor meget arbejde, der kræves for at kunne levere noget funktionsdygtigt. Det kan medføre at deadlinen gruppen havde sat sig for, bliver rykket. Da dette vil resultere i at projektet omhandler 2 forskellige emner, er det en mulighed at gøre det således, at dele af AI udviklingen skal betragtes som et parallelt projekt. Konsekvensen af inddragelse af at lave en kompleks AI er, at gruppen ikke længere vil have god tid til at snakke sammen, da arbejdsområderne er forskellige. Det er derfor vigtigt at planlægge arbejdsfordelingen grundigt, så tidsplanen ikke skrider. Side 34 af 53

35 Undersøgelse af muligheder for AI En mulighed er at anvende state machines. Her bliver udfordringen, at der skal implementeres hvordan AI'en skal opføre sig, altså hvornår skal den vælge at spille defensivt, offensivt eller lave et træk der gavner på længere sigt. En udfordring kan være, at gøre den minimalt statisk. Hvis ikke det er noget der fører nogle veje, vil der blive undersøgt på andre eksempler af AI's. Da det er en AI til et spil, forventes det, at det er muligt at finde eksempler på nettet og andre steder. Det håbes så at eksemplerne kan give inspiration til, hvordan det kan gøres. Genetiske algoritmer Det er en mulighed at bruge genetiske algoritmer 14. En genetisk algoritme tager udgangspunkt i en samling af individer, der hver repræsenterer en løsning for et givent problem. Algoritmen finder ud af, hvilke løsninger der er de bedste og parrer dem. Når løsninger bliver parret, sker der en cross-over, samt en mutation. Derved er der lavet en ny generation af løsninger. Denne proces gentages indtil et stopkriterium (termination condition) er nået. Disse kriterier er typisk: Når en løsning lever op til minimumsbetingelserne Hvis et bestemt antal af generationer er kørt igennem Når tiden det tager at komme frem til et resultat overskrider en grænse Når algoritmen ikke længere kan beregne bedre resultater Hver løsning har et sæt attributter, der kan ændres på. Ofte bliver løsningerne repræsenteret binært, som strenge af 0 og 1, men andre kodninger af dette er også tilladt. En strategi i genetiske algoritmer, gør det muligt at overføre de bedre løsninger til næste generation uændret. Denne strategi kaldes Elitist selection, I genetiske algoritmer er Cross-over en operator, der varierer programmeringen af løsninger fra en generation til en anden. Det er en analogi fra den biologiske verden, der beskriver de beslutninger der bliver taget, når 2 forældreceller skal lave en ny (et barn). Cross-over har flere teknikker til at fremstille en ny generation af løsninger. One-point crossover er en teknik, hvor der på begge forældrenes strenge er valgt et punkt. Alt data efter dette punkt er byttet imellem begge individer, og resultatet af dette er børn. Side 35 af 53

36 Two-point crossover er en lignende teknik, hvor der bliver anvendt 2 punkter i stedet. Hver gang der krydses et punkt, byttes data imellem forældrene. Ønskes mere variation, kan der altid indsættes flere punkter. Fremgangsmåden vil være den samme. Cut and splice er en fremgangsmåde der resulterer i forskellige længder af strenge hos børnene. Dette skyldes at hver forælder har crossover punkter sat forskellige steder på strengene. Dette tilbyder mere variation. De samme teknikker bliver brugt i en genetisk algoritme, når næste generation af løsninger skal produceres. Et problem med genetiske algoritmer er, at de ikke klarer sig godt, når det begynder at blive komplekst. Når antallet af individer der underlægges mutationer er højt, er der typisk en eksponentiel forøgelse af elementer, der skal søges igennem. Ifølge kilden betyder det, at genetiske algoritmer ikke er velegnede til at designe med. Derudover er den bedste løsning altid fundet ud fra at sammenligne andre løsninger. Genetiske algoritmer har tendens til at gå efter lokale optima, frem for globale optima. Dette skyldes at genetiske algoritmer ikke ved, hvordan de skal se bort fra den umiddelbart bedste løsning, for at åbne et bedre resultat på længere sigt. 15 Genetiske algoritmer har den fordel, at de implementeres som et "lag" ovenpå AI'en. Denne teknologi kan kun bruges til, at forbedre AI'en, og ikke til at udvikle en AI med. Denne kilde 16 sammenligner Genetiske algoritmer, Q-learning og neurale netværk. Forfatteren skriver, at den genetiske algoritme han har lavet er bedst til hans formål, men han er overbevist om, at et neuralt netværk kan laves til at være endnu bedre, og at Q-learning passede mindre godt til hans formål, da det krævede meget finpudsning. Side 36 af 53

37 Utility funktioner I stedet for at man definerer states, som en AI kan være i, hvor man skifter og reagerer ud fra "triggers", kan man bruge utility funktioner. Disse gør det muligt for individer at måle på handlinger, der er tilgængelige i det miljø de er i. En ligning der beregner hvor stort et udbytte (utility) en given handling vil give, bliver brugt til at vælge, hvad NPC'en(Non-Player-Character) skal gøre. Et eksempel givet fra kilden: en NPC i et skydespil har 100% af sin ammunition tilbage. Han har mulighed for at samle ammunition op fra hvor han står. Med en utility funktion kan NPC'en vide, at det ikke giver nogen fordel for ham at samle ammunitionen op. Havde han derimod 50% ammunition ville han have en stor fordel ved at samle det op. Dette kan laves som en lineær funktion, men hvis man ønsker variation, kan man bruge andre funktioner. Det er funktionerne, der definerer hvornår utility skal være højt og lavt. Derved er det muligt at lave en NPC, der ikke tænker meget på at samle ammunition op ved 90%, 80% og 70%, men har man mindre, vil grafen lave udsving, og utility vil hurtigt blive højt. Det er også muligt at lave en funktion der er tilsvarende en trigger, der reagerer på en Boolean. Funktionen kan hedde: If x > 0.5 then y = 1, else y = 0. Det er også muligt at sætte flere "steps" ind, da utility ikke nødvendigvis behøver at gå imellem 0% og 100%. På denne måde kan andre utilities stadig blive valgt. Det forventes at denne type vil blive anvendt meget i et spil som Ancient Secret, eftersom der er flere situationer hvor et given træk er det eneste logiske. Derudover kan disse også være med til at vælge, hvordan NPC'en skal opføre sig, alt efter hvor mange brikker der er tilbage. Alle funktioner kan bruges til utility funktioner. Dette giver mulighed for at lave enten komplicerede AI'er, eller nogle simple. Det kan selv bestemmes om AI'en skal være aggressiv eller defensiv. 17 Side 37 af 53

38 Neurale netværk Denne teknik simulerer, hvordan en menneskelig hjerne fungerer. Teknikken er i stand til at maskinlære, og genkende mønstre, og vurdere hvad en god beslutning er, på baggrund af erfaringer den tidligere har gjort sig. Der er flere måder at lave et neuralt netværk på, men der vil kun blive undersøgt på en måde. Som det ses på billedet, har man inputs, der sendes til stadiet "Hidden", hvor de forskellige inputs udgør forskellige kombinationer. Outputs vil være produktet af, hvad det neurale netværk har lært. De forskellige inputs har en vægt med, som bliver brugt til at beslutte, hvor god beslutningen er. 18 Tager man udgangspunkt i, at teknikken simulerer et biologisk netværk, kan man overveje hvor mange niveauer man ønsker af inputs. Dette giver mulighed for at manipulere meget med sit input. Beslutningen kan derved blive grundigt gennemtænkt, og hvis lavet rigtigt, vælge en fornuftig action. 19 Skal dette bruges i spillet, kan det allerede nu ses, det kræver at lære, hvordan man træner et kunstigt netværk. Derudover skal der besluttes, hvordan beslutningerne skal tages. Gruppen vil ikke vælge at gå videre med neurale netværk. Efter at have forsøgt at forstå, hvordan det bygges op, er gruppen blevet enig om at det er for kompliceret, og tidskrævende. Desuden mener gruppen at teknikken er alt for avanceret i forhold til problemstillingen. Der er derfor ikke blevet undersøgt mere på dette. Q-Learning En anden mulighed er at bruge Q-Learning, der er en anden læringsteknik. Ligesom utility funktioner er det en teknik der bruges til at vælge den bedste action, i en given MDP(Markov decision process). Det virker ved at lære en action-value function. Resultatet af at bruge Q-Learning er utilitien for en given action i et givent stadie. Styrken ved Q-Learning er, at det ikke behøver nogen model af programmets miljø, for at kunne sammenligne de utility funktioner. Denne teknik har vist sig værende i stand til at vælge de optimale beslutninger i ethvert givent MDP. Algoritmen bag teknikken består af en agent, states og et set af actions for hvert state. Hvert state giver agenten en belønning i form af et nummer, agentens mål er at maksimere dets totale værdi. Dette gøres ved Side 38 af 53