TU Delft Open Dagen App. Technische Informatica

TI3800 Bachelorproject Eind Verslag

TU Delft Open Dagen App

Technische Informatica

Auteurs:

Edward Teng Tom Zwart

Onder de begeleiding van: Rafael Bidarra Trudy Middendorp

Faculteit Elektrotechniek, Wiskunde en Informatica Technische Universiteit Delft Juli 2014

Voorwoord Dit verslag beschrijft het resultaat van ons Bachelor Eind Project voor de studie Technische Informatica aan de Technische Universiteit Delft. Het project is opgesteld door de Marketing en Communicatie afdeling van de TU Delft in samenwerking met Rafael Bidarra en is uitgevoerd voor het vak TI3800 - Bachelorproject. Het project is van start gegaan op 7 april 2014 en is geëindigd op 4 juli 2014. In deze periode hebben wij full time gewerkt aan een applicatie dat gebruikt zal worden tijdens de open dagen van de TU Delft op de faculteit EWI, waarmee scholieren op een interactieve en leerzame manier worden rondgeleid door de faculteit. Wij willen graag de volgende mensen bedanken voor hun hulp tijdens dit project. Onze opdrachtgever Trudy Middendorp en begeleider Rafael Bidarra, voor het meedenken over de applicatie, de goede ideeën die ons in de juiste richting hebben geleid en de kritische feedback tijdens dit project. Bart Vastenhouw, voor het inrichten van de server en iedereen die heeft geholpen met het testen van de applicatie tijdens de testdag. Tom Zwart en Edward Teng Delft, juli 2014

Samenvatting Dit bachelor project heeft als doel om een applicatie te ontwikkelen voor de open dagen van de TU Delft, waarmee scholieren op een interactieve, leerzame manier kennis maken met hun gekozen studie en worden rondgeleid door de faculteit. Deze applicatie is in eerste instantie bedoeld voor de faculteit EWI, maar moet ook makkelijk uitbreidbaar zijn voor andere faculteiten en studies van de TU Delft. Om dit doel te bereiken is een mobiele applicatie ontwikkeld voor het Android platform, wat met een paar aanpassingen ook kan worden uitgebreid naar de iPhone. Met deze applicatie worden scholieren in groepjes rondgeleid door de faculteit en worden tijdens de rondleiding vragen gesteld die inhoudelijk iets te maken hebben met de gekozen studie, faculteit of iets anders TU Delft gerelateerd. Tijdens de rondleiding zullen de scholieren naar verschillende kenmerkende locaties in de faculteit worden gestuurd alwaar ze deze opdrachten met elkaar moeten oplossen. Denk hierbij aan de /pub, de kantine of DIMES. Het uiteindelijke systeem bestaat uit drie onderdelen, de applicatie (client), de server en een website voor de opdrachtgever. De applicatie kan worden ge¨ınstalleerd op de mobiele telefoons van de scholieren en dit is wat de scholieren zullen gebruiken tijdens de rondleiding. De applicatie is geschreven met Unity, wat het ontwikkelproces erg heeft versneld door de vele standaard functionaliteiten die Unity levert en de gratis beschikbare libraries. Verder is er gebruik gemaakt van een server om het multiplayer aspect van het spel te beheren. De client communiceert met de server door requests te sturen naar webpagina’s op de server die de server verder afhandelt. Ook kan de server push berichten versturen naar de client met data dat kan worden uitgelezen door de applicatie. Om data op te slaan wordt gebruik gemaakt van een MySQL database, waar informatie over onder andere de spelers, opdrachten en de route wordt opgeslagen. Naast de applicatie is er ook een website gemaakt met behulp van het Twitter Bootstrap framework, waarmee de opdrachtgever inhoud kan toevoegen aan het spel. Met de website kan de opdrachtgever informatie zoals groepen, mijlpalen, opdrachten en routebeschrijvingen toevoegen aan de database, wat vervolgens gebruikt kan worden door de applicatie. De kwaliteit van de code was ook een belangrijke factor in het project. Het testen van de applicatie door middel van unit tests en een gebruikerstest was een onderdeel daarvan. Ook is de code naar Software Improvement Group verstuurd die de onderhoudbaarheid van het systeem analyseren. Voor het systeem is een score van vier uit de vijf sterren behaald, met een mindere score voor duplicatie en unit size. Aan de hand van deze feedback zijn er aanpassingen gedaan aan het systeem om deze onderdelen te verbeteren. Uiteindelijk is er dus een applicatie ontwikkeld dat werkt voor Android telefoons, die uitbreidbaar is voor andere studies en schaalbaar is met het aantal mensen dat naar de open dag komt. De applicatie zal echter nog wel verder worden uitgebreid voordat de open dagen beginnen. We eindigen dit verslag dan ook met aanbevelingen voor verdere toekomstige ontwikkelingen.

2

Contents Contents

3

1 Introductie

5

2 Opdracht en eisen 2.1 Probleemstelling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 Doelstelling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3 Eisen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6 6 6 7

3 Game concept 3.1 Verhaallijn . . . . . . . . 3.2 Concept . . . . . . . . . 3.3 Opdrachten . . . . . . . 3.3.1 Raadsel . . . . . 3.3.2 Rebus . . . . . . 3.3.3 Zet de plaatjes in 3.3.4 Meerkeuze vraag 3.4 Route . . . . . . . . . .

. . . . . . . .

8 8 8 9 9 9 9 10 10

4 Planning 4.1 Globale planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2 Sprints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

11 11 12

5 Ontwerp en implementatie 5.1 Model, view controller . . . . . . . . 5.2 Tools en libraries . . . . . . . . . . . 5.2.1 Unity . . . . . . . . . . . . . 5.2.2 Github . . . . . . . . . . . . . 5.2.3 Vuforia en ZXing . . . . . . . 5.3 Push berichten . . . . . . . . . . . . 5.4 Client . . . . . . . . . . . . . . . . . 5.4.1 Communicatie met de server 5.4.2 De verschillende schermen . . 5.4.3 Popups . . . . . . . . . . . . 5.5 Server . . . . . . . . . . . . . . . . . 5.5.1 Database . . . . . . . . . . . 5.5.2 PHP . . . . . . . . . . . . . . 5.6 Website . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

14 14 15 15 15 15 16 17 17 18 21 22 22 23 24

6 Ontwikkelproces 6.1 Project fases . . . . . . . . 6.1.1 Onderzoek & design 6.1.2 Sprint 1 . . . . . . . 6.1.3 Sprint 2 . . . . . . . 6.1.4 Sprint 3 . . . . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

25 25 25 25 25 26

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . de goede volgorde . . . . . . . . . . . . . . . . . . . . . .

. . . . .

. . . . .

. . . . .

. . . . .

3

. . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

6.2

6.1.5 Sprint 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.1.6 Afronding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iPhone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7 Kwaliteit en testen 7.1 Server . . . . . . . . . . 7.2 Client . . . . . . . . . . 7.3 Gebruikers test . . . . . 7.4 SIG feedback . . . . . . 7.4.1 Eerste feedback . 7.4.2 Tweede feedback

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

26 27 27 28 28 28 28 30 30 30

8 Conclusie

31

9 Aanbevelingen 9.1 Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.2 Push berichten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.3 MoSCoW model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

32 32 32 32

Referenties

33

A Appendix : Screenshots A.1 Website . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A.2 Applicatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

34 34 37

B Appendix : Database diagram

40

C Appendix : SIG aanbevelingen

43

D Appendix : Plan van aanpak

44

E Appendix : Orientatie verslag

55

F Appendix : Originele project beschrijving

67

4

Introductie

1

Introductie

De open dagen van de TU Delft zijn kennismakingsdagen waar scholieren informatie over zijn of haar gekozen opleidingen bij de universiteit of faculteit kunnen krijgen. Het is niet alleen informatie over de studie dat ze krijgen, maar ook kunnen ze tijdens de open dag iets over de faculteit leren, andere ge¨ınteresseerde scholieren ontmoeten en kennismaken met de docenten. Het is dus belangrijk om een goede indruk te geven van de opleiding en de faculteit tijdens de open dag. Voor dit project focussen we ons op de open dagen van de faculteit EWI, wat voorheen bestond uit een informatiemarkt en een aantal presentaties die de scholieren konden bijwonen. De Marketing en Communicatie afdeling van de faculteit EWI wilt dit echter veranderen in iets wat meer interactief is en wilt dit bereiken door de scholieren met behulp van een interactieve, leerzame game een rondleiding te geven door de faculteit in plaats van een informatiemarkt op te stellen. Aan ons is dus de opdracht gegeven om deze game te gaan ontwikkelen. De game moet de scholieren die naar deze open dag komen dus op een interactieve en leerzame manier kennis laten maken met de studie en de faculteit. Door middel van spelletjes, opdrachten of een andere vorm van interactie wordt een route door de faculteit verkregen langs verschillende informatieve stands. Dit moet ervoor zorgen dat de scholieren een leukere ervaring hebben tijdens de open dag en na afloop ook een beter idee hebben wat ze van de opleiding kunnen verwachten. Dit verslag bestaat uit negen hoofdstukken en zes appendices. Allereerst zullen we de opdracht en de eisen van de applicatie toelichten. Hierna wordt er dieper ingegaan op het game concept dat bedacht is, waarin de verschillende onderdelen van het spel zullen worden toegelicht. Vervolgens wordt er kort iets verteld over de planning, waarna het ontwerp en de implementatie van het systeem uitgebreid aan bod komt. Daarna wordt in hoofdstuk zes uitgelegd hoe het ontwikkel proces verlopen is en in hoofdstuk zeven wordt het testen van het systeem en de feedback van SIG besproken. In het hoofdstuk acht wordt een conclusie getrokken over het resultaat van het project en in het laatste hoofstuk worden een aantal aanbevelingen gegeven. De zes appendices bevatten screenshots van de applicatie en website, een EER diagram van de database, de aanbevelingen van SIG, het plan van aanpak en het onderzoeksverslag en als laatste de originele project beschrijving.

5

Opdracht en eisen

2

Opdracht en eisen

In dit hoofdstuk zal de probleemstelling worden toegelicht en wat de uiteindelijke doelstelling is van dit project. Verder wordt ook een MoSCoW model weergegeven dat is opgesteld aan de hand van de eisen.

2.1

Probleemstelling

Er worden ongeveer 500 scholieren van vijf en zes vwo per dagdeel voor de opleidingen Technische Informatica, Technische Wiskunde en Electrical Engineering verwacht voor de open dagen, afgaande op informatie van voorgaande jaren. Dit is dan ook onze doelgroep. De scholieren worden verdeeld in groepjes van ongeveer tien personen, dus er moet rekening gehouden worden met ongeveer 50 groepjes die tegelijkertijd de game gaan spelen. Het systeem moet niet alleen stabiel zijn bij zoveel mensen, maar moet er ook voor zorgen dat deze scholieren zo georganiseerd mogelijk worden rondgeleid. De game moet de scholieren zo veel mogelijk verspreiden door de faculteit, zodat er niet teveel groepjes op één plek zijn. De vragen en opdrachten mogen ook niet te lang duren, want de scholieren moeten langs meerdere stands gaan en kunnen niet heel lang bij één stand blijven. Ook de scholieren die geen mobiel hebben of die een mobiel hebben waar de app niet op ge¨ınstalleerd kan worden moeten aan de opdrachten mee kunnen doen.

2.2

Doelstelling

Het doel van deze opdracht is om vijf en zes vwo scholieren die ge¨ınteresseerd zijn en zich willen verdiepen in de opleiding(en) Electrical Engineering, Technische Wiskunde en/of Technische Informatica tijdens de open dag op een leuke, leerzame en interactieve manier kennis te laten maken met hun gekozen opleiding en de faculteit middels een mobiele game.

6

Opdracht en eisen

2.3

Eisen

Aan de hand van de eisen van het project is een MoSCoW model opgesteld. Met de MoSCoW methode worden prioriteiten gesteld om aan te geven welke functionaliteit in het programma moet komen (must have), wat erg gewenst is om te hebben (should have), wat mogelijk nog meer aan het programma kan worden toegevoegd als er tijd over is (could have) en wat niet aan het product wordt toegevoegd, maar wat eventueel bij toekomstige projecten kan worden ge¨ımplementeerd (won’t have). De MoSCoW tabel is te zien in Tabel 2.1 Tabel 2.1: De MoSCoW tabel Onderwerpen Een centrale database om gegevens op te slaan De mogelijkheid om in een groep te komen Route berekening die elk groepje zoveel mogelijk verspreid door de faculteit en ze langs verschillende standjes leidt Minigame: Raadsels Minigame: Plaatjes in de goede volgorde zetten Minigame: Rebus Minigame: Meerkeuze vraag Mijlpalen die het verhaal benadrukken Begeleidende avatar Share mogelijkheid met Facebook QR-code scanner om locatie en opdracht te bepalen De mogelijkheid om scores van anderen te zien in de app en op een website De optie voor de opdrachtgever om content (opdrachten) toe te voegen aan het spel De mogelijkheid om het spel thuis verder te spelen Rollen verdeling onder de spelers SubMinigame: Foto nemen 2D plattegrond voor de routebeschrijving Augmented reality implementatie Share mogelijkheid met andere social media Chat systeem

7

M X X X

S

C

W

X X X X X X X X X X X X X X X X X

Game concept

3

Game concept

In dit hoofdstuk zullen verschillende elementen van het uiteindelijke game concept worden toegelicht. Door de eisen die aan de rondleiding waren gesteld was er minder vrijheid in het bedenken van een game concept dan van te voren was gedacht. Er is tijdens de onderzoeksfase ook veel tijd besteed aan het bedenken van een goed game concept dat zou voldoen aan de gestelde eisen en ook leuk zou zijn om te spelen. Met behulp van brainstorm sessies en veel overleg met de opdrachtgever en begeleider is hier uiteindelijk dan ook een leuk concept uit gekomen, wat naarmate het project vorderde nog een aantal keren is aangepast.

3.1

Verhaallijn

In ongeveer een uur tijd wordt de speler in een groep door zijn eerste studenten jaar worden geleid. Tijdens de rondleiding komt hij verschillende mijlpalen tegen die veel studenten in het echte leven ook zullen ervaren, waardoor hij alvast een voorproefje van het studentenleven krijgt. Denk hierbij aan op kamers gaan of zijn eerste studentenfeestje. Door met de groep samen te werken en de opdrachten goed uit te voeren worden er studiepunten verdient, waarmee deze mijlpalen gehaald kunnen worden. Er kunnen maximaal 60 punten gehaald worden tijdens de rondleiding als alle opdrachten in één keer goed worden beantwoord. Als een groep dit lukt hebben alle spelers van deze groep hun propedeuse en laatste mijlpaal van de rondleiding gehaald. Na de rondleiding kan de speler vervolgens nog alleen verder spelen met het aantal studiepunten dat hij met zijn groep tijdens de rondleiding heeft gehaald. Ook kan hij opdrachten maken om zo verder te komen met zijn bachelor opleiding en ook komt hij hierdoor hoger op de ranglijst te staan.

3.2

Concept

Het doel van het spel is om zoveel mogelijk studiepunten te halen, waarmee de mijlpalen gehaald kunnen worden en de de speler hoger op de ranglijst komt te staan. Naast studiepunten kunnen ook sterren gehaald worden voor een opdracht. Hoe sneller de groep een opdracht oplost, hoe meer sterren ze krijgen. De studiepunten bepalen hoe hoog een groep in de ranglijst komt te staan, mocht een groep een gelijke score hebben als een andere groep dan bepalen het aantal sterren wie er bovenaan staat. De scholieren krijgen aan het begin van de rondleiding een code die ze in de applicatie kunnen invullen, wat bepaalt in welke groep ze terecht komen. Vervolgens worden ze in deze groepjes rondgeleid door de faculteit d.m.v. routebeschrijvingen naar verschillende locaties in de faculteit. Bij deze locaties moet dan een QR code worden gescand om een opdracht te starten. Voor elke opdracht is er een timer en heeft de groep drie kansen om het goede antwoord te geven en na elk fout antwoord verliezen ze een derde van het totaal aantal punten. Ook als het de groep niet lukt binnen de tijd de opdracht goed te beantwoorden is de opdracht niet gehaald en krijgt de groep nul punten en sterren. Als de opdracht is afgerond krijgt de groep de routebeschrijving naar de volgende locatie, totdat ze bij elke locatie van de rondleiding zijn geweest. Na de rondleiding kan er individueel verder worden gespeeld met het aantal punten dat de groep tijdens de rondleiding heeft gehaald. Je hebt nu de mogelijkheid om in je

8

Game concept

eentje opdrachten te maken, waarmee je weer studiepunten en sterren kunt verdienen om zo de volgende mijlpalen te halen. Ook zal er een individuele ranglijst worden bijgehouden zodat je je score nog steeds kunt vergelijken met andere spelers.

3.3

Opdrachten

Er zijn in totaal vier verschillende opdrachten. Elke opdracht is zo bedacht dat het schaalbaar is met het aantal spelers van de groep, de scholieren moeten samenwerken om de opdracht op te kunnen lossen en dat ook mensen zonder smartphone mee kunnen helpen met het vinden van het antwoord. De opdrachten hebben inhoudelijk iets te maken met de gekozen studie voor de open dag, de faculteit of het studentenleven en zijn op het niveau van de doelgroep. In de volgende paragrafen worden deze opdrachten verder uiteen gezet. 3.3.1

Raadsel

Er wordt een raadsel gegeven en hints die helpen met het oplossen van dit raadsel. De hints worden zoveel mogelijk evenredig verdeeld over de spelers met de app om interactie tussen de spelers van de groep te bevorderen. Als er meer hints zijn dan spelers dan krijgen (sommige) spelers meerdere hints en als er meer spelers dan hints zijn krijgen meerdere spelers dezelfde hints. Als de groep het antwoord denkt te weten vult één iemand van de groep dit antwoord in en wordt er gecontroleerd of dit antwoord juist is. 3.3.2

Rebus

Een rebus bestaat uit figuren die een woord(deel) voorstellen en letters die toegevoegd, verwijderd of vervangen moeten worden door andere letters. Bij deze opdracht wordt een rebus opgedeeld in meerdere plaatjes en zoveel mogelijk evenredig verdeeld over de spelers met de app. De groep moet nu deze plaatjes in de goede volgorde zetten (de volgorde staat per plaatje aangegeven omdat het anders te moeilijk wordt) en vervolgens de rebus oplossen. De oplossing van de rebus is altijd een vraag en het antwoord kan weer door één iemand van de groep worden ingevuld. 3.3.3

Zet de plaatjes in de goede volgorde

Bij deze opdracht moeten plaatjes in de juiste, logische volgorde worden gezet. Op de locatie van deze opdracht liggen meerdere QR codes die een plaatje laten zien als ze gescand worden m.b.v. de app. Als een speler een plaatje scant wordt deze bijgehouden in de app in een lijst van plaatjes die gescand zijn. Een speler kan dan een plaatje uit deze lijst toevoegen aan het antwoord. De spelers moeten dus eerst bepalen wat de juiste, logische volgorde is en vervolgens de plaatjes in deze volgorde opsturen.

9

Game concept

3.3.4

Meerkeuze vraag

De spelers krijgen een vraag te zien en moeten bepalen welk meerkeuze antwoord juist is. De antwoorden zijn weer zoveel mogelijk evenredig verdeeld over de spelers met de app, maar voordat een speler zijn antwoorden te zien krijgt moet hij of zij eerst nog de juiste QR code scannen. Op deze locatie liggen namelijk weer meerdere QR-codes en de antwoorden zijn ’verstopt’ achter deze QR codes. Elke speler moet eerst de QR codes scannen om zijn of haar antwoorden te vinden en hierna kan worden bepaald wat het juiste antwoord is, waarna één iemand van de groep dit antwoord weer opstuurt.

3.4

Route

Een route bestaat uit een beginpunt (van waar de groepjes worden weggestuurd), meerdere locaties waar opdrachten worden uitgevoerd (deze verschillen per opleiding) en een eindpunt (waar de groepjes uiteindelijk weer samenkomen). Om ervoor te zorgen dat de groepjes zoveel mogelijk verspreid worden door het gebouw worden ze zo gelijk mogelijk verdeeld over de stands. Groepje één zal vanaf het startpunt naar stand één worden gestuurd, groepje twee naar stand twee enz. Als er meer groepjes dan stands zijn wordt dit herhaald en zal het volgende groepje ook naar stand één worden gestuurd, het groepje daarna naar stand twee enz. Op deze manier wordt voorkomen dat er veel groepjes bij één bepaalde stand staan, terwijl bij een andere stand misschien geen groepjes zijn. De locaties waar de opdrachten worden uitgevoerd en de routebeschrijvingen kunnen gezien worden als een cycle in een graaf. In Figuur 3.1 is uitgebeeld hoe dit eruit ziet, waarbij de knopen van de graaf de stands voorstellen en de paden de routebeschrijvingen. Omdat de eerste en laatste knoop uit deze cycle verschilt per groep moet er een routebeschrijving worden gemaakt voor het beginpunt naar elke knoop in de cycle en vanaf elke knoop in de cycle naar het eindpunt. Figuur 3.1: Graaf representatie van mogelijke routes

10

Planning

4

Planning

In dit hoofdstuk zal kort worden toegelicht welke ontwikkelmethode is gebruikt en hoe de planning is opgesteld. Door overleg met en feedback van de begeleider en opdrachtgever verschillen sommige onderdelen in de daadwerkelijke sprints met die van de planning. Ook is er besloten om een week langer door te gaan om de laatste dingetjes af te ronden.

4.1

Globale planning

Tijdens dit project werd de software ontwikkelmethode Scrum gebruikt, wat betekent dat het product ontwikkeld wordt in korte sprints waarbij aan het eind van elke sprint een werkend prototype beschikbaar is. Dit heeft als voordeel dat dit prototype na afloop van elke sprint getest kan worden en er gemakkelijk wijzigingen kunnen worden aangebracht aan het product tijdens de implementatie fase. Ook leent dit project zich hier goed voor door onder andere de verschillende opdrachten die ge¨ımplementeerd moesten worden. Aan het begin van het project is daarom een planning opgesteld die wordt weergegeven in Figuur 4.1. De daadwerkelijke planning is hier uiteindelijk iets van afgeweken, deze wordt weergegeven in Figuur 4.2. Figuur 4.1: Planning

Figuur 4.2: Daadwerkelijke planning

11

Planning

4.2

Sprints

De implementatiefase bestaat uit vier sprints. In elke sprint wordt er meer functionaliteit toegevoegd aan het systeem en aan het eind van elke sprint is er een nieuw prototype wat getest kan worden. Tabel 4.1 is een verdeling gemaakt van de functionaliteiten die per sprint worden toegevoegd en wat het resultaat van elke sprint is. Deze tabel is aan het begin van het project gemaakt. Tijdens het project waren een aantal veranderingen ingevoerd waardoor de sprint planning veranderd was. Deze planning wordt weergegeven in Tabel 4.2. Tabel 4.1: Planning van de vier sprints Sprint

Functionaliteit

Resultaat sprint

• Inlogscherm • Hoofdscherm • Server en database verbinding 1

Het is mogelijk om in te loggen, in een groep te komen en met de groep de minigame ’raadsels’ te spelen door een QR-code te scannen.

• Database tabellen • Groep implementatie • QR-code scanner • Opdracht scherm • Minigame : Raadsels • Score implementatie • Ranking scherm • Route scherm

2

Alle schermen, de verhaallijn en scores zijn ge¨ımplementeerd. Het is mogelijk om een rondleiding te doen, maar grafisch is het nog niet aantrekkelijk.

• Groep scherm • Journal scherm inclusief Mijlpalen • Route berekening • Minigame : Woorddelen • Minigame : Rebus • Minigame : Plaatjes

3

• Sharen met Facebook • Thuis spel • Website om content toe te voegen aan het spel

Alle opdrachten zijn ge¨ımplementeerd. Het grafische gedeelte ziet er beter uit. Het merendeel van thuis spelen en de mogelijkheid om content toe te voegen is af.

• Grafische verbetering • Grafische verbetering 4

Alle functionaliteit die is toegevoegd is af en getest en ook het grafische gedeelte is af. Het enige wat nog moet worden toegevoegd is de inhoud van opdrachten.

• Afronden implementatie • Verslag

12

Planning

Tabel 4.2: Daadwerkelijke planning van de sprints Sprint

Functionaliteit

Resultaat sprint

• Inlogscherm • Hoofdscherm • Server en database verbinding • Database tabellen 1

Het is mogelijk om in te loggen, in een groep te komen en met de groep de minigame ’raadsels’ te spelen door een QR-code te scannen.

• Groep implementatie • QR-code scanner • Opdracht scherm • GCM implementatie • Minigame : Raadsels • Score implementatie • Ranking scherm • Route scherm

2

• Groep scherm • Journal scherm inclusief Mijlpalen

Alle schermen, de verhaallijn en scores zijn ge¨ımplementeerd. Het is mogelijk om een rondleiding te doen, maar grafisch is het nog niet aantrekkelijk.

• Route berekening • Minigame : Rebus • Minigame : Plaatjes 3

• Sharen met Facebook

Drie opdrachten zijn ge¨ımplementeerd. Het merendeel van thuis spelen en de mogelijkheid om content toe te voegen is af.

• Thuis spel • Website om content toe te voegen aan het spel • Minigame : Meerkeuze

4

• Grafische verbetering

Alle functionaliteiten zijn merendeels af.

• Thuis spel Afronding

• Afronden implementatie

Alle functionaliteiten die zijn toegevoegd zijn af en getest. Het enige wat nog moet worden toegevoegd is de inhoud van opdrachten.

• Verslag

13

Ontwerp en implementatie

5


In dit hoofdstuk zal dieper in worden gegaan op het ontwerp en de implementatie van het systeem. Allereerst zal er een overzicht worden gegeven van het globale ontwerp en daarna wordt er toegelicht welke bestaande mogelijkheden gebruikt zijn voor de implementatie van het systeem. Als laatste zal er dieper ingegaan worden op de drie onderdelen van het systeem, namelijk de client, server en de website.

5.1

Model, view controller

Voor het ontwerp van de applicatie is er gekozen voor het model-view-controller model (Figuur 5.1). Dit betekent dat de data (model), grafische user interface (view) en de logica (controller) van elkaar gescheiden zijn. Het scheiden van deze onderdelen heeft als voordelen dat het de leesbaarheid en uitbreidbaarheid van de code bevordert. De data van de gebruiker, zoals aantal punten en sterren, wordt opgeslagen in een database op de server en haalt de client deze gegevens op als de gebruiker inlogt. Ook data van de opdrachten, de route en dergelijke wordt opgeslagen in de database. De client beschikt verder over klassen met variabelen die gebruikt worden om data in het geheugen van de telefoon op te slaan, zodat deze data niet opnieuw vanuit de database hoeft worden opgehaald zolang de app draait. De controller wacht op events en verwerkt deze. Bij deze applicatie zijn dat vooral user inputs en berichten van de server. Wanneer een gebruiker bijvoorbeeld op de knop ”verstuur” klikt bij een opdracht wordt een functie aangeroepen die het antwoord naar de server stuurt. De view geeft informatie weer aan de gebruiker in de vorm van een grafische user interface. Knoppen, icoontjes en andere interface elementen geven de user input door aan de controller die dit verder afhandelt. Figuur 5.1: Model-view-controller

14


5.2

Tools en libraries

Ter ondersteuning van de implementatie van het systeem zijn een aantal hulpmiddelen gebruikt, die ervoor hebben gezorgd dat de ontwikkeling sneller is verlopen. In de volgende paragrafen zullen deze verder worden toegelicht. 5.2.1

Unity

Voor de client side hebben we ter ondersteuning de game engine Unity [1] gebruikt na een vergelijking tussen verschillende soorten game engines (zie Appendix E). Het gebruik van een game engine heeft vele voordelen. Zo heeft Unity een uitgebreide editor waarmee makkelijk voor verschillende scherm resoluties kan worden getest, ondersteunt het meerdere platforms en zijn er veel (gratis) assets te vinden in de Unity Asset Store [2] die gebruikt kunnen worden. Binnen Unity is er verder gekozen voor C# als programmeertaal. 5.2.2

Github

Als versiebeheer systeem is er gekozen om Github te gebruiken [3], aangezien dit door ons al vaker is gebruikt tijdens de studie en er dus al ervaring mee was. Bij Github wordt code eerst lokaal op de PC opgeslagen en als code samengevoegd moet worden met dat van teamgenoten wordt het naar de de remote repository op het internet gestuurd. Voor de nieuwe functionaliteit zal telkens een aparte branch worden aangemaakt welke pas naar de hoofdbranch (de master) wordt gepushed als deze functionaliteit af en getest is. Hierdoor bestaat er altijd een werkend prototype en omdat voor elke feature een nieuwe branch kan worden aangemaakt leent dit systeem zich goed voor feature driven development (scrum). 5.2.3

Vuforia en ZXing

Om QR codes te herkennen is de Vuforia library [4] in combinatie met de ZXing library [5] gebruikt. Vuforia heeft een Unity extensie dat voornamelijk gebruikt wordt om augmented reality toe te kunnen passen in een applicatie, maar het kan ook gebruikt worden voor een QR of barcode scanner in combinatie met de ZXing library. De Vuforia extensie heeft een uitgebreid camera script dat als game object in Unity ge¨ımporteerd kan worden en het beeld van de camera op het scherm laat zien. De reden dat Vuforia wordt gebruikt om het camera beeld te verkrijgen is dat het elk Android toestel support met Android 2.3 of hoger, terwijl de standaard Unity WebcamTexture niet elk Android apparaat ondersteunt.

15


5.3

Push berichten

Om vanaf de server data te sturen naar mobiele telefoons worden push berichten gebruikt. Om berichten naar Android telefoons te sturen wordt de Google Cloud Message (GCM) dienst van Google toegepast [6]. Apples Push Notification Service (APNs) is nodig om push berichten naar iPhones te sturen [7], wat tijdens dit project niet ge¨ımplementeerd is (zie paragraaf 6.2). Push berichten bevatten data in JSON formaat, een populair formaat voor dataoverdracht [8], wat de applicatie kan uitlezen en verder kan afhandelen. Andere methodes die overwogen zijn om te gebruiken zijn polling [9] en long polling [10]. Bij polling moet echter vaak een request naar de server gestuurd worden met de vraag of er nieuwe data beschikbaar is, wat in verhouding meer energie verbruikt en wat voor een grotere belasting van de server zorgt. Ook zal hierdoor een delay zijn wanneer nieuwe informatie binnenkomt, terwijl push berichten meteen aankomen. Met long polling wordt een connectie met de server opengehouden totdat nieuwe informatie beschikbaar is, waarna deze informatie naar de client wordt gestuurd en dit proces wordt herhaald. De server die is gebruikt kan echter maximaal 250 connecties aan plus dat met zoveel connecties de server ook trager zou worden, waardoor dit ook geen geschikte methode was om te gebruiken voor ons systeem aangezien we van meer dan 250 spelers uit moeten gaan. Vandaar dat is gekozen voor push berichten. Om push berichten naar een telefoon te kunnen sturen moet eerst een registratie code worden verkregen, welke in de database wordt opgeslagen. Deze code wordt vervolgens gebruikt om push berichten naar die telefoon te sturen en om een unieke code aan een telefoon te geven, waarmee gecontroleerd kan worden of de gebruiker al bestaat. Dit wordt bijvoorbeeld gebruikt om gebruikers automatisch in te laten loggen als hij of zij de applicatie opstart en al een keer eerder heeft ingelogd. De push berichten worden voornamelijk gebruikt voor de opdrachten om bijvoorbeeld aan te geven dat een opdracht is gestart of als iemand een antwoord heeft opgestuurd, waardoor iedereen meteen het resultaat hiervan krijgt te zien. Om ervoor te zorgen dat de verbinding tussen de GCM servers en de clients open blijft wordt er om de vier minuten een ”hearbeat” bericht gestuurd van de server naar alle clients die op dat moment met de rondleiding bezig zijn. Dit is een bericht dat ervoor zorgt dat de router niet de connectie met de GCM servers verbreekt wegens inactiviteit. Sommige routers verbreken deze verbinding met een telefoon na een x aantal minuten van inactiviteit, wat er voor zorgt dat push messages niet meer aankomen op deze telefoon totdat er een nieuwe connectie wordt aangemaakt met de GCM servers. Dit gebeurt na 15 minuten op wifi en 28 minuten op 3G, of als de verbinding handmatig uit en aan wordt gezet. Omdat push berichten een belangrijk onderdeel van de applicatie zijn is het dus noodzakelijk deze verbinding open te houden, om te verzekeren dat alle push berichten ook aankomen. Het wilt echter een enkele keer wel is voorkomen dat de verbinding met de GCM service al verbroken is als de applicatie wordt opgestart. Dit probleem kan worden opgelost door de internetverbinding uit en aan te zetten, waardoor de connectie met de GCM service opnieuw aangemaakt wordt.

16


5.4

Client

De client is applicatie die op de telefoons van de gebruikers komt te staan. Het is de bedoeling dat deze applicatie uiteindelijk in de Google Playstore en wellicht ook in de Appstore komt te staan, waardoor scholieren tijdens de open dag de app hiervandaan kunnen downloaden. De app communiceert verder met de server om informatie op te halen vanuit of op te slaan in de database. 5.4.1

Communicatie met de server

Naast push berichten om informatie van de server naar de clients te sturen kan een client ook een request sturen naar een webpagina op de server, die dan een response teruggeeft in JSON formaat. Dit wordt gebruikt wanneer de client informatie op wilt halen van de server of iets aan de database wilt aanpassen (bijv. een nieuwe user toevoegen). Om dit makkelijk uitbreidbaar en testbaar te maken is er gekozen voor een Factory systeem, waarbij de Factory aan de hand van het type Message dat naar de server wordt gestuurd bepaalt wat voor Response klasse er moet worden aangeroepen. Een Message klasse bevat variabelen die aan de request URL worden toegevoegd en de Response klasse haalt de verschillende variabelen uit het JSON object dat de server terugstuurt. Ditzelfde principe wordt toegepast bij de afhandeling van de verschillende push berichten. Aan de hand van het type push bericht dat wordt ontvangen bepaalt de PushMessageHandlerFactory welke PushMessageHandler klasse, die het push bericht afhandelt, moet worden aangeroepen (zie Figuur 5.2 voor een overzicht van het klassendiagram van de client).

17


Figuur 5.2: Client klassendiagram

5.4.2

De verschillende schermen

De applicatie bevat verschillende schermen, waarbij elk scherm een ander doel heeft. In de eerste fase van het project zijn schetsen gemaakt van hoe de schermen er ongeveer uit zouden komen te zien, om alvast feedback van en goedkeuring van de opdrachtgever te krijgen. In Figuur 5.3 en 5.4 zijn de screenshots van de Hoofd en Route schermen te vinden, de rest van de schermen zijn terug te vinden in appendix A.2.

18


Figuur 5.3: Hoofd scherm

Figuur 5.4: Route scherm

De volgende schermen worden door de applicatie gebruikt: • Inlog scherm. Als de applicatie wordt opgestart is dit het eerste scherm dat wordt aangeroepen. Als de gebruiker nog niet eerder heeft ingelogd krijgt hij/zij dit scherm te zien en kan de gebruiker een username kiezen en door middel van een code inloggen. Bestaat de gebruiker al in de database dan wordt de gebruiker automatisch ingelogd en krijgt de gebruiker dit scherm niet te zien. • Hoofd scherm. De gebruiker krijgt dit scherm te zien als hij/zij is ingelogd . Vanuit dit scherm kan naar bijna elk ander scherm genavigeerd worden en als de gebruiker uit een ander scherm gaat keert deze vaak terug naar het hoofd scherm. Dit scherm bevat een aantal onderdelen. Allereerst is er de menu knop, linksboven in beeld, waarmee naar het Groep scherm, Journal scherm, Route scherm en Ranking scherm kan worden genavigeerd. Ten tweede is bovenaan het scherm een progressie balk te zien, die aangeeft hoeveel punten en ook welke mijlpalen er gehaald zijn. De robot (Eva) boven de progressie balk geeft aan hoe ver de groep is met de rondleiding. In de tekstballon in het midden van het scherm worden verder tips gegeven over het spel, of over iets dat te maken heeft met de opleiding. Daarnaast zijn er nog twee knoppen onder in het scherm, de QR scanner knop en de info knop. De QR scanner knop opent het QRScanner scherm en de info knop opent het Info scherm. Als er een opdracht actief is veranderd de QR scanner knop in een ”Join” knop en komt de gebruiker meteen op het Opdracht scherm terecht. 19


• Groep scherm. Dit scherm laat de namen van alle leden uit de groep zien. • Journal scherm. Alle mijlpalen die de gebruikers kunnen halen worden op dit scherm weergegeven. In het groen staan de mijlpalen die al gehaald zijn en in het rood de mijlpalen die nog gehaald moeten worden. • Route scherm. Hier komen de routebeschrijvingen die de gebruikers naar de verschillende stands leiden. Telkens als een opdracht is afgelopen keren de gebruikers terug naar dit scherm, waar ze vervolgens een nieuwe routebeschrijving te zien krijgen. • Ranking scherm. Op dit scherm worden de scores en sterren van alle groepen weergegeven. De gebruiker kan kiezen om alleen de scores van zijn opleiding te zien of die van alle opleidingen. Met de Facebook knop kan de score van de groep ook gedeeld worden op Facebook. • QRScanner scherm. Dit scherm start de camera en laat het beeld van de camera zien, waarmee een QR code kan worden gescand. De QR scanner wordt gebruikt om de QR code bij de stand te scannen om een opdracht te starten en voor de opdrachten ”Zet de plaatjes in de goede volgorde” en ”Meerkeuzevraag”. Als de QR code van de stand wordt gescand gaat de gebruiker naar het Lobby scherm en als een QR code van één van de twee opdrachten wordt gescand wordt respectievelijk een plaatje of een meerkeuze antwoord weergegeven. Een QR code wordt alleen herkend als de juiste pre condities waar zijn (er wordt bijvoorbeeld geen meerkeuze antwoord weergegeven als er geen Meerkeuze opdracht actief is). • Lobby scherm. Voordat de opdracht gestart wordt krijgen de gebruikers eerst het Lobby scherm te zien. Op dit scherm staat uitleg over de opdracht en komen spelers in een zogenaamde lobby terecht. Zodra één speler op ”Ready” klikt zal binnen 45 seconden een nieuwe opdracht worden gestart of als iedere speler uit de groep op ”Ready” heeft geklikt zal de opdracht meteen starten. Alleen de spelers die op ”Ready” hebben geklikt worden meegenomen in de verdeling van hints, rebus delen en meerkeuze antwoorden. Dit zorgt ervoor dat spelers die geen verbinding hebben of (tijdelijk) gestopt zijn met de rondleiding niet ook delen van de opdracht krijgen, want zouden zij deze wel krijgen kan de opdracht misschien niet meer worden opgelost. De spelers die aanvankelijk niet ”Ready” waren in de lobby kunnen later nog wel steeds meedoen met de opdracht, maar zij krijgen dan geen hints, rebus delen of meerkeuze antwoorden te zien. • Opdracht scherm. Dit scherm wordt gebruikt voor de vier verschillende soorten opdrachten. Per opdracht verschilt de Graphical User Interface (GUI), maar er zijn wel voor elke opdracht een aantal overeenkomsten. Zo wordt er altijd een klok weergegeven met daarnaast hoeveel seconden de groep nog heeft voor de opdracht. Ook staat er altijd rechtsboven een help knop (het lampje) die nog eens de uitleg van de opdracht laat zien. Mochten de gebruikers tijdens de opdracht iets nog niet snappen kunnen ze hier de uitleg teruglezen. Als een opdracht is afgelopen wordt het Route scherm aangeroepen en krijgen de spelers de route naar de volgende locatie te zien. • Info scherm. Op dit scherm kan de gebruiker informatie terugvinden over Eva en uitleg over het spel en de verschillende opdrachten. 20


• Thuisopdracht scherm. Als de rondleiding is afgelopen veranderd de QR scanner knop op het Hoofd scherm in een knop die naar dit scherm leidt. Op dit scherm kan de gebruiker kiezen wat voor soort opdracht hij/zij wilt maken, waarna de gebruiker naar het Opdracht scherm gaat en deze opdracht kan maken. 5.4.3

Popups

Om belangrijke gebeurtenissen te melden aan de gebruiker worden pop-ups gebruikt. Een pop-up is een klein venster met een melding dat bovenop het bestaande scherm verschijnt. Belangrijke gebeurtenissen zijn bijvoorbeeld een opdracht dat is gestart (Figuur 5.5) of als een goed of fout antwoord is opgestuurd (Figuur 5.6 en 5.7).

Figuur 5.5: Popup start op- Figuur 5.6: dracht antwoord

Popup goed Figuur 5.7: antwoord

21

Popup fout


5.5

Server

Om het multiplayer aspect van het spel te beheren is er gekozen voor een server met een database. Het doel van de server is om op één centrale plek gegevens over het spel bij te houden, zoals gebruikers, scores en actieve opdrachten, om requests van de clients af te handelen en om push berichten naar telefoons te sturen. Ook wordt op de server de website gehost (zie paragraaf 5.6). Op de TU was een webserver beschikbaar met PHP en MySQL. Aangezien we beiden al bekend waren met PHP en MySQL vonden we het een goed idee om deze omgeving te gebruiken voor de implementatie van de server. Er is ook nog onderzoek gedaan naar gratis alternatieve Backend as a Service (BaaS) modellen [11], wat redelijk wat werk uit handen kan nemen. De gratis mogelijkheden hebben echter altijd een limiet op het aantal API calls en/of push berichten die verstuurd kunnen worden en als hier overheen gegaan wordt moet er betaald worden. Aangezien niet duidelijk is hoeveel calls of push berichten er verstuurd gaan worden tijdens een open dag is er uiteindelijk gekozen voor de gratis server van de TU. Om ervoor te zorgen dat het systeem voldoet aan de eis dat gameplay en content gescheiden zijn wordt veel informatie opgeslagen in de database in plaats van in de applicatie zelf. Hierdoor kan de opdrachtgever zelf inhoud toevoegen aan verschillende onderdelen van het spel, zoals opdrachten en routebeschrijvingen. Dat kan via de website zoals besproken wordt in paragraaf 5.6. Dit betekent ook dat een rondleiding kan worden gemaakt voor elke studie van de TU Delft, dus de applicatie werkt niet alleen maar voor studies van de faculteit EWI, maar kan in theorie overal op de TU (of zelfs andere universiteiten) gespeeld worden. 5.5.1

Database

De MySQL database wordt gebruikt om data van de spelers, de rondleiding en de opdrachten in op te slaan. Een diagram van de database is te zien in Appendix B. Het grootste gedeelte van de database bestaat uit informatie over (actieve) opdrachten. Voor elke van de vier soorten opdrachten zijn twee tabellen in de database aangemaakt, een tabel waarin informatie over de opdrachten kan worden gezet (bijvoorbeeld een vraag, antwoord en hints in het geval van een raadsel) en een tabel waarin de actieve opdrachten, een opdracht waar een groep mee bezig is, van die soort worden bijgehouden. In het geval van een raadsel, rebus of meerkeuze opdracht worden in deze actieve opdrachten tabellen ook bijgehouden welke speler welke hints, rebus delen of meerkeuze antwoorden toegekend heeft gekregen. Een route wordt opgeslagen in de Stands tabel. Hier komen alle stands van die route te staan en voor elke stand een routebeschrijving hoe men van de vorige stand naar deze stand moet lopen. De routes verschillen per opleiding, dus vandaar dat er per opleiding een aparte route kan worden toegevoegd. In de tabel Opdrachten Per Stand wordt verder aangegeven welke opdracht(en) bij een stand gegeven worden. Andere inhoud dat door de opdrachtgever kan worden toegevoegd, zoals mijlpalen, tips en groepen, wordt opgeslagen in respectievelijk de Journal, Tips en Groep tabellen. Data over de speler, zoals score, sterren, GCM registratie id en naam wordt in de player tabel opgeslagen en wordt opgehaald als de speler inlogt. Een andere functionaliteit van de MySQL database dat wordt gebruikt is de event scheduler [12]. Met de event scheduler kunnen events gemaakt worden die op een bepaald 22


tijdstip één of meerdere keren worden uitgevoerd. De event scheduler wordt gebruikt om opdrachten op te ruimen als deze niet binnen de tijd is opgelost, om na 45 seconden een opdracht te starten als niet elke speler in de lobby op ”Ready” heeft geklikt en om elke dag een aantal ”opdracht punten” aan de spelers te geven, die ze kunnen gebruiken om thuis een opdracht mee te maken. 5.5.2

PHP

Om data toe te voegen of op te halen vanuit de database kan de client een POST of GET request sturen naar een PHP pagina op de server. Het script dat wordt aangeroepen handelt deze request verder af en bepaalt aan de hand van de meegegeven parameters welke data uit de database moet worden gehaald of welke data aan de database moet worden toegevoegd. Nadat de server de request heeft afgehandeld wordt een antwoord in JSON formaat teruggestuurd naar de client. Hiervoor is een Message klasse gemaakt waarmee een Message object kan worden aangemaakt, waar vervolgens parameters aan toegevoegd kunnen worden die dan in het JSON formaat worden omgezet, wat makkelijk leesbaar is voor mensen en de client makkelijk af kan handelen. Een volledig overzicht van het klasse diagram is te zien in Figuur 5.8. Om berichten naar meerdere clients te sturen worden er push berichten gebruikt (zie paragraaf 5.3). De push berichten bevatten een ”Type” parameter, waarmee de client kan bepalen om wat voor push bericht het gaat. Als bijvoorbeeld een raadsel opdracht wordt gestart krijgt iedereen in de groep een push bericht met type ”new riddle”, waardoor de client weet dat hij een NewRiddlePushMessage moet aanmaken. Push berichten worden bij de volgende situaties verzonden naar leden van de groep: • Iemand van de groep scant de QR code bij de stand, waardoor iedereen van de groep een push bericht krijgt dat een nieuwe opdracht op het punt staat om te beginnen. De spelers krijgen dan een popup te zien en als er op ”Join” wordt gedrukt wordt het Lobby scherm geopend. • Als iemand van de groep op ”Ready” klikt in de lobby. De rest van de spelers krijgt dan een push bericht die ”Ready” voor de naam van deze speler in de lobby zet. • Iemand van de groep stuurt een antwoord op naar de server. Er wordt een push bericht verstuurd naar de overige spelers of dit antwoord goed of fout is en dit wordt weergegeven met behulp van een popup. In het geval van de plaatjes opdracht wordt de nieuwe antwoord volgorde meegestuurd als iemand een plaatje toevoegt aan het antwoord en wordt geen popup weergegeven als nog niet alle plaatjes in de antwoord volgorde voorkomen. • Om de vier minuten wordt een heartbeat bericht verstuurd naar alle clients die bezig zijn met de rondleiding. Op de server draait een script in de achtergrond die om de vier minuten een heartbeat bericht stuurt naar alle clients die op dat moment bezig zijn met de rondleiding.

23


Figuur 5.8: Server klassendiagrammen

5.6

Website

Om aan de eis te kunnen voldoen dat gameplay en content gescheiden moeten zijn is er een website ontwikkeld waarmee inhoud toegevoegd kan worden aan de database, wat vervolgens daar de applicatie gebruikt kan worden. Op de website kan de opdrachtgever makkelijk informatie zoals, groepen, routes, mijlpalen en opdrachten toevoegen. De website is ontwikkeld met HTML, PHP en Twitter Bootstrap [13], een front-end framework dat er voor zorgt dat het ontwikkelen makkelijker en sneller gaat. De opdrachtgever kan inloggen op de website met een inlognaam en wachtwoord en kan vervolgens een onderdeel kiezen waar ze informatie aan wilt toevoegen. In Appendix A.1 worden verschillende screenshots van de website weergegeven. 24

Ontwikkelproces

6

Ontwikkelproces

In dit hoofdstuk zal verder worden toegelicht hoe het ontwikkelproces van het project is verlopen. Allereerst zal het verlopen van elke projectfase worden toegelicht, waarna zal worden uitgelegd waarom het niet gelukt is om tijdens dit project de applicatie ook voor de iPhone werkend te krijgen.

6.1

Project fases

Aan het einde van elke sprint wordt een nieuw prototype aan de opdrachtgever en begeleider laten zien, waarna de feedback meegenomen wordt in de volgende sprint. Ook is er veel mail contact geweest met de opdrachtgever en begeleider om afspraken te maken of korte vragen te stellen of uitleg te geven als iets niet helemaal duidelijk was. Doordat sommige onderdelen meer tijd hebben gekost dan gedacht, is in de vierde sprint besloten om nog een extra week door te gaan om de de laatste dingetjes nog toe te kunnen voegen. 6.1.1

Onderzoek & design

In de onderzoeksfase werd er nagedacht over wat voor een applicatie gemaakt zou worden voor het project en hoe wij ervoor zorgen dat deze applicatie aan het eind van het project klaar is, waarvoor een Plan van Aanpak is gemaakt (zie Appendix D). In deze fase is de meeste tijd besteed aan het bedenken van een goed game concept. Hiervoor is er gekeken naar bestaande games en is er veel gebrainstormd. Doordat gebruikers die de applicatie niet op hun telefoon hebben ook mee moeten kunnen spelen was het lastig om iets leuks en speelbaar te verzinnen. Uiteindelijk hebben een game concept bedacht die goed gekeurd was door de opdrachtgever. Dit game concept is te vinden in Appendix E. Naarmate het project vorderde zijn er echter wel een aantal aanpassingen gemaakt in het concept. Naast het bedenken van een game concept was het ook belangrijk om een onderzoek te doen op de mogelijke tools die gebruikt kunnen worden om de applicatie te maken. In de design fase hebben we ideeën bedacht over hoe de applicatie er uit zal zien. Er werden in deze fase klassen diagrammen, use cases en een uitgebreide planning voor de rest van het project gemaakt. Ook werd er langzaam gestart met de ontwikkeling van de applicatie, voornamelijk om alvast bekend te raken met Unity. 6.1.2

Sprint 1

De functionaliteiten van de vier sprints zijn terug te vinden in Tabel 4.1. De doelen van de eerste sprint waren de mogelijkheid om een opdracht te doen en de basis functies zoals inloggen en database connectie te implementeren. In deze sprint werd ook het push bericht systeem ge¨ımplementeerd om al met meerdere mensen een opdracht te kunnen maken. Deze eerste drie weken zijn eigenlijk precies volgens de planning verlopen, er waren weinig problemen en het project liep dus goed op schema. 6.1.3

Sprint 2

Het voornamelijke doel van deze sprint was de implementatie van meerdere schermen. Tijdens het testen werd echter al snel een groot probleem gevonden, namelijk dat de ingebouwde camera functie van Unity, waarmee het camera beeld op het scherm kon

25

Ontwikkelproces

worden getoond en wat werd gebruikt om de QR code te herkennen, niet goed bleek te werken voor alle type telefoons. Om ervoor te zorgen dat dit wel voor elk type telefoon zou werken is besloten om de Vuforia library te gebruiken, die de iPhone en elke Android telefoons ondersteunt met Android 2.3 of hoger (zie paragraaf 5.2.3). Naast dit probleem was er ook nog een wijziging aan de opdracht woorddelen gedaan, die in zijn geheel is geschrapt en waarvoor later de meerkeuzevraag in de plaats is gekomen. De opdrachtgever vond deze opdracht inhoudelijk niet goed genoeg en het leek een te makkelijke opdracht voor de doelgroep, dus toen is tijdens deze sprint de rebus opdracht ge¨ımplementeerd. Aan het einde van deze sprint waren weer alle onderdelen van de planning (behalve dus de opdracht woorddelen) ge¨ımplementeerd, maar er waren wel nog wat problemen met de push berichten die soms niet aankwamen. In de volgende sprint hebben we verder naar dit probleem gekeken en hebben hier toen ook een oplossing voor gevonden. 6.1.4

Sprint 3

Het doel van deze sprint was het implementeren van de andere opdrachten, een begin te maken met het thuis spel en te beginnen met het ontwikkelen van de website. Behalve het implementeren van deze onderdelen was er ook veel tijd nodig voor het oplossen van bugs, zoals de push berichten die niet aankwamen. Ook zijn na overleg weer een aantal aanpassingen aangebracht aan het game concept, waardoor sommige onderdelen aangepast moesten worden. Voor de push berichten is uiteindelijk een methode gevonden waarmee om de paar minuten een ”heartbeat” bericht naar alle telefoons werd gestuurd, zodat de connectie open blijft en de push berichten wel aankomen (zie paragraaf 5.3). Uiteindelijk zijn we hier zoveel tijd aan kwijt geweest dat het niet gelukt is om alles van de planning te implementeren, grafisch was er nog niet veel verbeterd en ook de vierde opdracht (de meerkeuzevraag) was nog niet ge¨ımplementeerd. 6.1.5

Sprint 4

Aangezien dit de laatste sprint was moest alle overige functionaliteiten ge¨ımplementeerd worden. Omdat aan het begin van deze sprint al duidelijk was dat dit teveel werk was en niet zou lukken in twee weken is er besloten om een week langer door te gaan. Tijdens deze sprint was ook weer een aanpassing op het game concept gemaakt, namelijk wanneer de groep de routebeschrijving zou krijgen voor de volgende stand. Het originele idee was dat de groep maximaal een x aantal minuten bij een stand kon blijven, waarna ze de volgende routebeschrijving zouden krijgen. Dit moest er voor zorgen dat groepjes niet te lang bij een stand zouden blijven waardoor het daar te druk kon worden, maar het nadeel van dit systeem was dat de groep ook naar de volgende stand zou kunnen gaan zonder een opdracht te maken of zou moeten wachten bij een stand als de groep de opdracht snel oplost. In overleg met de opdrachtgever en de begeleider is toen besloten om deze timer weg te halen en pas de routebeschrijving naar de volgende stand te geven als een opdracht afgerond is. Een opdracht is afgerond als een goed of te vaak een fout antwoord wordt gegeven, of als de tijd om is. Ook heeft tijdens deze sprint de gebruikers test plaatsgevonden, waarmee veel foutjes zijn ontdekt in het systeem die ook nog opgelost moesten worden. Dit heeft ook weer veel tijd gekost, maar aan het einde van deze sprint was het merendeel van alle functionaliteit wel zo goed als af.

26

Ontwikkelproces

6.1.6

Afronding

In deze week werden puntjes op de i gezet. De layout van de applicatie en de website zijn verbeterd en de laatste functionaliteiten zijn toegevoegd. Ook is de code voor de tweede keer naar SIG verstuurd om de onderhoudbaarheid van de code te testen. Daarnaast zijn ook plannen gemaakt om de grafische onderdelen van de app te bespreken met een paar IO studenten, die bereid zijn om voor ons nog mooiere plaatjes te gaan maken die toegevoegd kunnen worden aan de applicatie.

6.2

iPhone

Het is helaas niet gelukt om tijdens het project de applicatie ook helemaal werkend te krijgen voor de iPhone. Om de applicatie voor de iPhone te laten werken moet namelijk de Apple Push Notification Service nog worden ge¨ımplementeerd, waarmee ook push berichten naar de iPhone kunnen worden gestuurd. Hier is echter een Apple developer account voor nodig [14], wat 99 dollar per jaar kost en waar een credit card voor nodig is, en deze moet nog worden aangevraagd. Ook is het niet zeker of de push berichten van Apple betrouwbaar genoeg zijn, wat ook nog uitvoerig getest zal moeten worden.

27

Kwaliteit en testen

7

Kwaliteit en testen

Om de applicatie te testen zijn er gebruik gemaakt van unit tests, zowel aan de client als aan de server kant, en heeft er in de vierde sprint een gebruikers test plaatsgevonden. Dankzij deze gebruikers test zijn nog redelijk wat foutjes gevonden in de applicatie die er nog uitgehaald konden worden.

7.1

Server

Voor het testen van de server kant is PHPUnit [15] gebruikt, wat een PHP testing framework is. Hiermee was het mogelijk om unit tests uit te voeren door middel van assertions. Door het gebruik van unit tests werd elke methode apart getest. Voor het testen werden bij een methode passende variabelen meegegeven waarmee getest werd of de uitkomst van de methode hetzelfde is als wat er verwacht wordt. Met PHPUnit was het ook mogelijk om een code coverage overzicht te maken. Een code coverage overzicht laat precies zien welke regels code er wel en niet zijn getest. Het doel was om zo hoog mogelijk percentage geteste code te krijgen, maar het was ook belangrijk om een goede balans te vinden tussen gespendeerde tijd en de behaalde coverage. Figuur 7.1 laat de code coverage van de server unit tests zien, waaruit kan worden afgeleid dat er voor de server tests een coverage van meer dan 90% is gehaald. Voor de Message (en bijbehorende) klassen was een lagere coverage gehaald, omdat in deze klassen methoden zijn die gebruik maken van cURL functies die lastig te testen zijn. Figuur 7.1: PHP code coverage

7.2

Client

Om de client code te testen is de eigen test tool van Unity gebruikt genaamd Unity Test Tools. Unity Test Tools kan worden gedownload via de Unity asset store en werd gebruikt om de C# code binnen Unity te testen op basis van unit tests. Het principe van unit tests van Unity Test Tools is hetzelfde als die van PHPUnit.

7.3

Gebruikers test

Naast het testen van de code is het ook belangrijk om de applicatie zelf te testen met echte gebruikers. Aan het einde van de vierde sprint is de applicatie getest door elf personen. Het doel van deze test was voornamelijk om praktische punten zoals de opdrachten, de route van de rondleiding, het internet bereik binnen de faculteit, de speeltijd en de push berichten van de applicatie te testen. 28

Kwaliteit en testen

De test is als volgt opgezet. De groep werd in drie kleinere groepen verdeeld, elk met drie of vier man, en elke groep representeerde een andere opleiding (TI, TW en EE). Elke groep volgde dus een andere route door de faculteit, maar de opdrachten waren voor elke groep hetzelfde aangezien er geen tijd was om veel soorten opdrachten te bedenken. Tijdens de testdag kwamen de volgende problemen naar voren: • Twee groepen konden niet goed de opdrachten maken, want één persoon van de groep was twee keer ingelogd. Het probleem hiermee was dat de applicatie niet altijd een registratie ID doorkreeg voor de GCM dienst, waardoor de gebruiker meerdere keren kon inloggen. • Push berichten die niet binnen kwamen of verkeerd werden afgehandeld. Soms werd een verkeerd bericht weergegeven als de opdracht werd gestart, met de melding dat de opdracht correct is beantwoord. Er bleken nog een aantal foutjes te zitten in de manier waarop de push berichten werden afgehandeld. De reden dat sommige push berichten niet binnenkwamen was dat, net als bij het vorige punt, de applicatie geen registratie ID had verkregen. • Opdrachten die te lang duurden of niet duidelijk waren. Met name de plaatjes opdracht bleek te ingewikkeld om snel mee te kunnen beginnen. Deze is aan de hand van de feedback van de testpersonen aangepast om het wat duidelijker te maken en het bleek dat zeven plaatjes te veel zijn om binnen de tijd in de goede volgorde te zetten, dus dat zal ook verminderd moeten worden. • Niet werkende wifi op verschillende locaties. Op een aantal locaties in laagbouw en in de /pub bleek er geen wifi verbinding te zijn, waardoor de opdrachten niet gespeeld konden worden. Voor de echte rondleiding zal voor elke stand nog getest worden of op die locatie ook een goede wifi verbinding beschikbaar is. • In het algemeen duurde de rondleiding te lang. Tijdens de testdag bestond de route uit acht locaties. Aangezien dit te lang bleek te zijn worden het aantal stands gereduceerd tijdens de echte rondleiding. Aan de hand van deze problemen zijn aanpassingen aangebracht aan de applicatie. Het nadeel van de push berichten is echter dat dit niet volledig onder onze controle is, waardoor het nog steeds mogelijk is dat deze niet bij de gebruikers aankomen. Wel zijn de push berichten die soms fout afgehandeld werden aangepast. Niet alleen was de demo voor ons nuttig, maar ook voor de opdrachtgever. Voor de komende rondleiding kan zij beter inschatten hoeveel stands en waar deze stands moeten komen te staan en welke opdrachten passend zijn. Ook heeft zij een betere inzicht gekregen over hoe de applicatie tijdens de rondleiding gebruikt zal worden.

29

Kwaliteit en testen

7.4

SIG feedback

Halverwege en tegen het einde van het project hebben we onze code naar SIG verstuurd om de code te evalueren op onderhoudbaarheid. De feedback van SIG is te vinden onder Appendix C. 7.4.1

Eerste feedback

Voor de eerste feedback heeft SIG de code vier sterren gegeven, wat laat zien dat de code bovengemiddeld onderhoudbaar is. Er zijn twee punten waar onze code de hoogste score niet heeft behaald, namelijk duplicatie en unit size. Op basis van de feedback is er zoveel mogelijk duplicatie uit het systeem weg geprobeerd te halen door duplicatie code te omvatten in eenzelfde methode en deze aan te roepen waar nodig. Om de Unit Size te verminderen is gezocht naar de langere methodes en zijn deze korter gemaakt door ze op te splitsen in meerdere kleinere methodes. 7.4.2

Tweede feedback

Uit de tweede feedback van SIG is helaas gebleken dat de score voor onderhoudbaarheid van de code is gedaald. Er is wel een daling waargenomen van duplicatie in het PHP gedeelte, maar in het C# gedeelte is de duplicatie toegenomen. Het tegenovergestelde geldt voor de unit size, die is toegenomen in het PHP gedeelte en is verminderd in het C# gedeelte. Op basis hiervan concluderen ze dat er deels wat met de feedback is gedaan. De reden dat er bij de tweede feedback een slechtere score is verkregen is waarschijnlijk omdat er heel veel code is toegevoegd (de totale hoeveelheid code is met 183% gestegen) en dit in sommige gevallen niet altijd even netjes is gegaan, om maar snel functionaliteit af te krijgen aangezien het in de laatste paar weken heel druk was. Dit heeft dus helaas nadelig bijgedragen aan de score van de onderhoudbaarheid van de code.

30

Conclusie

8

Conclusie

Het doel van dit project was om een mobiele applicatie te ontwikkelen die de scholieren op een interactieve en leerzame manier kennis laten maken met de studie en de faculteit en dat makkelijk uitbreidbaar en schaalbaar is. Hiervoor is een game concept bedacht en door de toevoeging van de website kan de applicatie ook gebruikt worden voor andere opleidingen. Alle must haves van het MoSCoW model zijn ook gehaald, met als uitzondering de eis dat de applicatie ”iPhone klaar” moet zijn. Door een paar aanpassingen is het echter ook mogelijk de applicatie voor de iPhone uit te brengen. Met de uiteindelijke applicatie kan een speler in een groep een rondleiding volgen door een faculteit terwijl hij/zij opdrachten probeert op te lossen om studiepunten te halen om verder te komen in het spel en hoger op de ranglijst te komen. Deze score kan gedeeld worden op Facebook en na de rondleiding kan de speler nog individueel thuis verder spelen door overige opdrachten te maken, waarmee meer studiepunten worden verdiend en de speler hoger op de individuele ranglijst komt te staan. Het doel van het project is dus gehaald.

31

Aanbevelingen

9

Aanbevelingen

Hieronder volgen een aantal aanbevelingen waarmee het systeem in de toekomst kan worden uitgebreid. Voordat de open dagen beginnen zullen in ieder geval een aantal grafische elementen worden verbeterd en zal worden geprobeerd om de applicatie ook voor de iPhone werkend te krijgen.

9.1

Server

Tijdens het ontwikkelproces is een server van de TU Delft gebruikt. Het is echter niet zeker dat deze server ook een groot aantal mensen aankan die tegelijkertijd gebruik maken van de applicatie, omdat er veel connecties met de server zullen worden aangemaakt wat voor een zware belasting van de server zorgt. Aangezien wij ook niet de enigen zijn die van deze server gebruik maken is het aan te raden om een dedicated server, een server die niet gedeeld wordt met andere gebruikers, in te richten voor de open dagen.

9.2

Push berichten

Zoals vermeld wordt Google Cloud Messaging gebruikt om notificaties naar de telefoons te sturen. De betrouwbaarheid van GCM, wat betekent dat de notificaties bij het apparaat aankomen, is hoog wanneer er een connectie met de GCM service is gemaakt. Het wilt echter nog wel eens voorkomen dat deze connectie al is verbroken op het moment dat de applicatie voor het eerst wordt gebruikt. Door simpelweg de internetverbinding uit en aan te zetten is dit probleem al verholpen, maar dit is niet echt netjes. De eerder besproken long polling methode zou in dit geval in de toekomst toegepast kunnen worden mits er een server is die het aantal connecties toelaat.

9.3

MoSCoW model

Doordat er al extra tijd nodig was om het systeem op tijd af te krijgen is het niet gelukt verdere onderdelen van het MoSCoW model toe te voegen, wat eventueel in toekomstig werk gedaan zou kunnen worden.

32

Refentie

Referenties [1] Unity. http://unity3d.com/. Laatst bezocht op 03/07/2014. [2] Unity asset store. 03/07/2014.

https://www.assetstore.unity3d.com/en/.

Laatst bezocht op

[3] Github. https://github.com/. Laatst bezocht op 03/07/2014. [4] Vuforia. http://www.qualcomm.com/solutions/augmented-reality. Laatst bezocht op 03/07/2014. [5] Zxing. https://zxingnet.codeplex.com/. Laatst bezocht opn 03/07/2014. [6] Google cloud messaging. http://developer.android.com/google/gcm/index.html. Laatst bezocht op 03/07/2014. [7] Apple push notification service. https://developer.apple.com/library/ios /documentation/NetworkingInternet/Conceptual /RemoteNotificationsPG/Chapters/ApplePushService.html. Laatst bezocht op 03/07/2014. [8] Json. http://json.org/. Laatst bezocht op 03/07/2014. [9] Polling. http://en.wikipedia.org/wiki/Polling_(computer_science). Laatst bezocht op 03/07/2014. [10] Push technology. http://en.wikipedia.org/wiki/Push_technology. Laatst bezocht op 03/07/2014. [11] Backend as a service. https://cloud.google.com/developers/articles/mobile-backendstarter. Laatst bezocht op 03/07/2014. [12] Mysql event scheduler. http://dev.mysql.com/doc/refman/5.7/en/events.html. Laatst bezocht op 03/07/2014. [13] Twitter bootstrap. http://getbootstrap.com/. Laatst bezocht op 03/07/2014. [14] Apple developer account. 03/07/2014.

https://developer.apple.com/.

[15] Phpunit. http://phpunit.de/. Laatst bezocht op 03/07/2014.

33

Laatst bezocht op

Appendix

A A.1

Appendix : Screenshots Website

Hieronder worden een aantal screenshots van de website weergegeven. Niet alle schermen van de website zijn hieronder te vinden, want deze schermen zijn hier niet goed leesbaar. Figuur A.1: Inlog scherm

Figuur A.2: Hoofd scherm

34

Appendix

Figuur A.3: Groep scherm

35

Appendix

Figuur A.4: Mijlpaal scherm

36

Appendix

A.2

Applicatie

Figuur A.5: Inlog scherm

Figuur scherm

A.8:

Ranking

Figuur A.6: Welkom tekst

Figuur A.9: scherm

Groepsleden

37

Figuur A.7: Info scherm

Figuur scherm

A.10:

Journal

Appendix

Figuur A.11: Lobby info scherm

Figuur A.13: scherm

QRScanner

Figuur A.12: Lobby ready scherm

Figuur A.14: Raadsel opdracht scherm

38

Figuur A.15: dracht scherm

Rebus op-

Appendix

Figuur A.16: Plaatjes opdracht scherm

Figuur A.17: Meerkeuze opdracht scherm

39

Figuur A.18: dracht scherm

Thuis op-

Appendix

B

Appendix : Database diagram

40

Appendix

Figuur B.1: Database diagram opdrachten

41

Appendix

Figuur B.2: Database diagram overig

42

Appendix

C

Appendix : SIG aanbevelingen

Eerste feedback De code van het systeem scoort 4 sterren op ons onderhoudbaarheidsmodel, wat betekent dat de code bovengemiddeld onderhoudbaar is. De hoogste score is niet behaald door een lagere score voor Duplicatie en Unit Size. Voor Duplicatie wordt er gekeken naar het percentage van de code welke redundant is, oftewel de code die meerdere keren in het systeem voorkomt en in principe verwijderd zou kunnen worden. Vanuit het oogpunt van onderhoudbaarheid is het wenselijk om een laag percentage redundantie te hebben omdat aanpassingen aan deze stukken code doorgaans op meerdere plaatsen moet gebeuren. In dit systeem is er bijvoorbeeld duplicatie te vinden tussen de verschillende ’get.php’ paginas, binnen ’answer.php’, en de verschillende ’Awake’-methoden binnen de C#. Het is aan te raden om dit soort duplicaten op te sporen en te verwijderen. Voor Unit Size wordt er gekeken naar het percentage code dat bovengemiddeld lang is. Het opsplitsen van dit soort methodes in kleinere stukken zorgt ervoor dat elk onderdeel makkelijker te begrijpen, te testen en daardoor eenvoudiger te onderhouden wordt. Binnen de langere methodes in dit systeem, zoals bijvoorbeeld de ’OnGui’-methode binnen ’OpdrachtScherm’, zijn aparte stukken functionaliteit te vinden welke ge-refactored kunnen worden naar aparte methodes. Commentaarregels zoals bijvoorbeeld ’// Show the rebus images’ en ’// You can only call GUI functions inside OnGUI’ zijn een goede indicatie dat er een autonoom stuk functionaliteit te ontdekken is. Het is aan te raden kritisch te kijken naar de langere methodes binnen dit systeem en deze waar mogelijk op te splitsen. Over het algemeen scoort de code bovengemiddeld, hopelijk lukt het om dit niveau te behouden tijdens de rest van de ontwikkelfase. De aanwezigheid van test-code is in ieder geval veelbelovend, hopelijk zal het volume van de test-code ook groeien op het moment dat er nieuwe functionaliteit toegevoegd wordt. Tweede feedback In de tweede upload zien we dat de omvang van het systeem flink is gestegen (met 183%), maar dat daarbij de score voor onderhoudbaarheid is gedaald. Wat betreft de Duplicatie zien we een flinke daling van de hoeveelheid duplicatie binnen het PHP gedeelte van de applicatie, hier is 7% van de duplicatie verwijderd. Helaas zien we dat binnen de C# de hoeveelheid duplicatie is gestegen met 6%. Voor de Unit Size zien we dat er binnen het C# gedeelte methoden korter zijn gemaakt en kortere methoden zijn toegevoegd, maar dat aan de PHP kant langere methoden zijn ontstaan. Het is goed om te zien dat voor beide talen nieuwe test-code is ontwikkeld naast de productie code. Het valt op dat waar de C# is verbeterd de PHP is verslechterd, terwijl waar de PHP is verbeterd de C# is verslechterd. Uit deze observaties kunnen we concluderen dat de aanbevelingen van de vorige evaluatie deels zijn meegenomen in het ontwikkeltraject.

43

Appendix

D

Appendix : Plan van aanpak

44

Plan van aanpak Edward Teng en Tom Zwart April 2014

1

Contents Contents

2

1 Inleiding 1.1 Het plan van aanpak . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Achtergrond en aanleiding van de opdracht . . . . . . . . . . . .

3 3 3

2 Opdrachtomschrijving 2.1 Inleiding . . . . . . . . 2.2 De opdrachtgever . . . 2.3 Contactpersonen . . . 2.4 Probleemstelling . . . 2.5 Doelstelling . . . . . . 2.6 Opdrachtformulering . 2.7 Op te leveren product 2.8 Randvoorwaarden . . 2.9 Risicofactoren . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

3 3 4 4 4 4 4 5 5 6

3 Aanpak 3.1 Inleiding . . . . . . . . 3.2 Methodiek . . . . . . . 3.3 Techniek . . . . . . . . 3.4 Werkzaamheden . . . 3.4.1 Onderzoek . . 3.4.2 Design . . . . . 3.4.3 Implementatie 3.4.4 Testen . . . . . 3.5 Planning . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

6 6 6 6 7 7 7 7 7 8

4 Projectinrichting 4.1 Betrokkenen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2 Faciliteiten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8 8 8

5 Kwaliteitsborging 10 5.1 Inleiding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 5.2 De kwaliteit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 5.2.1 Versiebeheer . . . . . . . . . . . . . . . . . . . . . . . . . 10

2

1

Inleiding

In dit plan van aanpak worden de verschillende stappen beschreven die ervoor moeten zorgen dat er aan het eind van dit project een werkend product kan worden opgeleverd wat gebruikt kan worden tijdens de open dag van de TU Delft op de faculteit EWI. Er is behoefte aan verandering van de structuur van de open dag in EWI en in dit plan van aanpak staat beschreven hoe wij dit willen veranderen door middel van een interactieve mobiele game. Dit plan van aanpak kan naarmate het proces vordert worden bijgesteld als hier behoefte toe is.

1.1

Het plan van aanpak

Allereerst wordt informatie gegeven over de achtergrond van de opdracht en wordt beschreven wat de opdracht precies inhoudt. Ook wordt duidelijk aangegeven wat de randvoorwaarden zijn en hoe het uiteindelijke product eruit moet zien. Vervolgens wordt er dieper ingegaan op het proces en de planning, waarbij wordt uitgelegd welke technieken en methodes we gaan gebruiken tijdens dit proces. Als laatste wordt behandeld welke maatregelen we gaan nemen om aan de kwaliteitseisen van de opdrachtgever te voldoen.

1.2

Achtergrond en aanleiding van de opdracht

Tijdens de open dagen komen scholieren naar de TU Delft om meer informatie op te doen over een opleiding (of meerdere opleidingen) die ze wellicht willen gaan volgen. Er is echter behoefte aan een element wat ervoor zorgt dat de open dag een betere ervaring wordt voor de deelnemers. De Marketing en Communicatie afdeling van de faculteit EWI wilt dit bereiken door de scholieren met behulp van een interactieve, leerzame game een rondleiding te geven door de faculteit.

2 2.1

Opdrachtomschrijving Inleiding

De opdracht is om een leerzame, interactieve mobiele game te ontwerpen voor de open dag van de TU Delft die gespeeld kan worden op de faculteit EWI. De game moet de scholieren die naar deze open dag komen op een interactieve en leerzame manier kennis laten maken met de faculteit. Door middel van spelletjes, opdrachten of een andere vorm van interactie wordt een route door de faculteit verkregen langs verschillende informatieve stands. Dit moet ervoor zorgen dat de scholieren een leukere ervaring hebben tijdens de open dag en na afloop ook een beter idee hebben wat ze van de opleiding kunnen verwachten.

3

2.2

De opdrachtgever

Deze opdracht is aangeboden door Trudy Middendorp van de afdeling Marketing en Communicatie van de faculteit Elektrotechniek, Wiskunde en Informatica aan de TU Delft.

2.3

Contactpersonen

• Edward Teng ([email protected]) • Tom Zwart ([email protected]) • Rafael Bidarra ([email protected]) • Trudy Middendorp ([email protected])

2.4

Probleemstelling

Er worden ongeveer 500 scholieren per dagdeel voor de opleidingen Technische Informatica, Technische Wiskunde en Electrical Engineering verwacht voor de open dag, afgaande op informatie van voorgaande jaren. Deze scholieren worden verdeeld in groepjes van ongeveer 10 personen, dus er moet rekening gehouden worden met ongeveer 50 groepjes die tegelijkertijd de game gaan spelen. Het systeem moet niet alleen stabiel zijn bij zoveel mensen, maar moet er ook voor zorgen dat deze scholieren zo georganiseerd mogelijk worden rondgeleid. De game moet de scholieren zo veel mogelijk verspreiden door de faculteit, zodat er niet teveel groepjes op 1 plek zijn. De vragen en opdrachten mogen ook niet te lang duren, want de scholieren moeten langs meerdere stands gaan en kunnen niet heel lang bij één stand blijven. Ook de scholieren die geen mobiel hebben of die een mobiel hebben waar de game niet op ge¨ınstalleerd kan worden moeten aan de opdrachten mee kunnen doen.

2.5

Doelstelling

Het doel van deze opdracht is om 5 en 6 vwo scholieren die ge¨ınteresseerd zijn en zich willen verdiepen in de opleiding(en) Electrical Engineering, Technische Wiskunde en/of Technische Informatica tijdens de open dag op een leuke, leerzame en interactieve manier kennis te laten maken met hun gekozen opleiding en de faculteit middels een mobiele game.

2.6

Opdrachtformulering

In 11 weken moet een mobiele game worden gemaakt dat de volgende elementen bevat: • De game laat scholieren op een interactieve en leerzame manier kennis maken met de opleiding en de faculteit

4

• De game geeft scholieren tijdens de open dagen in groepjes een rondleiding door de faculteit en opleidingen

2.7

Op te leveren product

Het op te leveren product is een mobiele app voor tenminste Android en wellicht ook andere besturingssystemen (het is ook tenminste iPhone klaar). Deze app moet speelbaar zijn op de open dagen en kan ook thuis nog verder kunnen worden gespeeld. De game moet de scholieren een rondleiding geven door de faculteit en interactief zijn. Ook moet het mogelijk zijn om de game gemakkelijk verder uit te breiden met vragen/opdrachten en het moet uit te breiden zijn voor andere faculteiten.

2.8

Randvoorwaarden

De eisen waar het product aan moet voldoen zijn als volgt: • De game moet geschikt zijn voor Android (en is tenminste iPhone klaar) • De game moet schaalbaar zijn en moet tenminste gespeeld kunnen worden door 500 scholieren tegelijkertijd, verdeeld over groepjes van 10 personen • Iedereen in de groep moet mee kunnen doen met het oplossen van vragen, puzzels en dergelijke, ook mensen die geen telefoon hebben waar het spel op gespeeld kan worden • De game heeft een gameplay tijd van maximaal 60 minuten tijdens de open dag en kan thuis verder gespeeld kunnen worden • De inhoud van de vragen/opdrachten verschilt per opleiding • De game moet de scholieren langs verschillende stands, demo’s, faciliteiten en studenten projecten in de faculteit sturen • De game zorgt ervoor dat de groepjes zo gelijk mogelijk over de verschillende stands worden verdeeld • Er moeten scores gekoppeld worden aan vragen/opdrachten • Mogelijkheid tot sharen via social media • De vragen/opdrachten zijn op niveau van de doelgroep • Gameplay en content moeten gescheiden zijn, zodat het flexibel uit te breiden en vervangbaar is

5

2.9

Risicofactoren

Door de grote groep mensen die wordt verwacht tijdens de open dag moet het systeem rekening houden met veel mensen die tegelijkertijd requests gaan sturen naar de server, zodat deze niet crasht. Dit is de grootste risicofactor in dit project, want om onze game interactief te maken zullen de mobiele telefoons vaak met elkaar communiceren, wat niet meer kan als de server crashed. Ook kunnen er meer mensen komen dan verwacht, waardoor er misschien niet genoeg stands zullen zijn voor elk groepje en er dus meerdere groepjes bij een stand komen te staan.

3 3.1

Aanpak Inleiding

Het project duurt in totaal 11 weken met de mogelijkheid tot uitloop. De eerste 2 weken is de onderzoeksfase. Tijdens deze fase worden bestaande interactieve spellen bestudeerd om zo meer ideeën te krijgen voor verschillende game concepten en verschillende technieken en hulpmiddel worden onderzocht die gebruikt kunnen worden voor het implementeren van een game concept. Na de onderzoeksfase volgt de design fase. Deze duurt 1 week en hieruit volgt de systeem specificatie, zoals klasse diagrammen en use cases. Hierna volgt de implementatie fase, waarin er telkens in kleine periodes nieuwe prototypes worden ontwikkelt met als doel dat er aan het einde van elke periode al getest kan worden en eventuele aanpassingen aan het prototype in de volgende periode al kunnen worden doorgevoerd. In de laatste drie weken werken we ook aan het verslag en de presentatie en de laatste week van het project zullen we vooral besteden aan het testen en om laatste aanpassingen door te voeren.

3.2

Methodiek

Tijdens dit project wordt de software ontwikkelmethode Scrum gebruikt, wat betekent dat het product ontwikkelt wordt in korte sprints waarbij aan het eind van elke sprint een werkend prototype beschikbaar is. Dit heeft als voordeel dat dit prototype na afloop van elke sprint getest kan worden en er gemakkelijk wijzigingen kunnen worden aangebracht aan het product tijdens de implementatie fase.

3.3

Techniek

Om ons te helpen bij het ontwikkelen van de game gaan wij gebruik maken van de Unity game engine. Een game engine levert veel core functies (zoals een physics engine, geluid, animaties, networking etc.) die gebruikt kunnen worden, zodat deze niet zelf gemaakt hoeven te worden er meer gefocust kan worden op het ontwikkelen van de daadwerkelijke game. Ook ontwikkel je meteen voor

6

verschillende platforms, waardoor je niet voor elk platform apart code hoeft te schrijven. In het onderzoeksverslag wordt de keuze van Unity verder uitgelegd. Naast de game engine zijn er ook technieken, zoals Augmented Reality en QR-code die gebruikt kunnen worden in de mobiele applicaties. Door deze technieken te gebruiken is het mogelijk om de game leuker en interactiever te maken. Om de grafische elementen van de game mooier te maken, kunnen grafische applicaties gebruikt worden voor het creëren van 2D of 3D modellen. Voor het versiebeheersysteem wordt GitHub gebruikt om de codes makkelijk synchroon bij te houden. LateX editor wordt gebruikt voor het schrijven van de verslagen.

3.4 3.4.1

Werkzaamheden Onderzoek

Allereerst is er een onderzoeksfase van 2 weken. Tijdens deze fase zullen bestaande interactieve spellen wat met een groep mensen moet worden gespeeld worden bestudeert en dit nemen we mee in het bedenken van verschillende game concepten. Het mobiel gebruik van de doelgroep wordt onderzocht zodat we weten welke mobiele systemen we kunnen verwachten en hier rekening mee kunnen houden in het ontwerp. Er wordt onderzocht wat voor technieken we kunnen gebruiken en wat er al beschikbaar is (zoals libraries en (ontwikkel) tools) en wat eventueel zelf nog gemaakt moet worden. 3.4.2

Design

Na de onderzoeksfase komt de design fase. Deze duurt ongeveer 1 week en hierin zullen we een specificatie van het systeem opstellen die voldoet aan de opgestelde eisen. Denk hierbij aan klasse en use case diagrammen, het interface design en een MOSCOW model. 3.4.3

Implementatie

In de implementatie fase wordt er gewerkt met sprints van twee weken, met uitzondering van de eerste sprint, en aan het einde van elke sprint is er een werkend prototype wat getest kan worden. Het product wordt in deze fase ontwikkelt aan de hand van het design dat in de vorige fase is opgesteld en aan de hand van testresultaten kan het ontwerp nog worden aangepast. 3.4.4

Testen

Deze fase loopt in parallel met de implementatie fase. Na elke functie implementatie worden unit test uitgevoerd en aan het eind van een sprint worden user tests gedaan. Tijdens de laatste week van de implementatie fase zullen er uitgebreide gebruikerstest plaatsvinden met als doel de laatste foutjes uit het spel te halen en de laatste aanpassingen aan te brengen. Aan het einde van deze

7

fase moet de applicatie klaar zijn om in de Google playstore en/of app store te zetten.

3.5

Planning

Hieronder bevinden zich de planningen. Tabel 1 is de uitgebreide planning en Figuur 1 is het globale overzicht. Deze planningen zijn opgesteld op 14-04-2014: Figuur 1: Planning overzicht

4 4.1

Projectinrichting Betrokkenen

De betrokkenen bij dit project zijn Tom Zwart en Edward Teng (uitvoerders), Trudy Middendorp (opdrachtgever) en Rafael Bidarra (begeleider).

4.2

Faciliteiten

We hebben verschillende locaties beschikbaar in de faculteit EWI waar we kunnen werken (op de algemene ruimte op de 2de verdieping, op de 12de verdieping in het lab of eventueel op de begane grond). Verder heeft elk groepslid een laptop tot zijn beschikking.

8

Tabel 1: Planning uitgebreid Week

Summary / To do

Deliverables

• Plan van aanpak 1 (7 t/m 11 april)

• Onderzoek en oriëntatie • Verschillende game concepten bedenken • Plan van aanpak

2 (14 t/m 18 april)

• Onderzoek en oriëntatie

• Plan van aanpak

• Game concept vastleggen

• Onderzoeksverslag

• Design • Klasse en Use case diagrammen • Client-servermodel 3 (21 t/m 25 april)

• MOSCOW model

• Design verslag

• Interface design • Implementatie 4 (28 t/m 2 mei)

• Implementatie en testen

5 (5 t/m 9 mei)


6 (12 t/m 16 mei)


7 (19 t/m 23 mei)


8 (26 t/m 30 mei)


9 (2 t/m 6 juni)


10 (9 t/m 13 juni)


11 (16 t/m 20 juni)

• Product afronden

Begin Juli

• Prototype

• Code en documentatie naar SIG sturen • Prototype

• Feedback van SIG verwerken

• Verslag

• Verslag

• Prototype • Code en documentatie naar SIG sturen

• Eind verslag

• Verslag • 1 Week van te voren verslag sturen

9

• Demo presentatie

5 5.1

Kwaliteitsborging Inleiding

Kwaliteit is een belangrijke criterium bij het maken van een product. Hieronder staat beschreven hoe wij deze criterium waarborgen.

5.2

De kwaliteit

De manier van het schrijven van het programma is een belangrijk onderdeel om de kwaliteit te waarborgen. Daarom worden code standaarden, zoals commentaren schrijven, en goede werkwijze gebruikt om aan de kwaliteit waarborging te voldoen. Om te weten of de codes op de goede manier geschreven zijn, worden ze naar SIG verstuurd. SIG analyseert of de codes en de structuur van het programma op de goede richting liggen of niet. Aan de hand van de feedback van SIG, kunnen wij de kwaliteit van de programma verbeteren waar nodig is. Om de kwaliteit van het programma te waarborgen, is het ook noodzakelijk om de functies te testen. Er worden Unittest, Integratietest en Gebruikerstest uitgevoerd om vast te stellen dat het programma aan de eisen voldoet en dat de functies naar behoren werken. Ook worden de test codes door SIG geanalyseerd. Er worden ook prototypes gemaakt om de voortgang van het project aan de begeleider en opdrachtgever te laten zien. Zij kunnen aangeven wat er veranderd of verbeterd moet worden. 5.2.1

Versiebeheer

Zoals reeds vermeld gebruiken we GitHub, wat Git gebruikt, als versiebeheersysteem. Bij Git wordt een repository lokaal op de PC opgeslagen, dus nieuwe code en dergelijke wordt eerst lokaal opgeslagen. Als code samengevoegd moet worden met code van iemand anders dan wordt het naar de de remote repository op het internet gestuurd. Voor nieuwe functionaliteit zal telkens een aparte branch worden aangemaakt welke pas naar de hoofdbranch (de master) wordt gepushed als deze functionaliteit af is en getest. Hierdoor bestaat er altijd een werkend prototype.

10

Appendix

E

Appendix : Orientatie verslag

55

Orientatie verslag Edward Teng en Tom Zwart April 2014

1

Contents Contents

2

1 Inleiding

3

2 Praktische aspecten 2.1 Vergelijkbare games . . . 2.2 Het game concept . . . . . 2.2.1 Inleiding . . . . . . 2.2.2 Het game concept 2.2.3 Opdrachten . . . . 2.3 Smartphone gebruik . . . 2.3.1 Informatie . . . . . 2.3.2 Conclusie . . . . . 2.4 Kosten . . . . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

3 3 3 3 4 5 5 5 6 6

3 Technische aspecten 3.1 Game Engine . . . . . . . . . . . . . 3.1.1 Wat is een game engine? . . . 3.1.2 Vergelijking van game engines 3.1.3 Conclusie . . . . . . . . . . . 3.2 Programmeer talen . . . . . . . . . . 3.3 Technieken . . . . . . . . . . . . . . 3.4 Route . . . . . . . . . . . . . . . . . 3.5 Server . . . . . . . . . . . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

7 7 7 7 8 8 9 9 10

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

Referenties

. . . . . . . . .

. . . . . . . . .

11

2

1

Inleiding

Tijdens dit project zal er een app ontwikkelt moeten worden die een rondleiding geeft door de faculteit EWI en die de mogelijkheid geeft voor onze opdrachtgever om makkelijk vragen/opdrachten toe te voegen aan de game. In dit document worden de bevindingen van ons onderzoek in de eerste twee weken beschreven. Het onderzoek wordt opgedeeld in praktische en technische aspecten, bij de praktische aspecten richten we ons op gameplay en gebruikers en bij de technische aspecten wordt verder ingegaan op software gerelateerde zaken.

2 2.1

Praktische aspecten Vergelijkbare games

De game Tiny Games [8] gebruikt interactie tussen mensen in de echte wereld om verschillende vragen en puzzeltjes op te lossen. Het stelt je een aantal vragen, bijvoorbeeld ”met hoeveel mensen ben je?” en ”wat doe je op dit moment?” en aan de hand van de antwoorden op deze vragen kiest het een minigame voor je uit die je kunt spelen. Wij zouden zoiets ook in onze game kunnen integreren door de groep bijvoorbeeld een onderwerp te laten kiezen en aan de hand van het gekozen onderwerp een opdracht te geven. Een andere interactieve game is SNAG’EM [2]. Het doel van dit spel is om contact te maken met andere mensen die ook het spel spelen, zodat je informatie over elkaar te weten komt wat je kunt gebruiken om missies te voltooien voor punten. Je wordt ook ingedeeld in 1 van de 3 teams en samen met je team probeer je zoveel mogelijk punten te halen. Het idee van het strijden voor je team zouden wij makkelijk kunnen implementeren in de vorm van strijden voor je opleiding, dus je haalt niet alleen punten om de beste groep te zijn, maar tegelijkertijd haal je ook punten voor je opleiding wat weer zorgt voor meer competitie. Het spel CampusWar waar één van ons vorig jaar aan heeft gewerkt bevat ook veel van dezelfde elementen die ook in dit project zitten. Het doel van dit spel is om met een groep mensen een opdracht te doen waarmee je een gebouw op de campus kunt veroveren. Iedereen van de groep krijgt ook een onderdeel van de puzzel en je hebt alle onderdelen nodig om de puzzel op te lossen, dus iedereen moet actief deelnemen aan het spel. Deze puzzels zijn goede voorbeelden voor mogelijke interactieve opdrachten.

2.2 2.2.1

Het game concept Inleiding

Om tot een goed game concept te komen hebben we verschillende scenario’s en minigames bedacht die in het spel voor kunnen komen en deze met de opdrachtgever besproken. Aan de hand van dit gesprek is een game concept gemaakt die

3

de scenario’s en minigames bevat die de opdrachtgever graag terug wilt zien in de game. 2.2.2

Het game concept

Als de app wordt opgestart kan er een naam en het groepsnummer of code worden ingevuld (dit krijgen de scholieren voordat de rondleiding begint). Hierna kan er op de knop start worden gedrukt en wordt er gevraagd om een code. Deze code wordt pas vlak voor de rondleiding gegeven, zodat de organisatie kan bepalen wanneer de rondleiding begint. Als het groepje is gestart krijgen ze een locatie door waar ze heen moeten gaan. Op elke locatie krijgen ze een opdracht (of meerdere opdrachten) om zo punten te verzamelen voor de groep. De opdrachten duren niet zo lang en zijn zo gemaakt dat iedereen van de groep kan bijdragen om ze op te lossen. De inhoud van de opdracht heeft altijd iets te maken met de opleiding, de faculteit of iets anders TU Delft gerelateerd. Bij sommige locaties kan de groep kiezen uit een aantal onderwerpen en bij elk onderwerp hoort dan een andere opdracht. Dit geeft ze meer keuze en zorgt er ook voor dat ze met elkaar gaan overleggen om te bepalen over welk onderwerp ze het meeste denken te weten. Als de groep het antwoord denkt te weten vullen alle mensen die de game op hun telefoon ge¨ınstalleerd hebben dit antwoord in en als iedereen hetzelfde heeft ingevuld en het antwoord is goed dan krijgt de groep punten. Na een X aantal minuten vanaf dat de groepjes begonnen zijn met lopen wordt telkens de volgende locatie pas gegeven. Bijvoorbeeld 6 minuten nadat de scholieren begonnen zijn met de rondleiding krijgen ze de tweede locatie, 6 minuten daarna krijgen ze de derde locatie enzovoort. Dit zorgt ervoor dat elk groepje evenveel tijd bij iedere stand heeft en ze zich niet gaan haasten bij een stand omdat ze naar de volgende willen. Bij de stands zelf kunnen de scholieren namelijk nog vragen stellen over bijvoorbeeld de opdracht, opleiding of het onderwerp van die stand aan de student die erachter staat. Ieder groepje van dezelfde opleiding bezoekt ook dezelfde stands, maar in een andere volgorde zodat de groepjes zoveel mogelijk worden verspreidt. Om de game nog leuker te maken worden er nog meer spel elementen toegevoegd. Zo heeft elke groep een level, wat afhangt van het aantal punten die ze gehaald hebben, en elke keer als ze een level omhoog gaan ’unlocked’ de groep iets. Dit kan bijvoorbeeld extra functionaliteit in het spel zijn (kleine dingetjes zoals de mogelijkheid om de groepsnaam aan te passen) of een minigame voor extra punten. Ook zijn er achievements te behalen als er iets ’speciaals’ is gedaan, wat weer gedeeld kan worden op social media. De game kan verder nog uitgebreid worden met bijvoorbeeld wist je datjes of hints over de volgende opdracht (die gegeven worden terwijl de scholieren naar de volgende locatie lopen) of bij standjes waar dreamteams staan hun 3D voertuigen met augmented reality weergeven op de mobiel. Bij het oplossen van een opdracht wordt ook een letter gegeven, waarmee aan het einde van de rondleiding een woord of zin geraden kan worden voor extra punten. Tijdens de rondleiding kunnen de scholieren de score van hun groep en van 4

de andere groepjes zien. Aan het einde van de rondleiding heeft de groep met de meeste punten van een opleiding gewonnen en kan de score gedeeld worden op social media. Hierna kan thuis nog individueel verder gespeeld worden met de score die tijdens de open dag behaald is, waarbij elke dag een maximum aantal opdrachten gespeeld kan worden. Deze opdrachten geven nu alleen punten voor jezelf en door een maximum aan het aantal te spelen opdrachten per dag te hangen willen wij ervoor zorgen dat scholieren nog een aantal dagen/weken het spel thuis verder spelen. 2.2.3

Opdrachten

De opdrachten die de scholieren bij de stands kunnen krijgen zijn als volgt: • Quizvragen. De groep krijgt een vraag over een bepaald onderwerp met meerkeuze antwoorden. Deze antwoorden kunnen eventueel over de verschillende telefoons verspreidt worden om zo voor meer interactie te zorgen. • Zin in stukken hakken en verdelen over de verschillende telefoons. De originele zin moet nu worden gevonden. • Raadsels. Er worden hints verdeeld over de verschillende telefoons waarmee het raadsel kan worden opgelost. • Bij sommige standjes 3d objecten laten zien met behulp van Augmented Reality en hier een vraag over stellen • Verschillende plaatjes verdelen over de telefoons en deze moeten in de goede volgorde worden gezet. Er zijn bijvoorbeeld 6 verschillende plaatjes die, als ze in de goede volgorde staan, uitbeelden hoe een student begint met zijn bachelor opleiding en eindigt met een master diploma. Elke telefoon krijgt 1 van deze plaatjes en de groep moet samen bepalen wat de juiste volgorde van deze plaatjes is.

2.3 2.3.1

Smartphone gebruik Informatie

Er is onderzoek gedaan naar smartphone bezit van Nederlandse jongeren tussen de 10-17 jaar, hiervan heeft maar liefst 76% een smartphone [7]. De leeftijd van onze doelgroep is ongeveer 16-17 jaar en volgens dit onderzoek loopt het percentage smartphones voor deze leeftijd dan zelfs op tot maar liefst 90% (zie Figuur 1). Dit betekent dat we kunnen verwachten dat veruit het merendeel van de scholieren die naar de open dag komen een smartphone hebben. Volgens het rapport ’Dutch Smartphone User Q3 2013’ [6] had het besturingssysteem Android in het derde kwartaal van 2013 een marktaandeel van 69% terwijl iOS 22% had. Dit laat 9% over voor andere mobiele besturingssystemen dus verreweg de meeste smartphones draaien Android of iOS. Het blijkt ook

5

Figuur 1: Mobiel gebruik jongeren 10-17 jaar

dat de Windows Phone in Nederland helemaal niet zo’n groot marktaandeel heeft [5], namelijk maar zo’n drie procent, en dat dit percentage hoger ligt in de zakelijke markt. 2.3.2

Conclusie

Om ervoor te zorgen dat zoveel mogelijk mensen tijdens de open dag de app kunnen spelen op hun smartphone is het beter om de app niet alleen voor Android te ontwikkelen, maar ook voor iOS. Afgaande op ons onderzoek naar de doelgroep ondersteunen we ongeveer 90% van de mensen met een smartphone als we voor Android en iOS ontwikkelen en ’maar’ ongeveer 70% als we voor alleen Android ontwikkelen. Ook is het niet zeker of jongeren misschien in verhouding meer voor iOS kiezen dan voor Android, dus vanwege deze redenen is het aantrekkelijker om in ieder geval voor Android én iOS te ontwikkelen.

2.4

Kosten

Er zijn kosten verbonden voor het uitbrengen van de applicatie op de Google Play Store en App Store (iPhone). Voor de Google Play kost het $25 om een Google Play Developer Console account aan te maken. Met dit account is het mogelijk om games op de Google Play te uploaden. Voor de App Store is een iOS Developer Program nodig. Dit kost $99 per jaar. Eventueel kan grafische content door derden gemaakt worden, waar dan ook weer kosten aan verbonden zijn. Het is alleen niet van te voren te zeggen hoeveel dit kan zijn. We gaan er vanuit dat we vrijwel alles zelf kunnen maken en dit dus niet nodig zal zijn.

6

3 3.1 3.1.1

Technische aspecten Game Engine Wat is een game engine?

Een game engine is een software framework wat door game ontwikkelaars wordt gebruikt ter ondersteuning in de ontwikkeling van de game. Een game engine biedt veel core functionaliteiten (zoals een physics engine, geluid, animaties, networking etc.) die de ontwikkelaar meteen kan gebruiken, waardoor hij deze niet meer zelf hoeft te maken en zich dus meer kan richten op de game zelf. Ook hebben veel game engines de mogelijkheid om meteen voor meerdere platformen te ontwikkelen, waardoor je niet voor elk apart platform andere code hoeft te schrijven. Er zijn veel game engines die gratis worden aangeboden en tegen betaling meer functionaliteit bieden, voor ons zal de gratis versie in vrijwel alle gevallen echter voldoende zijn. 3.1.2

Vergelijking van game engines

Tegenwoordig zijn er veel verschillende game engines die allemaal voor en nadelen hebben. Game engines onderscheiden zich vooral in welke platformen ze ondersteunen, of ze 2D of 3D georiënteerd zijn, documentatie, beschikbare tutorials en de prijs. Na onderzoek naar beschikbare game engines [4] hebben wij 2 game engines gevonden die we het best geschikt vonden om te gebruiken tijdens dit project, Unity [3] en Corona SDK [1]. Beiden hebben een gratis versie waarmee snel goede games ontwikkelt kunnen worden. Corona is voornamelijk bedoeld voor het maken van 2D games, terwijl Unity altijd meer 3D georiënteerd was. Sinds versie 4.3 van Unity is er echter heel veel functionaliteit voor het maken van 2D games toegevoegd, waardoor dit op 2D gebied eigenlijk niet meer onder doet aan andere game engines. Hieronder staan de voor en nadelen van deze engines beschreven:

7

Unity

Corona

• Er is een grote community met veel documentatie en tutorials. • Unity maakt het gemakkelijk om plaatjes/objecten te importeren.

Voordelen

• Je kunt voor verschillende scherm resoluties testen en tijdens het testen heb je de mogelijkheid om real time variabelen aan te passen. • Unity’s GUI maakt de koppeling tussen verschillende game elementen eenvoudiger. • Sinds versie 4.3 is veel functionaliteit voor het maken van een 2D game toegevoegd. • Er zijn heel veel assets die je kunt gebruiken (gratis of tegen betaling)

• Er is een grote community met veel documentatie en tutorials, maar deze is niet zo uitgebreid als bij Unity. • Corona gebruikt Lua wat ervoor zorgt dat ontwikkelen snel gaat, want je hebt weinig code nodig voor een functie. Ook kan het project snel worden opgezet. • Het is eenvoudig om de graphics te schalen voor de verschillende schermen. • Corona heeft een eigen emulator waardoor je snel kunt testen voor verschillende apparaten.

• Corona mist een goede debugger. • Bij de gratis versie is de minimale app size redelijk groot. De .apk van een leeg project is al 7.7mb Nadelen

• Bij de gratis versie van Unity komt er een Unity splash screen bij het opstarten van de applicatie. • Unity werkt wat minder makkelijk met third-party versiebeheersystemen.

3.1.3

• De starter variant mist grafische features die alleen in Pro versies of hoger beschikbaar zijn. • Niet alle functionaliteit (bijv. networking) werkt op de emulator en moet op een echte telefoon worden getest wat veel tijd in beslag kan nemen. • Het gebruik van Lua zorgt ervoor dat het heel erg makkelijk is om lelijke code (spaghetti code) te schrijven.

Conclusie

Beide game engines hebben zo hun voor en nadelen, maar Unity komt hier wel wat beter uit de verf dan Corona. Unity biedt meer functionaliteit en beschikt over uitgebreidere tools die gebruikt kunnen worden tijdens het ontwikkelen. Met Corona kan echter wel snel een project worden opgezet en wordt meer voor je geregeld voor verschillende resoluties, maar dit zorgt ook voor minder controle over je game. Unity biedt gewoon simpelweg meer voor ons dan (de gratis versie van) Corona en dat is dan ook de reden dat we voor Unity als game engine kiezen.

3.2

Programmeer talen

Unity ondersteunt drie programmeer talen, C#, UnityScript (Javascript) en Boo. De eerste twee talen worden verreweg het meeste gebruikt en hier is dan ook meer informatie over te vinden dan Boo. Tussen deze twee talen zijn verder niet hele grote voor of nadelen, waardoor de keuze neerkomt op welke taal wij

8

persoonlijk fijner vinden om mee te werken. Onze voorkeur gaat uit naar C#, aangezien wij het fijner vinden om met een object georiënteerde programmeertaal te werken voor het maken van een game en hier ook meer ervaring mee hebben.

3.3

Technieken

Naast de game engine, zijn er ook een aantal technieken, zoals Augmented Reality (AR) en Quick Response (QR) code, beschikbaar om de game leuker te maken. AR is een toevoeging van virtuele elementen in de echte wereld door middel van een camera en sensoren. Met een smartphone en AR markers is het mogelijk om virtuele 3D objecten op het scherm te laten zien. Om Augmented Reality te implementeren zijn er verschillende toolkits die gebruikt kunnen worden. Een voorbeeld van een AR toolkit is Vuforia. Vuforia is een Augmented Reality Software Development Kit voor mobiele apparaten. Met deze kit kunnen 2D en 3D objecten, zoals gezichten, worden herkend. Het voordeel van deze kit is dat er een AR extensie voor Unity bestaat. Dit maakt het implementeren van AR makkelijker. Als wij nog ruim tijd over hebben, gaan we AR met deze toolkit implementeren. Een QR-code is een tweedimensionale streepjescode. Door het scannen van QR-codes is het mogelijk om acties uit te voeren, zoals naar een bepaalde URL gaan of andere functies uit te voeren. De library ZXing wordt gebruikt om QR-codes te implementeren en een telefoon met een camera is noodzakelijk om de QR-codes te scannen. Bij een stand is altijd een QR code die iemand van de groep kan scannen, waardoor de groep een opdracht krijgt. Ook kunnen er QR-Codes op andere plaatsen in de faculteit worden geplaatst die, wanneer ze gescand worden, aangeven welke kant je op moet om bij bepaalde stands te komen.

3.4

Route

Er zijn twee mogelijkheden voor de route beschrijving, de route van te voren of real-time berekenen. Als we de route van te voren berekenen, kunnen we een algemeen pad per opleiding maken. Hier moet wel rekening gehouden worden met het aantal groepen dat bij een stand kan staan. Het beste is dat er maximaal één groep per opleiding bij een stand staat, tenzij er meer groepen dan de aantal stands zijn. Om dit goed te laten verlopen is het noodzakelijk om de groepen in het begin te verspreiden en de volgende locatie na een aantal minuten pas te geven, zodat er altijd evenveel groepjes bij een stand staan. Ook is de afstand tussen twee stands belangrijk. Deze moet niet te lang zijn, anders hebben de scholieren minder tijd om bij een stand te blijven. Als we de route real-time berekenen, dan hebben we met meer dingen te maken. Eerst moeten we weten waar elke groep staat. Daarna moet er bepaald worden naar welke stand een groep gaat als die groep een opdracht voltooid. Een oplossing is door simpel naar de eerste dichtstbij lege stand te zoeken en die aangeven. Door middel van een notificatie kan de volgende locatie worden aangegeven. 9

Samen met de opdrachtgever hebben we besloten om de route beschrijving van te voren te berekenen. Er zal dus een algemeen pad gemaakt worden die alle groepen langs moeten gaan, maar het is wel per opleiding verschillend. Dit pad kan handmatig gemaakt worden aangezien er niet veel standjes zijn. In het begin krijgen de groepen een locatie te zien, dit is hun eerste stand. Na een aantal minuten krijgen de groepen de volgende locatie te zien. Het is de bedoeling dat de groepen binnen dat aantal minuten de opdracht oplossen en daarna nog vragen kunnen stellen aan de student die achter de stand staat. Aan het einde van de rondleiding worden de groepen naar de eindlocatie gestuurd.

3.5

Server

Voor het multiplayer aspect van het spel willen we een centrale server gaan gebruiken om de data bij te houden en requests af te handelen. Er zijn ook bedrijven die cloud diensten aanbieden om server gerelateerde zaken makkelijk voor ontwikkelaars te maken. Er zijn vier verschillende cloud services, namelijk Backend as a Service (BaaS), Infrastructuur (IaaS), Platform (PaaS) en Software (SaaS). BaaS, ook wel Mobile Backend as a Service(mBaaS) genoemd, ondersteunt onder andere push notificatie, sociale netwerk integratie, locatie services en gebruikersbeheer. Door deze functies is een BaaS interessanter dan de andere services voor mobiele applicatie. Het nadeel van bedrijven die een mBaaS dienst aanbieden is echter dat je maar beperkte gratis mogelijkheden hebt en maar een maximum aantal requests kan sturen voordat je moet betalen. De andere mogelijkheid is om vanuit de TU een server te regelen. Het kost meer tijd om alles hiermee draaiend te krijgen, maar uiteindelijk heb je wel veel meer controle over je applicatie en het is en blijft allemaal gratis. Onze voorkeur gaat hier naar uit in combinatie met een MySQL database en PHP.

10

Referenties [1] Corona. http://coronalabs.com/products/corona-sdk/. 15/04/2014.

Visited on

[2] Snagem - connect the world. http://snagemgame.com/index2.php5. Visited on 15/04/2014. [3] Unity3d. https://unity3d.com/. Visited on 15/04/2014. [4] What is the best 2d game engine? http://www.slant.co/topics/341/ whatis-the-best-2d-game-engine. Visited on 15/04/2014. [5] Nederlanders kopen minder vaak windows phone dan inwoners buurlanden. http://tweakers.net/nieuws/92959/nederlanders-kopen-mindervaak-windows-phone-dan-inwoners-buurlanden.html, 2013. Visited on 15/04/2014. [6] Danny Oosterveer. Bijna driekwart van de nederlanders bezit smartphone. http://www.marketingfacts.nl/berichten/bijna-driekwart-van-denederlanders-bezit-smartphone, 2013. Visited on 15/04/2014. [7] Stichting Mijn Kind Online en Kennisnet. Samen leren: Tieners en sociale media. pages 28–29, 2013. [8] Jim McCauley. New app brings social gaming into the real world. http://www.creativebloq.com/app-design/theres-always-time-playtiny-games-10135055, 2013. Visited on 15/04/2014.

11

Appendix

F

Appendix : Originele project beschrijving

Project description Kan jij je het moment nog herinneren dat je voor het eerst het hoogste gebouw van de TU Delft campus binnen liep tijdens de bachelor open dagen? Een dag vol met presentaties, hoorcolleges en een informatieve rondleiding. Dit kan echt niet meer in 2014! We zijn op zoek naar interactieve game voor mobiele telefoon als onderdeel van de open dagen. Door het spelen van de game worden de scholieren op een interactieve manier rondgeleid. Middels opdrachten, spelletjes of een andere vorm van interactie ontvangen ze de route door de faculteit. Doel Een game voor de bachelor open dagen middels een app, die de scholieren op een interactieve en leerzame manier laat kennis maken met de opleiding en de faculteit. De scholieren gaan zelf op onderzoek in de faculteit en hebben een onvergetelijke ervaring na het zien van demo’s en faciliteiten en het doen van opdrachten. De game kan vervolgens na de open dagen ook nog verder gespeeld worden. Doelgroep 5 en 6 vwo scholieren, die ge¨ınteresseerd zijn en zich willen verdiepen in de opleiding(en) Electrical Engineering, Technische Wiskunde en/of Technische Informatica. Opdracht Ontwerp en creëer een game voor een mobiele telefoon, die scholieren tijdens de open dagen in groepjes een rondleiding door de faculteit en opleidingen geeft. Company description Namens Marketing en Communicatie van de faculteit Elektrotechniek, Wiskunde en Informatica aan de TU Delft wordt deze opdracht aangeboden. De contactpersoon voor deze opdracht is Trudy Middendorp ([email protected]). Trudy is verantwoordelijk voor voorlichting van de bachelorwerving, waaronder de open dagen vallen. Auxiliary information Eisen De game moet de volgende elementen bevatten: - Geschikt voor Android (en tenminste iPhone klaar) - Game tijdens open dagen van maximaal 60 minuten, maar kan thuis verder gespeeld worden - Per opleiding een aparte game - De game wordt gespeeld in kleine groepjes - De game moet langs de verschillende (fysieke) demo’s, faciliteiten en studentenprojecten gaan in de faculteit - Scores verbinden aan de opdrachten/(quiz)vragen - Op niveau van de doelgroep - Mogelijkheid tot sharen via Facebook of andere social media (WhatsApp, Snapchat etc.) - Gameplay en content moeten gescheiden zijn, zodat het flexibel uit te breiden en vervangbaar is.

67

TU Delft Open Dagen App. Technische Informatica

Recommend Documents