Invasiviteit van wijzigingen

De implementatie van de generieke architectuur in de serious game mag geen onnodige aan- passingen van de originele code van de game tot gevolg hebben. Ook wijzigingen in componenten van de architectuur moet zo weinig mogelijk invasieve wijzigingen in het spel en andere compo- nenten van de architectuur tot gevolg hebben. De hoeveelheid onnodige veranderingen in andere delen beperken, laat toe op een eenvoudige manier uitbreidingen en aanpassingen van de archi- tectuur te maken. Ook wanneer meer gegevens van het spel of van externe bronnen gebruikt willen worden, moet de toevoeging ervan eenvoudig kunnen gebeuren. Hetzelfde geldt voor an- dere methodes van adaptatie. Een methode moet uitgewisseld kunnen worden met een andere methode, met dezelfde soort gegevens, zonder hiervoor aanpassingen in het spel te hoeven doen. Om na te gaan in welke mate aanpassingen invasief zijn, wordt gemeten hoeveel van de originele code verandert wanneer de architectuur toegevoegd wordt. Ook wanneer wijzigingen aan metho- des voor adaptatie aangebracht worden, wordt gemeten hoe groot de impact van de wijziging op het volledige systeem is.

Implementatie van de architectuur in de dinosaurusgame

In de eerste test werd het dinosaurusspel adaptief en gepersonaliseerd gemaakt door de archi- tectuur erin te implementeren. Als eerste, zal gemeten worden hoeveel van de originele code van het spel wijzigde. Nieuwe bestanden die aangemaakt werden wanneer de architectuur geïmple- menteerd werd, tellen hier niet mee. Ze bevatten toch enkel implementaties van interfaces en geen code van het spel. Enkel de bestanden die aanwezig waren in het originele spel zullen hier bijgevolg onderzocht worden.

70 HOOFDSTUK 6. EVALUATIE

Implementatie van de architectuur in Flappy Bird

De architectuur werd ook in de Flappy Bird serious game geïmplementeerd. Het verschil met het dinosauruspel is dat hier offsite adaptatie aan de orde is. Opnieuw zal gemeten worden hoeveel van het spel zonder de architectuur wijzigde. Bij de test van de realtimeliness van het systeem werd een nieuwe methode toegevoegd aan het systeem waardoor, in plaats van enkel offline score en hartslagen te analyseren, ook realtime hartslagen geanalyseerd kunnen worden. Opnieuw zal de vergelijking gemaakt worden. Hoeveel componenten wijzigden wanneer aan het model van de adaptive engine een methode toegevoegd werd waarmee realtime adaptatie mogelijk was?

6.3 Conclusie

De architectuur zal getest worden op zowel functionele als niet-functionele vereisten. Er wordt gekeken naar hoe goed de architectuur de moeilijkheid aanpast en of dit snel genoeg gebeurt. Voor deze testen zal geen gebruik gemaakt worden van testpersonen, maar zal met behulp van simulatiegegevens gewerkt worden. Dit laat toe om eenvoudig te bepalen wat er van het systeem verwacht wordt. In het volgende hoofdstuk worden de resultaten van deze testen besproken.

7

Resultaten en discussie

In dit hoofdstuk worden de resultaten van de testen uit Hoofdstuk 6 besproken. Als eerste worden de games, die geïmplementeerd werden door gebruik te maken van het stappenplan, geëvalueerd. Vervolgens worden nieuwe moeilijkheidswaarden, die gegenereerd werden door het systeem als reactie op de simulatiewaarden, vergeleken met de verwachtingen gelinkt aan de simulatiewaarden. Verder wordt naar de reactietijden van het systeem gekeken om hieruit de realtimeliness van het systeem te evalueren. Als laatste wordt onderzocht hoeveel wijzigingen aan het originele spel een implementatie van het systeem vereist alsook hoeveel wijzigingen in het systeem nodig zijn om een andere adaptatietechniek te gebruiken.

72 HOOFDSTUK 7. RESULTATEN EN DISCUSSIE

7.1 Integratie van het systeem met een serious game

In deze sectie worden de stappen besproken, die genomen werden om de architectuur in het dinosaurusspel te implementeren. Hiervoor werd het stappenplan gebruikt dat te vinden is in Bijlage A. Voor elke stap in het stappenplan wordt besproken hoe deze uitgevoerd werd voor het dinosaurusspel.

Stap 1 De eerste stap is om de bruikbare gegevens van het spel te selecteren. Voor deze

implementatie zullen enkel de scores van de vorige spelsessies gebruikt worden voor adaptatie.

Stap 2 De tweede stap is om de adaptatiemogelijkheden, die gebruikt zullen worden, te selec-

teren. Voor deze implementatie werd beslist om onsite adaptatie te gebruiken en voor analyse gebruik te maken van een eenvoudig regelgebaseerd model.

Stap 3 De volgende stap is om de opdrachten, die de adaptive engine kan gebruiken voor

adaptatie, te selecteren. Voor deze implementatie werd bijgevolg een methode setMainSpeed in de Level-klasse voorzien, die toelaat om de snelheid van de dinosaurus in te stellen. Hoe sneller de dinosaurus loopt, hoe moeilijker het wordt om de obstakels te ontwijken.

Stap 4 Nadat de methodes geselecteerd zijn, moet het uniform object bepaald worden. Zo-

als het stappenplan aanraadt, zal het voorgestelde uniform object uit het stappenplan gebruikt worden. Dit uniform object is te zien in Listing 7.1.

1 class UnifObject {

2 public Object Content; 3 public String ContentType; 4 public UnifObjectType type; 5 public String Tag;

6 }

Listing 7.1: Het gebruikte uniform object voor de implementatie van het systeem in het dinosaurusspel

7.1. INTEGRATIE VAN HET SYSTEEM MET EEN SERIOUS GAME 73

Stap 5 De volgende stap is om ervoor te zorgen dat het spel de score naar het systeem kan

sturen. Omdat onsite adaptatie gebruikt wordt, is geen transformatie van de gegevens nodig. Als eerste werd de interface ISender<T, V> toegevoegd aan de bestanden van het spel. Hierna werd deze interface geïmplementeerd in de Scores-klasse van het spel. Het is immers in deze klasse dat de scores van de speler verwerkt worden. De templateparameters voor de ISender interface zijn respectievelijk van het type Number en het type String. De score wordt als een Number voorgesteld en om de score te beschrijven wordt een String gebruikt. Er werd een lijst voorzien in de klasse waaraan ontvangers toegevoegd kunnen worden via de methodes van de ISender- interface. Elke keer de gebruiker tegen een obstakel botst, wordt de score met de Send-methode in het systeem gestuurd.

Stap 6 In stap 6 dienen de eerste interpreters geïmplementeerd te worden. Aangezien enkel

de score gebruikt wordt, wordt enkel een interpreter voor de score voorzien. Als eerste werd de

IReceiver<T> interface toegevoegd aan de bestanden van het spel waarna deze in een nieuwe

klasse genaamd ScoreInterpreter geïmplementeerd werd. De templateparameter voor de receiver is hier van het type Number, omdat de score van dit type is. Omdat maar één instantie van de ScoreInterpreter nodig is, werd hiervan een Singleton gemaakt. Vervolgens werd de IInter-

preter<T> interface aan de bestanden toegevoegd en in de ScoreInterpreter geïmplementeerd.

Hier wordt, na het ontvangen van een nieuwe score uit de Receive-methode, de waarde van de score verpakt in een uniform object. Als laatste moest het uniform object naar de integrator gestuurd worden waardoor de ISender interface in de ScoreInterpreter geïmplementeerd werd. De templateparameters van de ISender interface zijn hier respectievelijk van de types UnifObject en UnifObjectType, omdat de ScoreInterpreter uniforme objecten maakt en doorstuurt.

Stap 7 In stap 7 dient de integrator geïmplementeerd te worden. Hiervoor werd een nieuwe

klasse DataIntegrator voorzien. Daarboven werd de interface IIntegrator<T> toegevoegd aan de bestanden van het spel. De DataIntegrator moet gegevens van de interpreters ontvangen dus de

IReceiver interface werd hierin geïmplementeerd waarna de interface IIntegrator geïmplemen-

teerd werd. De templateparameters voor deze twee interfaces zijn in de DataIntegrator beiden van het type UnifObject. Ook de DataIntegrator werd als een Singleton geïmplementeerd, omdat hier steeds maar één instantie van hoeft te zijn.

74 HOOFDSTUK 7. RESULTATEN EN DISCUSSIE

Stap 8 De volgende stap is om de adaptive engine en de bijhorende modellen te implementeren.

Als eerste werd een model TaskModel voorzien, die de score van de speler zal gebruiken om nieuwe opdrachten voor het spel te genereren. Hierin werd de interface IAdaptiveEngineModel<T> met de templateparameter van het type UnifObject geïmplementeerd. De score van de gebruiker kan in dit model verwerkt worden in de methode HandleScore. Vervolgens werd in het nieuwe bestand AdaptiveEngine de interface IAdaptiveEngine<T>, met templateparameter van het type

UnifObject, geïmplementeerd. Het TaskModel werd toegevoegd aan deze adaptive engine en er

werd een operatie ProcessScore voorzien die opgeroepen zal worden in de Push-methode van de DataIntegrator. In de ProcessScore-methode wordt het TaskModel van de adaptive engine geselecteerd en wordt de HandleScore-methode uitgevoerd. De adaptive engine is ook hier een

Singleton omdat hier maar één instantie van nodig is.

Stap 9 In stap negen moet de interpreter, die de nieuwe opdrachten van het spel interpreteert,

geïmplementeerd worden. Er werd voor deze implementatie een singletonklasse TaskInterpreter voorzien. Hierin werden de interfaces IReceiver en IInterpreter geïmplementeerd. Nadat nieuwe opdrachten ontvangen worden, zal de Interpret-methode ervoor zorgen dat de eerder geselec- teerde opdracht setMainSpeed uitgevoerd zal worden in de Level-klasse van het spel.

Nadat alle componenten die moeten communiceren met elkaar geregistreerd waren bij elkaar, werd het spel met de architectuur getest door enkele spellen te spelen. De startsnelheid van het dinosaurusspel werd op 10 gezet. Zoals verwacht paste het spel de moeilijkheid aan afhankelijk van de eerder behaalde scores. Wanneer lagere scores gedetecteerd werden, werd het spel makke- lijker gemaakt. Wanneer de speler beter presteerde, werd de moeilijkheid van het spel verhoogd. Bij spel 3 veranderde de architectuur de moeilijkheidsgraad niet. De adaptive engine registreerde een betere score maar wachtte nog een spel vooraleer het spel moeilijker te maken. De resultaten van zes gespeelde spellen zijn te zien in Tabel 7.1. De serious game werd dus adaptief gemaakt door, aan de hand van het stappenplan, de architectuur erin te implementeren. De hoeveelheid wijzigingen die hiervoor in het spel aangebracht moesten worden, wordt besproken in Sectie 7.4.