Leren op speelse wijze

Transcriptie

1 Departement Handelswetenschappen en Bedrijfskunde 3de jaar Toegepaste Informatica Applicatieontwikkeling Leren op speelse wijze Kinect game ontwikkeling in C# CAMPUS Geel Mohamed Kadi Academiejaar

2 3 VOORWOORD In het laatste jaar van de bachelor opleiding Toegepaste Informatica, heb ik de kans gekregen om stage te lopen bij een bedrijf. Het bedrijf dat ik gekozen had, was de K.H.Kempen. Hier heb ik samen met 3 andere stagestudenten samengewerkt. Ik zou graag iedereen, zowel familie en vrienden als docenten, willen bedanken voor de steun, hulp en uitleg die ze hebben gegeven tijdens mijn stage en eindwerk. In de eerste plaats wil ik Joan De Boeck, mijn stagebegeleider, bedanken voor de geweldige werksfeer. Het was zeker een genoegen om te mogen werken onder hem. Hij heeft mij altijd goed geholpen en raad gegeven wanneer ik daarom vroeg. Verder wil ik ook Koen Vangeel, mijn eindwerkbegeleider, bedanken bij de hulp en raad die hij mij heeft gegeven bij het schrijven van dit eindwerk. Zonder zijn hulp zou dit eindwerk het niveau niet halen dat het nu haalt. Als laatste wil ik ook even mijn medewerkers Tim Vannuffelen, Jeroen Aerts, Evelien Van Dingen en Glenn Cenens bedanken voor de aangename werksfeer waarvoor ze mede hebben gezorgd.

3 4 SAMENVATTING Dit eindwerk is het resultaat van de stage die ik heb gelopen bij de K.H.Kempen in Geel. Ik heb de stage gelopen op het onderzoeksdomein ICT - Inclusie en ICT. Deze stage heeft 13 weken geduurd. De K.H.Kempen Geel is één van de campussen van de hogeschool. Naast het opleiden van studenten lopen er ook verschillende onderzoeken op de hogeschool. Aan één van deze onderzoeksproject heb ik meegewerkt. Het project had als naam Spe-Ler. Spe-Ler is een onderzoeksproject waarin het principe van 'serious gaming' wordt gebruikt waarbij educatieve inhoud wordt aangeleerd bij jongeren met een verstandelijke beperking. Specifiek voor het Spe-Ler project zullen leefregels worden aangeleerd met als hulpmiddel computerspelletjes. Tijdens de eerste weken van de stage heb ik mijzelf vooral bezig gehouden met het uitzoeken hoe ik de Kinect aan de praat zou krijgen met de computer. Omdat Microsoft geen API heeft vrijgegeven, heb ik mijzelf moeten richten op de open source wereld. Zo ben ik terecht gekomen bij OpenNI na een tip van mijn stagebegeleider. Na deze eerste 2 weken zijn we met het team begonnen met het uitwerken van een administratie omgeving. Tijdens deze uitwerking hebben we heel wat problemen tegengekomen die we hebben moeten oplossen. De hele administratie omgeving is geschreven met de programmeertaal C# en er is gebruik gemaakt van Windows Forms. Nadat we de belangrijkste delen van de administratie hadden uitgewerkt hebben we bestaande spelletjes geïntegreerd met het project, één nieuw spel aangemaakt en het aanspreken van de Kinect verder afgemaakt. Om alle gegevens bij te houden van de administratie omgeving en om gegevens die tijdens een spel worden getoond aan de gebruiker op te slaan, is er gebruik gemaakt van een database. Deze database werd altijd aangesproken via webservices. We hebben als team veel SQL commando's moeten gebruiken om alles te laten werken. Verder hebben we ons project mogen voorstellen op de Europese Commissie in Brussel en op de opendeurdag van de K.H.Kempen Geel. Tenslotte hebben we de administratie omgeving vervolledigd en alle bugs die er nog inzaten opgelost.

4 5 INHOUDSTAFEL VOORWOORD... 3 SAMENVATTING... 4 INLEIDING STAGEOPDRACHT Voorstelling stagebedrijf K.H.Kempen Structuur K.H.Kempen Inclusie en ICT - K-point MPI Oosterlo Situering van de opdracht Doel Uitvoering Fasering & Planning GEBRUIKTE TOOLS & TECHNIEKEN C# C# als programmeertaal Versies Voordelen & Nadelen Scrum SCRUM Werking Toepassing op stageplaats Windows Forms Userinterface Microsoft Visual Studio Microsoft Team Foundation Server XNA UML Klassendiagram Use Case StarUML REALISATIE Analyse Administratieomgeving Use Case Login Administrator Content Provider Begeleider Speler Uitwerking use cases Systeem architectuur Games Klassen Webservices Structuur van programma s Werking verschillende componenten met elkaar Kinect Kinect OpenNI Integratie OpenNI & Spe-Ler Administratie Problemen... 46

5 Uitwerking Spelletjes Gebruikersanalyse Spelletjes Testen & Debuggen OPENDEURDAGEN Voorbereiding Situering binnen E-Inclusion Nabeschouwing BESLUIT LITERATUURLIJST BIJLAGEN... 69

6 7 INLEIDING Ik heb 13 weken gewerkt aan het onderzoeksproject Spe-Ler. Het onderzoeksproject behandelt het aanleren van educatieve inhoud door middel van spelletjes te spelen. Ik heb meegeholpen een administratieomgeving op te zetten, naast het kunnen aanspreken van de Kinect en het helpen integreren van bestaande spelletjes in het project. Dit project zal het MPI in Oosterlo verder kunnen helpen bij het aanleren van gedragsregels voor de jongeren. In dit eindwerk ga ik het niet hebben over hoe ons project zal worden gebruikt in het centrum. Ik geef wel weer wat mijn inbreng was in dit project en hoe ik problemen heb opgelost die zich voordeden. Door dit eindwerk te lezen zal u een beeld kunnen krijgen van het project. In het eerste hoofdstuk leg ik uit wat de stageopdracht omvat. Het volgende hoofdstuk beschrijft de tools en technieken die we hebben gebruikt tijdens de stage. Net zoals elk goed IT-project is er een analyse gemaakt. Deze hebben we zelf niet moeten maken omdat deze al gebeurd was voor de aanvang van onze stage. De analyse hebben we wel moeten gebruiken om de administratieomgeving op te bouwen. Verder in dit hoofdstuk wordt de hele structuur en samenhang van het project uitgelegd. Dit hoofdstuk bevat ook de logica die achter de programmatie van de Kinect zit. De uitwerkingen van de administratie en het integreren van de spelletjes met het project kunnen in dit hoofdstuk worden gelezen. Tenslotte kan ook nog informatie worden gevonden over het testen en het debuggen van het project. Dit wordt allemaal uitgelegd in hoofdstuk 3. Als laatste hoofdstuk zal ik iets meer uitleg geven over de opendeurdagen van de Europese Commissie en de K.H.Kempen Geel. Als afsluiter van dit eindwerk is er nog een besluit.

7 8 1 STAGEOPDRACHT De stageopdracht was duidelijk geformuleerd, we moesten in een team van 4 stagstudenten aangevuld met een werknemer samen met de stagebegeleider een administratie omgeving maken. Ook moesten spelletjes worden voorzien die met de Kinect konden worden bestuurd. De opdracht bevatte de volgende onderdelen: Kinect kunnen aanspreken Administratie omgeving opbouwen Login schermen voor de jongeren Spellen maken en/of aanpassen Integratie van onderbrekingen en de kinect besturing in de spelletjes 1.1 Voorstelling stagebedrijf K.H.Kempen Het bedrijf waar ik stage gelopen heb, is de Katholieke Hogeschool Kempen campus Geel waar ik slechts 1 van de in totaal 800 werknemers ben. De K.H.Kempen is op het vlak van onderwijs- en onderzoek de toonaangevende instelling in de Kempen. Dit wordt alleen maar duidelijker door het feit dat de K.H.Kempen sinds 11 juli 2002 tot de Associatie K.U.Leuven behoort. De partners in deze associatie waren instellingen die in het verleden al samenwerkten. De Associatie K.U.Leuven gaat over een samenwerking die heel Vlaanderen bestrijkt. De K.H.Kempen biedt een uitgebreid gamma aan bachelor- en masteropleidingen. Er zijn 11 departementen die verspreid zijn over de 4 campussen die de K.H.Kempen vormen. De campussen zijn Geel, Lier, Turnhout en Vorselaar. Wat zo typerend is voor de K.H.Kempen is de intensieve samenwerking met het werkveld. Op deze manier kan de K.H.Kempen studenten een goede opleiding aanbieden die afgestemd is op het werkveld. Op het vlak van onderwijs, onderzoek en maatschappelijk engagement is de K.H.Kempen het voorbeeld bij uitstek. Voor de volgende interessegebieden biedt de campus Geel opleidingen aan: Biologie Bio-natuur-dieren Bouw Chemie Cultuur Economie Elektriciteit-elektronica Energie Entrepreneurship Exacte wetenschappen Handel Hardware Informatica-ICT-pc's Kantoorondersteuning-secretariaat Kinderen-tieners Kunst-cultuur Land- en tuinbouw Logistiek Management Mechanica Medisch-gezondheidszorg Mensen-zorg Milieu Onderwijs-opvoeding Recht Sociale economie Software-programmeren Sport-beweging Talen-communicatie Technologie Voeding Winkel en retail

8 Structuur K.H.Kempen De K.H.Kempen heeft een duidelijke structuur. Er zijn verschillende clusters aanwezig. Deze clusters bevatten op hun beurt verscheidene departementen en onderzoeksgroepen. Hieronder een klein overzicht van de verschillende clusters en hun departementen en onderzoeksgroepen voor de K.H.Kempen. Cluster Wetenschap & Technologie Energiemanagement - Kenniscentrum Energie Duurzame gewasbescherming Dier & Welzijn ICT o Inclusie en ICT - K-point o Real-time Electronics and Integrated Circuits Duurzame procestechnologie - Kleinschalige waterzuivering Cluster Gezondheid & Zorg Biomedische technologie - Mobilab Moeder- en kindzorg Lab4Food Cluster Mens & Maatschappij Lokaal sociaal en lokaal economisch beleid Gerontologie en ouderenzorg - VONK3 Effectiviteit van onderwijsprocessen Sociaal Werk Onderzoek Inclusie en ICT - K-point De K-Point onderzoeksgroep richt zich vooral op de vraag Hoe ICT een hulpmiddel kan zijn in onze samenleving?. Zo onderzoekt de groep hoe men ICT, inclusie en kansgroepen kan laten samenvloeien. De groep zal op deze manier de impact van ICT op de samenleving kunnen in kaart brengen en proberen de kloof die er is te verkleinen. Er wordt vooral aandacht besteed aan de zwakkere groepen en kansgroepen van onze samenleving. Spe-Ler: spelend leren voor jongeren met verstandelijke beperking, Joan De Boeck Onze stageopdracht behoort tot het onderzoeksproject Spe-Ler. Dit project is mede gefinancierd door de federale overheidsdienst maatschappelijke integratie. Men gebruikt serious gaming om jongeren met een verstandelijke beperking iets aan te leren door middel van spelletjes te spelen. In de bijlage is er meer informatie over dit project te vinden. Voor onze stageopdracht specifiek moeten de jongeren leefregels leren terwijl ze een spelletje aan het spelen zijn.

9 MPI Oosterlo Het MPI in Oosterlo is een vzw die zich richt op personen met een matige, ernstige of zeer ernstige verstandelijke handicap met mogelijke gedragsproblemen. De vzw begeleidt deze personen, vangt ze op en behandelt ze. De opvang kan op verschillende manieren worden gedaan. Men kan de personen een plaats geven om te blijven slapen. Maar ook is het mogelijk om deze personen overdag op te vangen en kunnen ze gewoon 's avonds naar huis. Het is ook mogelijk om deze opvangvormen te combineren. Er worden verschillende groepen opgevangen op het MPI. Voor één van deze groepen, namelijk de jongeren tussen jaar, is het aanleren van gedragsregels een belangrijk onderdeel van de opvang. Dit onderdeel blijkt ook het moeilijkste onderdeel, omdat je in feite probeert de jongeren regels op te leggen die in sommige gevallen in de ogen van de jongeren een beperking is op hun vrijheid. Een ander probleem dat zich voor doet is dat de jongeren het gewoon niet willen zoals elke jongere het moeilijk heeft met de huisregels in hun huis. Om dit rebels karakter een beetje te omzeilen is er een idee ontstaan waarbij de jongeren de regels kunnen leren op een speelse manier. Alle jongeren van deze tijd spelen graag spelletjes. Dus waarom niet de jongeren spelletjes laten spelen en dit spel regelmatig onderbreken om iets bij te leren op het vlak van gedragsregels. Op deze manier zijn de regels makkelijker te verteren dan wanneer iemand je vertelt dat je iets niet mag doen. 1.3 Situering van de opdracht De stageopdracht waaraan ik meegewerkt heb, is het onderzoeksproject Spe-Ler die door de onderzoeksgroep K-Point van de K.H.Kempen wordt uitgevoerd. De opdracht is vooral gegroeid uit een gelijkaardig project dat loopt in het buitenland. Bij dat project spelen jongeren een spel dat op regelmatige tijdstippen onderbroken wordt. Wanneer het spel onderbroken is, wordt de jongere die het spel aan het spelen is een vraag gesteld. Hierop kan de jongere een antwoordkeuze kiezen en kan dan terug verder spelen. We gebruiken hetzelfde principe bij de stageopdracht. 1.4 Doel Het doel van onze stageopdracht is dat de jongeren van het MPI in Oosterlo leefregels leren door middel van een spel te spelen. Hoe dit juist allemaal gebeurt wordt duidelijk in de rest van dit eindwerk. 1.5 Uitvoering De stageopdracht wordt vooral door stagestudenten uitgevoerd. De stagebegeleider beheert vooral het project en er is nog één medewerker die ongeveer 25% van zijn tijd kan besteden aan het helpen implementeren.

10 Fasering & Planning De stageopdracht had twee duidelijke deadlines die koste wat kost moesten gehaald worden. Door middel van prioriteiten op te stellen is dit ons zeer goed gelukt om een goede voorstelling te kunnen geven van ons project op de deadlines. Er zijn twee grote deadlines die gehaald moesten worden: Opendeurdag Europese Commissie op 7 mei & opendeurdag K.H.Kempen Geel op 8 mei Einde stage studenten op 10 juni Om deze twee deadlines te halen hebben we de SCRUM werkmethodiek gebruikt. Hoe we dit juist hebben aangepakt wordt verder uitgelegd in dit eindwerk. Verder is de stage verlopen in verschillende fases. Fase 1: kennismaking & eerste aanzet We hebben met het hele team (uitgezonderd de twee ICT stagestudenten omdat zij twee weken later zijn begonnen) eventjes rond de tafel gezeten. We hebben wat algemene afspraken gemaakt en hoe we ongeveer onze tijd zullen besteden tijdens onze stage. Hierna zijn we begonnen met de kinect eens uit te testen. We hebben een voormiddag spelletjes gespeeld met de kinect op de XBOX en geleerd wat de kinect kan en niet kan. Daarna heb ik de taak gekregen om de kinect aan de praat te krijgen zodat we deze konden gebruiken voor ons project. Hoe ik dit heb verwezenlijkt staat uitgelegd verder in dit eindwerk. Evelien had de taak gekregen om een gebruikersonderzoek te doen. Fase 2: uitwerking administratie omgeving, spelletjes, kinect Nadat we onze eerste aanzet hebben gegeven en toen de ICT studenten hun stage zijn begonnen zijn we begonnen met de uitwerking van de administratie omgeving. Er is ook één spel gemaakt en twee bestaande spelletjes zijn klaargemaakt om in ons project te integreren. Verder is er ook aan de kinect gewerkt om deze stabiel te krijgen en te laten werken zonder problemen. Fase 3: testen & debuggen We hebben de laatste week voor de opendeurdag van de Europese Commissie heel het project gedebugged. We hebben verder ook het hele project getest op fouten, we hebben geprobeerd om de spelletjes te laten vastlopen. Fase 4: finaliseren administratie omgeving De administratie omgeving was nog niet helemaal uitgewerkt tegen de opendeurdagen. Dus hebben we de resterende functionaliteiten toegevoegd aan de administratie omgeving. Fase 5: testen Heel het project werd getest op fouten die ervoor kunnen zorgen dat het programma zou kunnen vastlopen. Deze fouten zijn dan opgelost.

11 12 2 GEBRUIKTE TOOLS & TECHNIEKEN Tijdens de stage zijn er gebruik gemaakt van verschillende tools en technieken om tot een goed einde te komen. In dit hoofdstuk zullen alle belangrijke tools en technieken aan bod komen en zullen deze toegelicht worden. De volgende onderdelen zullen worden besproken: C# Scrum Windows Forms Microsoft Visual Studio Microsoft Team Foundation Server XNA UML 2.1 C# Voor het project Spe-Ler is gekozen voor de programmeertaal C#. In het begin was Java ook nog één van de kans hebbers om als programmeertaal te worden gebruikt. Maar dit idee was al snel van de baan wanneer het XNA framework op de proppen kwam. Het XNA framework laat toe om spelletjes te ontwikkelen in C#. Omdat twee van de stagestudenten voor het vak C# en gameontwikkeling in XNA al kennis hadden gemaakt met het XNA framework was dus de logische keuze gemaakt. C# als programmeertaal om zo gebruik te kunnen maken van de Windows Forms klasses voor de administratie omgeving en het XNA framework voor de spelletjes die ontwikkeld werden C# als programmeertaal C# is een programmeertaal die is ontwikkeld door Microsoft voor hun.net omgeving, later werd de taal geaccepteerd door ECMA (ECMA-334) en ISO (ISO/IEC 23270). C# omvat de volgende programmeer technieken: Imperatief programmeren Declaratief programmeren Functioneel programmeren Generiek programmeren Objectgeoriënteerde programmeren Component georiënteerd programmeren C# is dus een objectgeoriënteerde programmeer taal die het beste van verschillende talen bevat. De objectgeoriënteerde, procedurele syntaxis die vooral gebaseerd is op C++ met toevoegingen van andere talen zoals Delphi, Java,... De taal wordt gebruikt voor allerlei verschillende toepassingen, zowel voor desktopapplicaties en serverapplicaties als voor mobiele apparaten (pda's, smartphones,..).

12 Versies Er zijn verschillende versie van C# vrijgegeven. Hier een klein overzicht van alle versies die zijn vrijgegeven door Microsoft Voordelen & Nadelen Voordelen C# gebruikt het beste van Java en C++ en laat de overbodige, onnutige dingen weg Objectgeorienteerd Kan worden geschreven in een textverwerkingsprogramma Managed code (gecontroleerde omgeving met weinig ruimte voor bugs) Kan gebruikt worden voor zowel simpele applicaties als webservices Nadelen Komt te kort op gebied van open source. C# is vooral voor een Microsoft Windows omgeving.net framework moet aanwezig zijn op het systeem 2.2 Scrum Voor het beheren van het project zijn er verschillende mogelijkheden. De stagebegeleider, die ook de leider is van het project, heeft gekozen om dit op een Agile manier te doen. SCRUM was in zijn ogen de manier bij uitstek om dit project in goede banen te leiden SCRUM Scrum is een iteratieve en incrementele manier van werken. Als men werkt met Scrum als basis dan kan men elke keer dezelfde onderdelen terug vinden: Scrummaster die overeen komt met een project leider Customer proxy die een persoon uit de business voorstelt Het team dat bestaat uit verschillende experts (programmeurs, analisten, ) Tijdens onze stage opdracht was de scrummaster en de customer proxy onze stagebegeleider namelijk Joan De Boeck. Het team bestond uit 4 stage studenten (twee toegepaste informatici en twee ICT ers) en een extra medewerker van de onderzoeksgroep die 25% van zijn tijd heeft gespendeerd aan dit project.

13 Werking Als men gebruik maakt van Scrum om een project te realiseren kan men niet naast het feit van de sprints kijken. Deze sprints zijn periodes die 2 á 4 weken duren, dit hangt af van wat het team het beste vindt. Tijdens deze sprints wordt er gewerkt aan een product dat geleverd kan worden aan de klant. De delen die worden geïmplementeerd komen van een product backlog en zijn genaamd stories. De product backlog bevat alle stories die moeten worden geïmplementeerd voor het hele project. Deze stories hebben prioriteiten die eraan zijn toegekend die aanduiden hoe kritisch het stuk is. Ook wordt er bijgehouden hoelang men inschat hoeveel tijd deze stories nodig hebben om deze te kunnen implementeren. Welke stories nu juist van de product backlog in de sprint komen wordt bepaald door de customer proxy op de sprint planning meeting. Wanneer deze sprint vast staat, kan deze sprint niet meer veranderd worden. Aanpassingen kunnen enkel tussen sprints gebeuren, nooit tijdens. Tijdens elke sprint wordt er elke dag een scrum-meeting (ook standup-meeting genoemd) gehouden. Tijdens deze meeting worden er 3 vragen beantwoord door elk teamlid: Wat heb je gedaan? Wat ga je doen? Wat zijn je problemen? Hierna werkt iedereen terug verder. Tijdens deze scrum-meeting kan men ook een aanvraag dienen om aan pair-programming te doen moest er iemand problemen hebben bij het implementeren van een story Toepassing op stageplaats Tijdens onze stage duurden de sprints telkens 1 week. Dit was zo gekozen zodat we sneller konden inspringen op veranderingen moesten die er zijn. Maar dit diende ook als extra controle over hoe de applicatie juist moest werken. Op deze manier konden we snel ingrijpen indien we een verkeerde weg waren ingeslagen. Aan het einde van elke week hadden we een stukje werkende software ontwikkeld waarmee een klant eventueel al zou kunnen werken. Als een sprint was afgelopen dan hebben we een sprint planning meeting gehouden waarbij we met een kaart spel hebben gespeeld. De nummers op de kaarten representeerden ideale werkuren. Deze ideale uren moesten een inzicht verwerven hoeveel uren men ongeveer bezig zou zijn aan een story. We gingen dus de verschillende stories die waren geselecteerd inschatten en hoeveel ideale uren ze in beslag zouden nemen. Na deze sprint planning meeting beginnen we aan het uitwerken van deze stories. Ieder teamlid mocht vrij kiezen welke story hij uitwerkt, natuurlijk moet het een story zijn binnen de sprint. Liefst werden eerst de kritische stories uitgewerkt. Op deze manier konden we stories kiezen waar we al eerder ervaring in hadden, dit laat toe om efficiënter te werken. Elke dag hebben we ook een scrum-meeting gehouden waarin we de 3 vragen beantwoordden. Na deze meeting ging iedereen weer terug aan het werk. Tijdens het werken aan stories kon iedereen vrij hulp vragen aan elkaar.

14 Windows Forms Het project Spe-Ler heeft een administratie omgeving waarbij gegevens kunnen worden toegevoegd, aangepast of verwijderd worden. Om dit op een zo eenvoudig mogelijke manier te laten gebeuren is er gekozen om dit op te bouwen met Windows Forms. Windows Forms is een deel dat uitmaakt van het.net framework. De keuze voor Windows Forms was genomen omdat het gehele project ook stand-alone moet kunnen werken, zonder dat men daarvoor een webserver moet hebben. In het project wordt er momenteel wel gebruik gemaakt van een webserver voor de webservices, maar dit kan zodanig aangepast worden in de DatabaseConnection component dat men eender welke database kan gebruiken Userinterface Windows Forms is een verzameling van allemaal classes die een programmeur toelaten om snel en op een eenvoudige manier een applicatie te maken. Deze formulieren zijn visuele interfaces waar gebruikers informatie kunnen lezen en interacties uitvoeren met de formulieren. Deze acties die een gebruiker uitvoert, genereren events die kunnen worden opgevangen door de programmeur om daar specifieke acties aan te koppelen. In het project is hier gretig gebruik van gemaakt om de gebruiker het zo simpel mogelijk te maken. Informatie wordt op een duidelijke manier weergegeven en mogelijke acties voor de gebruiker zijn duidelijk gemaakt door knoppen die zijn toegevoegd aan de formulieren. Windows Forms laat ook toe om zelf controls (knoppen, labels, tekstvakken, ) te maken. In het project is er gebruik van gemaakt om zo zelf een control te maken. De control die gemaakt is, noemt UserControlBladeren. Deze nieuwe control maakt gebruik van twee bestaande controls, namelijk een tekstvak en een bladeren control. Deze controls worden als het ware samengegoten in een nieuwe control die op deze manier kan worden gebruikt als een control die op zich staat. Deze control laat een gebruiker toe om te bladeren. Wanneer een keuze is gemaakt, wordt het tekstvak opgevuld met de gewenste informatie, in dit geval de bestandsnaam. In de afbeelding hieronder is een voorbeeld te zien waar deze zelfgemaakte control is gebruikt.

15 Microsoft Visual Studio Voor het project Spe-Ler is er gebruik gemaakt van Microsoft Visual Studio Dit is een geïntegreerde ontwikkel omgeving(ide = Integrated Development Envirement) van Microsoft. Deze applicatie kan gebruikt worden om andere applicaties te maken zoals Windows Forms (waarover meer in een ander hoofdstuk), websites, web applicaties, webservices,. Men kan programmeren in verscheidene programmeertalen zoals C#, VB.Net, C++,. Voor ons project is er gekozen voor C# omdat de spelletjes in XNA die zouden gemaakt worden. Deze keuze was gemaakt omdat twee stagestudenten al ervaring hadden opgedaan tijdens hun opleiding in het ontwikkelen van spelletjes met het XNA framework. XNA ondersteunt enkel C#. Dus de keuze was snel gemaakt. Deze IDE bestaat uit verschillende onderdelen die typerend zijn voor een IDE: Code-editor Compiler Debugger Designer In de code-editor kan men code schrijven. De code-editor voorziet het verduidelijken van de syntax door deze een andere kleur te geven. Ook is er een IntelliSense die ervoor zorgt dat code niet helemaal geschreven moet worden omdat ze in een klein venster in een lijst worden weergegeven. De compiler zorgt ervoor dat de broncode wordt omgezet naar machine taal. Als er iets mis loopt tijdens het compileren dan stopt de compiler en wordt de actie afgebroken. De debugger laat toe om fouten op een heel makkelijke manier te kunnen opsporen die zich niet voordoen bij het compileren. Het visueel ontwikkelen van een applicatie kan heel makkelijk gebeuren met de designer. In de designer kan men gewoon de layout verzorgen die men graag zou willen. Indien men geavanceerde designs wil die veranderen naar gelang de code die wordt uitgevoerd dan is men nog altijd verplicht om via code alles te maken. Er zijn verschillende designers aanwezig, het hangt af van wat voor soort applicatie je wil maken dat de juiste wordt gebruikt.

16 Microsoft Team Foundation Server Voor het project Spe-Ler is er gebruik gemaakt van een andere tool die Microsoft aanbiedt nl. Team Foundation Server. Deze tool biedt verschillende diensten zoals versie beheer, data collectie, rapportering en project opvolging. Deze tool was dus ideaal om te gebruiken voor het project en als extra voordeel, we konden onze scrum werkwijze hierin verwerken. Tijdens onze stage hebben we elke dag te maken gehad met de source control (versie beheer). Elke avond moesten onze code inchecken. Liefst haalde je de meest recentste informatie van de server af. Wanneer er conflicten waren kon je gewoon de code samenvoegen via een scherm (dit gebeurde deels automatisch). Wanneer je compilerende code had, kon je de code inchecken. De volgende dag s morgens moest iedereen altijd de nieuwste versie halen van de server. Op deze manier werkt iedereen aan het begin van elke dag terug opnieuw met dezelfde code. De meeste activiteit bevond zich rond de work items. Een work item kon een bug, story of taak voorstellen tijdens onze stage. Elk van deze items konden worden toegekend aan personen. Op deze manier kon men te allen tijde zien wie met wat bezig was en konden stories geen twee keer worden gemaakt. In onderstaande foto kan je een voorbeeld zien van zo een work item. Deze work item representeert een story. Elke story kan worden toegewezen aan een persoon, verder heeft een story een status. De status van een story in ons project kon op Active of op Resolved staan. Een story kan ook aan een iteratie (sprint) worden toegekend. Verder zijn er ook nog 2 heel belangrijke velden, namelijk de Stack Rank en Story Points. Hier kan men respectievelijk de belangrijkheid aanduiden en het aantal ideale werkuren inschatten voor deze story. Hoe hoger het getal bij de stack rank hoe belangrijker deze story was. Men kan ook een beschrijving zetten bij de story.

17 18 Ook is er de mogelijkheid om een story op te delen in verschillende taken die hieraan verbonden zijn. Een taak ziet er grotendeels hetzelfde uit als een story. Een taak heeft wat extra veldjes die belangrijk zijn. De belangrijkste zijn het inschatten van hoelang een taak in beslag zal nemen. Men kan ook nog verder invullen hoeveel werk nog een taak nodig heeft en op hoeveel tijd men deze taak heeft afgerond. In dit voorbeeld is te zien dat de taak schijnbaar het dubbele van de tijd in beslag heeft genomen dan origineel is ingeschat. Dit is niet zo omdat de ingeschatte uren in ideale uren is voorgesteld, 1 geschat ideaal uur komt ongeveer overeen met 2 werkelijke uren. Verder biedt de Team Foundation Server ook nog grafieken aan als onderdeel van de rapportering service. In onderstaande grafiek is te zien hoeveel werk er is gedaan en hoeveel werk er nog te doen was voor onze eerste iteratie. Het aantal gepresteerde uren neemt toe in de tijd en het aantal resterende uren neemt af in de tijd. Dus dat betekent dat er progressie aan de gang was.

18 XNA Microsoft XNA is een game-ontwikkelomgeving die door Microsoft is uitgebracht. Deze ontwikkelomgeving is een uitbreiding op de bestaande Microsoft Visual Studio en wordt gratis aangeboden door Microsoft. Het is mogelijk om op een makkelijke en gebruiksvriendelijke manier spelletjes te maken voor Windows, Xbox 360 en de Windows Phone 7. Er zijn verschillende versies uitgebracht van XNA maar voor ons project is er gebruik gemaakt van de nieuwste versie, namelijk XNA versie 4.0. Wanneer er een nieuw XNA project wordt gestart zijn er 2 elementen die de basis vormen voor het hele spel, de game klasse en de content pipeline. In een game klasse kan men al de benodigde elementen inladen en in een components-lijst steken. Door dit te doen worden de update en de draw methodes van de elementen die in de components-lijst staan automatisch opgeroepen. De content pipeline is het tweede grote deel waarin alle afbeeldingen, models, muziekbestanden, worden geladen zodat men deze kan gebruiken voor het spel. Voor de geluidsbestanden is er een tool bijgeleverd genaamd Microsoft Cross-Platform Audio Creation Tool. Deze tool laat toe om geluidsbestanden op eender welk platform te laten afspelen. Tijdens ons project hebben we de spelletjes die gemaakt werden door studenten in het verleden moeten overzetten naar XNA versie 4.0 omdat deze in een oudere versie zijn gemaakt. Tijdens dit proces zijn we paar problemen tegengekomen omdat de code is veranderd door Microsoft bij het overgaan van versie 3.1 naar versie 4.0. We hebben een website gevonden waar we alle nodige informatie konden vinden om de spelletjes op een correcte manier te converteren. Nadat deze problemen van de kaart waren moest er nog fouten eruit gehaald worden waarbij de syntax wel juist was. 1 van die problemen was hoe de objecten getekend moesten worden in een 3D spel. Uiteindelijk bleek dat we wat extra eigenschappen moesten toekennen aan een effect (welke effecten een 3D object krijgt, bijvoorbeeld doorschijnend) wat in de vorige versie automatisch gebeurde. Enkele belangrijke methodes: Draw(): Het tekenen van de objecten gebeurt hier. Het is ook op deze plaats waar we het probleem met het effect object kregen en hebben opgelost. Update(): Hier wordt de logica uitgewerkt zoals het opvangen van Keyboard events en deze aan bepaalde acties te koppelen. Initialize(): In deze functie laadt men alle niet tekenbare elementen van een spel. LoadContent(): De tekenbare elementen van een spel worden hier ingeladen.

19 UML UML is de afkorting voor Unified Modeling Language en is een taal om een informatie systeem in kaart te brengen met tekeningen. Deze tekeningen zijn diagrammen waarvan er 13 verschillende soorten zijn met elk hun eigen inbreng. In het project Spe- Ler is er enkel gebruik gemaakt van 2 diagrammen namelijk het Klassendiagram en de Use Case-diagram. Deze diagrammen zijn tijdens de analyse fase van het project gemaakt door onze stagebegeleider en nog een andere medewerker. De stagestudenten moesten deze enkel kunnen lezen. Dit was geen probleem voor de 2 studenten toegepaste informatica omdat UML een onderdeel is van de onderwijsactiviteiten. Voor de ICT studenten echter was het iets moeilijker, maar ze hebben de draad snel kunnen oppikken met een beetje hulp Klassendiagram Een typische klassendiagram bestaat uit 3 onderdelen. Het eerste onderdeel is de naam van de klasse. Deze staat altijd bovenaan. De naam is uniek in het diagram en moet een voorstelling geven over welk object men het heeft. In het bovenste compartiment van zo een klassendiagram kan men ook stereotypes kwijt. Dit stereotype vertelt meer over de functie van de klasse en wordt boven de naam gezet tussen haken ( <<stereotype>> ). De attributen zijn het 2 de onderdeel van een klassendiagram. Deze staan in het middelste deel. Deze attributen kan men voorstellen als soort van eigenschappen van een klasse. Zoals het voorbeeld hieronder heeft de Game klasse een attribuut die de naam moet voorstellen van een spel. Deze attributen kunnen verschillende zichtbaarheden worden toegekend: publiek (+), privaat (-), protected (#), internal (~) dit symbool representeerde in ons project internal, in de standaard UML definitie representeert dit symbool package protected. Het 3 de onderdeel van een klassediagram is het deel waar de methodes in terecht komen. Deze methodes zijn kunnen de attributen in het 2 de deel wijzigen en ophalen. Maar dit moet niet zo niet altijd zijn. In ons project waren er ook databasebewerkingen in methodes in deze klassen. Zoals in het voorbeeld hieronder is er een methode DeleteGame(), deze methode zal het desbetreffende spel uit de database verwijderen. Een voorbeeld van een klasse in ons project:

20 21 UML biedt ook de mogelijkheid aan om klassen met elkaar te verbinden. Dit kan op verschillende manieren namelijk met associaties, aggregaties en compositieaggregaties. In ons project is er enkel gebruik gemaakt van associaties. Hier volgt een opsomming van de verschillende verbindingsmogelijkheden met uitleg erbij: Associatie: Dit stelt een verbinding tussen 2 klassen voor. Door deze verbinding kunnen de 2 klassen met elkaar communiceren. Aan elke kant van de pijl staat een getal, dit getal stelt het aantal voorkomens voor van elke klasse gerelateerd met de andere kant. Zoals het voorbeeld hieronder kan je zien dat een vraag bestaat uit 0 of tot maximaal 4 antwoordkeuzes en elke antwoordkeuze kan maar behoren tot 1 vraag. Aggregatie: Dit is een speciale associatie waarbij een deel tot een geheel hoort die i.p.v. een pijl een lege ruit heeft op het einde van een lijn. Een voorbeeld hiervan is bijvoorbeeld een schip dat tot een vloot behoord. Het schip kan op zich bestaan net zoals de vloot. Compositie-aggregatie: Deze vorm is een doorgedreven aggregatie. Het één kan niet zonder het andere bestaan. Een voorbeeld hiervan is dat een poot van een stoel op zich kan bestaan. Maar een stoel kan niet zonder poten bestaan want dan stelt het geen stoel meer voor. Een voorbeeld van een associatie tussen 2 klassen: UML voorziet ook in de mogelijkheid om overerving te kunnen voorstellen met diagrammen. Dus een klasse kan overerven van een superklasse. In ons project waren er verschillende soorten gebruikers namelijk spelers en begeleiders. De basis voor beide soorten gebruikers was hetzelfde op enkele punten na. Door gebruik te maken van overerving hoeven de gemeenschappelijke punten niet apart gedefinieerd te worden. Een voorbeeld van overerving van klassen:

21 Use Case Use Cases zijn ook een heel belangrijk onderdeel van UML. Deze use case diagrammen beschrijven de verschillende actoren en wat hun functie is, wat de actoren met het systeem kunnen doen. Een use case bestaat, net zoals elke diagram, uit verschillende onderdelen: Use cases: Deze use cases stellen een opeenvolging van acties voor die het systeem kan doen voor een bepaalde actor. Er kunnen ook relaties worden gezet tussen use cases. De meest gebruikte vormen zijn de include en de extend. Actoren: Een actor kan een persoon voorstellen, maar dit moet niet altijd zo. Een actor kan evenzeer ook een hele organisatie voorstellen of zelfs een ander systeem. Actoren kunnen met het systeem werken en bepaalde acties op gang brengen. Actoren kunnen ook relaties met elkaar hebben. Zo kan men een generalisatie of specialisatie pijl tussen actoren tekenen om aan te duiden dat ze overlappende rollen hebben. Afbakening van het systeem: Men kan het systeem ook afbakenen met een rechthoek. Dit is optioneel en is niet echt nodig. In het voorbeeld hieronder is een use case te zien van een speler. Een speler kan inloggen, een spel spelen en terug uitloggen. Tijdens het spelen van een spel kan (maar moet niet) een speler inhoud bekijken en vragen beantwoorden. Een voorbeeld van een use case:

22 StarUML Om al deze diagrammen te maken is er gebruik gemaakt van een open-source programma genaamd StarUML. Deze tool biedt allerlei afbeeldingen, pictogrammen en lijnen om fatsoenlijke UML diagrammen te maken. StarUML ondersteunt UML 2.0. Een schermafdruk van StarUML:

23 24 3 REALISATIE Tijdens de realisatie van het project zijn er verschillende onderdelen uitgewerkt. De uitwerking van deze onderdelen zullen in dit hoofdstuk allemaal beschreven worden. De volgende onderdelen zullen aan bod komen in dit hoofdstuk: Analyse administratieomgeving Architectuur achter de schermen Kinect Uitwerking administratie omgeving Uitwerking spelletjes Testen & debuggen 3.1 Analyse Administratieomgeving De analyse van het project is gebeurd tijdens het 1 ste semester van het jaar, dus voor de start van onze stage. Tijdens de analyse zijn de stagestudenten dus niet betrokken. De analyse is gebeurd door de stagebegeleider (Joan De Boeck) en nog een medewerker (Tim Vannuffelen). Er zijn verschillende diagrammen opgesteld, usecasediagrammen en klassediagrammen. De use-casediagrammen zijn allemaal apart nog verder uitgeschreven in aparte documenten. Verder is er ook een prototype gemaakt van hoe de administratie ongeveer er moet uitzien Use Case Er zijn verschillende use cases opgesteld tijdens de analyse. Voor elke gebruiker die met het systeem moet werken zijn er use cases opgesteld. Er is ook nog een extra use case gemaakt die de werking van het inloggen duidelijk maakt. De use cases maken duidelijk wat elke gebruiker met het systeem kan en hoe de use cases zelf ook nog gebruik maken van andere use cases. Elk van de use cases hebben een letter en een nummer gekregen. De letter verwijst naar wat voor soort gebruiker (of actie) de use case betrekking heeft: A Administrator B Begeleider C Content Provider S Speler L Login Na elke letter staat er een getal, dit is een willekeurige, unieke nummering van de use cases die bij een bepaalde gebruiker horen.

24 Login Er is ook een use case gemaakt die duidelijkheid moet verschaffen van hoe het inloggen juist moest gebeuren voor de gebruikers van de admintool. Wanneer een gebruiker inlogt met zijn gegevens krijgt hij naargelang zijn rol (administrator, content provider of begeleider) verschillende icoontjes te zien in het startscherm.

25 Administrator De administrator is een soort van oppergod die alles kan beheren met het programma wat beheerbaar is. Alleen een administrator kan begeleiders toevoegen die een welbepaalde rol krijgen toegedeeld (administrator, content provider of begeleider). Dus alleen een administrator kan een andere administrator aanmaken. Verder is de administrator de enige die spelers en klasgroepen kan beheren (toevoegen, wijzigen & verwijderen). Het toewijzen van spelers aan klasgroepen of omgekeerd kan ook enkel door de administrator gebeuren. Hieronder kan je de specifieke use cases vinden die alleen toegankelijk zijn voor de administrator.

26 Content Provider De content provider voorziet zoals het woord zelf al duidelijk maakt de inhoud. Een content provider kan de films uploaden, vragen opstellen met de mogelijke antwoordkeuzes. Deze inhoudsblokken kunnen dan tijdens een spel worden opgeroepen. Verder voorziet een content provider er ook in om spelletjes toe te voegen die kunnen gespeeld worden door spelers. Hieronder zijn de use cases te zien die specifiek voor een content provider zijn. Natuurlijk kan een administrator deze use cases ook gebruiken omdat een administrator bovenaan de lijst staat van de machtigingen.

27 Begeleider Een begeleider is iemand die verantwoordelijk is voor een bepaalde klasgroep waarin jongeren (in ons project spelers) zitten. De hoofdtaak van een begeleider is het beheren (toevoegen, aanpassen & verwijderen) van spelsessie voor de spelers. De spelsessies bevatten de volgende onderdelen: Spelletjes Inhoudsblokken Verder is het ook de taak van een begeleider om deze sessies te koppelen aan de spelers. Op deze manier kan een begeleider kiezen welke spelletjes een speler mag spelen en welke inhoudsblokken dat die deze speler moet doorlopen. Wanneer spelers inhoudsblokken te zien krijgen en antwoorden ingeven, worden deze antwoorden bijgehouden. De antwoorden die een speler geeft, kan een begeleider inkijken en afdrukken indien een begeleider dit wenst. Ook heeft een begeleider de mogelijkheid om deze antwoordlijsten te verwijderen indien deze niet meer nodig zijn. De use case die is gemaakt kan u hieronder bekijken. Natuurlijk kan een administrator en een content provider deze use cases ook gebruiken omdat zij bovenaan de lijst staan van de machtigingen.

28 Speler De speler moet niet zo heel veel kunnen met het systeem. Een speler moet kunnen inloggen in het systeem en uitloggen. Verder moet een speler een spel kunnen spelen. Tijdens het spelen van een spel krijgt de speler inhoudblokken te zien en moet de speler ook vragen beantwoorden. Uit de analyse is de volgende use case bekomen Uitwerking use cases Elk van de use cases is verder uitgewerkt in een apart Word document per use case. De structuur van elk van zo een use case is dezelfde. Elke use case moet een doel hebben dat duidelijk maakt waarom deze use case nodig is. Verder wordt er een beschrijving gegeven van de use case om meer duidelijk te maken wat de use case nu net doet. De actoren die de use case zullen gebruiken worden ook opgesomd. De kritikaliteit en de uitvoeringsfrequentie zijn onderdelen die mee moesten helpen bepalen welke use cases eerst moesten worden uitgevoerd. Indien men rekening moest houden met mogelijke uitbreidingen in de toekomst kon men het veldje met schaalbaarheid invullen. De mogelijkheid om pre- en postcondities in te vullen zijn ook aanwezig om zo duidelijk te maken waaraan de use case moet voldoen indien je de use case wil gebruiken of waaraan de use case moet voldoen indien deze doorlopen is. Het belangrijkste onderdeel voor ons, de stagestudenten, waren de onderdelen primaire pad en alternatieven. Hierin werd de werking van een use case duidelijk uitgelegd hoe deze diende te werken en ook de mogelijke alternatieve werkingen. Ook het deel Uitzondering was belangrijk om te zien of er uitzonderingen waren waar we rekening mee moesten houden.

29 30 Een voorbeeld van een uitgewerkte use case: Nummer use-case: Naam van use-case: Inhoudsblok Wijzigen C5 Doel: de inhoud van een inhoudsblok wijzigen Korte Beschrijving: De Content Provider selecteert een inhoudsblok en wijzigt de gegevens hiervan. Met een inhoudsblok verstaan we een entiteit met een naam en korte beschrijving, een inhoudsdeel (video, beeld of audio) en een bijhordende vraag. (zie document met definities) Actoren: Content Provider Uitvoeringsfrequentie: Hoog, telkens inhoud aan het systeem wordt toegevoegd of wordt gewijzigd Schaalbaarheid: nvt Kritikaliteit: hoog, telkens wanneer inhoud wordt gewijzigd Overige niet-functionele eisen: Precondities: Content Provider moet ingelogd zijn Postcondities: gegevens zijn gewijzigd Primaire pad: 1. Content Provider kiest het onderdeel inhoud uit het hoofdscherm 2. Content Provider krijgt een lijst van alle inhoudsblokken gesorteerd per thema (tree view) 3. Content Provider selecteert een inhoudsblok 4. Volgende alternatieven zijn nu mogelijk a. Wijzigt naam, infoveld van het blok, thema s(c12) waartoe het behoort b. Nieuwe inhoud uploaden (Usecase C8) c. Nieuwe vraag aanmaken (Usecase C9) d. Bestaande vraag wijzigen (Usecase C10) e. Bestaande vraag verwijderen (UseCase C11) 5. Bij bevestiging worden alle gegevens in de databank opgeslagen Use-cases gerelateerd aan primaire pad: C8,C9,C10,C11, C12 Alternatieven: 1. In stap 4 heeft de begeleider de mogelijkheid om in willekeurige volgorde sommige of alle van de 4 mogelijke alternatieven uit te voeren. 2. In stap 5b kan de Content Provider ook kiezen om te annuleren. In dat geval wordt er niets aan de databank gewijzigd (ook alle aangemaakte vragen en antwoorden dienen dan terug verwijderd te worden) Use-cases gerealteerd aan alternatieven: Uitzonderingen: Vereiste informatie is niet ingevoerd (naam, thema s, vragen, ) Use-cases gerelateerd aan uitzonderingen: Geen. Opmerkingen: Geen.

30 Systeem architectuur Het project Spe-Ler is opgebouwd in een logische structuur die makkelijk te begrijpen is. De ontwikkeling van het project is gebeurd in Microsoft Visual Studio Met behulp van de Microsoft Team Foundation Server is er voor gezorgd dat er met een gemeenschappelijke code kan gewerkt worden. Er is een aparte solution gemaakt met daarin verschillende projects. Zoals in de afbeelding hieronder te zien is, bevat het project Spe-Ler 3 spelletjes, een administratie tool, een corecomponents project, een Database ConnectionWebService, een GameInterface, een KinectDriver en een SpelerApp. Dan zijn er nog twee test projecten die louter dienden om de GameInterface, Kinect en de DatabaseConnectionWebService te testen. De Spe-Ler Suite is de installer die alle benodigde programma s zal installeren op de computers van de klanten Games In deze map staan 3 spelletjes namelijk BombSquad, BreakFree en Commander Keen. BombSquad is een spel dat ontwikkeld is door één van de stagestudenten namelijk Evelien. De andere twee spelletjes zijn gemaakt door studenten Toegepaste Informatica voor het vak C# en gameontwikkeling in XNA in het 3 de jaar. Aan deze spelletjes is een GameInterface toegevoegd. Deze GameInterface zorgt voor de onderbreking. Tijdens deze onderbreking krijgt een gebruiker een filmfragment te zien en moet de gebruiker hierna een antwoordkeuze aanduiden. Ook werd de KinectDriver aan deze spelletjes toegevoegd om de mogelijkheid toe te laten om met de Kinect spelletjes te kunnen spelen. Het aanpassen van deze spelletjes is gebeurd door de 2 ICT stage studenten (Glenn en Jeroen).

31 Klassen Het project Spe-Ler bevat een aantal klassen. Elk van deze klassen hebben een stereotype gekregen namelijk control ofwel entity. De entity klassen stellen objecten voor die informatie bijhouden. Bijvoorbeeld ClassGroup zal informatie bij kunnen houden over een klasgroep. Verder bevat ons project een entity klasse code om bewerkingen te kunnen uitvoeren op de database. Een voorbeeld hiervan is dat men een nieuwe rij in de database kan toevoegen als men een nieuwe klasgroep wil toevoegen. Dus alle bewerkingen op de database die betrekking hebben op een entity worden in de entity gezet. De control klassen hebben een static instantie van zichzelf. Dit zorgt ervoor dat men informatie kan bijhouden over formulieren heen. Zo houdt de controllerklasse die voor de beveiliging zorgt een gebruiker bij en of deze is ingelogd. Door deze gebruiker overheen de formulieren bij te houden kan men elke keer controleren wat voor soort gebruiker (administrator, Content Provider, Begeleider) is ingelogd. Zo kan men enkel de informatie tonen die deze gebruiker mag zien zonder dat men elke keer naar de database moet gaan om deze gebruiker te controleren. SecurityController: bevat alle informatie die nodig is om de beveiliging te garanderen. UserController: bevat alle informatie die nodig is om bewerkingen uit te voeren op gebruikers en wat aan deze gebruikers is verbonden zoals de klasgroep waartoe een gebruiker hoort. GameController: bevat de nodige informatie om bewerkingen op spelletjes en spelsessies uit te voeren. ContentBlockController: deze controller klasse bevat alle informatie die te maken heeft met het tonen van inhoudsblokken. Ook bevat het de nodige bewerkingen om deze informatie aan te passen. DatabaseConnector: deze controller zorgt voor de connectie met de database waarvan alle entiteit klassen gebruik maken om bewerkingen op de database uit te voeren. Hieronder is de hele structuur van de klassen uitgetekend. Hieruit wordt duidelijk welke entity klassen aan welke control klassen vastzitten.

32 Webservices Een webservice is een manier van communicatie tussen 2 componenten. Een client kan een dienst opvragen van een server. Zoals het afhalen van informatie vanuit een databank. Deze communicatie kan gewoon via standaard webprotocollen zoals HTTP. Applicaties of clients kunnen via SOAP (XML gebaseerd protocol) gebruik maken van de webservice. De services die worden aangeboden worden gedocumenteerd met WSDL (Web Services Definition Language). Dit is een XML-document dat uitgelezen kan worden. Om bewerkingen op de database te kunnen uitvoeren hebben we dus gebruik gemaakt van een webservice. Deze webservice is door onze stagebegeleider (Joan De Boeck) gemaakt. Er zijn verschillende methodes die beschikbaar zijn gesteld in de DatabaseConnectionWebService. De 2 belangrijkste zijn de volgende: GetDataSet: Deze methode geeft een dataset terug. Deze dataset kan verschillende tabellen bevatten, hoewel dat bij al onze methodes slechts één tabel wordt teruggegeven. Deze tabellen bevatten rijen uit de database, welke rijen hangt af van welk SQL commando wordt meegegeven. Dus deze methode wordt gebruikt voor het halen van gegevens uit de database. ExecuteNonQuery: Deze methode zal een bewerking uitvoeren op de database. Men kan gegevens toevoegen, verwijderen en aanpassen aan de database met een SQL commando dat meegegeven wordt met deze methode Structuur van programma s Al de bestanden van het project hebben over het algemeen dezelfde structuur. We hebben voor deze manier van werken gekozen zodat alles goed gestructureerd staat en alle bestanden ook ongeveer dezelfde volgorde hebben. Elk bestand is verdeeld in verschillende regionen: Member Variables: Hier worden alle member variabelen aangemaakt. De access modifiers van deze member variabelen staan in ons project altijd op private. Properties: Met deze properties kan men de getters en de setters van de member variabelen maken. En op deze manier kan men de nodige velden beschikbaar stellen buiten het object indien men dit wenst. Constructors: De verschillende constructoren komen in deze regio terecht. Methods: Alle methodes worden in deze regio gegroepeerd.

33 34 De volgende afbeelding zal alles meer verduidelijken: Verder is er ook afgesproken om de samenvatting altijd per methode in te vullen. Op deze manier kan men informatie lezen wanneer de IntelliSense in werking treedt. Zo een samenvatting bestaat uit een beschrijving van wat de methode juist doet. Verder kan je voor elke parameter ook een beschrijving geven. Als er een return waarde is, kan deze ook een toelichting krijgen. De volgende afbeelding geeft meer duidelijkheid bij het toepassen van deze samenvatting voor een bepaalde methode: Wanneer de methode in bovenstaande afbeelding wordt gebruikt doet de IntelliSense zijn intrede. In de afbeelding hieronder kan je een voorbeeld zien van wanneer je de methode gebruikt:

34 Werking verschillende componenten met elkaar Het project Spe-Ler bestaat uit verschillende componenten. Het was soms moeilijk om ons voor te stellen hoe alles met elkaar samenwerkt. Om alles goed te kunnen begrijpen is een duidelijk overzicht onmisbaar. Er zijn 3 grote groepen die te maken krijgen met het project: Speler PC Admin PC Remote Server Speler PC Dit stelt de computer voor die een speler gebruikt. Op deze computer staat de SpelerApp. Met deze applicatie kan een speler inloggen en een spel spelen. Een speler kan inloggen door zijn klasgroep aan te klikken en daarna zijn eigen foto. Hierna krijgt die een keuze uit spelletjes die hij kan spelen. Hieronder kan u de verschillende schermen zien die worden doorlopen: Voor ons project is het enkel nog maar mogelijk om 3 spelletjes (BombSquad, BreakOut & Commander Keen) te spelen die onderbreekbaar zijn. Een Content Provider kan ook andere spelletjes toevoegen, maar die zullen dan niet onderbreekbaar. Elk spel maakt gebruik van 2 andere componenten: KinectDriver: De kinectdriver zorgt ervoor dat de spelletjes gespeeld kunnen worden met de kinect. Hoe deze component in elkaar zit wordt in detail uitgelegd in het hoofdstuk over de kinect. GameInterface: Dit is het scherm dat getoond wordt wanneer een spel wordt onderbroken. Dit scherm laat altijd eerst een film (of een afbeelding en een geluidsfragment) zien die een situatie schetst. Wanneer deze film klaar is wordt er een vraag met verschillende antwoordmogelijkheden getoond. De speler kan dan kiezen welk antwoord hij selecteert. Dit zijn de schermen die de speler te zien krijgt wanneer een spel onderbroken wordt:

35 36 Admin PC Dit stelt de computer voor van een beheerder (Administrator, Begeleider of Content Provider). Op deze computer zal de admintool aanwezig zijn. Met deze admintool kan een beheerder de applicatie beheren. De admintool maakt gebruik van de Corecomponents en de GameInterface. In de Corecomponents staan alle klassen in die men kan gebruiker voor dit project. Wat er allemaal kan gedaan worden met deze tool wordt verduidelijkt in het hoofdstuk waar de volledige werking van de admintool wordt uitgelegd. Remote Server Dit stelt de server voor waarop de database staat die de admintool, SpelerApp en de spelletjes gebruiken om gegevens in op te slagen, aan te passen of op te halen. Deze remote server kan overal staan, het is een kwestie van een paar instellingen te veranderen om een andere database te kunnen gebruiken. Hieronder is een afbeelding te zien met de hele structuur.

36 Kinect De spelletjes die we gaan maken zullen bestuurd worden met de Kinect. Om deze Kinect te besturen heeft Microsoft nog geen API vrijgegeven. Hierdoor hebben we ons moeten richten op de Open Source wereld. We hebben gekozen voor OpenNI Kinect De kinect is een toestel dat toelaat om een spel te spelen met het lichaam. Door bewegingen uit te voeren met het lichaam kan men dus spelletjes besturen. De kinect bestaat uit verschillende onderdelen: Microfoons: De microfoons aan beide kanten van de kinect laten toe om een bron van geluid te kunnen lokaliseren. Verder kunnen deze microfoons omgevingsgeluid onderdrukken, dit laat toe om zonder een headset te praten met andere mensen op het internet. 3D Sensors: De twee 3D sensoren bestaan uit infrarood laser projectoren die op deze manier zorgen voor een 3D zicht. Motor: De motor laat toe om de kinect omhoog of omlaag te laten kijken. RGB Camera: Deze camera laat toe om gekleurd beeld te kunnen opvangen met de kinect. Zo kunnen er bijvoorbeeld foto s worden getrokken in het midden van een actie. De sensor heeft een horizontaal zicht van 57 graden en verticaal 43 graden. De motor kan de kinect 27 graden omhoog of omlaag bewegen. De kinect laat dus toe om geavanceerde bewegingen te herkennen. Verder kan de kinect gezichten en geluiden herkennen. De kinect kan verschillende personen tegelijkertijd herkennen die allemaal punten krijgen toegewezen op de belangrijkste posities van het lichaam (hoofd, ellebogen, knieën, heupen, handen, ). Het maximum aantal personen voor de camera is gelimiteerd tot hoeveel personen binnen het gezichtveld van de kinect kunnen passen OpenNI OpenNI is een non-profit organisatie dat zich bezighoudt met Natural Interaction (NI) toestellen, applicaties en middleware. De organisatie heeft een opensource framework (OpenNI framework) vrijgegeven dat een API (Application Programming Interface) voorziet om programma s te kunnen schrijven voor deze toestellen waarbij natuurlijke interactie aan te pas komt.

37 Integratie OpenNI & Spe-Ler Om de kinect te kunnen aanspreken in het project Spe-Ler is er een nieuw project aangemaakt binnen de solution, namelijk de KinectDriver. Deze KinectDriver bevat verschillende klassen. Deze KinectDriver wordt gebruikt in de spelletjes om te kunnen communiceren met de kinect. In de afbeelding hierboven wordt duidelijk hoe uit een spel de kinect kan worden aangesproken. Er is ook nog altijd de mogelijkheid om een toetsenbord te gebruiken voor de spelletjes. In een spel wordt er een UserInteraction gedefinieerd. Deze UserInteraction is voor elk spel anders, omdat een ander spel andere betekenissen kan geven aan bepaalde acties. Deze UserInteraction erft over van een abstracte klasse UserInteractionAbstract. In deze abstracte klassen zijn er bepaalde methodes die voor alle UserInteractions hetzelfde zijn. Bijvoorbeeld het controleren of er bepaalde bewegingen zijn uitgevoerd. Deze UserInteractionAbstract klasse zal op zijn beurt een KinectInterface definiëren. Deze KinectInterface zal events opvangen die de Kinect klasse zal oproepen. Game1 Dit stelt een spel voor waarin de UserInteraction wordt gebruikt. In elk spel moet er een UserInteraction worden gedefinieerd. Deze UserInteraction moet in elk spel in de Game1 worden geüpdate in de update methode. De GetStatus() methode van de UserInteraction moet worden opgeroepen in de update methode van de Game1 als eerste regel (na de regel die ervoor zorgt dat je een spel kan pauzeren). In dezelfde update methode in de Game1 klasse van een spel moet er op het einde een ClearStatusList() worden opgeroepen van de UserInteraction. Dit is nodig zodat er geen oude bewegingen in de statuslijst blijven.

38 39 In het voorbeeld hieronder is te zien hoe de UserInteraction gebruikt wordt in een spel om bijvoorbeeld te zien of de speler heeft gesprongen of aan het leunen is naar een kant. UserInteraction In de UserInteraction klasse kunnen de methodes worden geschreven die in een spel worden gebruikt. Men kan zelf kiezen welke methodes en welke bewegingen moeten worden gebruikt voor een spel. Men kan altijd kiezen om dit te implementeren voor de kinect, toetsenbord of allebei. Het enige wat in de UserInteraction wordt geïmplementeerd zijn dus de bewegingen/toetsen die men wil gebruiken voor een spel. Hieronder kan u een voorbeeld zien van een methode die in de UserInteraction is geïmplementeerd. De methodes CheckForStatusDictionary( ) en IsKeyPressed( ) worden overgeërfd van UserInteractionAbstract. UserInteractionAbstract Dit is een abstracte klasse waarvan de UserInteraction overerft. Het belangrijkste in deze klasse zijn de statuslijst, keyboardstates en de methodes om de statuslijst te controleren. De statuslijst is een Dictionary waarin de verschillende bewegingen die zijn uitgevoerd worden bijgehouden en aangepast. De keyboardstates (een huidige keyboardstate en een oude keyboardstate) worden gebruikt om op te vangen welke toetsen op het toetsenbord worden ingedrukt. Verder zijn er de methodes om te controleren of een beweging al dan niet is uitgevoerd. Ik ben in het begin begonnen om het duwen in een bepaalde richting (x, y of z-as) met een ledemaat op te vangen. Ik ga de volledige statuslijst af tot ik de juiste sleutel met de juiste as en lichaamspunt tegenkom. Dan ga ik controleren of het duwen in die bepaalde as met dat lichaamspunt is gebeurd.

39 40 Hieronder is te zien hoe ik dit heb geïmplementeerd. Deze manier van bewegingsherkenning werkt enkel als ik duw met een ledemaat in een bepaalde as. Bijvoorbeeld voor het springen kon ik dit niet op deze manier implementeren. Daarom dat ik een andere methode moest verzinnen om bewegingen te kunnen herkennen waarbij niet wordt geduwd in een bepaalde as. Het is dan dat ik op het idee ben gekomen om zelf een sleutel te definiëren zodat ik verschillende soorten sleutels kan bijhouden in eenzelfde Dictionary. Deze nieuwe methode is beter dan de oude omdat die gebruiksvriendelijker is. Men moet gewoon een enumeratie meegeven,die een beweging moet voorstellen, met de methode. Hieronder is een voorbeeld te zien van de methode.

40 41 Beide manieren van het zoeken en het opvullen van de statuslijst werken goed. De eerste manier waarbij een as en een lichaamspunt moet worden gegeven is minder programmeerwerk. Als het duwen in elke as voor elke lichaamspunt toch een aparte Gesture zou krijgen, betekent dit 45 extra Gestures (15 lichaamspunten x 3 assen) die bij in de enumeratie moeten bijkomen en daarbovenop moeten deze ook nog worden toegevoegd aan de statuslijst. Dus de eerste methode heeft zijn voordeel bij het programmeerwerk dat veel minder wordt. De tweede methode is gewoon gebruiksvriendelijker. De code ziet er dan ook iets properder uit. Voor de rest is er niet echt veel verschil tussen beide methodes. KinectInterface In de KinectInterface worden de events, die door de Kinect klasse worden gegooid, opgevangen. Dit gebeurt door handlers aan te maken en deze te koppelen aan de juiste events. Verder zijn er nog enkele belangrijke methodes in deze klasse: opvullen van de statuslijst statuslijst kopiëren statuslijst terug opnieuw zetten naar de standaardwaardes (alles op false ) Hieronder is een afbeelding te zien waar het opvangen van een spring beweging gebeurt. Wanneer een beweging herkend is, wordt deze in de statuslijst opgevuld en de waarde die aanduidt dat de beweging is herkend op true gezet. Net zoals bij de UserInteractionAbstract waarbij er 2 methodes zijn waarmee je door een statuslijst kan zoeken, zijn er nu ook 2 methodes om de statuslijst bij te werken. Hieronder is het voorbeeld te zien waarbij gewerkt wordt met de methode die een enumeratie binnenkrijgt. Verder zijn er nog 2 belangrijke methodes die zorgen dat een statuslijst kan worden gekopieerd en kan worden teruggezet. Hieronder kan u een afbeelding zien waarbij de hele statuslijst kan worden gekopieerd. Zoals op de afbeelding te zien is, is er een lock nodig zodat hetzelfde stuk geheugen niet kan worden overschreven wanneer het kopiëren aan de gang is.

41 Om de statuslijst terug te zetten naar de standaard waarde moet de hele statuslijst worden doorlopen. Eerst maak ik een lijst van alle sleutels die aanwezig zijn in de statuslijst. Op deze manier kan de statuslijst worden aangepast terwijl alle waardes worden afgelopen. Alle waardes die aanduiden of een actie is uitgevoerd worden op false gezet. Op deze manier worden bewegingen die al zijn herkend niet nog eens herkend bij de volgende keer dat de statuslijst wordt gecontroleerd. Hieronder is een afbeelding te zien van hoe dit gebeurt. 42

42 43 Kinect Deze klasse is de belangrijkste klasse van heel de KinectDriver. In deze klasse gebeurt namelijk het wegschrijven van de posities van de verschillende lichaamspunten en het herkennen van de bewegingen. Hieronder is een voorbeeld te zien van welke punten allemaal kunnen worden opgevraagd. Al de punten waarin lijnen samenkomen of elkaar snijden zijn punten die kunnen opgevraagd worden. ReaderThread & movementsthread Het inlezen van deze punten en het herkennen van bewegingen gebeurt in 2 verschillende threads: ReaderThread (inlezen van punten en deze wegschrijven) en movementsthread (herkenning van bewegingen). Dit is nodig omdat dit anders performantie problemen geeft omdat het onnodig is om bijvoorbeeld elke milliseconde de punten die de kinect geeft weg te schrijven. Het herkennen van bewegingen gebeurt ook in een andere thread ook weer omdat dit performantie problemen geeft wanneer elke keer na het wegschrijven van punten ook direct gecontroleerd wordt of er bewegingen zijn uitgevoerd. In de readthread worden de punten opgevraagd die zijn herkend. Deze punten worden voor elke gebruiker die voor de kinect staat in een dictionary opgeslagen. Daarna worden deze punten die in deze dictionary staan toegevoegd aan een lijst. Deze lijst staat in een andere klasse namelijk de MovementCache. Deze klasse houdt een lijst bij met punten voor elk lichaamspunt. In het project Spe-Ler worden er 50 punten bijgehouden voor elk lichaamspunt, dit zou ongeveer moeten overeenkomen met een tijdspanne van bijna 2 seconden. Dus er kan bijna 2 seconden in het verleden worden teruggekeken. De nieuwe punten worden gewoon toegevoegd als de cache vol is en het oudste punt wordt dan verwijderd. Deze punten kunnen niet zomaar worden opgevraagd. Een speler die voor de kinect staat moet eerst worden herkend. Dus elke speler die voor de kinect staat moet altijd eerst een pose aannemen. Wanneer deze pose is aangenomen wordt de speler gekalibreerd. Wanneer het kalibreren succesvol is gelukt, kunnen de verschillende lichaamspunten worden opgevraagd.

43 44 Hieronder is een afbeelding te zien waar de pose wordt aangenomen om gekalibreerd te worden. Terwijl punten worden ingelezen in de readerthread (en opgeslagen in de cache) wordt er aan bewegingherkenning gedaan in de movementsthread. Er zijn variabelen gebruikt in deze movementthread die dienen als drempelwaardes. Deze drempelwaardes worden gebruikt bij de herkenning van verschillende bewegingen. Een voorbeeld hiervan is bijvoorbeeld het springen. Wanneer de drempelwaarde voor de sprong wordt overschreden dan heb je gesprongen en wordt er een event jump uitgevoerd. De drempelwaardes moeten elke keer worden herberekend, dit heeft te maken met hoe de kinect werkt met zijn 3D sensoren. Bijvoorbeeld een speler lijkt groter wanneer deze dichter bij het apparaat staat en kleiner wanneer deze verder van het apparaat staat. De drempelwaardes zijn afgestemd op mijn lengte en op de positie waar ik deze drempelwaardes heb uitgetest. Daarom dat deze waardes moeten worden herberekend en dit gebeurde op de volgende manier: Drempelwaarde = (drempelwaarde voor Mohamed / lengte Mohamed) * lengte huidige speler De cache die constant wordt aangevuld kan worden uitgelezen. Dit gebeurt voor de duw bewegingen in elke as. Ik neem als voorbeeld het boksen vooruit. Wanneer er met de rechterhand een boksbeweging vooruit wordt uitgevoerd dan zal dit worden opgemerkt door de KinectDriver. Dit komt omdat er een lijst van de laatste 50 punten wordt bijgehouden van de rechterhand. Heel deze lijst wordt afgelopen en de 2 verst uiteen liggende punten worden gebruikt om te controleren of een drempelwaarde is overschreden. Daarna wordt gecontroleerd of de beweging die is uitgevoerd een duw of trek beweging is. Indien in het voorbeeld van de boks een duw beweging is herkend dan zal er een duw event voor de z-as worden uitgevoerd. Het controleren of er voor een bepaalde beweging een duw of een trek beweging gebeurt werd simpel opgelost door heel de cache te doorlopen en elk punt te controleren met het vorig punt.

44 45 Er is verder ook nog gebruik gemaakt van een BaselineSkeleton. Dit is een dictionary van lichaamspunten die nodig was om minder ruis te krijgen bij de berekening van de lengte van een speler en de berekening van de y-waarde van de grond. Deze ruis wordt gecreëerd doordat de lichaamspunten constant veranderen van waarde, ook al staat een speler kaarsrecht. Het skelet dat overeenkomt met een speler is maar een schatting van de kinect van waar ongeveer elk punt zou moeten zitten. Om dit probleem te omzeilen is daarom gewerkt met de baselineskeleton. Deze baselineskeleton wordt berekend op een logaritmische manier. Dus punten veranderen in de beginfase snel maar wanneer deze in de buurt komen van een bepaalde grens zal het veranderen van deze punten richting die grens heel traag verlopen en zal deze die grens ook nooit bereiken. De berekening gebeurt als volgt: Nieuw baselineskeleton lichaamspunt = ((49 * lichaamspunt in baselineskeleton) + huidig lichaamspunt)/50 Hieronder is een voorbeeld te zien van een speler die een spel aan het spelen is met de kinect waarbij de KinectDriver wordt gebruikt om de bewegingen te herkennen.

45 Administratie Één van de grote luiken van onze opdracht was de uitwerking van de administratie omgeving. Er moest een administratieomgeving opgebouwd worden waarmee de medewerkers van het MPI de vragen en antwoorden en alles wat erbij komt kijken kunnen beheren Problemen Tijdens onze uitwerking zijn we op een paar struikelblokken gestoten. De 2 grootste moeilijkheden die ik had waren de datagridview en de treeview. DataGridView De allereerste story die ik op mij had genomen was het tonen van een lijst met alle inhoudsblokken. Ik heb toen gekozen om deze lijst weer te geven met een datagridview. Dit was op het eerste zicht een niet al te moeilijke taak. Maar tijdens het werken hieraan merkte ik al vrij snel dat zo een datagridview immens veel mogelijkheden biedt. En net omdat dit zoveel mogelijkheden biedt was het moeilijk om de juiste eigenschappen te vinden om die in te kunnen stellen. Ik heb veel tijd verloren met het zoeken naar de juiste eigenschappen om de datagridview op de juiste manier te kunnen weergeven. Hieronder vindt u een foto met al de eigenschappen die ik dan heb gevonden die de datagridview op de juiste manier weergeven en zoals de gebruiker het ook wil. Nog een probleem met de datagridview was het verplaatsen van kolommen of het veranderen van de inhoud van de datagridview in een paar cellen. Of foto s die geladen moesten worden afhankelijk van de waardes die in andere cellen aanwezig waren. Dit veranderen heb ik in het begin gedaan met een event dat CellFormatting noemt. Met dit event kan je op een makkelijke manier de inhoud van een cel veranderen. Maar dit gaf voor afbeelding problemen omdat deze begonnen te flikkeren. Ook was het geen goede manier omdat dit veel rekenkracht van de processor vroeg. Ik heb dit process dan verschoven naar een ander event DataBindingComplete. Wanneer de datasource van een datagridview opgevuld is wordt het event DataBindingComplete uitgevoerd. Dit gebeurt maar één keer en op de juiste moment. Dus dit was een ideale oplossing voor de minder performante CellFormatting.

46 47 Het resultaat van deze eigenschappen kan u zien in de volgende schermafdruk: Treeview De treeview heeft mij ook wat problemen bezorgd. De story waarbij ik op het probleem was gestoten was de story waarbij ik inhoudsblokken aan een sessie moest toekennen. Dit was het makkelijkste te bereiken met een treeview. De elementen op het hoogste niveau stelden de thema s voor. De elementen die behoorden tot de thema s zijn de inhoudsblokken. Je kan de optie om checkboxen toe te voegen aan de verschillende nodes van een treeview aanzetten. Dit heb ik gedaan, maar op het hoogste niveau moesten er geen checkboxen staan omdat hier thema s staan. Deze mochten niet aanvinkbaar zijn. Het weglaten van deze checkboxen was makkelijker gezegd dan gedaan, omdat er geen methode is die deze handeling toelaat. De mogelijkheid bestaat, maar dit is niet beschikbaar gezet voor de gewone programmeur. Op het internet heb ik dan na lang zoeken een oplossing gevonden voor dit probleem. Er wordt een TVITEM aangemaakt, dit is een struct. Hoewel deze bijna dezelfde syntax als een klasse heeft, is een struct gelimiteerd. Verder is er een methode SendMessage die ervoor zal zorgen dat je de checkbox in de treeview al dan niet tekent. Verder zijn er nog wat constanten.

47 48 Hieronder is de code te vinden die ik heb gevonden op het internet: Hieronder is de methode die opgeroepen wordt om een checkbox van een node te verbergen in een treeview: Het resultaat van de treeview ziet eruit als volgt:

48 Uitwerking In het volgend voorbeeld kan gezien worden wat de administratie allemaal moet kunnen beheren. Dit startscherm is voor elke soort van gebruiker anders. Het scherm hieronder toont aan welke soort gebruiker toegang heeft tot welke icoontjes. De Administrator heeft toegang tot de administrator icoontjes en al die icoontjes eronder, dus die van de Content Provider en van de Begeleider. De Content Provider kan niet aan de icoontjes van de Administrator maar wel aan die van een Begeleider. En om af te sluiten kan de Begeleider enkel aan zijn eigen icoontjes aan.

49 50 Spelers Dit is het scherm dat een administrator krijgt wanneer hij op de optie "Spelers" klikt in het hoofdmenu. De administrator krijgt een lijst van alle spelers te zien die bij zijn affiliatie horen. Deze lijst van spelers kan men filteren. Als men de naam van een speler in het daarvoor voorziene veld bovenaan invult en dan op de entertoets of op de filter knop drukt, krijgt de administrator een lijst van spelers te zien, gefilterd op de invoer. In dit scherm kan de administrator spelers wijzigen door op het potloodje te klikken. In dit scherm kunnen alle gegevens van een speler worden gewijzigd. Men kan ook spelers aan klasgroepen toewijzen. Wijzigingen naar de database worden pas doorgevoerd als er op bewaren worden geklikt in het venster 'Spelergegevens wijzigen'. Dit is hetzelfde scherm dat de administrator te zien krijgt wanneer hij een speler wil toevoegen. De administrator kan ook spelers snel verwijderen door op het kruisje te klikken. Er wordt nog een controle voorzien waarbij de administrator zijn keuze moet bevestigen.

50 51 Gebruikers Gebruikers van de administratiekant kunnen hier worden toegevoegd, aangepast en verwijderd. Ook hebben deze gebruikers 3 verschillende rollen (begeleider, inhoudsleverancier en administrator). Deze rollen beperken of breiden hun rechten uit om aanpassingen te kunnen doen. In dit scherm kunnen aan een begeleider klassen worden toegekend. Op deze manier kan een begeleider alleen de leerlingen die verbonden zijn met deze klassen beheren. Deze manier laat toe om op een efficiënte manier de leerlingen te beheren.

51 52 Klasgroepen Spelers worden onderverdeeld in klasgroepen. In dit deel van de administratie kunnen spelers toegewezen worden aan hun klasgroep. De administrator dient een keuze te maken welke klasgroep hij wil aanpassen. De administrator kan spelers aan een klasgroep toevoegen door de spelers te selecteren en deze dan door middel van de knoppen in het midden over te zetten. Administrators kunnen ook in deze sectie van de administratie de begeleiders koppelen aan klasgroepen.

52 53 Spellen Spellen kunnen hier worden toegevoegd, aangepast en verwijderd. Een administrator kan een spel wijzigen indien hij dit wenst door op de wijzigen knop te drukken. Ook is er de mogelijkheid een spel te verwijderen.

53 54 Spelsessies Hier kunnen spelsessies worden aangemaakt waarin een batterij van spelletjes ter beschikking wordt gesteld aan de speler. De gebruiker die ingelogd is kan enkel zijn spelsessies zien en aanpassen.

54 55 Een gebruiker kan spelletjes toevoegen aan een spelsessie. Hij dient enkel de spelletjes aan te vinken die hij aan een spelsessie wil toevoegen. De spellen worden pas effectief toegevoegd aan een spelsessie in de database wanneer men in het aanpassen scherm op bewaren klikt. Een gebruiker kan ook inhoudsblokken toevoegen aan een sessie. Hij kan ook de volgorde waarin deze inhoudsblokken moeten worden getoond aanpassen door in het scherm op de pijltjes te drukken. Inhoudsblokken kunnen worden toegevoegd door ze te selecteren. Als er inhoudsblokken bij meerdere thema's horen dan zullen dezelfde inhoudsblokken ook automatisch geselecteerd worden. Men kan ook kiezen hoe de inhoudsblokken worden getoond aan de speler. Men heeft 3 mogelijke keuzes: Inhoudsblokken tonen in dezelfde volgorde en dit blijven herhalen. Inhoudsblokken tonen in willekeurige volgorde en dit blijven herhalen. Inhoudsblokken één keer laten zien, en wanneer er geen inhoudsblokken meer zijn, geen inhoudsblokken laten zien.

55 56 Spelers & spelsessies Hier gebeurt de effectieve koppeling waarin spelers aan spelsessies worden gekoppeld. Dit scherm heeft twee tabbladen. Men kan op twee manieren spelers en spelsessies koppelen. De eerste manier is door aan spelers spelsessies te koppelen. Men selecteert het potloodje naast een speler en men krijgt dan een scherm te zien waarin alle spelsessies zitten die men kan toewijzen aan een speler. Men kan slechts één spelsessie toewijzen per speler. Als men een andere spelsessie selecteert, wordt het vinkje verplaatst. De tweede manier is dat men per spelsessie spelers toevoegt. De gebruiker selecteert het potloodje naast een spelsessie en dan krijgt men het venster te zien waarin de gebruiker spelers kan toevoegen aan de spelsessie. Dit gebeurt op dezelfde manier als bij het toevoegen van spelers aan klasgroepen. Als men een speler probeert toe te voegen aan een andere spelsessie terwijl deze speler nog gekoppeld staat met een andere spelsessie dan krijgt men een waarschuwingsvenster waarin men een keuze kan maken om de aanpassing door te voeren of niet.

56 57 Thema s Thema's kunnen hier aangemaakt, aangepast en verwijderd worden. De administrator krijgt eerst een lijst te zien waaruit hij een keuze dient te maken indien hij een thema wil aanpassen. De administrator kan ook thema s verwijderen indien hij dit wenst. Inhoud Dit deel is het belangrijkste onderdeel, want hier wordt de inhoud die aan de speler wordt getoond aangemaakt met bijhorende filmpjes, geluidjes en afbeeldingen. Een administrator krijgt een lijst van inhoudsblokken te zien die hij kan aanpassen of verwijderen indien hij dit wenst. Een inhoudsblok behoort altijd tot een bepaald thema. Uit een lijst van thema s kan een administrator kiezen om het inhoudsblok hieraan te koppelen. Er is ook de mogelijkheid om een inhoudsblok aan meerdere thema s te koppelen.

57 58 Aan elk inhoudsblok kan een media fragment worden toegevoegd (video of afbeelding en geluidsfragment). Het bewaren van alle gegevens naar de databank gebeurt enkel wanneer er op de knop bewaren in het venster Inhoudsblok bewerken wordt geklikt. Verder kan een administrator ook een vraag toevoegen aan een inhoudsblok. Zo een vraag bestaat natuurlijk uit een vraag met verschillende antwoordmogelijkheden. Aan elk van deze onderdelen kunnen er geluidsfragmenten en afbeeldingen worden toegevoegd.

58 59 Resultaten De resultaten van de antwoorden die een speler heeft gegeven kunnen hier worden opgevraagd. De gebruiker krijgt eerst een scherm te zien waarin hij filters krijgt te zien die hij moet aanvullen. De gebruiker kan op verschillende onderdelen sorteren namelijk op sessie, datum en vraag. Wanneer de gebruiker op de knop Toon resultaten klikt krijgt hij een scherm te zien met 2 tabbladen. Op het eerste tabblad krijgt de gebruiker antwoorden te zien per sessie. Door op de checkboxen te klikken kan een gebruiker antwoorden verbergen. In het tabblad Scores kan een gebruiker de scores bekijken die een speler heeft gehaald tijdens het spelen van een spelsessie.

59 Spelletjes Een ander grote luik is de spelletjes die we maken. Evelien heeft als taak gekregen om een nieuw spel uit de grond te stampen terwijl Glenn en Jeroen bestaande spelletjes integreren in het project Spe-Ler Gebruikersanalyse Om te weten wat voor soort spelletjes we nodig hadden, heeft Evelien een gebruikersanalyse gedaan. Zij heeft onderzocht welke soort spelletjes de kinderen van het MPI in Oosterlo graag spelen. Verder heeft ze ook onderzocht hoe moeilijk of makkelijk een spel moet zijn. Dit onderzoeken heeft ze gedaan door bestaande spelletjes (ontwikkeld door leerlingen applicatieontwikkeling, ook van de vorige jaren) te laten spelen door de jongeren en dan een evaluatie op te stellen. De resultaten van het onderzoek werden per vraag geëvalueerd met een gemiddelde en een standaarddeviatie per spel. Deze resultaten zijn in een Excel document bijgehouden. Elk resultaat wordt gequoteerd op 5 punten, waarbij 5 het beste en 1 het slechtste resultaat voorstelde. Hieronder zijn afbeeldingen te zien die de gemiddeldes en de standaarddeviaties weergeven voor elk spel.

60 Spelletjes Na de gebruikersanalyse is gekozen om 1 spel te maken dat rekening houdt met de resultaten van het onderzoek. Er is dan gekozen om een 2D platform spelletje te maken en andere bestaande spelletjes te integreren in het Spe-Ler project. Je kan de platformspelletjes vergelijken met Super Mario Bross. Bij dit genre spelletjes moet een heel parcours worden afgelegd waarbij vijanden of obstakels moeten worden verslagen of ontweken worden en punten verzameld. Al deze spelletjes zijn opgebouwd met het XNA Framework. De structuur van deze spelletjes zijn ongeveer allemaal dezelfde: GameComponents In deze map komen alle klassen die iets voorstellen in een spel zoals de speler, obstakels, ballen, muren, HelpComponents Hierin zitten alle componenten die niet zichtbaar zijn voor de gebruiker. Een voorbeeld hiervan is bijvoorbeeld de klasse die ervoor zorgt dat er geluid kan worden afgespeeld. Verder is de belangrijkste help klasse de UserInteraction die ervoor zorgt dat spelletjes met de kinect kunnen worden gespeeld. GameScenes Dit zijn de verschillende schermen die een speler kan zien tijdens een spel. Deze schermen kunnen help schermen zijn, maar ook bijvoorbeeld het scherm waarop het menu staat. De belangrijkste is het scherm waarop het spel effectief wordt gespeeld. Managers Deze manager klassen zijn klassen die een collectie bijhouden van objecten. De manager klassen zullen ervoor zorgen voor de collectie van objecten die ze bijhouden de Update() en Draw() methodes worden opgeroepen. Game1 In dit game object worden de grafische componenten die op een scherm komen ingeladen. Verder heeft de Game1 een components collectie waaraan objecten worden toegevoegd zodat de Update() en Draw() methodes van deze objecten automatisch worden opgeroepen. De volgende spelletjes zullen gebruikt worden voor het MPI: BombSquad (door Evelien) Commander Keen (door Jeroen) BreakFree (door Glenn)

61 62 BombSquad Dit spel is een 2D spel gemaakt door Evelien Van Dingenen. Het doel van het spel is om een bom veilig aan de overkant te brengen. Deze bom ontploft na een bepaalde tijd maar ook wanneer de speler tegen een opstakel botst. Dus de speler loopt aan een constante snelheid (niet controleerbaar door de speler) over een veld, terwijl de speler obstakels ontwijkt kan deze ook bonusitems verzamelen. Deze bonusitems kunnen een extra leven bevatten, maar ook gewoon extra punten of meer tijd. De speler kan het level blijven herhalen tot zijn levens op zijn. De levels worden opgeslagen in een XML document. Deze kunnen met een tool die Evelien eveneens gemaakt heeft worden ingelezen, aangemaakt en bewerkt. Verder zijn er 3 moeilijkheidsgraden: easy, medium, hard. Hoe moeilijker de graad, hoe dichter de obstakels bij elkaar staan, wat meer anticipatie vermogen vraagt van de speler. Hieronder zijn 2 afbeeldingen te zien van het spel. Commander Keen Dit is een 2D spel gemaakt door Tim Lavrysen. Dit spel heeft Jeroen aangepast zodat het compatibel is met het nieuwe XNA 4.0 Framework. Verder heeft Jeroen ervoor gezorgd dat de UserInteraction (zorgt voor de werking met de kinect) en de GameInterface (zorgt voor de onderbrekingen) geïntegreerd werden met het spel. Dit spel is vergelijkbaar met het spel Super Mario Bross. Het doel is om aan een eindpunt te geraken in een level. Terwijl de speler naar het eindpunt vordert komt de speler monsters, obstakels, lava putten tegen. Deze kan de speler ontwijken of doodschieten met ninja sterren. Buiten allerlei monsters die de speler dood willen zijn er ook punten te verzamelen door ballonnen te verzamelen en beren. Er zijn ook extra levens te verkrijgen indien men het icoontje met het extra leven aanraakt. De speler heeft een beperkt aantal levens om een level uit te spelen. Hieronder zijn afbeeldingen te zien van het spel.

62 63 BreakFree Dit is een 3D spel gemaakt door Bart Mermans. Dit spel heeft Glenn aangepast zodat het compatibel is met het nieuwe XNA 4.0. Het omzetten naar het nieuwe Framework verliep niet van een leien dak. We hebben moeten zoeken naar oplossingen zodat het 3D tekenen van de objecten terug normaal gebeurde. Er zijn bij het veranderen een paar instellingen die expliciet moeten worden vermeld die in het 3.1 Framework automatisch gebeurden. Verder heeft Glenn ervoor gezorgd dat de UserInteraction (zorgt voor de werking met de kinect) en de GameInterface (zorgt voor de onderbrekingen) geïntegreerd werden met het spel. Het doel van het spel is om alle blokken die zichtbaar zijn kapot te maken met een bal. Het scherm doet dienst als paneel om de bal terug te kaatsen. Om het spel uit te spelen moeten alle blokken worden kapot gemaakt binnen de tijd. Sommige van deze blokken bevatten bonusitems. Er zijn 2 bonusitems aanwezig, een zandloper en een bal. De zandloper zorgt ervoor dat je meer tijd krijgt om het spel uit te spelen, terwijl de bal voor een extra bal in het spel zorgt zodat je sneller alle blokken kan kapot maken. Hieronder zijn afbeeldingen te zien van het spel.

63 Testen & Debuggen In alle programma s die worden gemaakt zitten bijna altijd nog fouten die op het eerste zicht niet worden opgemerkt. Dit was in ons project niet anders. Er zijn 2 momenten geweest waarin we het hele project echt hebben getest en fouten hebben opgelost. We hebben altijd wanneer we iets implementeerden geprobeerd om fouten eruit te halen door zelf het stuk dat geïmplementeerd was te testen. Wanneer dit stuk werkte konden we deze inchecken op de Team Foundation Server. Verder heeft onze stagebegeleider sporadisch onze implementatie gecontroleerd of er nog fouten inzaten. Wanneer hij fouten vond voegde hij deze toe aan een lijst met bugs. Als er bugs inzaten die snel konden worden opgelost werden deze ook opgelost. Zo hebben we gewerkt tot 2 weken voor de het weekend waarin we ons project hebben voorgesteld op de Europese Commissie en de opendeurdag van de K.H.Kempen Geel. Toen hebben we 2 weken bugs opgelost en de applicatie getest op fouten. Dit was nodig zodat we een fatsoenlijke demonstratie konden geven waarbij het programma niet zou crashen. Na de demonstraties hebben we verder nieuwe functionaliteiten geïmplementeerd. Toen alle functionaliteiten waren geïmplementeerd hebben we opnieuw een sessie gehouden om de hele applicatie te testen op fouten. Dit is gebeurd tijdens de laatste 2 weken van de stage voor de TI studenten. Deze fase liep nog 2 weken verder waarin de ICT studenten hebben verder getest en gedebugged. Hieronder kan u een afbeelding zien waarin duidelijk zichtbaar is hoe de bugs zich opstapelden en hoeveel bugs het hele team heeft opgelost. Er is duidelijk te zien dat er 2 fasen zijn geweest waarin bugs werden opgelost: rond 26 april en rond 19 mei. Verder is te zien dat vanaf 24 mei weer een sessie is gehouden om de applicatie te testen op fouten.

64 65 4 OPENDEURDAGEN We hebben de eer gekregen om ons project voor te stellen op 2 opendeurdagen: de opendeurdag van de Europese commissie (7 mei) in Brussel en die van de K.H.Kempen Geel (8 mei). Er is heel wat voorafgegaan om dit klaar te krijgen. Op het moment dat aan ons werd voorgesteld om dit te doen, hadden we nog maar heel weinig kunnen implementeren voor het project. Maar we zijn er als team voor gegaan om een goede presentatie te geven van het project. 4.1 Voorbereiding Om het project voor te stellen, moesten we eerst alles goed werkend krijgen. Daarom dat we een test en debug sessie hadden gehouden een week voor de voorbereidingen voor de opendeurdagen. Verder moesten we ook nog rekening houden met bepaalde vereisten om het project te mogen voorstellen op de Europese Commissie. Zo moest onze applicatie meertalig zijn, indien dit niet kon, was Engels het minimum. We hebben Nederlands, Frans en Engels voorzien voor de voorstelling van ons project. De filmfragmenten die in het Nederlands waren gesproken, zijn ondertiteld in het Frans en Engels. De vragen en antwoorden die een speler krijgt wanneer een spel onderbroken wordt, zijn ook vertaald naar het Frans en Engels. Deze vragen en antwoord waren ingesproken teksten. Het project moest ook voldoen aan privacy regels. Zo mochten we geen vragen stellen waarop het antwoord een mening is van de gebruiker omdat dit de privacy schendt van de gebruiker. Daarom hebben we ervoor gezorgd dat de knoppen die de antwoorden moesten voorstellen 3 figuren kregen: een cirkel, vierkant en een driehoek. De opstelling van ons project hebben we ook getest. Er was een lokaal gereserveerd in de school waar we onze opstelling konden testen. We hebben gewerkt met een backprojectie om de spelletjes op grote scherm te kunnen spelen. We hebben ook getest hoever ongeveer de speler moet verwijderd staan van de kinect zodat deze goed zou kunnen werken. Tijdens het testen van onze opstelling hebben we de kinderen van onze stagebegeleider laten spelen. We zijn tot de conclusie gekomen dat kinderen dichterbij moeten staan dan volwassenen zodat de kinect behoorlijk kon werken. De geluiden die gebruikt zijn voor de voorstellingen moesten allemaal worden bewerkt zodat deze beter klinken. Daar heeft Joan zich mee beziggehouden. De geluiden die zijn bewerkt zijn de geluiden van de filmfragmenten omdat deze in een slechte kwaliteit waren opgenomen.

65 Situering binnen E-Inclusion Op de Europese Commissie staan normaal gezien enkel Europees gesteunde projecten. De projecten die binnen E-Inclusion gebeuren zijn projecten die zich vooral bezighouden met de volgende vraag: Hoe kan iedereen genieten van de voordelen van ICT?. Dus projecten binnen E-Inclusion zullen proberen die groepen van de gemeenschap te stimuleren om ICT te gebruiken. Op deze manier zorgen deze projecten onder andere voor het volgende: Betere economische prestaties Meer kans op tewerkstelling Betere levenskwaliteit Deelname aan sociale activiteiten Ons project is geen Europees gesteund project, maar het leunt wel heel erg dicht aan bij E-Inclusion. Ons project probeert door middel van ICT jongeren met een verstandelijke handicap (afstand tussen hen en de samenleving is groot) leefregels aan te leren. Dat is ook de reden waarom we ons project mochten voorstellen op de Europese Commissie. 4.3 Nabeschouwing Terugkijkend op het weekend van de opendeurdagen kan worden besloten dat het een zeer geslaagde voorstelling was. Onze applicatie heeft zo goed als zonder fouten gelopen. De mensen die komen kijken zijn vonden het een leuk initiatief. Er waren ook mensen aangenaam verrast dat het project met zo weinig middelen toch zo goed in elkaar zat. We moesten de stand delen met nog 2 andere projecten namelijk Playmancer en Replay. Playmancer is een project waarbij mensen mentaal worden gestimuleerd. Replay is dan weer een project waarbij gewerkt wordt met probleemjongeren. Het project Spe-Ler leunt heel erg dicht aan bij Replay maar i.p.v. probleemsituaties voor probleemjongeren (zoals het stelen van voorwerpen) worden er in ons project gedragsregels aangeleerd. We hadden 2 plaatsen om voorstellingen te geven voor 3 projecten, dus was er een beurtrol opgemaakt. Het veranderen van de standen is zeer vlot verlopen. Het weekend is dus zeer goed verlopen en het is leuk om reacties te krijgen dat het werk dat we geleverd hebben geapprecieerd wordt.

66 67 BESLUIT. Dertien weken lang heb ik gewerkt aan een project waarbij jongeren leefregels leren door spelletjes te spelen. Ik heb een stukje software geschreven waarmee de Kinect kon worden aangesproken om zo spelletjes te spelen. Verder heb ik meegewerkt aan het ontwikkelen van de administratieomgeving. Met deze administreeromgeving kan geregeld worden welke filmpjes, vragen antwoorden een speler kan krijgen tijdens het spelen van een spelletje. Ik heb ook meegeholpen bij de integratie van bestaande spelletjes in het project zodat deze konden worden onderbroken maar ook konden worden gespeeld met de Kinect. Tot slot heb ik de software geschreven om spelletjes met de Kinect te spelen. Het project dat gemaakt is door het team wordt nu gebruikt op het MPI in Oosterlo. Het project was nog niet helemaal klaar toen deze in gebruik is genomen. Ik ben trots dat we als team een werkende omgeving hebben kunnen maken die gebruikt zal worden om jongeren verder te helpen. Dankzij de stage heb ik een eerste kennismaking gehad met het bedrijfsleven. Ik heb veel bijgeleerd op het vlak van programmeren. Maar dat niet alleen, ik heb ook leren werken in een team waarbij het resultaat van het hele team telt. Hetgeen dat mij het meeste is bijgebleven van mijn stage is de uitwerking van de software voor de Kinect. Dit was een grote uitdaging die mijn vaardigheden zwaar hebben getest. Tijdens mijn stage heb ik alle vaardigheden die ik heb geleerd gedurende mijn opleiding Toegepaste Informatica goed kunnen gebruiken. Dus mijn stage was een mooie afsluiter van mijn studie.

67 68 LITERATUURLIJST Allen, S. (sd). C# DataGridView Tips and Secrets. Opgeroepen op Maart 17, 2011, van Allen, S. (sd). C# Dictionary Examples, Keys and Values. Opgeroepen op April 8, 2011, van Allen, S. (sd). DataGridView Property Notes. Opgeroepen op Maart 23, 2011, van Eggheadcafe. (sd). Create datatable with specific columns type. Opgeroepen op Maart 18, 2011, van Hodnick, M. (sd). Basic cursor control with Kinect hand tracking in WPF. Opgeroepen op Maart 1, 2011, van blogs.inetium.com: Iconfinder. (sd). Iconfinder. Opgeroepen op Maart 17, 2011, van Microsoft. (sd). how to add a button in datatable. Opgeroepen op Maart 17, 2011, van social.msdn.microsoft.com: US/csharplanguage/thread/19fc666c-d5b dc1-cbb20b90f901 Microsoft. (sd). How to: Customize Data Formatting in the Windows Forms DataGridView Control. Opgeroepen op Maart 18, 2011, van msdn.microsoft.com: OpenNI. (sd). OpenNI. Opgeroepen op Februari 28, 2011, van wiki.openni.org: OpenNI. (sd). openni-dev. Opgeroepen op Februari 28, 2011, van groups.google.com: Pterneas, V. (sd). Kinect and WPF: Painting with Kinect using OpenNI. Opgeroepen op Maart 3, 2011, van Schwarz, J. (sd). Hacking Kinect with C# using OpenNI: Basic Depth Viewer. Opgeroepen op Maart 1, 2011, van Stackoverflow. (sd). How to disable a WinForms TreeView node checkbox? Opgeroepen op Maart 22, 2011, van stackoverflow.com: Studio, N. (sd). XNA 3.1 to XNA 4.0 Cheat Sheet. Opgeroepen op Maart 2, 2011, van unity3d. (sd). Need help Installing OpenNI to get the Kinect working. Opgeroepen op Maart 2, 2011, van forum.unity3d.com: Need-help-Installing-OpenNI-to-get-the-Kinect-working.

68 69 BIJLAGEN Bijlage 1 Spe-Ler

69 70