Combinatie met hartslagwaarden

Voor deze test werd de scorereeks, met gemiddeld constante scores, gecombineerd met de ge- middeld stijgende hartslagwaarden. Zoals eerder vermeld, wordt een minder steile stijging in moeilijkheidsgraad verwacht alsook een daling van de moeilijkheidsgraad wanneer de maximale hartslagwaarde overschreden wordt. In Figuur 7.5 is te zien dat het systeem anders reageerde wanneer ook simulatiehartslagwaarden gebruikt werden in plaats van de scorereeks alleen. In Figuur 7.5a is de geadapteerde moeilijkheid te zien in combinatie met de gemiddeld stijgende scores. Figuur 7.5b toont dezelfde geadapteerde moeilijkheid maar in combinatie met de stijgen- de hartslagwaarden. Zoals veracht, steeg de moeilijkheidsgraad minder vergeleken met de reeks

7.3. REALTIMELINESS 79 met contante scores zonder hartslagwaarden. Wanneer, bij de laatste twee spellen, de maximale hartslagwaarden van 180 BPM overschreden wordt, zakt de moeilijkheidsgraad sterk ook al blijft de score relatief constant.

7.3 Realtimeliness

Als eerste werd in het model van de adaptive engine een methode voorzien die toelaat de moeilijkheid van het spel in realtime aan te passen aan de hand van een hartslagwaarde. Er werd verwacht dat het systeem frequenter de moeilijkheidsgraad zou aanpassen wanneer de methode voor het realtime adapteren toegevoegd was. Inderdaad, in Figuur 7.6 is te zien dat, wanneer de hartslagwaarde het maximum voor de gebruiker benadert, er veel frequenter geadapteerd wordt. Figuur 7.6a toont de scores in combinatie met de geadapteerde moeilijkheidsgraad, terwijl Figuur 7.6b de hartslagwaarden toont in combinatie met de geadapteerde moeilijkheidsgraad. Ten gevolge van de steeds stijgende hartslagwaarden, daalt de moeilijkheidsgraad, met behulp van realtime adaptatie, sneller vergeleken met de niet-realtime adaptatie.

Om ervoor te zorgen dat realtime adaptiviteit effectief is, moet snel genoeg gereageerd worden door het systeem op een bepaalde spel- of persoonsgegevens. Deze responsetijd werd, zoals eerder vermeld, gemeten door gebruik te maken van het tag-veld van het uniform object. De tijd tussen het sturen van het gegeven en het interpreteren van de nieuwe opdracht kon zo gemeten worden. De antwoordtijd kan enkel gemeten worden wanneer er een antwoord van het systeem komt. Als eerste werden responsetijden voor offsite adaptatie met Kafka gemeten. In Figuur 7.7 is te zien hoe snel het systeem reageerde. Het eerste bericht duurde het langste, dit is wellicht omdat Kafka geïnitialiseerd dient te worden en hiervoor een connectie geopend moet worden. De zelfgemaakte implementatie van Kafka-bibliotheek, die in Sectie 5.1 vermeld werd, kan daarboven niet goed geoptimaliseerd zijn. Nadat het eerste bericht gestuurd is, ligt de gemiddelde responsetijd tussen de 4 en 10 milliseconden. Deze waarde zal afhankelijk zijn van hoe ver het pakket moet gestuurd worden en hoe complex de analyse in de adaptive engine is.

Ten tweede werd dezelfde snelheidstest uitgevoerd voor onsite adaptatie. Hier werd dus niet gewerkt met Kafka maar met het observer pattern. Omdat voor onsite adaptatie de program- meertaal dezelfde moet zijn als de taal waarin het Flappy Bird spel geschreven is, werd de

80 HOOFDSTUK 7. RESULTATEN EN DISCUSSIE

(a) Moeilijkheid (rechter y-as) in combinatie met gemiddeld constante scores (linker y-as)

(b) Moeilijkheid (rechter y-as) in combinatie met gemiddeld stijgende hart- slagwaarden (linker y-as)

Figuur 7.5: Geadapteerde moeilijkheidsgraden volgens de waarden van de gemiddeld stijgende scores (a) in combinatie met de stijgende hartslagen (b) in 30 gesimuleerde spellen

7.3. REALTIMELINESS 81

(a) Moeilijkheid (rechter y-as) in combinatie met gemiddeld constante scores (linker y-as)

(b) Moeilijkheid (rechter y-as) in combinatie met gemiddeld stijgende hart- slagwaarden (linker y-as)

Figuur 7.6: Geadapteerde moeilijkheidsgraden volgens de waarden van de gemiddeld stijgende scores (a) in combinatie met de stijgende hartslagwaarden (b) voor realtime adaptatie in 30 gesimuleerde spellen

82 HOOFDSTUK 7. RESULTATEN EN DISCUSSIE

Figuur 7.7: Responsetijden van het systeem (rechter y-as) voor realtime en offsite adaptatie van de moeilijkheid (linker y-as) gebruik makende van gemiddeld constante scores in combinatie met gemiddeld stijgende hartslagwaarden

architectuur in C# geschreven. Alle regels en modellen in de adaptive engine blijven dezelfde als in de Java-implementatie. Hierdoor zal het systeem dezelfde nieuwe moeilijkheden beslissen als bij de offsite adaptatie. In Figuur 7.8 wordt getoond hoe het systeem de moeilijkheid aan- paste en hoe snel dat gebeurde. Alle antwoorden liggen tussen de 0 en 1 milliseconden wat een significant verschil is vergeleken met de offsite adaptatie. Alles kan lokaal gebeuren en er is geen communicatie over het internet nodig. Gegevens moeten niet geserialiseerd en gedeserialiseerd worden, waardoor het spel sneller de nieuwe opdrachten ontvangt.

De volgende test zal uitgevoerd worden om na te gaan wat het systeem doet als drie of vijf ge- bruikers tegelijkertijd het spel spelen door respectievelijk drie en vijf instanties van de simulaties tegelijkertijd berichten te laten sturen. De simulaties sturen sneller dan werkelijk hun gegevens door naar het adaptief systeem waardoor de tijden tussen scores niet realistisch zijn. Het is wel een goede test om na te gaan hoe goed het systeem om kan gaan met grote hoeveelheden data en of zo een belasting veel vertraging van het realtime adapteren met zich meebrengt. Om initialisatie- en deïnitialisatietijden niet mee op te nemen in de gemiddelde tijden, worden van de resultaten telkens de eerste drie en laatste drie responsetijden weggelaten.

Zoals zichtbaar op Figuur 7.9, is er een duidelijk verschil merkbaar tussen onsite en offsite adaptatie. Voor onsite adaptatie blijft de gemiddelde tijd steeds onder de milliseconde. In het geval van offsite adaptatie ligt de gemiddelde responsetijd steeds boven de vijf milliseconden.

7.4. INVASIVITEIT VAN WIJZIGINGEN 83

Figuur 7.8: Responsetijden van het systeem (rechter y-as) voor realtime en onsite adaptatie van de moeilijkheid (linker y-as) gebruik makende van gemiddeld constante scores in combinatie met gemiddeld stijgende hartslagwaarden

Ook qua stijging is er een verschil merkbaar. De responsetijd van de onsite adaptatie stijgt met een constante hoeveelheid terwijl bij offsite adaptatie de responsetijd bijna een exponentiële trend vertoont.

7.4 Invasiviteit van wijzigingen

Voor deze test werd als eerste gemeten hoeveel van de originele code van het dinosaurusspel wijzigde wanneer de architectuur erin geïmplementeerd werd met behulp van het stappenplan. Om de architectuur in het spel te implementeren, moesten twee bestanden bijgewerkt worden. Het eerste bestand bevat de klasse waarin de score van het spel bijgehouden en verwerkt wordt. Hieraan moest de ISender interface aan toegevoegd worden zodat na elk spel de score naar de adaptive engine gestuurd kan worden. Aan de initiële 61 lijnen code, werden 20 lijnen code toegevoegd. Het grootste deel van deze nieuwe lijnen code is het implementeren van ISender interface. Het werkelijk sturen van de gegevens naar de adaptive engine kan echter gedaan worden in 1 lijn code (Send(score, ”score”)). Het tweede bestand bevat de snelheden van de dinosaurus. Hieraan werd een methode setMainSpeed toegevoegd, die toelaat om de snelheid van de dinosaurus te wijzigen. De interpreter die de opdrachten voor het spel interpreteert, zal deze methode oproepen wanneer die een opdracht van de adaptive engine ontvangt. De nieuwe methode voegde 5 lijnen toe aan een bestand van 25 lijnen code.

84 HOOFDSTUK 7. RESULTATEN EN DISCUSSIE

Figuur 7.9: Responsetijden van het systeem voor zowel realtime onsite adaptatie als realtime offsite adaptatie bij 1, 3 en 5 simultane spelers

In de volgende test werd gemeten hoeveel de implementatie van de architectuur in de Flappy Bird serious game de originele implementatie wijzigde. Hierbij werd ook gemeten op hoeveel componenten het toevoegen van de methode voor realtime adaptatie een impact had. Voor de implementatie van de architectuur in het Flappy Bird spel, worden de ISender en ITransformer interfaces in aparte bestanden geïmplementeerd. Hierdoor moet, buiten het initialiseren en het doorsturen van de gegevens, geen extra code toegevoegd worden. De architectuur voegt hierdoor voor het doorsturen van de gegevens slechts 8 lijnen code toe aan de GameController, die initieel 245 lijnen code telde. De methodes die toelaten op snelheden te wijzigen werden al voorzien en worden opgeroepen door de TaskInterpreter. Er moet voor het uitvoeren van methodes geen extra code toegevoegd worden in de GameController.