SCHOOLYARD Eindverslag Bachelorproject Technische Informatica
IN3405 BSc project Revisie 2 Delft, 16 juli 2012 Joeri van der Velden 1358480 Thomas Breekveldt 1388584 Opdrachtgever R. E. Kooij, TNO Begeleider R. Bidarra, TU Delft 1
VOORWOORD In de laatste fase van de bacheloropleiding moet een student aan de Technische Universiteit Delft een bachelorproject voltooien. Dit project is in de vorm van een opdracht opgegeven door een werkgever, binnen of buiten de universiteit. Het project is bedoeld om de studenten ervaring te geven met zelfstandig het hele software ontwikkelingstraject door te lopen. Dit eindverslag is bedoeld voor het Schoolyard project wat uitgevoerd is in opdracht van het TNO. Onze opdrachtgever is de heer R. E. Kooij. Wij willen hem hartelijk bedanken voor de kans om aan dit project te werken, en het enthousiasme waarmee hij onze vooruitgang heeft gevolgd. Wij willen de heer R. Bidarra, onze begeleider aan het TU, ook hartelijk bedanken voor zijn assistentie. Ten slotte onze dank aan mevr. B. Motjé en B. Kitz, leraressen aan de OBS De Tweemaster basisschool in Capelle aan den IJssel voor hun hulp en betrokkenheid bij het project.
2
SAMENVATTING Mobiele technologie is van groot belang in de samenleving van vandaag. Er komen steeds meer applicaties op de markt die ons alledaagse leven verrijken en assisteren. Het onderwijs profiteert hier ook van. De klas krijgt steeds meer met ICT te maken en leerlingen worden getoetst in digitale omgevingen. Serious games spelen hier in een grote rol. Deze games draaien om het trainen en toetsen van de speler, om zo het leerproces te vergemakkelijken en te verbeteren. Het doel van het Schoolyard project is om een educatief spel te maken dat basisschoolleerlingen op het schoolplein kunnen spelen, met behulp van locatiebepaling. Er is veel vrijheid in de invulling van het project en ruimte om met verschillende technieken te experimenteren. Na de oriëntatiefase is besloten om de client applicatie voor Android smartphones te ontwikkelen, ondersteund door een laptop die als server dient en het spelverloop van meerdere clients bijhoudt. Tijdens de ontwikkeling van het eerste prototype bleek dat de GPS te onnauwkeurig is voor locatiebepaling op het schoolplein, en er geen andere praktische alternatieven zijn die je locatie vast stellen aan de hand van draadloze signalen. Om deze redenen kiezen we er voor de camera van een smartphone te gebruiken. Deze kan toegepast worden voor het scannen van QR codes. De speler kan de Schoolyard applicatie gebruiken om QR codes verspreid over het speelveld uit te lezen, waardoor hij aangeeft op een bepaalde locatie te staan. We zijn tevreden met het uiteindelijk ontwikkelde prototype. De laptop die als server dient kan een Wifi hotspot opzetten waarmee alle spelers kunnen verbinden. Als de server het startsignaal geeft start het spel voor alle verbonden spelers. Het ontwikkelde test spel, genaamd Reken Ren, toetst de hoofdrekenvaardigheden van de speler. Het spel start met een start en doel getal. Door QR codes in te scannen worden er operaties uitgevoerd op het start getal. Het doel voor de speler is om vanaf het start getal het doel getal te bereiken. De uitbreidingsmogelijkheden van de applicatie zijn talrijk. Het systeem is modulair, zodat er makkelijk nieuwe spellen voor de applicatie ontworpen kunnen worden. Er kunnen ook nieuwe opdrachten voor een spel vanaf de server verzonden worden zodat het speelveld telkens anders is. Het is zelfs mogelijk compleet andere vormen van locatiebepaling te implementeren in de applicatie zonder veel te hoeven veranderen.
3
INHOUDSOPGAVE
1. 2.
Inleiding Schoolyard 2.1. Opdrachtomschrijving 2.2. Eisen 2.3. Prototype 2.4. Handleiding 3. Planning 3.1. Oorspronkelijke planning 3.2. Werkelijke planning 4. Onderzoek 4.1. Platform keuze 4.2. Communicatie techniek 4.3. Locatie bepaling 4.4. Gebruikers 4.5. Spel omgeving 5. Ontwerp 5.1. Spel ontwerp 5.2. Shared code 5.3. Server implementatie 5.4. Client implementatie 5.5. Uitbreidingsmogelijkheden 5.6. Evaluatie SIG 6. Conclusie 7. Toekomst 8. Evaluatie 9. Bronnen Appendix A: Opdrachtomschrijving Appendix B: Oriëntatieverslag 1. Inleiding 2. Gebruikers 3. Locatiebepaling 3.1. GPS 3.2. Triangulation 3.3. Scannen 3.4. De Keuze 3.5. Implementatie 4. Netwerk Communicatie Appendix C: Plan van Aanpak Appendix D: Spelconcepten 1. MathRun 2. City Matching 3. Word Builder 4. Timeline 5. City Matching Multiplayer
4
1. INLEIDING Mobiele technologie dringt steeds verder door in onze samenleving. De laatste jaren heeft de smartphone grotendeels de standaard mobiele telefoon verdreven uit het straatbeeld. Mensen hebben 24 uur per dag het internet binnen handbereik. Het is nooit makkelijker geweest om je exacte locatie op onze planeet te visualiseren dankzij ondersteunende technologieën zoals de GPS. In ons huidige informatie tijdperk is het niet alleen de hardware die vooruitgang boekt. De software is wat het allemaal samenbind. Er word ons dagelijks ontzettend veel informatie voorgeschoteld. Voor werk, vermaak, of educatie. Serious games, spellen bedoeld ter educatie van de speler, worden steeds breder toegepast. In het begin vooral voor training van bedrijfspersoneel voor scenario’s die lastig na te bootsen zijn in de fysieke wereld. Tegenwoordig zit het ook verweven in lesprogramma’s van basisscholen tot universiteiten. Ons project draait om het ontwikkelen van een platform waarop zulke serious games gespeeld kunnen worden. Het Schoolyard project is bedoeld om basisschoolleerlingen bewegend te laten leren op het schoolplein, met behulp van locatiebepaling. De keuze hoe dit aan te pakken, zowel op hardware en software gebied, stond volledig open. Naast het concept stond er geen enkele eis vast. Eerst zullen we in hoofdstuk 2 de opdrachtomschrijving bekijken en het concept verder uitdiepen door onze eigen eisen te stellen. Daarna, in hoofdstuk 3, zullen we de planning behandelen die we voor dit project hadden uiteengezet. In hoofdstuk 4 wordt het onderzoek besproken, waarna in hoofdstuk 5 het ontwerp aan bod komt. Vervolgens zullen onze conclusies in hoofdstuk 6 staan. Als laatst bespreken we de toekomst van het project in hoofdstuk 7, met bijhorende aanbevelingen.
5
2. SCHOOLYARD 2.1 OPDRACHTOMSCHRIJVING Het doel van de opdracht is als volgt samen te vatten: “Het ontwikkelen van een educatieve spelomgeving met behulp van mobiele locatie bepaling voor basisschoolleerlingen op het schoolplein” Het Schoolyard project probeert kinderen uit het basisonderwijs bewegend te laten leren en kennis te toetsen. Er zijn momenteel niet veel projecten of systemen te noemen die een vergelijkbaar doel hebben gesteld. Het is dus zeker interessant dit gebied binnen educatieve games te verkennen. De opdrachtgever is Prof. Dr. Ir. R. E. Kooij van TNO. De project begeleider is Dr. Ir. R. Bidarra van de TU Delft. Tijdens het laatste kwartaal van ons project zal de heer Bidarra in het buitenland zijn en kan ons dus niet direct ondersteunen. In plaats daar van sturen we donderdag elke week een email rond met een project update. Daarnaast zullen we proberen zo vaak mogelijk met de heer Kooij om tafel te zitten om de voortgang direct te bespreken. De werkplek voor ons project staat niet vast. We kunnen gebruik maken van de practicumzalen aan de Drebbelweg. De heer Bidarra zou nog kijken voor een vaste locatie. De tools benodigd voor het project zijn onze eigen laptops en smartphones (modellen HTC Desire en Google Nexus S). De applicatie wordt ontwikkeld voor Android 2.2+ met behulp van de Android SDK in Eclipse, gebruikmakend van de taal Java (compiler versie 1.6).
2.2 EISEN Het project heeft geen vaste eisen naast het concept, en het feit dat er een werkend prototype ontwikkeld moet worden. Om deze reden stellen wij zelf enkele eisen om het project in goede banen te leiden. Functionele eisen:
Er moest sprake zijn van een server – client systeem, waarbij een enkele server meerdere clients kan ondersteunen. De server geeft het startsignaal aan de client. De client stuurt zijn spelvoortgang terug naar de server. De client moet op elk moment terug kunnen naar zijn start state en de verbinding met de server verbreken. De client moet input vanuit willekeurige bronnen kunnen verwerken om het spel te beïnvloeden (bijv. GPS, of camera). De server en client moeten user interfaces hebben waarop de spelvoortgang te zien is.
Niet-functionele eisen:
Er moet sprake zijn van een educatieve spelomgeving dat de speler toetst over zijn kennis van een bepaald vakgebied. De besturing van zowel de server als client moet simpel worden gehouden. De client moet snel informatie van het scherm kunnen aflezen om zo zijn voortgang in het spel te zien. De spellen moeten simpele regels hebben zodat de speler snel snapt wat de bedoeling is, en dus veel in beweging is. De spellen moeten gebruik maken van de dimensies van een doorsnee schoolplein. 6
De spellen moeten meerdere spelers ondersteunen en zodoende vermijden dat de spelers elkaar niet fysiek in de weg zitten.
Wensen:
Handleiding voor eindgebruikers. Systeem om modificaties en opdrachten te maken binnen bestaande spellen.
2.3 PROTOTYPE Het uiteindelijk ontwikkelde prototype kan gespeeld worden met een enkele laptop en meerdere Android smartphones. De laptop dient als een server, de smartphones als client. Om connectie te maken moet de laptop een wifi hotspot opzetten, waarmee de smartphones vervolgens verbinden. De server registreert alle verbonden clients zodra deze verbinding maken en geeft het startsignaal voor een spelsessie. Tijdens de spelsessie stuurt de client updates van zijn voortgang naar het serverprogramma. Door gebrek aan testapparatuur hebben we de limieten van de wifi en connectie niet op kunnen zoeken. Al hebben we wel succesvol connectie kunnen maken tussen een laptop en smartphone op afstanden van ongeveer 20 meter. De server bestaat uit een Java applicatie, gebruikmakend van de ingebouwde GUI library. De clients draaien op het Android OS en vereisen Android 2.2 of hoger. De client applicatie heeft permissie nodig voor het gebruik van de smartphone camera, internetconnectie en het uitlezen van de telefoon status. Er word gebruik gemaakt van de publieke ZXing (“Zebra Crossing”) library [1] voor het uitlezen van QR codes. De client toont bij het opstarten van de applicatie ook een “Debug” mode, waarbij men zonder connectie met de server het spel kan spelen. Dit was voornamelijk bedoeld om het spel snel te kunnen debuggen zonder daarvoor een server connectie op te moeten zetten.
2.4 HANDLEIDING Dit is een verkorte handleiding om de applicatie in actie te zien. Deze is voornamelijk bedoeld voor ontwikkelaars. Benodigdheden: 1.
2.
Laptop met een Windows 7, Java 1.6, actieve wifi hotspot en het SchoolyardWindowsHost programma. Een handleiding voor het opzetten van een wifi hotspot is te vinden in het netwerk hoofdstuk van het oriëntatieverslag (Appendix B). Een Android smartphone met Android versie 2.2 (of hoger), een camera en wifi mogelijkheden. Het word ook aangeraden de “Barcode Scanner” applicatie van de Android Market (tegenwoordig “Play Store”) te installeren omdat de ZXing library in de huidige implementatie niet goed word meegeleverd tijdens het testen van de applicatie. De Barcode Scanner app neemt deze taak vanzelf over omdat deze met dezelfde library werkt.
Opzetten spel: 1. 2. 3. 4.
Verbind de smartphone met het wifi netwerk dat de laptop aan het broadcasten is. Start het SchoolyardWindowsHost programma op de laptop en druk op de Start/Stop Server knop om de server sessie te starten. Start de SchoolyardClient op de smartphone en druk op Connect. Optioneel: voer een naam in het bovenstaande tekstveld voor makkelijke identificatie op de server. Als het goed is moet de client nu de tekst “Waiting for game” tonen. De server toont de speler in de lijst. Druk op Start Game om het spel te starten. 7
5.
De client moet nu het scherm van de MathRun game tonen. De handleiding van dit spel kan gevonden worden in hoofdstuk 5.1.
Overige functies en bijzonderheden: 1. 2. 3. 4.
De client kan terug naar het start menu door op het rode kruisje rechtsboven in het scherm te drukken. Hierdoor vervalt de speelsessie. De server heeft knoppen voor het accepteren en afwijzen van client connecties, maar deze worden op het moment niet gebruikt. De server accepteert elke connectie poging. De server GUI toont een kolom met alle verbonden gebruikers en hun huidige voortgang. Op het moment is dit opgezet in de context van het MathRun spel. Het IP adres dat de client gebruikt om de server te vinden staat op het moment hardcoded in de NetworkManager class van de SchoolyardClient broncode. Deze moet verwijzen naar het adres van de wifi hotspot die op de laptop is opgezet.
8
3. PLANNING In de eerste fase van het project hadden we een Plan van Aanpak (zie Appendix C) opgesteld, welke gebruikt zou worden als richtlijn voor de projectplanning. Het project zou lopen van februari tot juli, verspreid over het hele semester. Gewoonlijk loopt het bachelorproject een enkel kwartaal fulltime, maar in ons geval was het parttime 3 dagen per week. We zullen eerst de voorgenomen planning beschrijven in 3.1, gevolgd door de werkelijke planning in 3.2.
3.1 VOORGENOMEN PLANNING Het project zou worden opgesplitst in een oriëntatiefase, ontwerpfase, implementatiefase en testfase. De laatste 3 genoemde fasen zouden sterk verwikkeld zijn omdat het waterfall model, waarbij de oriëntatie-, ontwerp-, implementatie-, en testfasen elkaar sequentieel opvolgen, niet ideaal is voor het ontwikkelen van een spel. In plaats daarvan pasten we iterative development toe, waarbij prototypes en tests elkaar vlug opvolgen. Tijdens de oriëntatiefase, na het opstellen van het Plan van Aanpak document, moesten we onderzoek doen en keuzes maken op het gebied van platform, communicatie techniek, locatie bepaling, spel ontwerpen, spel omgeving en de gebruikers. Deze fase wilden we verspreiden over de maand februari. Hierna zou de ontwerp en implementatie fase van start gaan. Het doel was de eerste werkende prototypes tegen eind maart te hebben, en deze gedurende de maanden daarna verder te ontwikkelen en te testen. Er was gepland 3 speltypes te implementeren. In de eindfase van ons project hoopten we een live test te kunnen doen met een groep kinderen van de basisschool. Het was dus essentieel dat we een speelbaar prototype begin juni hadden. Ten slotte moesten we ons eindrapport en presentatie opbouwen, waarvoor we begin juli in gedachten hadden.
3.2 WERKELIJKE PLANNING De uiteindelijke planning week sterk af van de oorspronkelijke. De oriëntatiefase verliep redelijk als gepland en ging niet verder dan de maand februari. De ontwerpfase verliep echter een stuk minder snel dan gehoopt. Het oorspronkelijke idee om GPS te gebruiken vereiste onderzoek naar de nauwkeurigheid en stabiliteit van de GPS ontvangst van onze huidige smartphones. Hiervoor moesten we een prototype bouwen. Uiteindelijk bleek het gebruik van de GPS niet nauwkeurig genoeg voor het gebruik op het schoolplein, wat betekende dat we weer van voor af aan begonnen met onze code. Tegen die tijd was het halverwege april. Hierna besloten we de applicatie rond de camera en QR codes te bouwen. Het duurde een paar weken voordat hier een werkend prototype van was, maar het probleem schoof nu richting de networking tussen de centrale laptop en smartphones. Rond deze tijd gingen we ook op zoek naar extra test telefoons. Uiteindelijk ging de maand juni snel voorbij. Het duurde tot eind juni voordat de netwerkcode stabiel werkte, geplaagd door hardware en 3rd party software issues. Daarnaast was het ons ook niet gelukt extra test telefoons te krijgen. We moesten ons prototype terugschalen naar een enkel spel, en de live test werd van af gezien. Het doel was nu een goed prototype en eindrapport neer te zetten en de basis te leggen voor een mogelijk vervolgproject.
9
4. ONDERZOEK Dit zullen verkorte samenvattingen zijn van het onderzoek beschreven in het oriëntatieverslag in Appendix B.
4.1 PLATFORM KEUZE Voor de platformkeuze hadden we verschillende opties tot onze beschikking. Er was specifieke hardware zoals Siftables die Jorien van Vliet in haar verslag [2] voorstelt, en er waren de 3 grote mobiele platformen die op het moment het grootste deel van de markt in hun hand hebben: de Apple iPhone, Windows Phone en Android. Wij hebben voor Android gekozen om een aantal redenen. Ten eerste hadden we Android telefoons tot onze beschikking. Ten tweede is het makkelijk om voor het Android platform te ontwikkelen. Het enige wat je nodig hebt is Eclipse en de Android SDK, beide gratis producten. Door de openheid zit er ook een grote community van ontwikkelaars achter het platform, zodat het makkelijk was om hulpmiddelen en voorbeelden te vinden tijdens de ontwikkeling van de applicatie. Ten slotte zijn Android telefoons uitgerust met een hele reeks sensoren en input mogelijkheden, zoals het touchscreen, GPS, Wifi, Bluetooth, camera’s, etc.
4.2 COMMUNICATIE TECHNIEK Een van de punten die ons onderzoek moest uitwijzen was welke communicatie techniek geschikt zou zijn om data tussen de verschillende telefoons uit te wisselen en het spel bij te houden. Omdat we voor het Android platform gekozen hadden waren Wifi en Bluetooth de meest voor de hand liggende opties. Hiervan bleek Wifi het meest aantrekkelijk, omdat Bluetooth een vrij beperkt bereik had en extra handelingen vereiste om verbinding te leggen. Een Wifi verbinding leggen tussen een laptop en een smartphone bleek echter niet voor de hand liggend. In alle Android versies ouder dan de recente 4.0 is het niet mogelijk om een ad-hoc Wifi verbinding aan te leggen, omdat dit softwarematig geblokkeerd is. We moesten de laptop dus als Wifi hotspot laten dienen, vergelijkbaar met hoe een draadloze internetrouter functioneert. Deze feature zat gelukkig in het Windows 7 besturingssysteem ingebouwd. Deze techniek bleek voldoende voor het functioneren van onze applicatie.
4.3 LOCATIE BEPALING Het project begon met het idee de GPS te gebruiken voor locatiebepaling. Echter, na het bouwen van het eerste prototype, bleek al snel dat de GPS van onze test telefoon niet nauwkeurig genoeg is. De nauwkeurigheid was tussen de 10 en 20 meter, wat niet praktisch is voor een schoolplein wat waarschijnlijk maar enkele tientallen meters lang is. We gingen hierbij van uit dat de test telefoon (een HTC Desire) vrij representatief is voor de gemiddelde particuliere GPS. Onze tweede optie was triangulation te gebruiken, een techniek waarbij meerdere zendpunten van een signaal gebruikt worden voor het vaststellen van een relatieve positie ten opzichte van de zendpunten. Dit kan op verschillende manieren: een optie is om de zendmasten voor mobiele telefonie te gebruiken. Dit bleek bij voorbaat al onhandig, volgens alle geraadpleegde bronnen was dit accuraat op honderd of meer meter. Een andere optie was om wifi en Bluetooth zendpunten te gebruiken. Deze methode vereiste echter specifieke hardware en viel dus ook af voor gebruik in het project. We maakten uiteindelijk de keuze om gebruik te maken van de ingebouwde camera die veel smartphones bevatten. Het idee was dat door codes of symbolen verspreid over het schoolplein te plaatsen, de gebruiker deze kan scannen met de camera om zo het signaal te geven dat hij op een bepaalde positie is aangekomen.
10
We hebben ervoor gekozen om QR codes hiervoor te gebruiken, omdat we dan een externe library konden toepassen, wat ons ontwikkelingstijd scheelde.
4.4 GEBRUIKERS We hebben ons niet heel erg verdiept in het gebruikersonderzoek. In plaats daarvan konden wij ons baseren op het Schoolyard verslag van Jorien van Vliet [2]. Door de experimentele aard van het project was een diepgaand onderzoek ook niet benodigd: het Schoolyard systeem vervangt geen bestaand systeem, het is bedoeld als een mogelijke aanvulling op het lesprogramma van de basisschool. Echter, er moet wel gezegd worden dat het succes van ICT projecten in de schoolklas sterk samenhangt met de meerwaarde die het biedt [3]. De gebruikersgroep bestaat uit de leraar en zijn klas. Van basisschoolleraren worden geen vergaande ICT vaardigheden vereist, en om deze reden hebben we als doel gesteld de bediening van onze applicatie zo simpel mogelijk te houden. De leerlingen zouden veel in beweging zijn, en dus moest hun bediening nog simpeler. Daarnaast moest informatie snel en goed zichtbaar zijn.
4.5 SPEL OMGEVING De applicatie moet kunnen functioneren in de omgeving van een schoolplein. Schoolpleinen zijn ontworpen voor spelende kinderen, waardoor we ons niet erg druk hoefden te maken over mogelijke fysieke limieten voor het Schoolyard systeem. Echter, spellen moesten wel zo ontworpen worden dat kinderen elkaar niet in de weg zouden zitten tijdens het uitvoeren van de opdrachten die het spel aan hun toewees. Om de reden stelden we oorspronkelijk een limiet van 10 spelers per spelsessie, al hebben we deze grens nooit kunnen testen.
11
5. ONTWERP 5.1 SPEL ONTWERP Er waren 5 verschillende spelconcepten ncepten gemaakt. Deze zijn te vinden in Appendix D. Het ontwerp dat uiteindelijk in de prototype is opgenomen is MathRun / RekenRen. Aan het begin van het spel worden 2 getallen op het scherm getoond. getoond Het bovenste getal is zijn startcijfer, het onderste getal ge het doelcijfer. Door op het bovenste cijfer te drukken gaat het spel naar camera modus. Nu moet de gebruiker een QR code inscannen. Bepaalde QR codes zijn verbonden aan bepaalde operaties. Voorbeelden van operaties zijn “minus 5”, “plus 3”, “maal 2”, “delen “ door 3”. Door een operatie in te lezen wordt deze uitgevoerd op het huidige cijfer, en veranderd deze naar het resultaat van de operatie. De volgende QR code staat in het huidige prototype voor de operatie “plus 5”:
Als je huidige cijfer 18 is, en je scant bovenstaande code in, dan veranderd je huidige cijfer in 23. 2 Het doel voor de speler is om in zo weinig mogelijk stappen het huidige cijfer in het doelcijfer om te zetten. Als dit eenmaal gelukt is toont het scherm dat de speler gewonnen heeft, en herstart het spel. Op het moment is het zo dat de server applicatie alle beschikbare operaties doorgeeft in de payload van de GAME_START message. Operaties zijn gebonden aan een code. In het huidige prototype kunnen de volgende volg operaties gevonden worden in de GameManager class in de SchoolyardWindowsHost broncode: fieldOps.put("op1", fieldOps.put("op2", fieldOps.put("op3", fieldOps.put("op4", fieldOps.put("op5", fieldOps.put("op6", fieldOps.put("op7", fieldOps.put("op8",
(new (new (new (new (new (new (new (new
Operation(5, Operation(3, Operation(2, Operation(3, Operation(7, Operation(6, Operation(5, Operation(8,
Operator.ADD)).toString()); Operator. Operator. Operator.SUBTRACT)).toString()); Operator. Operator.MULTIPLY)).toString()); Operator. Operator.DIVIDE)).toString()); Operator. Operator.ADD)).toString()); Operator. Operator.MULTIPLY)).toString()); Operator. Operator.DIVIDE)).toString()); Operator. Operator.SUBTRACT)).toString());
“op1”, “op2”, “op3”, p3”, etc. staan dus respectievelijk voor de operaties “plus 5”, “minus 3”, “maal 2”, etc. Om deze codes om te zetten van tekst naar een QR code afbeelding kunnen online services zoals http://qrcode.kaywa.com/ gebruikt worden. Een enkele QR code kan dus verschillende betekenissen toegewezen worden in de code van de applicatie.
12
5.2 SHARED CODE Alle gedeelde code is te vinden in het Schoolyard project. Het kan niet op zichzelf uitgevoerd worden, maar is essentieel voor de SchoolyardClient en SchoolyardWindowsHost projecten.
GEDEELDE CODE De volgende code wordt gedeeld tussen zowel het server al het client project, omdat deze klassen vaak essentieel zijn voor consistente communicatie tussen beide applicaties. Met name het protocol voor berichten die verstuurd worden moet aan beide kanten gelijk zijn.
PACKAGES Om alles consistent te houden volgen deze packages dezelfde benaming en indeling. -
nl.tudelft.schoolyard.game Bevat de basis abstractie om de Games te realiseren. nl.tudelft.schoolyard.game.mathrun Heeft de basis elementen van een MathRun game. nl.tudelft.schoolyard.net Deze package bevat de code die beide programma’s gebruiken voor het verzenden vnet netwerk berichten. nl.tudelft.schoolyard.net.exceptions Package voor de exception die de Message.parse kan werpen.
KLASSEN Game Abstractie die er voor zorgt dat de benodigde methoden aanwezig zijn. Methoden - onDataInput(input) Verwerk input van een component wat speler handelingen detecteert. - getCurrentObjective() Geef het huidige object terug. - setCurrentObjective(objective) Zet het huidige object. Objective Abstractie die er voor zorgt dat de benodigde methoden aanwezig zijn. Attributen - isCompleted
Of het doel al bereikt is.
Player Speler object dat standaard informatie bevat dat gesynchroniseerd gehouden moet worden tussen de server en client. Attributen - name - deviceID
De naam die opgegeven is door de speler. De unieke deviceID van het Android apparaat van de speler.
13
MathRunObjective Het doel wat bereikt moet worden in een enkele spelsessie van MathRun. Attributen - startNumber - targetNumber - currentNumber - appliedOperations
Het nummer vanaf waar begonnen wordt. Het doel nummer. Het huidige nummer. De geschiedenis van toegepaste operaties.
Methoden - applyOperation(op) Past de gegeven operatie toe op het huidige nummer. Operation Wiskundige operatie met een gegeven rechterhand waarde dat uitgevoerd kan worden op een gegeven linkerhand waarde. Attributen - number - operator
De rechterhand waarde. De operatie.
Methoden - canApplyToNumber(input) Kijkt of de operatie toegepast kan worden op de gegeven waarde. - applyToNumber(input) Past de operatie toe op de gegeven waarde. - parse(str) Zet een string om naar een Operation object. - toString() Zet het object om in een string voor netwerk transmissie. - toStringVisual() Zet het object om in een string voor visualisatie gebruik. Message Netwerk bericht object wat zichzelf in een string kan omzetten en zichzelf daaruit weer kan opbouwen. Attributen - messageDelimiter Gebruikt als markering in de string. - payloadDelimiter Gebruikt als markering in de string. - keyvalDelimiter Gebruikt als markering in de string. - keyvalEndDelimiter Gebruikt als markering in de string. - emptyPayloadIdentifyer Gebruikt als markering in de string. - sender Degene die het bericht verstuurd (heeft). - messageType Het type bericht. - payloadEntries Payload van het bericht. Methoden - parse(msg) Zet een string om naar een Message object.
14
- encodeHashMapForPayload() Zet een hashmap om in een string om verstuurd te worden met een Message. - decodeHashMapFromPayload(entry) Zet een string van de payload om in een hashmap. - toString() Zet het bericht om in een string wat klaar is om verstuurd te worden. MessageFormatException Speciale exception wat gegenereerd wordt tijdens het parsen van Message objecten zodat de fout makkelijker identificeerbaar is. MessageType Enum van de verschillende type berichten. MessageBuffer Verzamelt de string weergave van een message object in blokken totdat het compleet is. Attributen - PACKAGEDELIMITER - message - deviceID
Gebruikt als markering voor het einde van een Message. Stringbuffer van het tot nu toe verzamelde bericht. deviceID van het android object waar deze buffer mee verbonden is.
Methoden - append(values) Voeg een nieuw deel van het bericht toe aan het tot nu toe verzamelde stuk. - extractString() Haal de complete string weergave van het bericht uit de StringBuffer en reset de StringBuffer
15
5.3 SERVER IMPLEMENTATIE Het server project, SchoolyardWindowsHost, vereist Java 1.6. Daarnaast moet het Schoolyard project met alle gedeelde code inbegrepen worden. Deze applicatie is alleen getest op Windows 7 x64 maar er is geen reden te verzinnen waarom het niet op andere platformen kan werken.
SERVER De server moet meerdere verbindingen tegelijk kunnen afhandelen. Bij het ontwikkelen van de server is de focus ook gelegd op de afhandeling van netwerk verbindingen en de berichten binnen de applicatie. Vooral in welke thread deze behandeld worden. Er is gekozen voor een single thread netwerk beheer, in tegenstelling tot een thread per verbinding.
PACKAGES Net zoals de client zijn de server packages opgedeeld aan de hand van het soort functionaliteit dat klassen bieden. Een dergelijke benaming van de packages was niet nodig geweest voor een Windows Java programma, maar is behouden voor de consistentie met de client packages. -
nl.tudelft.schoolyard Hierin staat het program main entry point en hoofdklasse SchoolyardServer en de update thread de ServerUpdateLoop nl.tudelft.schoolyard.interfaces Dit bevat de Interface voor de update observer pattern aan de server kant. nl.tudelft.schoolyard.managers De beheerders van data zijn hierin verzameld. nl.tudelft.schoolyard.net Verzameld staan hier de klassen die te maken hebben met de netwerk verbinding zoals de thread die van het netwerk leest als de input en output buffers. nl.tudelft.schoolyard.views Verzameling van de GUI elementen van de server.
KLASSEN Voordat we de specifieke klassen gaan belichten bekijken we eerst de globale structuur aan de hand van een klassendiagram. Om een volledig beeld te krijgen van de werking van de klassen wordt aangeraden om naar de javadoc comments te kijken.
16
SchoolyardServer Bevat het main entry point van het programma. Initialiseerd de rest van het programma en beheert het starten en stoppen van de netwerk verbinding. Attributen - running - debug - SERVER_PORT - frame - window - sLoop - sUpdateLoop
Flag die weergeeft of de netwerk verbinding aan staat of niet. DebugPanel waarnaar debug berichten gestuurd worden. Poort waarop de server gaat luisteren naar inkomende verbindingen. Venster waarin de server wordt weergegeven. SchoolyardWindow wat weergegeven wordt binnen het frame. ServerNetworkLoop dat de netwerk verbinding blijft uitlezen. Thread dat de geregistreerde ServerUpdatable objecten aanroept.
Methoden - showGUI() Initialiseerd de GUI en maakt deze zichtbaar. - toggleServer() Veranderd de staat van de server van aan naar uit, en vice versa. - debug() Print een debug bericht op de DebugPanel
17
ServerUpdateLoop Runnable Observerable object dat de updates van de ServerUpdatable objecten aanroept elke 16 milliseconden (ongeveer 60 keer per seconde). Attributen - updatables
Lijst van geregistreerde objecten.
Methoden - run() Deze methode loopt totdat de server afsluit en roept de update methoden van de geregistreerde objecten aan. Met een minimum wachttijd tussen de aanroepen van 16 milliseconden. - addUpdatable(id, updatable) Registreer een nieuw ServerUpdatable object aan de hand van de gegeven ID. ServerUpdatable Interface dat de update methode garandeert voor de ServerUpdatable observerable. Methoden - update() Ongedefinieerde methode. ConnectionManager Kijkt naar de berichten van nieuwe spelers en accepteert deze wanneer ze in de tabel zijn ingevoegd. Beheert het toevoegen en verwijderen van spelers in de tabel. Attributen - playerList - panel
Lijst van spelers gesorteerd op deviceID van de Android telefoons. PlayerListPanel waarmee de connectionManager verbonden is.
Methoden - newPlayer(deviceID, name) Maakt een nieuwe player aan in zijn eigen lijst van Player objecten. - update() Verwerkt netwerk berichten van het type PLAYER_IDENTIFICATION en update zichzelf en de tabel in de GUI respectievelijk - actionPerformed(event) Callback voor wanneer een van de knoppen wordt ingedrukt waar de ConnectionManager zich voor heeft geregistreerd. GameManager Kijkt naar de berichten van spelende servers en update hun gegevens in de GUI tabel. Attributen - panel
PlayerListPanel waarmee de GameManager verbonden is.
Methoden - update() Kijkt naar de beschikbare netwerk berichten van type OBJECTIVE_UPDATE en GAMESTATE_UPDATE en roept de gerelateerde methoden aan. - processObjectiveUpdate() Verwerk een bericht van type OBJECTIVE_UDPATE en update de GUI met de nieuwe informatie als dat nodig is. - processGamestateUpdate() Verwerk een bericht van type GAMESTATE_UPDATE en update de GUI met de nieuwe informatie. - startNewGame() Broadcast een Message van type GAME_START naar alle verbonden clients om zo simultaan globaal het spel te starten. 18
Input Singleton netwerk buffer voor binnengekomen berichten. Deze berichten worden gesorteerd op bericht type zodat elk object berichten kan opvragen waar het verantwoordelijk voor is. Attributen - instance - lock
Singleton instantie van Input Lock object voor de synchronized blokken voor thread-safety
Methoden - putMessage(msg) Zet een bericht in de buffer aan de hand van het bericht type. - getMessage(type) Geeft een lijst van alle berichten van dat type. Lijst is lengte 0 als er niets is. En leegt vervolgens de buffer van dit type. Output Singleton netwerk buffer voor uitgaande berichten. Deze berichten worden gesorteerd op deviceID van de bedoelde ontvanger. Attributen - instance - lock
Singleton instantie van Output Lock object voor synchronized blokken voor thread-safety.
Methoden - putMessage(msg, targeted) Zet een bericht in de buffer voor de gespecificeerde ontvanger. - getMessages(targetID) Geeft een lijst van alle berichten voor deze ontvanger. En leegt vervolgens de buffer voor deze ontvanger. - hasMessage(targetID) Kijkt of er berichten zijn voor deze ontvanger. - broadcast(msg) Stopt dit bericht in de buffer van elk geregistreerde speler. - removePlayer(deviceID) Verwijdert de buffer van de gespecificeerde speler. ServerNetworkLoop Loop die constant kijkt of er nieuwe activiteiten zijn bij de geregistreerde channels. En vervolgens de activiteit afhandelt. Attributen - port - ssc - selector - startTime - BUFSIZE
Poort waarop er geluisterd wordt. ServerSocketChannel waarop er naar verbinden geluister wordt. Observerable object voor de channels. Start tijd van de huidige iteratie. Maximum hoeveelheid bytes die uit de channel gelezen worden in een keer.
Methoden - run() Blijft loopen totdat de SchoolyardServer de running flag uit zet. Kijkt elke keer of er activiteit is, zo ja roept de methode aan om het te verwerken - processKeys() Kijkt welke type activiteit er bij welke channel hoort en roept voor dat type een specifieke methode aan. - processWrite(key)
19
Schrijft alle beschikbare berichten in de Output buffer weg voor de ontvanger waar deze channel bij hoort. - processRead(key) Leest van de channel en stopt het in de MessageBuffer. Roept gerelateerde methode aan als het Message object compleet is. - closeConnections() Sluit alle channels behalve de ServerSocketChannel waarop de server aan het luisteren is. - readMessage(key) Verwerkt het bericht en stop het in de Input buffer. - getMessagePart(key) Leest een blok bytes van de channel en geeft een string terug. - acceptConnection(key) Verwerkt een nieuw binnenkomende verbinding. - removePlayer(key) Sluit de SocketChannel gerelateerd aan deze SelectionKey. DebugPanel GUI element om debug berichten weer te geven. Attributen - console - button - server
JTextArea waarin de debug weggeschreven wordt. JButton die de netwerk verbinding aan en uit zet. De SchoolyardServer.
PlayerListPanel GUI element waar de tabel in staat met alle relevante speler data. Attributen - acceptButton - rejectButton - startButton - connectionList - players
Knop om een speler te accepteren. Staat altijd uit omdat spelers automatisch geaccepteerd worden. Knop om een speler te weigeren. Staat altijd uit omdat spelers automatisch geaccepteerd worden. Knop om het spel simultaan voor alle verbonden spelers te starten. JTable met alle data van de spelers. Table Model waarin de daadwerkelijke data van de spelers staat.
Methoden - addNewElement(deviceID, playerName) Voegt een nieuwe speler toe aan de tabel. Mocht de deviceID al bestaan wordt de naam overschreven. Als er na toevoeging meer dan 1 speler in de lijst staat wordt de start knop geactiveerd. - setElementState(deviceID, state) Zet de status van de speler. - updateElement(deviceID, current, target) Update de game info bij de speler met deze nieuwe waarden. - resetElementCount(deviceID) Reset de telling van hoeveel stappen de speler nodig heeft om het doel te bereiken. - removeElement(deviceID) Verwijder deze complete regel uit de tabel. SchoolyardWindow Verzameling van de GUI elementen Attributen - panels
Verzameling van alle GUI elementen.
20
5.4 CLIENT IMPLEMENTATIE Het client project, SchoolyardClient, vereist Java 1.6 en de Android 2.2 (API 8) package die te verkrijgen is met de Android SDK. Daarnaast moet de core.jar van de ZXing library opgenomen worden in de build path.
ONTWERP In de ontwerpfase zijn we begonnen vanuit een basis architectuur die we zelf vaker gebruikt hebben in games. Dit framework is vervolgens ingevuld en verbeterd volgens een iteratief proces. We hebben het bachelor project in 4 aparte JAVA projecten verdeeld: - Client - Server - Gedeelde code tussen Server en Client - Test-Code
CLIENT De client is ontworpen om flexibel te zijn met de mogelijke spel types. En om modules te kunnen wisselen waar nodig. Bijvoorbeeld de WiFi NetworkManager te vervangen door een bluetooth module. Of de QR-code scanner door een real-time GPS systeem.
PACKAGES De packages zijn gesorteerd op het soort functionaliteit dat klassen bieden. Zo zijn bijvoorbeeld de interfaces voor de Observer patterns bij elkaar gebonden. En zo zijn ook de Observers weer bij elkaar gegroepeerd. -
-
nl.tudelft.schoolyard De enige klasse die hier in staat is een extended vorm van de Android Activity die uniek is in zijn soort in deze applicatie. nl.tudelft.schoolyard.game In deze package zitten de Gerealiseerde spel-concepten. En het hoofdmenu wat de visualisatie en updates van een game overneemt zonder daadwerkelijke spelfunctionaliteit om zo het hoofdmenu weer te geven. nl.tudelft.schoolyard.game.mathrun Hierin staan alle klassen die specifiek nodig zijn voor het realiseren van een mathrun spel-type. nl.tudelft.schoolyard.gamelogic Hier staan de klassen die de (timing van de) stroom van het programma sturen, namelijk de Runnable objecten voor de update en draw threads. nl.tudelft.schoolyard.interfaces Verzameld zijn hier de interfaces die gebruikt worden bij Observer patterns voor de update en draw calls, maar ook de netwerk call-backs nl.tudelft.schoolyard.managers Dit zijn de klassen die of als een observerable handelt of als singleton een bepaalde beherende taak op zich neemt. nl.tudelft.schoolyard.util De util package is een verzameling van klassen die globaal nuttig zijn. nl.tudelft.schoolyard.views Hierin staat het enige scherm element wat getekend moet worden.
KLASSEN Met een klassendiagram schetsen we eerst een globale structuur van het programma waarna we een voor een de klassen en hun belangrijkste methoden behandelen. Om een volledig beeld te krijgen kan JAVA code geraadpleegd worden waar bij elke methode een javadoc commentaar is toegevoegd.
21
SchoolyardClient Vanuit dit object komt de meeste interactie met het OS zoals de beschikbaarheid van verschillende threads en i/o methoden. De verantwoordelijkheden wordt zo goed mogelijk verdeeld over de managers, maar veel blijft toch afhankelijk van dit object. Attributen - tag - MATHRUN - deviceID - drawManager - updateManager - networkManager - drawLoop - updateLoop - inScanMode - activeGame - player - active - hideText
String tag die gebruikt wordt om android debug logging te identificeren. unieke int identifier voor een mathrun game. String dat uniek is voor elke android telefoon. Observerable van de drawable observers. Observerable van de updatable observers. Verantwoordelijk voor netwerk communicatie. Regelt de timing van de calls aan de drawManager. Regelt de timing van de calls aan de updateManager. Flag die wordt aangezet wanneer de qr-code scanner actief is Huidige active SchoolyardGame object Player object wat de speler op deze client voorstelt Flag die wordt uitgezet wanneer het OS deze applicatie pauzeert Een runnable object wat uitgevoerd wordt om een textarea te verbergen 22
Methoden - onCreate(savedInstanceState) Grofweg de constructor van de applicatie. Is in ieder geval de eerste methode die wordt aangeroepen vanuit het OS na het starten van de applicatie. Is dus verantwoordelijk voor het initialiseren van de applicatie. - startGame(type, startMsg) Start een nieuwe SchoolyardGame van het gegeven type gebruikmakend van het meegegeven netwerk bericht. Omdat er maar 1 speltype is, wordt automatisch een MathRunClient aangemaakt ongeacht de waarde van type. - returnToMenu() Verwijderd het actieve spel en zet het hoofdmenu als actief object neer. - onPause() Wordt aangeroepen vanuit het OS als signaal dat de applicatie gaat pauzeren. Hier worden de update en drawloops uitgezet. - onResume() Wordt aangeroepen vanuit het OS als signaal dat de applicatie zich hervat. Hier worden de update en drawloops gestart. - startScan() Start de qr-code scanner - onActivityResult(requestCode, resultCode, intent) Verwerk het resultaat van een eerder aangeroepen applicatie. In ons geval het resultaat van de qrcode scanner. Stuurt het resultaat door naar het actieve game. SchoolyardGame Deze klasse zorgt voor de aanwezigheid van methoden nodig om een spel te realiseren. Implementeert de afhandeling van touch-events en geeft subklassen de mogelijkheid om eenvoudige methodes te overschrijven zonder zich zorgen te hoeven maken over de touch-events. Attributes - screentext
Verzameling van alle Text2D elementen die op het scherm worden getekend
Methoden - onDownEvent(downs) Callback die subklassen kunnen overschrijven om alle down-events te verwerken. - onUpEvent(up) Callback die subklassen kunnen overschrijven om up events te verwerken. Gelimiteerd tot 1 up event per callback. - onTouch(view, event) Callback van het OS die dit object informeert over een touch event. Kijkt of het event een up of down event is en kijkt of Text2D elementen geraakt zijn of niet. - draw(canvas) Tekent alle Text2D elementen op het scherm. Menu Het hoofdmenu van de schoolyard client waar de client zijn/haar naam kan invoeren en een verbinding kan starten met de server. Na het openen van de verbinding wordt er gewacht op een bericht van de server om een spel te starten.
23
Attributen - MENU State id voor het absolute begin scherm - CONNECTING State id voor wanneer er gewacht wordt op de verbinding met de server - WAITING_FOR_GAME State id voor wanneer er gewacht wordt op een bericht van de server. - activity De SchoolyardClient. - nameEditor Textarea waar de speler zijn/haar naam kan invoeren - state de huidige state van het menu - startGame Flag die wordt aangezet wanneer er vanuit de update thread een nieuwe game gemaakt wordt - startGameparam Parameter die meegegeven wordt wanneer een game aangemaakt wordt. Methoden - onDownEvent(downs) Geeft de ingedrukte text een andere kleur. - onUpEvent(up) Vuurt de juiste methoden aan de hand van welke text/”knop” gedrukt was. - resetTextColours() Zet de tekst terug in haar originele staat. - connectWithServer() Zegt tegen de activity om de netwerk verbinding te starten. - changeToState(state) Veranderd de state van het menu en verander de zichtbare elementen waar nodig. - handleNetworkMessage(msg) Verwerk een bericht wat binnengekomen is vanuit de netwerk manager. MathRunClient De klasse die het MathRun spel definieert. Hier in worden de update / draw loops en alle input verwerkt specifiek voor dit spel. Attributen - operations Alle Operation objecten die op het moment op het speelveld zijn - currentObjective De huidige objective - difficulty De moeilijkheidsgraad. Word op het moment alleen gebruikt voor het aantal stappen waarn in doel getal vanaf het startgetal gegenereerd word. - curNumber Scherm tekst object van het huidige nummer - targetNumber Scherm tekst object van het doel nummer - history cherm tekst object van de historie van toegepast Operation objecten - canPress Boolean check of er scherm invoer word verwerkt of niet - lastOperationFailed Boolean voor als de laatst toegepaste Operation niet toegepast kon worden - activity De SchoolyardClient - timer Timer object voor vertraagde acties - winResetTime Tijd in seconden voordat de game opnieuw start nadat de speler wint - soundNTextUpdateDelay Tijd in seconden voor de vertraging waarmee geluid wordt afgespeeld en de scherm tekst veranderd nadat input is verwerkt - pressDelayAfterScan Tijd in seconden wanneer de speler weer op het scherm kan drukken nadat input is verwerkt Methoden - processStartMessage(msg)
24
Verwerkt het startbericht van de server nadat deze klasse is aangemaakt. Hier in worden de huidige Operations van het speelveld uitgelezen. - processInput(input) Verwerkt input - playSoundEffects() Speelt een geluidseffect af afhankelijk van of de laatste Operation geslaagd is - updateTextFields() Update alle tekst velden met de laatste spelgegevens - setAvailableOperations(operations) Zet alle huidige Operation objecten die het spel kan gebruiken - initNewObjective() Bouwt een nieuw MathRunObjective aan de hand van een MathRunTask op en initieert deze - onDataInput(input) Word aangeroepen zodra er data input is. Word doorgegeven aan de processInput methode en zorgt ervoor dat de gebruiker tijdelijk niet op het scherm kan drukken - onUpEvent(up) Verwerkt het indrukken van tekstvelden - handleNetworkMessage(msg) Verwerkt specifieke network messages voor de game. Wordt niet gebruikt in MathRun MathRunTask Deze klasse wordt gebruikt voor het genereren van MathRun objectives. Het genereert een start en eind getal aan de hand van een aantal limieten en een simpel algoritme. Attributen - possibleOperations - startNumber - targetNumber - numOperationsToApply genereren van het doel getal - minStartNumber - maxStartNumber - maxTargetNumber - minTargetNumber
Alle Operations die gebruikt kunnen worden Het gegenereerde start getal Het gegenereerde doel getal De hoeveelheid Operations die toegepast mogen worden voor het Het minimum voor het start getal Het maximum voor het start getal Het maximum voor het doel getal Het minimum voor het doel getal
Methoden - generate() Genereert een start getal en doel getal, net zo lang totdat deze aan de gezette criteria voldoen - targetNumberValid(startNum, targetNum) Controleert of het gegeven start en doel getal aan criteria voldoen DrawLoop Beheert de timing van de draw calls die de DrawManager vuurt. Attributen - drawManager
De DrawManager waarvan de timing beheerd wordt.
Methoden - run()
25
Blijft loopen totdat de Activity pauzeert. En roept de draw functie van de DrawManager aan op de in de constructor gespecificeerde frequentie. UpdateLoop Beheert de timing van de update calls die de UpdateManager vuurt. Attributen - updateManager
De UpdateManager waarvan de timing beheerd wordt.
Methoden - run() Blijft loopen totdat de Activity pauzeert. En roept de update functie van de UpdateManager aan op de in de constructor gespecificeerde frequentie. Drawable Interface dat de draw methode garandeert voor de Drawable observerable. Methoden - draw(canvas) Ongedefinieerde methode. NetworkListener Interface dat de handleNetworkMessage garandeert voor een callback vanuit de SchoolyardClient Methoden - handleNetworkMessage(msg) Ongedefinieerde methode. Updatable Interface dat de update methode garandeert voor de Updatable observerable. Methoden - update(activity) Ongedefinieerde methode. DrawManager Beheert het scherm van de SchoolyardClient. Van het tekenen tot het registreren van objecten die naar touchevents luisteren. Attributen - drawables - view - holder
Lijst van Drawable observers SufraceView waarop getekend wordt. SurfaceHolder die het canvas beheerd tussen de draw-calls door.
Methoden - draw() Calls the draw method of all registered Drawables. - registerDraw(id, drawer) Register a new Drawable object with given id.
26
- registerTouchListener(listener) Registers an OnTouchListener object to listen for and handle touch-events. - clear() Clears the list of registered drawables. NetworkManager Beheert het netwerk verkeer. Luistert elke update of er nieuwe informatie is binnengekomen. Attributen - SERVERIP - SERVERPORT - READ_SIZE - channel - socketAddr - messageBuffer - isConnecting
IP van de server. Poort waarop de server luistert. Grootte van het blok wat in een keer gelezen wordt. SocketChannel waarmee de client verbonden is met de server. Het InetSocketAddress waar de SocketChannel mee verbindt. MessageBuffer object wat blokjes van een Message omzet in een compleet Message object Flag wat aangeeft of de NetworkManager nog bezig is met verbinden.
Methoden - attemptConnection() Probeert even te verbinden met de server. Zet de isConnecting Flag uit wanneer het lukt. - onFinishConnecting() Callback voor wanneer de verbinding gemaakt is. - close() Sluit de verbinding met de server. - sendMessage(msg) Stuurt een bericht naar de server. - update(activity) Als er data beschikbaar is leest het van de SocketChannel en voegt het toe aan de MessageBuffer. Verwerkt Message wanneer het compleet is. Output Singleton wrapper voor de netwerk manager die kijkt of hij wel geïnitialiseerd is. Attributen - lock - out
Object dat gebruikt wordt om de klasse te locken tijdens een synchronized Block. Instantie van zichzelf
Methoden - initialize(network) Initialiseerd de Singleton en zet de NetworkManager. - invalidate() Verwijdert z’n eigen static instantie zodat er geen berichten meer verstuurd worden. - sendMessage(message) Schrijft een bericht naar de netwerk manager. SoundManager Beheert geluidseffecten die de telefoon kan afspelen.
27
Attributen - SOUND_ALLOW - SOUND_DENY - manager - soundPool - soundPoolMap - audioManager - context
Index voor positief geluidseffect Index voor negatief geluidseffect SoundManager singleton Het SoundPool object Map voor het mappen van indices naar werkelijke geluidseffect indices AudioManager object Het Context object
Methoden - initialize(context) Initialiseert de sound engine en voegt de gebruikte geluidseffecten toe - play(index) Roept playSound aan van de singleton - playSound(index) Speelt het geluid met de gegeven index af UpdateManager Observerable klasse die zich bezighoudt met de update methoden van de Objecten die de Updatable interface implementeren. Attributen - activity - updatables
De SchoolyardClient. De geregistreerde updatable objecten.
Methoden - update() Roept de update methode aan van alle geregistreerde Objecten - registerUpdate(id, updater) Registreert een nieuw updatable Object met een gegeven id. - clear() Verwijdert alle geregistreerde Objecten SYLog Wrapper om de static Android Log klasse. Zo worden errors afgevangen die alleen gegenereerd worden wanneer vanuit het test-project de Log klasse wordt aangeroepen. Methoden - d(msg) Wrapper om de Log.d functie die exceptions afvangt. - e(msg) Wrapper om de Log.e functie die exceptions afvangt. ParamTimerTask Uitbreiding van TimerTask klasse. Voegt de optie toe om een parameter mee te geven die gebruikt kan worden wanneer de timer de code uitvoert.
28
5.5 UITBREIDINGS MOGELIJKHEDEN De applicatie is modulair opgebouwd en kan makkelijk uitgebreid worden met nieuwe spellen, opdrachten of zelfs systemen voor locatiebepaling. Meerdere spellen Als voorbeeld voor verschillende spellen kan gekeken worden naar de MathRunClient class in het SchoolyardClient project. Een spel moet de SchoolyardView class extenden en zijn eigen update, draw, onDataInput, onUpEvent, onDownEvent, setCurrentObjective en getCurrentObjective methoden definiëren. Op het moment wordt het spel dat gespeeld wordt gedefinieerd in de startGame methode van de SchoolyardClient class. Dit kan omgebouwd worden om meerdere spellen te ondersteunen, bijvoorbeeld door de START_GAME message van de server uit te breiden zodat de server kan bepalen welk spel de client start. Verschillende opdrachten Op het moment stuurt de START_GAME message ook alle beschikbare operaties mee voor de MathRun game sessie. Deze staan op het moment hardcoded in de GameManager class van de server, maar kunnen dus gemakkelijk gewijzigd worden door bijvoorbeeld deze data uit bestanden te halen die op de server zijn aangemaakt. Op deze manier hebben alle clients dus altijd hetzelfde beeld van het speeldveld, zelfs als deze tussen sessies door wordt veranderd. Andere locatiebepaling Het huidige prototype maakt gebruik van de ZXing library om camera beelden te verwerken en QR codes uit te lezen. Het resultaat van deze scan komt terug in de onActivityResult methode van de SchoolyardClient class, en wordt vervolgens als een string doorgegeven aan de onDataInput methode van de huidige actieve game. De huidige game bepaalt dus al zijn acties en state veranderingen in de onDataInput methode. In theorie zou bijvoorbeeld een GPS manager ontwikkeld kunnen worden welke locaties codeert als strings, en zodra de speler een dergelijke locatie bereikt, zou de bijhorende string doorgegeven kunnen worden aan de onDataInput. Deze abstracte laag zorgt er voor dat de input bron makkelijk te veranderen is zonder enige wijziging te hoeven maken aan de game code zelf.
29
5.6 EVALUATIE SIG De Software Improvement Group (SIG) beoordeelt de implementatie van software producten. Ze kijken naar verschillende elementen die betrekking hebben op de onderhoudbaarheid van het product. Deze elementen zijn van belang wanneer een product voor een langere tijd onderhouden moet worden of als de ontwikkeling van handen wisselt. Het is een score die aangeeft hoe makkelijk (of moeilijk) de code te begrijpen is voor iemand die er onbekend mee is, en hoe makkelijk de integratie van een uitbreiding is. SIG beoordeelt ook bachelor eindprojecten voor de Technische Informatica opleiding van de TU Delft, dus ons project moest deze evaluatie ook ondergaan. Dit was het eerste commentaar op onze code tijdens de laatste maand van de ontwikkelingsfase: De code van het systeem scoort vier sterren op ons onderhoudbaarheidsmodel, wat betekent dat de code bovengemiddeld onderhoudbaar is. De hoogste score is niet behaald door een lagere score voor Unit Size en de Unit Complexity. 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 extreem lange methodes in dit systeem, zoals bijvoorbeeld de 'run'-methode in de class 'ServerLoop', zijn aparte stukken functionaliteit te vinden welke ge-refactored kunnen worden naar aparte methodes. Debugs-statements zoals bijvoorbeeld 'server.debug("Initializing...");' en 'server.debug("Accepting Connection...");' 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. Voor Unit Complexity wordt er gekeken naar het percentage code dat bovengemiddeld complex is. Ook hier geldt dat het opsplitsen van dit soort methodes in kleinere stukken ervoor zorgt dat elk onderdeel makkelijker te begrijpen, makkelijker te testen en daardoor eenvoudiger te onderhouden wordt. In dit geval komen de meest complexe methoden ook naar voren als de langste methoden, waardoor het oplossen van het eerste probleem ook dit probleem zal verhelpen. Wat verder nog opvalt is dat er een tweetal classen zijn welke 'OLD' in de naam hebben. Daarnaast is er in bijvoorbeeld de 'ServerLoop'-klasse oude code in commentaar te vinden. Het lijkt erop dat deze code niet meer gebruikt dient te worden, het is dan ook aan te raden deze code uit het project te verwijderen. Het gebruik van een versiebeheersysteem zorgt er dan voor dat het altijd mogelijk blijft om oudere versies van de code terug te halen indien dit nodig blijkt te zijn. Over het algemeen scoort de code bovengemiddeld, hopelijk lukt het om dit niveau te behouden tijdens de rest van de ontwikkelfase. Als laatste nog de opmerking dat er geen (unit)test-code is gevonden in de code-upload. Het is sterk aan te raden om in ieder geval voor de belangrijkste delen van de functionaliteit automatische tests gedefinieerd te hebben om ervoor te zorgen dat eventuele aanpassingen niet voor ongewenst gedrag zorgen. Dit betekende voornamelijk dat we ongebruikte code beter moesten opruimen. En de bestaande code moest op een paar plekken beter opgedeeld worden om zo het formaat en de complexiteit te reduceren. Het ontbreken van (unit)test-code was een fout aan onze kant door het vergeten te uploaden.
30
Qua implementatie hebben we gereageerd door alle ongebruikte code definitief uit het project te verwijderen. En mocht de code toch nodig zijn konden we deze altijd nog terug halen d.m.v. de SVN-repository. De server-code heeft naar aanleiding van het commentaar op complexiteit een aangepaste structuur gekregen die de fases waarin de server zich bevindt beter aangeeft. Op deze manier was het veel overzichtelijker dan dat alles achter elkaar was geplakt. Na het afronden van de implementatie voor de eindpresentatie is de code nogmaals opgestuurd voor een eind beoordeling: In de tweede upload zien we dat de omvang van het systeem fors is gestegen en dat daarbij de score voor onderhoudbaarheid licht is gestegen. Op het gebied van Unit Size is een vooruitgang te zien, in deze upload zijn geen extreem lange units meer te vinden. Het opschonen van de langere units heeft ook de score voor Unit Complexity verbeterd. Daarnaast zien we ook geen code meer in bestanden met 'OLD' in de naam, of grotere blokken code in commentaar (slechts enkele regels in de 'PlayerListPanel'-class en de 'Text2D'-class). Als laatste valt het op dat er enkele unit-tests zijn toegevoegd. Uit deze observaties kunnen we concluderen dat de aanbevelingen van de vorige evaluatie zijn meegenomen in het ontwikkeltraject. Het is goed om te zien dat ondanks de forse uitbreiding van het systeem de score voor onderhoudbaarheid van het systeem is verbeterd. Hierin kunnen we merken dat SIG positief reageert op onze aanpassingen. En dat we de onderhoudbaarheid hebben kunnen verhogen ondanks een forse uitbreiding van de code, wat normaalgesproken een verslechtering van de onderhoudbaarheid met zich meebrengt.
31
6. CONCLUSIE We hadden ons doel als volgt omschreven: “Het ontwikkelen van een educatieve spelomgeving met behulp van mobiele locatie bepaling voor basisschoolleerlingen op het schoolplein” Het prototype wat wij hebben ontwikkeld voldoet hier aan. De ontwikkelde client applicatie kan gebruikt worden om basisschoolleerlingen met het Reken Ren spel te laten spelen en zo hoofdrekenen te toetsen. Locatiebepaling is geïmplementeerd doormiddel van het uitlezen van QR codes. Deze kunnen op specifieke locaties geplaatst worden voor de speler om te scannen met behulp van de applicatie. De eisen genoemd in hoofdstuk 2.2 zijn allen in het prototype verwerkt. Het prototype heeft een gebruiksvriendelijk interface dat alle benodigde informatie aan de gebruiker toont. De client applicatie kan met de server verbinden. De server kan een startsein geven met alle benodigde parameters voor de client om het spel te starten. Vervolgens stuurt de client alle spel updates naar de server tijdens het spelverloop. De client kan input verwerken in de vorm van QR codes die door de smartphone camera gescand worden. Ons project is uiteindelijk niet zo ambitieus geworden als oorspronkelijk gedacht. Door tijdsgebrek hebben we niet kunnen testen met daadwerkelijke eindgebruikers. Technisch gezien zijn alle limieten ook nog niet verkend, en we kunnen alleen maar gissen of er meer mogelijk is met de juiste hardware. De GPS zou gebruikt kunnen worden als deze nauwkeurig tot op enkele meters kan worden gemaakt. Toch kunnen we tevreden zijn met de basis die gelegd is. Het prototype kan alleen maar beter worden als deze verder wordt ontwikkeld.
32
7. TOEKOMST In het geval dat er een vervolgproject komt adviseren wij de volgende punten: 1. 2.
3.
4.
Verken andere platforms. Is een smartphone het ideale platform voor gebruik op het schoolplein? Uiteindelijk zou speciale hardware mogelijk efficiënter kunnen wezen, en minder breekbaar. Zijn er praktische alternatieven voor de locatie bepaling? Onze QR code scan methode is ontstaan omdat locatiebepaling aan de hand van signalen niet doenlijk leek tijdens het project. Met de juiste hardware kan de nauwkeurigheid mogelijk verbeterd worden. Verken de toepasbaarheid van het project. Zou het ook gebruikt kunnen worden in de klas? Of op een speurtocht in het bos? Dit project is een vorm van ‘augmented reality’, waarbij mobiele technologie de werkelijkheid kan verrijken. Dit heeft veel potentie voor het onderwijs. Houd contact met de eindgebruikers. Wij hebben tijdens het project contact gehad met een Bernadette Motjé, lerares van groep 8 op de OBS De Tweemaster basisschool, gelegen in Capelle aan de IJssel. Ze toonde belangstelling voor het project en voorzag ons van lesstof die groep 8 zoal behandelde. Daarnaast was haar groep beschikbaar voor een live test van de applicatie. Hoewel wij daar tijdens dit project geen gebruik van hebben kunnen maken, verloopt het voorstel waarschijnlijk niet en zou men in de toekomst met haar contact op kunnen nemen als er kandidaten voor een live test gezocht worden.
33
8. EVALUATIE Het bachelorproject heeft voor ons een afwijkend traject gevolgd. Normaal wordt er verwacht dat de groep e gedurende het 4 kwartaal van het studiejaar fulltime werkt aan het project. Wij hebben echter verspreid over e e e het 2 semester (3 en 4 kwartaal) aan het project gewerkt. Hierbij gingen we uit van 3 dagen per week, zodat we op dezelfde eisen uit kwamen qua gespendeerde tijd aan het project. Onze projectgroep bestond uit twee mensen, beide met de ambitie om in de toekomst in de game industrie te werken. Om deze reden zochten we een project dat vergelijkbaar was met dat van het ontwikkelen van een game. Deze vonden we dan ook in de vorm van het Schoolyard project. Naast het concept werden er geen harde eisen gesteld, waardoor er veel ruimte was om te experimenteren en om een creatieve invulling te geven. De werkplek is in de loop van ons project vaak gewijzigd. Door het ontbreken van reserveerde ruimtes hebben we een vrij nomadisch bestaan geleden. In het begin hebben we voornamelijk gebruik gemaakt van het practicumgebouw aan de Drebbelweg, maar vanwege luidruchtige groepen mensen en gereserveerde tijdsloten moesten we ons vaak verplaatsen halverwege de dag. Tijdens de laatste paar maanden van het project was onze werkplek gesitueerd in de lobby van de EWI faculteit omdat hier altijd plek te vinden was, en relatief rustig. De taakverdeling binnen de groep verliep soepel. We waren maar met twee mensen dus er was geen noodzaak voor afgesproken vergaderingen en dergelijke. De taken waren zo opgedeeld dat Thomas zich kon bezig houden met de onderliggende systemen van onze applicatie, zoals de update / draw loops en de netwerkcommunicatie. Joeri werkte aan de interfaces en spel mechanieken. Wij zijn beiden meer progammeur dan manager, en dit zorgde dat onze samenwerking een paar zwakke punten had bij het lange termijn plannen en het zetten van deadlines. Het voornemen om logboeken bij te houden was ook vrij snel verbroken. We hielden een voornamelijk pragmatische blik op de voortgang van ons project. Dit heeft redelijk goed gewerkt, maar het kon mogelijk beter. De implementatiefase van ons project liep flink uit omdat, ironisch genoeg, dezelfde vrijheid die we zochten in ons project erg veel tijd heeft gekost. Het ontwikkelen van de client prototype die een GPS gebruikte had anderhalve maand gekost, wat op zich geen verloren tijd was maar nadat de GPS te onnauwkeurig bleek moesten we praktisch van voor af aan beginnen. We hadden nog gehoopt een live test te doen aan het eind van de implementatiefase, maar door de uitloop en het feit dat we geen extra test smartphones konden vinden moesten we hier van af zien. Het was een leerzaam project. We hadden gehoopt op meer resultaat, maar we zijn tevreden met de basis die we gelegd hebben en het prototype dat gebouwd is. We willen onze opdrachtgever nogmaals bedanken voor de kans die hij ons gegeven heeft, en wij hopen dat ons werk van pas kan komen bij een mogelijk vervolgproject.
34
9. BRONNEN [1] “ZXing”, Multi-format 1D/2D barcode image processing library with clients for Android, Java, http://code.google.com/p/zxing/ [2] Schoolyard afstudeerverslag, Onderdeel van opleiding Human Technology aan De Haagse Hogeschool, Jorien van Vliet, 2011 [3] Niederhauser, D.S. and Stoddart, T. (2001) Teachers’ instructional perspectives and use of educational software. Teaching and Teacher Education, 17 (1), 15-31
35
APPENDIX A: OPRDACHTOMSCHRIJVING Schoolyard-Edu-Game - afstudeerproject Kernwoorden: Serious gaming, location based gaming, beweging, mobiele telefoon, smartphone, basisschool Schoolyard-Edu-Game is een spelconcept waarbij het doel is om kinderen in het basisonderwijs bewegend te laten leren. Schoolyard-Edu-Game wordt geïnstalleerd op pda of smartphone met GPSfunctie, waardoor het spel location based is. Het spel bevat een plattegrond van het schoolplein, welke van te voren wordt gemaakt door de leraar. Bij de start van het spel geeft het spel, door middel van GPS, de locatie van de leerling op het schoolplein weer. Het spel start: er knippert een cirkel op het scherm; dit is de locatie waar de leerling heen moet rennen. Wanneer de leerling binnen de aangegeven cirkel komt, krijgt hij een vraag. Deze moet hij zo snel mogelijk beantwoorden, waarna er een nieuwe cirkel begint te knipperen. Wanneer de leerling binnen de nieuwe cirkel komt volgt er een nieuwe vraag enzovoorts. Na bijvoorbeeld 20 vragen is het spel afgelopen en krijgt de leerling te zien hoeveel vragen er goed waren. De leraar ontvangt de resultaten ook op zijn computer.
Naast dit spel zijn er verschillende spelmodules mogelijk. Bijvoorbeeld:
Breuken (rekenen): ballen die op de leerling afkomen; leerling moet alle ballen die kleiner zijn dan ½ vangen. Alle ballen die grote zijn dan ½ mogen ze niet raken Wiskundig inzicht: leerlingen moeten met elkaar driehoeken vormen in de ruimte Sport: piepjestest (shuttlerun test) op het schoolplein (met bijv. digitale coach) Samenwerken: leerlingen moeten elkaar d.m.v. communicatie door een digitaal doolhof over het schoolplein sturen.
Voor een pilot is er een prototype nodig om te testen of leraren hier mee kunnen en willen werken. De komende weken zal er onderzoek gedaan worden naar de behoefte van leraren m.b.t. dit concept. Deze zal input vormen voor het te vervaardigen prototype. Ook de game zal ontwikkeld worden gedurende deze aankomende weken.
36
APPENDIX B: ORIENTATIEVERSLAG
SCHOOLYARD ORIENTATIE VERSLAG
IN3405 Bachelorproject Revisie 1 Delft, 20 juni Joeri van der Velden 1358480 Thomas Breekveldt 1388584 37
1. INLEIDING Voordat het programma geïmplementeerd of zelfs ontworpen kan worden, moeten bepaalde dingen eerst worden onderzocht. Er is een voorstudie gedaan naar de leraren als gebruikers groep. Dit onderzoek was gedaan door Jorien van Vliet, en het resultaat was volledig tot onze beschikking. Daarnaast hebben we zelf nog een blik op onze gebruikers geworpen. Deze is te vinden in hoofdstuk 2. Voordat we een spelconcept konden uitdiepen moest er eerst nog onderzocht worden hoe de locatie van de spelers bepaald werd. Omdat variaties hierin details in het concept kunnen veranderen. Een real-time systeem heeft namelijk andere beperkingen dan een event-based systeem. En ook de nauwkeurigheid heeft invloed. In hoofdstuk 3 staat onze gedachtengang beschreven. Om een client-server model te realiseren moet er natuurlijk een verbinding gemaakt worden tussen de apparaten. We hebben hiervoor een paar communicatie technieken naast elkaar gezet. Het resultaat van deze vergelijking staat in hoofdstuk 4.
38
2. GEBRUIKERS Wat zijn de eisen en wensen van de leraren en kinderen? ICT in het onderwijs is een zeer actueel topic in het laatste decennium. De huidige generatie leraren is vaak zonder ICT middelen onderwezen, en hebben hun eigen manier van lesgeven hier dus niet op 1
afgestemd. Vaak worden leraren ook nog aan hun lot over gelaten wat betreft het toepassen van ICT 2
tijdens de les. Maar een derde van de leraren heeft afspraken met de rest van het team. Het grootste deel van de leraren zoekt ICT ondersteuning nog bij collega’s. ICT middelen worden vooral ter ondersteuning van het lesprogramma ingezet, in plaats van het lesprogramma fundamenteel te bepalen. Gemiddeld wordt de computer 8 uur per week gebruikt om 2
les te geven. Het succes van de ICT technologie hangt sterk af van de meerwaarde die het kan bieden 3
tijdens de lesuren. Dit lijkt steeds vaker het geval. De laatste jaren is de adoptie van ICT technologie in het onderwijs wel sterk gestegen. In de periode van 2007 tot 2011 is het gebruik van digitale schoolborden in het basisonderwijs van ongeveer 10% 2
naar 95% gestegen. Er is gemiddeld 1 computer beschikbaar per 5 leerlingen. Kinderen in het basisonderwijs groeien op in een steeds verder gedigitaliseerde samenleving, en hebben vaak meer affiniteit met ICT technologie dan de leraar. Goede gestroomlijnde ICT middelen 2
zouden het leerproces van deze generatie sterk kunnen verbeteren.
39
3. LOCATIEBEPALING Een van de belangrijkste features in het Schoolyard project is de mogelijkheid voor de gebruikte apparaten om accurate locatiebepaling te verrichten op het schoolplein. Dit vereist dat het apparaat op de meter nauwkeurig moet zijn. We hebben voor dit project enkele mogelijkheden onderzocht en getest.
3.1 GPS Een van de meest gebruikte techniek vandaag de dag is het Global Positioning System, kortweg GPS, wat wereldwijd in miljoenen apparaten is verwerkt. Deze technologie zit ook ingebakken in smartphones, wat ons apparaat van keuze was voor dit project. We liepen echter tegen een aantal problemen aan. Bij het vooronderzoek op het web bleek al dat de nauwkeurigheid van een GPS sterk kan variëren. Sommige bronnen spraken van tientallen meters, terwijl andere een accuraatheid van enkele meters claimden. We zijn vervolgens zelf gaan testen en hebben de volgende resultaten verkregen. De GPS in mijn Android smartphone (een HTC Desire van het jaar 2010) was nauwkeurig tot op ongeveer 7 tot 10 meter. Dit is getest door locatie op te slaan, enkele routes te lopen, en te zien hoe ver mijn gemeten locatie afweek van mijn werkelijk opgeslagen locatie eerder. Daarnaast is de meetnauwkeurigheid sterk afhankelijk van de zichtbaarheid van GPS satellieten. Binnen een gebouw laten de metingen het al snel afweten. We kunnen met redelijke zekerheid concluderen dat GPS te onnauwkeurig is voor gebruik op het schoolplein. De technologie is niet geschikt voor locatiebepaling op een relatief kleine omgeving zoals een schoolplein. Gezien de gebruikelijke toepassingen van GPS (navigatie over lange afstanden) is dit niet erg verrassend. Daarnaast zijn de nauwkeurigheid en de snelheid van de metingen erg afhankelijk van obstakels in de omgeving.
40
3.2 TRIANGULATION Een andere techniek voor locatiebepaling op basis van signalen is triangulation. Bij deze techniek wordt de relatieve locatie van een object gemeten door de afstand te meten naar drie verschillende zendpunten (de driehoek). We identificeerden een aantal verschillende signalen die we mogelijk konden gebruiken voor deze techniek: GSM zendmasten, Bluetooth en Wifi. GSM zendmasten bedekken vrijwel het gehele land en verzorgen de telefoon ontvangst. Daarnaast zitten er op sommige smartphones systemen ingebakken om deze masten als backup locatiebepaling te gebruiken in het geval dat de GPS het laat afweten. Na wat onderzoek hebben we deze optie echter laten varen: de nauwkeurigheid van de locatiebepaling via GSM masten wordt gemeten op honderden meters, dus nog slechter dan GPS. Bluetooth en Wifi zijn signaal technologieën die gebruikt worden door veel apparaten, zoals laptops en smartphones, voor communicatie op korte afstand. Voor ons project lijkt deze techniek echter onhandig: er is extra hardware voor vereist welke rond het schoolplein geplaatst zou moeten worden. Daarnaast is de nauwkeurigheid ook variabel en is het onbekend hoeveel extra ontwikkelingstijd het kost om deze techniek te implementeren.
3.3 SCANNEN Tot dusver is gebleken dat signalen gebruiken voor locatiebepaling te onnauwkeurig of onpraktisch is voor gebruik op het schoolplein. We zijn daarom naar andere methoden gaan kijken, waaronder het gebruik van de camera. Praktisch alle smartphones hebben een camera ingebouwd. Men gebruikt deze vooral voor het opslaan van momenten of, wat voor ons van belang is, locatiebepaling. Vakantiefoto’s tonen vaak waar een persoon geweest is. Dit achterliggende gedachte zouden we ook kunnen toepassen op het schoolplein. Het idee is om locaties rond het schoolplein te markeren en dat gebruikers de camera van hun apparaat gebruiken om bij een locatie ‘in te checken’. Op deze manier ben je vrij zeker van de locatie van een persoon wanneer hij op een bepaald punt een markering scant. Een nadeel van de techniek is echter dat de gebruiker dus telkens een actie moet verrichten als hij op een locatie aan komt.
41
3.4 DE KEUZE We concluderen dat het scannen van locaties met behulp van de camera waarschijnlijk de meest praktische oplossing is voor ons project. Uiteindelijk is het hoofddoel van het project om te kijken of location-based games op het schoolplein te doen (en leuk) zijn, waarbij de methode voor locatiebepaling niet vast staat. Als het project dus een vervolg krijgt dan kan de methode altijd nog veranderd worden.
3. 5 IMPLEMENTATIE Het scannen van deze locatie markeringen kan op verschillende manieren. Waar het vrijwel allemaal op neerkomt is dat je via image processing gecodeerde data achterhaald. Onze keuze valt daarom op QR codes. Dit zijn vierkante barcodes die gebruikt kunnen worden om tekst te coderen. Ze zijn tegenwoordig al vaak te vinden op reclame borden en in sommige winkels. In principe kunnen we een eigen codering verzinnen en die via image processing identificeren, maar dat vergt extra ontwikkelingstijd. QR codes zijn al via een tal van applicaties en code libraries uit te lezen.
42
4. NETWERK COMMUNICATIE Om te zien wat de spelers aan het doen zijn, en om daar invloed op uit te oefenen, kwam de noodzaak voor netwerk communicatie. De eerste vraag was: met welke hardware zouden de apparaten gaan communiceren? Deze vraag was een van de redenen, naast locatie bepaling, dat we een Android toestel als testapparatuur gekozen hebben. Omdat een Android device (meestal) beschikt over meerdere communicatie methoden zoals WiFi en Bluetooth. Om daadwerkelijk een keuze te maken hebben we de communicatie-technieken naast elkaar gelegd en argumenten voor en tegen genoteerd.
Figuur 1. Uit deze vergelijking (figuur 1) bleek dat de voorkeur naar een WiFi verbinding uitgaat, maar heeft toch nog twee aardige minpunten. Om deze minpunten te verhelpen zijn we verder gaan onderzoeken. Uit eigen onervarenheid kwam de vraag: Waarom kunnen twee apparaten met WiFi niet direct met elkaar communiceren, een Ad-Hoc netwerk opzetten? Uit onderzoek bleek dat bij Android telefoons er softwarematig een blokkade is geworpen op Ad-Hoc netwerken. Android telefoons kunnen alleen verbinden met een WiFi Hotspot. Om deze blokkade weg te halen is root-access nodig, toegang tot het besturings systeem van de telefoon. Omdat dit een ongewenste eigenschap was voor het prototype, zochten we verder naar andere oplossingen. 4
In de Android documentatie kwamen we WiFi Direct tegen. Dit was helaas een feature beschikbaar vanaf Android versie 4.0 wat dus niet beschikbaar was voor onze ontwikkeling voor Android 2.2+.
43
Uiteindelijk kwamen we tot de oplossing om de laptop die als Server zou dienen ook als hotspot te 5
configureren. Dit was zo eenvoudig als een installatie van een programma genaamd Connectify.
Waarna je een hotspot kon opzetten via je WiFi verbinding. Dit bleek echter onstabiel wegens onverklaarbare redenen. Om een stabielere oplossing te vinden hebben we doorgezocht naar alternatieve oplossingen. Wat bleek was dat Connectify gebruik maakte van een Windows 7 eigen feature. Windows 7 is in staat een virtuele adapter te maken van een bestaande netwerk adapter en geeft deze een uniek MAC-adres door die van de bestaande te verhogen met 1. Op deze manier kan Windows 7 een draadloze internet 6
verbinding delen over WiFi, waardoor beide verbindingen over dezelfde netwerk adapter lopen.
Op deze manier kan een Android telefoon doen alsof het gebruik wil maken van de internet verbinding, maar in werkelijkheid direct communiceren met de Server laptop. Zo is de verbinding van de telefoon gratis, en heeft de laptop een statische, door Windows 7 aangewezen, intern IP-adres. Zo blijven de (complexe) handelingen aan de kant van de server. Deze commando's kunnen in een batch file gezet worden om het proces te vereenvoudigen voor de gebruiker, of wellicht volledig geautomatiseerd kunnen worden. Het enige wat een client hoeft te doen is een verbinding maken met het nieuwe draadloze netwerk. Het liefst zou alles automatisch gebeuren, maar dit is in onze ogen acceptabel.
BRONNEN 1
Kennisnet (2010) Vier in balans monitor 2010, ICT in het onderwijs de stand van zaken.
2
Kennisnet (2011) Vier in balans monitor 2011, ICT in het onderwijs de stand van zaken
3
Niederhauser, D.S. and Stoddart, T. (2001) Teachers’ instructional perspectives and use of educational
software. Teaching and Teacher Education, 17 (1), 15-31 4
Android development API, http://developer.android.com/reference/android/net/wifi/p2p/package-
summary.html 5
Connectifiy home page, http://www.connectify.me/
6
Robert David Graham (2009), Errata Security Blog, http://erratasec.blogspot.nl/2009/11/windows-7-
includes-soft-ap.html
44
APPENDIX C: PLAN VAN AANPAK
Bachelorproject Schoolyard - Plan van Aanpak Inhoudsopgave • • • •
Introductie Project opdracht Aanpak en tijdsplanning Project inrichting
Introductie Dit document zal worden gebruikt als startpunt voor het Schoolyard Educational Game project, welke uitgevoerd zal worden door Thomas Breekveldt en Joeri van der Velden in opdracht van TNO. Het uiteindelijke doel van het project is om een werkend prototype te ontwikkelen van een educatieve game welke toegepast kan worden op het schoolplein door de leraar om zijn of haar leerlingen al bewegend te laten leren. Eerst zal de project opdracht verder uitgewerkt worden. Vervolgens zetten we de aanpak en tijdsplanning uiteen. Als laatst beschrijven we de organisatie rond het project.
Project opdracht Het Schoolyard-Edu-Game is een open spelconcept wat draait om leerlingen uit het basisonderwijs bewegend te laten leren, met behulp van moderne ICT technologie zoals smartphones en GPS. Er moet een methode geformuleerd worden om het schoolplein op te nemen in een digitale omgeving. Daarnaast moeten er games ontworpen worden welke gebruik maken van de locatiegegevens van leerlingen en de kennis van het schoolplein. 1. Opdrachtformulering Werk het Schoolyard-Edu-Game concept uit in een digitale omgeving welke gebruik maakt van locatiebepaling op het schoolplein en gebruikt kan worden door leraren en leerlingen in het basisonderwijs. 2. Op te leveren producten Een werkend prototype van de Schoolyard-Edu-Game omgeving met meerdere spellen die gespeeld kunnen worden hierin.
Aanpak en tijdsplanning Omdat dit project gericht is op het ontwerpen van een prototype van een game, adopteren we een agile development schema. Dit betekent dat het ontwikkelingsproces iteratief zal verlopen, met kort opvolgende perioden van onderzoek, implementatie en testen. Op deze manier kunnen er op een vast tempo features worden toegevoegd, getest en aangepast. De volgende punten van onderzoek moeten afgewerkt worden in de loop van het project: • Platform keuze • Communicatie techniek • Locatie bepaling -> 3.1 Nauwkeurigheid & 3.2 Gebruik • Gebruikers • Spel omgeving • Spel ontwerpen • Implementatie
45
Bovenstaand is een klein schema van mogelijke afhankelijkheden van de verschillende onderzoekspunten. [1] Platform Keuze Welke bestaande hardware kan gebruikt worden om het hoofddoel te realiseren en hoe verschillen ze? Dit onderzoek moet verschillende oplossingen aan het licht brengen en aspecten vergelijken daarvan om een conceptkeuze te faciliteren. [2] Communicatie Techniek Welke communicatie technieken bieden de verschillende platformen en hoe verschillen ze? Kijkend naar de communicatie technieken beschikbaar zoals eventueel WiFi, Bluetooth, e.d. [3] Locatie Bepaling Wat zijn de voor en nadelen van verschillende methodes voor locatie bepaling, met betrekking tot de eerder genoemde platformen? Deze vraag vonden we nodig om op te splitsen in twee onderzoeken. [3] [1] Nauwkeurigheid Wat is de nauwkeurigheid (en betrouwbaarheid) van de verschillende mogelijkheden? De nauwkeurigheid van het concept is een belangrijk aspect dat significante gevolgen met zich mee brengt. [3] [2] Gebruik Hoe weet Schoolyard de grenzen van het speelveld en vallen de benodigde acties binnen de eisen gesteld door de leraar? Onder het motto gebruiksvriendelijkheid, wat zijn de mogelijkheden en implicaties om dit autonoom door het systeem te laten gebeuren? Is dit überhaupt mogelijk autonoom uit te voeren? Moet de leraar vooraf de omgeving “scannen”/”invullen”? Kan het probleem versimpeld worden? [4] Gebruikers Wat zijn de eisen en wensen van de leraren en kinderen? Een kritische blik naar het onderzoek van Jorien. En eventueel een eigen steekproef doen of andere relevante onderzoeken vinden. [5] Spel omgeving Wat zijn de omstandigheden (variabelen) van de omgeving waarin Schoolyard gebruikt gaat worden? 2 Het is (wellicht) onrealistisch om een concept te ontwerpen voor een schoolplein van 300m als het gemiddelde formaat significant lager ligt. Wat is het gebruikelijke oppervlak van een schoolplein en hoeverre zou deze benut kunnen worden? [6] Spel ontwerpen Welke spel concepten kunnen gerealiseerd worden binnen de eisen van het vooronderzoek, en hoe worden deze in de omgeving geïntegreerd?
46
Het ontwerpen van daadwerkelijke spelconcepten voor Schoolyard. [7] Implementatie De realisatie van het hoofddoel. Wij hebben de volgende milestones geformuleerd om bovenstaande punten af te werken: • • • • •
Eind februari: vooronderzoek. Techniek concept keuze. Opzetten ontwikkelingsomgeving. Eind maart: Locatie bepaling afronden. Halverwege april: prototype multiplayer. Gebruikersonderzoek. Begin mei: eerste "echte" prototype game Begin juni: eerste tests in live omgeving
Een voorlopige meer detailleerde planning: week 1 proces: kalenderweek 6 (6 feb) Orientatie Onderzoek week 2 proces: kalenderweek 7 (13 feb) Orientatie Onderzoek week 3 proces: kalenderweek 8 (20 feb) Orientatie Onderzoek week 4 proces: kalenderweek 9 (27 feb) Vakantie / Onderzoek in eigen tijd week 5 proces: kalenderweek 10 (5 mrt) Deliverable: Het laten bewegen van 1 (of meer verschillende) punt(en) op een vlak dmv doorgeven van punt-data. week 6 proces: kalenderweek 11 (12 mrt) Deliverable: Huidige locatie kunnen aflezen voor nauwkeurigheids metingen en koppelen aan de punt(en) van de vorige versie. Eerste spelconcept. week 7 proces: kalenderweek 12 (19 mrt) Deliverable: Extra data van de punten kunnen opvragen (o.a. snelheid en afgelegd pad) week 8 proces: kalenderweek 13 (26 mrt) Deliverable: Test-versies eerste spel types (singleplayer). Tweede spelconcept. week 9 proces: kalenderweek 14 (2 apr) Deliverable: Communicatie met server & synchronisatie van tenminste 1 speler (+ eventueel meer spel-types) week 10 proces: kalenderweek 15 (9 apr)
47
Deliverable: Synchronisatie tussen meerdere spelers van verschillende typen data (o.a. locatie, game-state, score) (+ eventueel meer spel-types). Derde spelconcept. week 11 proces: kalenderweek 16 (16 apr) Deliverable: Game-state changes testen / uitloop week week 12 proces: kalenderweek 17 (23 apr) week 13 proces: kalenderweek 18 (30 apr) week 14 proces: kalenderweek 19 (7 mei) week 15 proces: kalenderweek 20 (14 mei) week 16 proces: kalenderweek 21 (21 mei) week 17 proces: kalenderweek 22 (28 mei) week 18 proces: kalenderweek 23 (4 jun) uiterlijke deadline code opsturen naar SIG week 19 proces: kalenderweek 24 (11 jun) Wachten op/verwerken van feedback SIG week 20 proces: kalenderweek 25 (18 jun) week 21 proces: kalenderweek 26 (25 jun) week 22 proces: kalenderweek 27 (2 jul)
Project inrichting Het project zal uitgevoerd worden door Thomas Breekveldt en Joeri van der Velden, studenten Technische Informatica aan de TU Delft. De begeleidend docent is professor Rafeal Bidarra, supervisor van het Game Technology onderzoek aan het TUD. Het project wordt uitgevoerd in de opdracht van professor Rob Kooij van TNO.
48
APPENDIX D: SPELCONCEPTEN EPTEN 1. MATHRUN Setup 1. 2.
Every player has a device which shows two numbers on the display. One is their start number. The other is the target number. In the schoolyard there are several locations (marked with colored circles on the ground) that correspond to an operation (such as "multiply by 5", "add 3", "subtract 2")
Gameplay 1. 2.
Once each player sees their start and target number, they have to deduce what operations they need to apply to incrementally turn the start number into the target tar number. The players will start moving across the schoolyard and stand on the different circles to apply the corresponding operations.
Player performance Player performance can be measured in how many operations they required versus the theoretical number numb of operations required, and the amount of time they needed to complete.
Difficulty scaling The difficulty of the game can be adjusted by giving players bigger numbers (requiring more operations) and/or by adding more exotic operations (such as "add 3 and and divide by 4") which require players to think harder before moving.
Educational value Math, reasoning and memorizing
Menu design Mockup #1:
Notes: the player's current number is largest. Target number is right below. The player presses on his number to go to 'scan mode' in which the QR code is read and the operation is applied. The list of operations that the player has applied are shown at the bottom.
49
2. CITY MATCHING Setup 1. 2. 3.
Every player has their device ready, nothing is shown on it yet In the schoolyard there are an even number of locations, half of them marked as 'countries', the other half being '(capital) cities'. Each country has a corresponding capital city The city of a city location is not clear until a player stands on its location. Players can only identify it as a 'city' from a distance, not which city.
Gameplay 1.
2.
Every player needs to go to a city location, read what city it is, and then find the matching country which that city is the capital of. For example, a player goes to a city location and finds out it's "Berlin". He then needs to find the country location of which "Berlin" is the capital (in this case "Germany"). If the player matches it correctly he is told so. If not, he has to keep on looking or pick a different city to match. The game ends once the player matched all capital cities with their corresponding countries.
Player performance Player performance can be measured in how quickly he matches cities, and if there are any failed attempts to match incorrect country - capital city pairs.
Difficulty scaling The difficulty of the game can be scaled by using different and larger sets of countries. This game can also be adapted to find the capitals of different provinces in a single country.
Educational value Topography and memorizing
3. WORD BUILDER Setup 1. 2. 3.
Every player has their device ready, nothing is shown on it yet In the schoolyard there are an even number of locations, each one presenting a part of a word (for example, "le", "mier", "lijk", "en", "voor", "werp", "men", "tulp", "sen") There is a time limit (one minute or something)
Gameplay 1.
2.
Players need to create valid words by combining two word parts. They do this by reading the first part on a location, and then moving to the second location to combine it with that part. For example, "mier" + "en" = "mieren", "voor" + "werp" = "voorwerp", or "werp" + "en" = "werpen". The matches are not exclusive, you can use a single word part in several combinations. Each player needs to make as many unique and valid words within the time limit.
Player performance Player performance can be measured in how many different words they can build before time runs out.
Difficulty scaling The difficulty of the game can be adjusted by giving more complex word combinations.
Educational value Language and memorizing. Note: might be a little low leveled for group 7/8.
50
4. TIMELINE Setup 1. 2.
Every player sees a legend on his screen combining several colours with historic ages or event. Each player gets shown the same historic data but paired with different colours In the schoolyard there are several locations, each with a colour (that corresponds to the colours in the legend)
Gameplay 1.
2.
Players need to traverse the timeline, meaning they need to walk over the colours in such a way that the historical events or ages they're paired with are traversed in a chronological order. For example, a player sees the pairs "Roman age" with blue, "Industrial age" with green, "Medieval age" with red and "Iron age" with yellow. His goal goal is then to go to the locations marked yellow, blue, red and green, in that order. Each player has a different set of pairs so not everyone goes to the same locations and they can't derive the right answers from each other's movement.
Player performance Player performance can be measured in how many tries, and how fast, the player gets the correct order.
Difficulty scaling The difficulty of the game can be changed by using more pairs or more complex historical events.
Educational value History
Menu design Mockup #1:
Notes: the gray numbered items are the top are correctly queued historical events. The coloured items still need to be found in the correct order. The next good answer in the above example would be the blue "Middeleeuwen". The player goes to o scan mode by pressing the screen.
51
5. CITY MATCHING MULTIPLAYER Setup Same as the original City Matching concept: 1. 2. 3.
Every player has their device ready, nothing is shown on it yet In the schoolyard there are an even number of locations, half of them marked as 'countries', the other half being '(capital) cities'. Each country has a corresponding capital cit. The city of a city location is not clear until a player stands on its location. Players can only identify it as a 'city' from a distance, not which city.
Gameplay 1.
2.
Players are grouped in pairs (so an even number of players is needed). 1) If one of the two players reads a (capital) city or country, the other player has to find the matching capital city or country. They communicate whatever they find vocally (so expect lots of screaming kids). For example, one player goes to a city location and finds out it's "Paris". He then tells the other player that he needs to find the matching country, "France" (or he tells he found "Paris" and the other player reasons that he needs to find "France"). If the players match a correct country / city pair they are told so. If not, they have to keep on looking. The game ends once the the pair of players matched all capital cities with their corresponding countries.
Player performance Player performance can be measured in how quickly he matches cities, and if there are any failed attempts to match incorrect country - capital city pairs.
Difficulty scaling The difficulty of the game can be scaled by using different and larger sets of countries. This game can also be adapted to find the capitals of different provinces in a single country.
Educational value Topography and memorizing
52
