Afstudeerverslag. Interactive Storytelling System. november 2013

Transcriptie

1 Interactive Storytelling System november 2013 Versie: 1.0 Opdrachtgever: T-Xchange Bedrijfsbegeleider: Dhr. T. de Groot Schoolinstelling: Hogeschool Saxion te Enschede Opleiding: Informatica Afstudeerbegeleider: Dhr. P. de Groot Afstudeerder: S.H. van der Poel (134018)

2 Voorwoord Het Interactive Storytelling System (ISS) is een uitbreiding op de serious game van T-Xchange genaamd Strategic Decision Making Game (SDMGame), een game waarbij de speler dilemma s moet beantwoorden. De uitbreidingen die het ISS biedt voor de SDMGame zijn onder andere niet-lineaire verhaallijnen, multiplayer en replay functionaliteit. Het ISS is gerealiseerd als afstudeerproject voor de HBO opleiding Informatica van Hogeschool Saxion te Enschede. Ik dank Paul de Groot voor de begeleiding tijdens dit project, T-Xchange voor het aanbieden van een afstudeerplek en Thomas de Groot voor de technische begeleiding. Het was zeer interessant om een kijkje te nemen achter serious games. Ook wil ik mijn collega s bij T-Xchange bedanken voor de gezellige werksfeer. ~ 1 / 47 ~

3 Inhoudsopgave Voorwoord... 1 Samenvatting Inleiding Achtergrond Doelstelling Opbouw Methode Resultaten Onderzoek Software Documenten en Handleidingen Publicatie Kwaliteitsbehoud Discussie Conclusie Conclusie Aanbevelingen Ontvangstneming Terminologie Bronnen Bijlagen Bijlage A Projectdossier Bijlage B Systeemdossier ~ 2 / 47 ~

4 Samenvatting T-Xchange is een bedrijf dat action research uitvoert op het gebied van met serious games. Serious games zijn spellen met als doel niet alleen te entertainen maar ook iets anders te bereiken. Dit kan bijvoorbeeld zijn om de speler ervaring op te doen met bepaalde situaties. Eén zo n game is de Strategic Decision Making Game. Deze singleplayer game is gericht op een speler die in een rol zich moet trainen in een bepaalde situatie, de speler moet onder tijdsdruk, wel overwogen keuzes maken in een crisis situatie. In de game krijgt de speler virtueel ervaring met een realistisch scenario. Deze game wordt vooral gebruikt door overheidsinstanties voor het trainen van ambtenaren met scenario s die niet vaak voorkomen, maar wel een grote impact kunnen hebben. Een scenario verhaallijn binnen de SDM Game is op dit moment nog erg lineair, tijdens het spel hebben de acties van de speler geen consequenties op de verhaallijn. Alle vooraf gedefinieerde dilemma s worden alleen getoond op basis van tijd. T-Xchange wil nu kunnen experimenteren met scenario s waarbij de keuzes van de speler invloed hebben op het verdere verloop van het spelverhaal. Het ISS is een uitbreiding die het mogelijk maakt voor T-Xchange om te experimenteren met een aantal adaptieve spelmechanieken en verhaallijnen. Scenario s kunnen nu worden gespeeld in de SDM Game waarbij het verhaal wel afhangt van de keuzes van de spelers, zo worden bepaalde dilemma s alleen getoond als in een vorig dilemma een bepaalde keuze is gemaakt, of als een virtueel karakter boos is. Daarnaast is deze uitbreiding zo gemaakt dat in de toekomst, T-Xchange zijn eigen spelmechanieken kan toepassen op de SDM Game. De SDM Game kan nu ook in multiplayer worden gespeeld, wat een nieuwe dimensie geeft aan serious games. Ook wordt nu alle progressie die een speler maakt in een (niet-lineair) scenario opgeslagen op de server. T-Xchange kan hiermee dataminen en gedragspatronen vinden in hoe spelers nou eigenlijk een scenario spelen. Met deze informatie kan T-Xchange strategische keuzes maken voor bijvoorbeeld toekomstige spellen. Afsluitend brengt het ISS ook nog een analyse tool met zich mee. Deze tool tekent een boomgraaf op basis van een nieuw niet-lineaire scenario. Met deze tool kan ook live een game worden gevolgd, het kleurt het pad in de graaf in met kleuren. Dit project is uitgevoerd binnen een afstudeerproject voor de opleiding Informatica van Hogeschool Saxion te Enschede. Het was een full-time eenmansproject voor 5 maanden. In dit document wordt verslag gelegd wat dit project heeft bereikt en hoe het is aangepakt. ~ 3 / 47 ~

5 1. Inleiding 1.1 Achtergrond T-Xchange is een gezamenlijke onderneming tussen Thales Nederland B.V. en Universiteit Twente. T-Xchange ontwikkelt serious games voor de publieke en private sector en richt zich daarnaast op onderzoek op het gebied van serious games en de toepassing ervan. Serious games focussen zich in het algemeen op het trainen van de speler in het omgaan in realistische situaties. Zo n situatie wordt realistischer naarmate de keuzes en acties van de speler ook echt invloed hebben op de situatie. T-Xchange heeft de wens dat het voor hen mogelijk is om hierin te experimenteren en wenst daarvoor een infrastructuur. Een belangrijk product van T-Xchange is de Strategic Decision Making Game Suite (SDMGameSuite of SDMGame). Met deze suite laat T-Xchange verscheidene types personen trainen om te gaan met specifieke scenario s die in hun rolgebied kunnen voorkomen. Een voorbeeld hiervan is de burgemeester die beslissingen moet maken tijdens een potentiele natuurramp in zijn gemeente. Als een speler een scenario begint te spelen, krijgt hij te maken met dilemma s. Deze dilemma s bevatten een vraag en de speler moet deze vraag beantwoorden met een JA of NEE. De speler wordt in zijn rol ondersteund door virtuele adviseurs, zij geven hun mening over de dilemma s via advies (positief of negatief) of door informatie te geven. Zie figuur 1 voor een grafische weergave van de interface van een SDM Game. Figuur 1: Interface van een SDM Game, waarbij de verschillende onderdelen van het scherm zijn gemarkeerd. Wanneer de speler een dilemma heeft beantwoord, kan hij deze keuze niet corrigeren. Wanneer alle dilemma s zijn beantwoord wordt het spel beëindigd. Ook als de speler geen tijd meer over heeft eindigt het spel. In het spel kan de speler geen goed of slecht antwoord geven. Aan het einde van het spel krijgt de speler feedback en kan hij op zijn gemaakte keuzes reflecteren, eventueel samen met anderen. ~ 4 / 47 ~

6 1.2 Doelstelling De doelstelling luidt: Er moet een infrastructuur worden opgezet voor experimenten rond adaptieve spelmechanieken en verhaallijnen. Op het moment ondersteunt de SDM Game Suite alleen lineaire verhaallijnen. Dit houdt in dat de keuzes van de spelers geen invloed hebben op het verloop van het verhaal. T-Xchange kreeg regelmatig de vraag van (potentiele) afnemers of speler keuzes ook van invloed kunnen zijn op het verloop van het verhaal. Het verhaal houdt bij de SDM Game in de volgorde van de dilemma s die de speler tegenkomt. Er moet hiervoor een infrastructuur komen waarmee geëxperimenteerd kan worden met adaptieve spelmechanieken en verhaallijnen. Om vrijheid te geven in de mogelijkheden voor adaptieve spelmechanieken, wil T-Xchange de SDM Game Suite cliënt een zogenoemde thin client maken. Dit houdt in dat de cliënt niet de game logica beheert, maar alleen zorgt voor het tonen van de grafische interface en het afhandelen van user input. Een server moet in dat geval de game logica bij gaan houden. De game logica is de game state en de veranderingen aan de game state. Een verandering in de game wereld wordt dus uitgevoerd door de server. Een reactie op een actie die de speler uitvoert, wordt behandeld door de server en het resultaat ervan teruggestuurd naar de cliënt die er een grafische weergave van maakt. Met een server module die bepaald hoe een verhaal in een game verloopt, wordt het mogelijk verschillende types server modules te maken zodat daar meer geëxperimenteerd kan worden. Voorbeelden van wat mogelijk gemaakt dient te worden: 1. Een verhaal waarbij het verloop afhangt van de keuzes van de speler, waarbij alles vooraf gedefinieerd is door de schrijver van het verhaal 2. Een verhaal waarbij het verloop afhangt van de keuzes van de speler, waarbij niet alles vooraf is gedefinieerd. In plaats daarvan, is er een AI die zelf keuzes kan maken T-Xchange wilt punt 1 van de voorbeelden hierboven gerealiseerd zien voor de SDM Game Suite. Met de infrastructuur die dit zal brengen, zal het voor T-Xchange mogelijk worden om punt 2 redelijk eenvoudig ook te kunnen implementeren voor de SDM Game Suite. Punt 2 is voor T-Xchange interessant omdat er ook wordt gewerkt aan de Virtual Storyteller in samenwerking met de Universiteit Twente. De Virtual Storyteller kan automatisch verhalen schrijven en maakt het mogelijk te experimenteren met AI. De cliënt server communicatie moet via een Message Broker verlopen, zodat nieuwe modules gemakkelijk kunnen worden gekoppeld aan het bestaande systeem. ~ 5 / 47 ~

7 Het Interactive Storytelling System (ISS) is de uitbreiding voor de SDM Game Suite. De uitbreidingen zijn onder andere: - De SDM Game Suite cliënt een thin client maken - Het vervangende server onderdeel ontwikkelen - De communicatie tussen cliënt en server via de Message Broker laten verlopen - Ondersteuning voor een verhaallijn waarbij de keuzes van de speler invloed hebben op het verloop van het verhaal - Toepassingen ontwikkelen voor onderzoek en analyse ten behoeve van experimenteren met de nieuwe mogelijkheden Het gebruik van een thin client impliceert dat de game logic aan de server kant zit. Op deze manier hoeft niet perse alleen de SDM Game Suite cliënt te communiceren met de server, maar zou het net zo goed mogelijk zijn voor een andere cliënt om te communiceren met de ISS server. Dit geeft betere flexibiliteit in de mogelijkheid om verschillende User Interfaces (UI) te kunnen koppelen aan de ISS. Omdat de cliënt server communicatie zal verlopen over een algemene Message Broker, wordt het mogelijk om meerdere cliënts mee te laten participeren in dezelfde game en om alle communicatie te loggen, en deze later opnieuw af te laten spelen. Op deze manier kan er replay functionaliteit gerealiseerd worden. De vervangende server onderdelen zijn onder andere: - Systeem o Houdt actieve games bij o Haalt op aanvraag van een cliënt de beschikbare speelbare scenario s op o Haalt op aanvraag van een cliënt de beschikbare replays op o Start op aanvraag een game of replay - Game manager o Houdt de state van de game bij o Past de state van de game aan naar aanleiding van verlopen tijd of user input De Message Broker regelt communicatie tussen processen die geabonneerd zijn op een topic. Een proces dat zich abonneert op een topic om te luisteren heet een subscriber. Een subscriber ontvangt alle berichten die zijn verstuurt naar dat topic door een publisher. Een subscriber kan op basis van bepaalde criteria, berichten filteren zodat het niet ongewenste data ontvangt. ~ 6 / 47 ~

8 Overige uitbreidingen die mogelijk worden gemaakt met dit nieuwe systeem: - Multiplayer o Meerdere cliënt(s) kunnen meeluisteren via hetzelfde topic op de Message Broker - Replay functionaliteit o Communicatie tussen cliënt en server wordt gelogd en kan later opnieuw worden afgespeeld via de Message Broker door de server - Live analyse o Ten behoeve van onderzoek en analyse kan een cliënt ontwikkeld worden die een scenario visueel weergeeft als een graaf. Deze cliënt kan live mee luisteren op een topic op de Message Broker Al deze uitbreidingen zijn extra en geen onderdeel van de originele projectopdracht maar passen goed bij het algemene doel van experimenteren met verschillende spelmechanieken in de SDM Game Suite. Het project is Interactive Storytelling System (ISS) genoemd. Storytelling System omdat er een verhaallijn systeem ontwikkeld wordt voor de SDMGame, Interactive omdat er minstens 1 verhaallijn systeem zal worden gerealiseerd waarbij keuzes invloed hebben op de verhaallijn. De SDMGame bestaat uit een cliënt en server kant. De cliënt kant is geschreven in de programmeertaal Action Script 3 onder het Flex Framework. De server kant is geschreven in de programmeertaal Java. De IDE (Integrated Development Environment) die wordt gebruik is Eclipse. Voor versiebeheer wordt SVN (Subversion) gebruikt. 1.3 Opbouw In dit verslag wordt het verloop van het project Interactive Storytelling System (ISS) beschreven. Het ISS is een software uitbreiding op een serious game van T-Xchange, meer informatie over de achtergrond van T-Xchange en de betreffende game is te vinden in het hoofdstuk Achtergrond. De doelstelling van de uitbreiding is te vinden in het hoofdstuk Doelstelling. De projectaanpak van deze software uitbreiding is beschreven in het hoofdstuk Methode. Tijdens dit project heeft er naast het realiseren van de software uitbreiding, ook een onderzoek plaatsgevonden. De resultaten van het onderzoek, de software uitbreiding, documenten en kwaliteitsbehoud zijn beschreven in het hoofdstuk Resultaten. Aan het eind van het hoofdstuk Resultaten wordt er kort gediscussieerd over het gerealiseerde systeem. Het document sluit af met een conclusie en aanbeveling. Bij dit document horen bijlagen. Dit zijn de projectdossier en het systeemdossier. Naar deze bijlagen wordt gerefereerd binnen dit document. De locaties van deze bijlagen worden omschreven in het hoofdstuk Bijlagen. ~ 7 / 47 ~

9 2. Methode De geplande methode is Scrum. Scrum is een projectmanagement methode, waarbij gewerkt wordt in team die in korte sprints werkende (deel)producten opleveren. Scrum heeft als doelstelling het verhogen van de effectiviteit binnen een team, het bewaken van de voortgang, snel signaleren van problemen en het in kaart brengen van de risico s die kunnen optreden tijdens een project. Figuur 2: Proces van een Scrum project Bij een Scrum project wordt gewerkt in sprints die elke twee tot vier weken duren. Vooraf een sprint wordt gepland welke taken in die sprint zullen worden gerealiseerd en door wie, de Sprint Backlog. Elke dag wordt de voortgang van ieder teamlid besproken, de Daily Standup. In de Product Backlog staan alle taken geprioriteerd die het team in het volledige project wil realiseren, en kan tijdens het project worden aangevuld. De sprint bestaat uit taken uit de product backlog. Taken van een Product Backlog worden User Stories genoemd, met een User Story geef je een gewenste functionaliteit aan vanuit het perspectief van een eindgebruiker. Een werkend product wordt aan het eind van een increment afgeleverd, een increment bestaat uit vooraf bepaald aantal sprints. Een Product Owner houdt de voortgang officieel bij. Voor de projectmanagement van het ISS is een spin-off van Scrum gebruikt. In het ISS was er i.p.v. een Sprint Backlog een groeiende Requirements lijst. Er was een wekelijkse planning i.p.v. een Sprint Backlog. Er was geen dagelijkse Daily Scrum Meeting omdat het ISS een eenmansproject is. Er werd gewerkt met increment waarbij aan het einde van elke increment een significant onderdeel van het ISS is afgerond. In plaats van een Product Backlog, is een Requirements lijst bijgehouden. Dit was de voorkeur want van User Stories was minder sprake: het ISS is een uitbreiding op het onderliggende systeem van de SDMGame. Alhoewel de uitbreidingen ook invloed hebben op de functionaliteit, is van User Stories ~ 8 / 47 ~

10 toch minder sprake. De Requirements zijn opgesteld volgens het MoSCoW principe. Met het MoSCoW principe prioriteer je de Requirements door ze te karakteriseren als, respectievelijk van hoge naar lage prioriteit: Must, Should, Could, Won t. Must Requirements moeten worden afgerond om het project als geslaagd te markeren. Should Requirements zouden moeten worden afgerond, maar als ze niet zijn afgerond betekent dat niet perse van falen van het project. Could Requirements zouden kunnen worden afgerond als er nog tijd over is. Won t Requirements zullen niet aan worden gewerkt maar zijn wel interessant om te noteren. Tijdens het project zijn een aantal globalere planningen gemaakt met deadlines. Halverwege het project waren alle Must Requirements afgerond, en werden er Should Requirements toegevoegd aan het project in overleg met de bedrijfsbegeleider. Het was eigenlijk al vroeg voor de afstudeerder duidelijk dat er meer dan de originele Requirements zou worden gerealiseerd, en dat er dus van extra uitbreidingen sprake zou zijn. Het principe van minder beloven en meer leveren, heet het under promise, over deliver management principe. In dit principe, beloof je de klant minder, maar lever je uiteindelijk meer (zoals bijvoorbeeld sneller, extra s of onder budget). Op deze manier krijgt de klant een hogere tevredenheid. Zolang je voorkomt dat de klant steeds meer gaat verwachten, kun je een goede klantrelatie behouden. Nou moet er gezegd worden dat bij dit project niet vooraf bewust dit principe was toegepast: dit principe kwam pas naar boven nadat alle Must Requirements waren afgerond en er moest worden gezocht (ten behoeve van dit verslag) naar een benoeming van de situatie. In plaats van een Sprint Backlog is er een weekplanning bijgehouden. Dit omdat er niet in teamverband is gewerkt, en een Sprint Backlog vooral handig is voor een team om de progressie van andere teamleden en van het team in het algemeen bij te houden. Mijn progressie is bijgehouden door middel van het afstrepen van de Requirements. Daarnaast was er elke week een voortgangsgesprek met de begeleider, waarbij van afgeronde taken gelijk een demo werd gegeven, en eventuele commentaar gelijk werd verwerkt in de planning. Het principe van increments werd toegepast door aan het eind van elke increment een significant onderdeel van het ISS af te ronden. De volgende increments zijn aanwezig geweest tijdens het ISS project: 1. Basis voor onderliggende Message Broker systeem voor de SDMGame met bijbehoren 2. De Server module die een niet-lineair verhaallijn afspeelt via de Message Broker 3. Extra: multiplayer functionaliteit 4. Extra: replay functionaliteit 5. Extra: live graaf analyzer Niet elke increment duurde even lang. De eerste increment duurde het langst vanwege dat tijdens die increment ook de huidige code van de SDMGame moest worden geleerd. ~ 9 / 47 ~

11 3. Resultaten In dit hoofdstuk komen de resultaten van het onderzoek, de verschillende gerealiseerde software onderdelen en het kwaliteitsbehoud van de onderdelen naar voren. 3.1 Onderzoek Als onderdeel van het ISS project is er een onderzoek uitgevoerd. Het doel van dit onderzoek was het beantwoorden van een aantal vragen waar de afstudeerder nog geen antwoord op had voorafgaand dit project. De hoofdvraag luidt: Hoe kan de server software van de SDMGameSuite het beste worden aangepast, zodat deze ondersteuning biedt voor niet-lineaire verhaallijnen? Dit is een redelijk algemene vraag. Het doel van deze hoofdvraag is vooral dat het alle deelvragen moest sommeren: de deelvragen is waar het echt om gaat in dit onderzoek. Dit hoofdstuk is onderverdeeld in vijf deelvragen. Bij dit hoofdstuk hoort het onderzoeksrapport, te vinden in Bijlage B Systeemdossier. In deze bijlage kan achtergrondinformatie met betrekking tot het onderzoek gevonden worden. Het onderzoek is tijdens het project uitgevoerd, voorafgaand implementatie van de verschillende onderdelen. De deelvragen zijn chronologisch geordend, dus deelvraag 1 is als eerste onderzocht. De laatste deelvraag is tijdens het project erbij gekomen, en stond niet in het Plan van Aanpak Eerste deelvraag Wat is de beste structuur en protocol voor de berichten die zullen worden verstuurd via een Message Broker? Omdat het uit de opdrachtomschrijving al duidelijk was dat een Message Broker gebruikt zou gaan worden, moest er worden onderzocht welke dat zou worden en hoe deze zou worden gaan gebruikt. Voor de Message Broker en Protocol zijn al bestaande implementaties ontwikkeld door derde partijen. Met deze onderzoeksvraag wilden we te weten komen welke daarvan het beste voldoet aan de criteria van het ISS. Met deze vraag werd beantwoord: Welke Message Broker zal worden gebruikt Criteria: de Message Broker ondersteunt meerdere Message Protocollen op hetzelfde topic en de Message Broker moet bereikbaar zijn via een Tomcat webservlet Welke Message Protocol zal worden gebruikt Criteria: de Message Protocol heeft een implementatie library voor Java en is tekstueel i.p.v. binair Welk Message Structuur zal worden gebruikt Criteria: de Message Structuur moet tekst-gebaseerd zijn, positie-onafhankelijk, interoperabiliteit zijn, een simpele structuur hebben en de snelheid van het parsen moet z.s.m. zijn Deze deelvraag is aangepakt door te testen en het gebruikt van internet bronnen. ~ 10 / 47 ~

12 Zie figuur 3 voor het concept achter een Message Broker systeem. Figuur 3: Concept proces communicatie via een Message Broker De Message Broker is een server applicatie die altijd draait. Deze beheert de topics waarover processen met elkaar communiceren en zorgt ervoor dat berichten over zijn topics naar de juiste abonnees wordt verstuurd. Apollo had de voorkeur van de opdrachtgever. In het onderzoek kwamen zowel ActiveMQ als RabbitMQ het beste naar voren, maar werd uiteindelijk door de opdrachtgever voor ActiveMQ gekozen omdat het daarmee al ervaring had. Apollo werd niet gekozen vanwege het feit dat het een functionaliteit mistte die nodig is: rich transition tussen verschillende Message Protocols. Rich transition is dat de Message Broker ervoor zorgt dat berichten die zijn verstuurd over een ander protocol dan dat het wordt ontvangt, op de juiste manier worden omgezet door de Message Broker zodat er geen fouten ontstaan. Een Message Protocol is het protocol voor data dat heen en weer gestuurd wordt tussen een proces en de Message Broker. Een Message Broker heeft maar een beperkt aantal Message Protocols dat het ondersteund. De opdrachtgever had een voorkeur voor het STOMP protocol. Dit is een tekstbased protocol. Een tekst-based protocol is makkelijker te ontwikkelen in programmeertalen, zoals Javascript, die moeilijk omgaan met binaire data. Op ActiveMQ maakt het niet uit of een subscriber STOMP gebruikt en een publisher OpenWire (een ander protocol) gebruikt als Message Protocol. Het maakt dus in principe niet uit voor het ISS welke Message Protocol zou worden gebruikt. Toch is gekozen voor STOMP vanwege de randvoorwaarde van de opdracht. Reden van die randvoorwaarde is dat het T-Xchange ook met Javascript wilt werken. Het Message Structuur is de structuur van de inhoud van berichten. Ook hiervoor had de opdrachtgever een voorkeur voor XML, omdat het deze al gebruikt voor andere projecten. XML is makkelijker leesbaar is voor de programmeur. Uit het onderzoek kwam echter ook JSON naar voren omdat het sneller door een computer kan worden gelezen en geschreven. Uiteindelijk is toch XML gebruikt vanwege de randvoorwaarde van de opdracht. ~ 11 / 47 ~

13 3.1.2 Tweede deelvraag Hoe gaan bestaande games (buiten T-Xchange, op de markt) om met niet-lineaire verhaallijnen met vooral betrekking tot het voorkomen van zeer divergerende verhaal-bomen? Onderdeel van de ISS opdracht is dat de SDM Game Suite uitgebreid moet worden met de mogelijkheid, om het verloop van het verhaal van een scenario te laten beïnvloeden door de keuzes en acties die de speler maakt tijdens het spelen. Oftewel, niet-lineaire verhaallijnen moeten worden ondersteund in scenario s voor de SDM Game Suite. Met dit in het achterhoofd werd bepaald dat het interessant zou zijn om eens te kijken hoe andere games nou eigenlijk omgaan met niet-lineaire verhaallijnen. Uiteindelijk zijn 3 games onderzocht: GTA 4, Heavy Rain en The Walking Dead. Er was al speelervaring voor de stage met deze games, dus tijdens het project zijn deze games eigenlijk niet gespeeld. Het onderzoek naar deze games is gedaan op eigen interpretatie van het verhaallijn van deze games. GTA4 heeft niet een niet-lineair verhaallijn, maar geeft de keuze aan de speler om de ene missie voor de andere te spelen. Daarnaast kan de speler eigen invulling geven aan de missies door het op een bepaalde manier aan te pakken, zoals welke wapens hij gaat gebruiken. Dat heeft echter niet impact op het verhaal zelf. Het principe dat meerdere missies tegelijk worden aangeboden is hetzelfde als bij de SDM Game waar dilemma s tegelijk worden aangeboden. Waar het verschilt echter is dat dilemma s worden getoond op basis van gemaakt keuzes in voorafgaande dilemma s, iets wat niet aanwezig is in missies van GTA4. In Heavy Rain hebben de keuzes van de speler in de scenes wel invloed op het verloop van de verhaallijn. De speler speelt in totaal vier protagonisten, waarvan enkele kunnen overleiden als de speler een (verkeerde) keuze maakt. Als zo n protagonist is overleden, wordt een ander pad in de verhaallijn belopen. In figuur 4 is het concept van de verhaallijn in Heavy Rain gevisualiseerd middels een graaf. Figuur 4: Concept verhaallijn Heavy Rain Zoals in de figuur te zien is, kunnen dezelfde scenes wel terugkomen in een aparte tak van de boom (scene A), dit zijn dan scenes waar eigenlijk naartoe wordt convergeert vanuit twee takken, maar dat wordt zo niet gevisualiseerd. Naar eind scene 1 wordt ook geconvergeerd en is dat wel duidelijk te zien in de graaf. Het is gewenst dat in een graaf van een verhaallijn dezelfde scenes eenmalig voorkomen en convergerende delen duidelijk zijn. Uiteindelijk divergeert het verhaallijn van Heavy Rain naar eenentwintig mogelijke eind scenes. ~ 12 / 47 ~

14 In The Walking Dead speelt de speler 1 protagonist. Het verhaal heeft 1 eind scene maar tijdens het spel heeft de spelers wel keuzes die het verhaallijn kunnen laten divergeren, die dan laten weer convergeren naar de eind scene toe. In figuur 5 is te zien hoe in The Walking Dead de speler keuzes moet maken. Meestal zijn dit ogenschijnlijk kleine keuzes die pas veel later in het spel grote impact hebben op het verhaallijn. In dit geval kan de speler kiezen om informatie achter te houden of de waarheid te vertellen. Figuur 5: Maken van keuzes in The Walking Dead In figuur 6 is aangetoond hoe zo n schijnbaar kleine keuze impact heeft later in het verhaallijn. Een voorwaarde van een scene kan op basis zijn van keuzes die gemaakt zijn lang geleden in het verhaal. Om niet voor elke (kleine) keuze gelijk een geheel ander pad te belopen in een verhaallijn, zoals in de figuur 4 van Heavy Rain, is het beter om op met voorwaarden een bepaalde scene te laten afhangen. Op die manier komen dezelfde scenes maar eenmalig voor en blijft de graaf overzichtelijk. In principe zou de graaf van Heavy Rain op deze manier ook moeten kunnen worden getoond. ~ 13 / 47 ~

15 Het antwoord op deze onderzoeksvraag is dat binnen verhaallijnen je voorwaarden kan definiëren die bepalen welk pad in de verhaallijn wordt belopen. Stel bijvoorbeeld dat een bepaalde scene alleen zou worden getoond NA een andere scene EN als een bepaalde actie is uitgevoerd door de speler (een scene moet je dan zien als een interactieve omgeving / missie). Er is in het ISS project ook gebruik gemaakt van het concept van voorwaarden. Zie figuur 6 voor het concept verhaallijn op basis van voorwaarden. Figuur 6: Concept verhaallijnen met voorwaarden In onderzoeksvraag 3 wordt dit principe verder uitgelegd. ~ 14 / 47 ~

16 3.1.3 Derde deelvraag Welke mogelijkheden zijn er om een niet-lineaire verhaallijnboom te doorlopen? Met deze deelvraag was het doel kennis op te doen over hoe een verhaallijn van een scenario van de SDM Game zou kunnen worden gevisualiseerd middels een graaf. Dit bleek uiteindelijk ook handig te zijn voor het ontwikkelen van de Scenario Analyzer tool, waarin zo n graaf wordt getoond. Verder was het doel van deze deelvraag om te weten te komen hoe een verhaallijn weer kan convergeren naar 1 of meerdere eindpunten. Dit bleek redelijk eenvoudig binnen het voorwaardeprincipe. Dit onderzoek is aangepakt op basis van eigen interpretaties van verhaallijnen en een aantal internet bronnen die gaan over non-lineaire verhaallijnen. Tijdens dit onderzoek werd duidelijk dat de verhaallijn van een SDM Game duidelijk zou gaan verschillen met de games die onderzocht zijn in deelvraag 2. In de SDM Game, zijn er dilemma s die moeten beantwoord door de speler, echter kunnen er meerdere dilemma s tegelijk worden getoond aan de speler, het is niet 1-voor-1. De speler mag uiteindelijk zelf kiezen welke dilemma hij als eerste beantwoord. Een ander dilemma kan van dat antwoord afhankelijk zijn en wel of niet worden getoond. In de games die zijn onderzocht in deelvraag 2, worden scenes 1-voor-1 getoond aan de speler; een scene kan niet halverwege worden gestopt om een andere scene te spelen. Zie figuur 7 hoe een verhaallijn eruitziet middels een graaf waarbij de scenes 1-voor-1 worden getoond. Figuur 7: Verhaallijn met scenes 1-voor-1 In figuur 7 stelt de rode lijn het pad voor dat de speler heeft belopen in het verhaallijn. In dit verhaal zijn scenes C, D en E exclusief van elkaar, alleen 1 van de 3 zal uiteindelijk worden getoond aan de speler. In figuur 8 is te zien hoe een verhaallijn van een scenario van de SDM Game eruit zou zien. ~ 15 / 47 ~

17 Figuur 8: Verhaallijn die kan splitsen In figuur 8 stellen de vertices van de graaf de dilemma s voor. In deze verhaallijn kunnen de dilemma s wel ieder getoond worden zolang als aan de voorwaarden wordt voldaan, in tegenstelling tot dat er maar één vervolgend dilemma wordt getoond. Uit het antwoord op deze deelvraag werd ook duidelijk dat een verhaallijn weer kan convergeren middels een voorwaarde met een OF-logische expressie. Stel, dat in de graaf van figuur 8 er rechts nog een vertex/dilemma E stond, als we zouden willen dat het verhaallijn naar dilemma C en D weer convergeert naar E, dan hoeft de voorwaarde van dilemma E simpelweg alleen te zijn: Speler heeft dilemma C beantwoord OF dilemma D beantwoord. In figuur 9 wordt dit gevisualiseerd. Figuur 9: Verhaallijn convergeren m.b.v. een logische expressie Als een dilemma een voorwaarde heeft die nooit waar kan zijn, bijvoorbeeld een afhankelijkheid op het antwoord JA en NEE van eenzelfde dilemma, dan komt die dilemma simpelweg nooit aanbod. Recursieve paden worden niet ondersteund, dit komt omdat dilemma s maar eenmalig kunnen voorkomen in een scenario. Een puur recursieve pad (niet verbonden aan een niet-recursief pad) wordt nooit belopen. Een recursief pad dat verbonden is aan een niet-recursief pad, kan maximaal eenmalig worden belopen. ~ 16 / 47 ~

18 3.1.4 Vierde deelvraag Hoe kan het beste de structuur van het scenario XML bestand worden opgezet om er niet-lineaire verhaallijnen in te kunnen definiëren? Deze vraag is meer implementatiegericht. Op dit punt was al duidelijk dat op basis van de antwoorden van deelvraag 2 en 3, dat voorwaarden voor dilemma s zouden worden gaan gebruikt om scenario s met niet-lineaire verhaallijnen te kunnen schrijven voor de SDM Game. Het doel van dit deelonderzoek is om duidelijkheid te krijgen hoe een scenarioschrijver het beste een voorwaarde zou definiëren in een XML bestand. Er is gekozen om dit deelonderzoek te beantwoorden met een resultaat dat voor, vanuit het perspectief van de programmeur, de ideaalste implementatiemethode zou zijn. Voor de scenarioschrijvers is een Scenario Analyzer tool gemaakt die een boomgraaf tekent op basis van alle afhankelijkheden die dilemma s hebben op elkaar in een scenario. Die tool maakt het eenvoudiger voor een scenarioschrijver om een scenario te beheren omdat het grafische feedback geeft over het verhaallijn dat hij aan het schrijven is. Er werd eerst gekeken om elke afhankelijkheid die een dilemma kan hebben los te specificeren van elkaar. In dat geval zou een dilemma worden getoond als alle afhankelijkheden (lees: voorwaarden) waar zouden zijn. Hieruit bleek echter dat het niet mogelijk zou zijn om verhaallijnen weer te convergeren, zoals in deelvraag 3 is beschreven. Uit het resultaat van deze onderzoeksvraag is gebleken dat het eenvoudig zou zijn om een voorwaarde te kunnen schrijven voor een dilemma met één zin, waarin alle voorwaarden met elkaar worden verbonden middels een logische operator zoals EN of OF. Elk scenario van de SDM Game staat gedefinieerd in een XML bestand. In dat bestand, is voor ieder mogelijk dilemma in dat scenario een eigen blok gereserveerd zoals bijvoorbeeld: Dit kan redelijk eenvoudig worden getransformeerd naar een voorwaarde: Met deze aanpassing is het mogelijk voor een scenario schrijver om een voorwaarde te schrijven voor dilemma s. De syntax van de voorwaarde is voor deze deelvraag niet zozeer van belang. Dat is vervolgens bepaald tijdens de ontwerpfase. In theorie is het mogelijk om een zo n complexe voorwaarde te definiëren als de scenarioschrijver wil. Tijdens dit onderzoek kwam ook naar voren dat de Backus-Naur Form (BNF) een handige notatiemethode zou zijn voor het beschrijven van de syntax. De BNF kan bijvoorbeeld gebruikt worden om te definiëren waaruit een postcode moet bestaan, maar ook complexere zinnen zoals een voorwaarde voor een dilemma. ~ 17 / 47 ~

19 3.1.5 Vijfde deelvraag Wat is de beste Graph Library voor het tekenen van een graaf in Java of AS3? Deze onderzoeksvraag is pas later in het project erbij gekomen, toen het duidelijk werd dat er ook aan een Scenario Analyzer tool zou worden gewerkt. De Scenario Analyzer visualiseert een nietlineair verhaallijn van een scenario van de SDM Game in een graaf. Bij deelvraag 3 was het al duidelijk over hoe zo n graaf er ongeveer uit zou gaan zien. Het idee van de Scenario Analyzer is dus het tonen van een graaf op basis van een scenario. Maar dat niet alleen, het zou ideaal zijn als de Scenario Analyzer live mee zou kunnen luisteren met een speler die aan het spelen is, en dat op basis van de keuzes van de speler, de graaf zijn edges en vertices inkleurt. Voor het tekenen van die graaf is gedoeld op het gebruiken van een bestaande library. Door alleen aan te geven welke vertices en edges er in de graaf zich bevinden zou de library een graaf moeten tekenen op het scherm. Met dit deelonderzoek zijn verschillende bestaande libraries onderzocht door voor ieder te kijken naar de specificaties. Zowel AS3 als Java libraries zijn onderzocht. Door de library moet aan de volgende criteria worden voldaan: Opensource Kan edges als pijlen tekenen (gerichte graaf) Vertices kunnen verschillende vormen hebben Vertices en edges kunnen gekleurd worden Er kunnen labels over vertices en edges geplaatst worden Kan vertices en edges zelf positioneren Kan de grootte van vertices en edges aanpassen Heeft actieve development (in het laatste jaar minstens een update gehad) JGraphX is een Java library dat voldoet aan alle bovengenoemde criteria. yfiles is een commerciële Java library en voldoet dus niet aan de criteria. GraphStream is een Java library dat ook voldoet aan alle criteria maar werd beter gepresenteerd dan JGraphX (bijv. betere tutorials en documentatie). yfiles FLEX is een commerciële AS3 library en voldoet ook niet aan de criteria. Flare is een verouderde AS3 library die niet meer wordt geupdate. Uiteindelijk bleek de open source GraphStream java library het beste naar voren te komen, en is die uiteindelijk ook gebruikt voor de Scenario Analyzer. ~ 18 / 47 ~

20 3.2 Software Het ISS project bevat verschillende software onderdelen. In figuur 10 is een systeemdiagram te zien met de onderdelen van het ISS. Figuur 10: Systeemdiagram ISS De verschillende processen zijn aangegeven met een cirkel. Een cirkel met cursieve tekst geeft aan dat dit proces alleen een uitbreiding/aanpassing is op wat al onderdeel was van de SDMGame. Een cirkel met dikgedrukte tekst is een nieuw stuk software als onderdeel van het ISS. De Message Broker is de regelaar van communicatie tussen de processen. De DB is de File Database. In figuur 11 is de oude situatie te zien. Samen met figuur 10 wordt duidelijk gemaakt hoe de ISS het systeem achter de SDM Game heeft uitgebreid. ~ 19 / 47 ~ Figuur 11: Oude situatie systeemdiagram SDM Game

21 3.2.1 Flash Client Van de Flash Client is een thin client gemaakt, dit houdt in dat de game logic wordt bijgehouden aan de server kant. Voordat ISS was geïmplementeerd, werd alle game logica lokaal op de Flash Client geregeld. Het verplaatsen van de game logic naar de server opent nieuwe mogelijkheden, zoals multiplayer. Visueel is er weinig veranderd aan de Flash Client, behalve dat in de lobby van het spel er nu ook kan gekozen worden om een actieve game te joinen of een replay te bekijken. In figuur 12 is de lobby van de SDM Game te zien, standaard zie je eerst de lijst met scenario s, dat opgehaald is van de server. De tabs games en replays zijn toegevoegd als onderdeel van het ISS project. Figuur 12: Lobby SDM Game Als je een scenario kiest om te spelen, wordt de server verteld om een nieuwe game instantie te starten. Als de nieuwe game instantie klaar is op de server wordt het in-game scherm van de SDM Game getoond. Zie figuur 13. ~ 20 / 47 ~

22 Figuur 13: In-game interface SDM Game Voor de eindgebruiker (de speler), is het niet direct duidelijk of hij een scenario aan het spelen is met een lineaire verhaallijn (origineel scenario) of een niet-lineaire verhaallijn (ISS scenario). Alleen als de speler het scenario nog een keer zou spelen en andere antwoorden zou geven, krijgt hij door dat zijn keuze direct invloed hebben op het verloop van het verhaal. Als de speler scherp is zou hij ook indirect kunnen herleiden uit een dilemma met een boze reactie van een virtueel karakter dat dat komt door zijn keuzes. Als de Flash Client in-game is, communiceert hij via een topic op de Message Broker met de Scenario Player, de Scenario Player is de server instantie die een game en alle logica ervan beheert. Als bijvoorbeeld een nieuw dilemma moet worden getoond, dan stuurt de Scenario Player een berichtje via de Message Broker dat een nieuw dilemma moet worden getoond. Dit geldt ook met info elementen en advies elementen. De Flash Client stuurt alle keuzes die de speler maakt, zoals bijvoorbeeld als hij antwoord ja kiest op een dilemma, naar de Scenario Player. De Scenario Player gebruikt deze input voor de volgende stap in het verhaallijn. Omdat de game logica nu op de server geregeld wordt en dat dankzij het Message Broker systeem meerdere applicaties kunnen meeluisteren op eenzelfde topic, is het mogelijk om multiplayer functionaliteit toe te voegen aan de SDMGame. Dit is gedaan door de lobby uit te breiden met een lijst met actieve games, zie figuur 14. ~ 21 / 47 ~

23 Figuur 14: Lijst met actieve games in de SDM Game Lobby Een andere speler, wellicht op een totaal andere fysieke locatie, kan deze game joinen. Op dat moment communiceren beide Flash Clients met dezelfde Scenario Player over eenzelfde topic op de Message Broker. In figuur 15 is te zien hoe twee instanties van de SDM Game draaien in verschillende internet browser en in dezelfde game zitten. Figuur 15: Twee Internet Browsers draaien de SDM Game en beide zitten in dezelfde game Multiplayer is een nieuwe functionaliteit dat de ISS brengt voor de SDM Game en maakt het mogelijk voor groepen om samen scenario s op te lossen, terwijl ieder elk hun eigen device kunnen gebruiken. Na het spelen van een spel wordt nu ook door het ISS een replay opgeslagen op de server. In de lobby van de SDM Game is een lijst te zien van de beschikbare replays. Zie figuur 16. ~ 22 / 47 ~

24 Figuur 16: Lijst met Replays in de SDM Game Lobby Als de speler kiest om een replay te bekijken, wordt op de server een proces aangemaakt, de Scenario Replayer, dat de replay zal beheren. De speler krijgt de in-game interface te zien, maar kan verder geen acties uitvoeren. Een replay is simpelweg het opnieuw afspelen van de communicatie tussen de cliënt en server toen de game werd gespeeld, op chronologische volgorde en op het juiste tijdstip. Tijdens een replay heeft de speler nog wel de macht om de replay te pauzeren of terug naar de lobby te gaan. ~ 23 / 47 ~

25 3.2.2 System Manager De System Manager is onderdeel van de ISS server software. Het houdt een lijst bij van actieve users en games. Daarnaast kan een cliënt (zoals de Flash Client) aan de System Manager vragen om een lijst van scenario s en replays te krijgen. Deze data wordt door de System Manager opgehaald uit de File Database. Verder regelt de System Manager dat een game of replay wordt gestart op vraag van een client. De System Manager, Scenario Player (beheert een game) en Scenario Replayer (beheert een replay) zijn runnable jars (executables) en zijn allen onderdeel van de ISS server. De systeembeheerder moet ervoor zorgen dat de firewall de connectie naar de Message Broker toelaat. Verder is ook de juiste versie van de Java runtime nodig. De systeembeheerder kan de juiste verbindingsinstellingen invoeren in de configuratiebestanden. Bij problemen kunnen de logs worden geraadpleegd. De System Manager is het centrale punt van het ISS. Zonder de System Manager kan geen enkel onderdeel van het ISS gebruikt worden. Andere applicaties communiceren met de System Manager via de system topic op de Message Broker. De System Manager regelt onder andere de actieve users met ieder een uniek ID; games, waarvan een lijst kan worden opgevraagd door een cliënt; een lijst van scenario s dat kan worden opgevraagd; een lijst van replays dat kan worden opgevraagd; dat een nieuwe game wordt gestart (dit start een ScenarioPlayer proces); dat een nieuwe replay wordt gestart (dit start een ScenarioReplayer proces). Een voorbeeld van de flow van de communicatie die tussen de verschillende applicaties verloopt bij het opstarten van een game is in figuur 17 te vinden. Figuur 17: Flow van berichten bij het opstarten van een nieuwe game Een spel opstarten vanuit de Flash Client begint bij de Flash Client met het Start Scenario bericht en eindigt bij de Flash Client met Scenario gereed om te spelen. Al deze berichten worden via de system topic verstuurd. De Scenario Player gebruikt andere topics voor berichten over de game state, daarover is meer te vinden in het volgende hoofdstuk. ~ 24 / 47 ~

26 3.2.3 Scenario Player De Scenario Player is de server tool dat nu alle game logica beheert van een actieve game. De Scenario Player wordt gestart door de System Manager wanneer een nieuwe game wordt gestart door de speler in de lobby. De Scenario Player speelt dan het scenario af via een topic op de Message Broker. Op dat moment is de cliënt ook verbonden met dat zelfde topic zodat de juiste display wordt getoond aan de speler op basis van de inkomende berichten van de Scenario Player. De Scenario Player is gemaakt om zowel de originele scenario s van de SDM Game te ondersteunen, als de nieuwe ISS scenario s. In dit hoofdstuk wordt uitgelegd hoe een niet-lineaire verhaallijn van een ISS scenario werkt en hoe de Scenario Player met de cliënt communiceert. Scenario Player als voorbeeldmodule voor toekomstige uitbreidingen De Scenario Player kan verder als voorbeeldmodule gebruikt worden voor de toekomstige wens van T-Xchange om hun Virtual Storyteller te kunnen binden aan de SDM Game. Het zou dus mogelijk zijn om in de toekomst een Virtual Storyteller Player te maken die net als de Scenario Player een scenario van de SDM Game beheert en afspeelt via de Message Broker. Voor de client maakt het namelijk niet uit wat het achterliggende systeem is dat het voedt met het verhaal, en kan dus makkelijk worden vervangen. De Virtual Storyteller zou dan als toegevoegde waarde hebben dat het een AI heeft, wat de ISS scenario s niet hebben. Dit heeft als voordeel dat reacties van virtuele karakters realistischer kunnen zijn. Uitbreiding scenario s voor ondersteuning van niet-lineaire verhaallijnen Scenario s van de SDM Game worden gedefinieerd in een.xml file. De XML wordt ingeladen door het Scenario Player proces en omgezet in een datamodel dat gebruikt wordt voor het doorlopen van het verhaal. De originele scenario s van de SDM Game bestaan uit een lijst met dilemma s met display tijden. Elke dilemma heeft een absoluut tijdstip dat bepaald op welke tijd in het spel de dilemma moet worden getoond. Dit kun je lezen als dat de dilemma een afhankelijkheid heeft op de absolute game tijd. De originele scenario s zijn uitgebreid door in plaats van een dilemma alleen afhankelijk te laten zijn van een absolute tijdstip, het afhankelijk te laten zijn van een voorwaarde. Deze voorwaarde is een stuk tekst en wordt geschreven door de scenarioschrijver. De complexiteit van de voorwaarde kan variëren van zeer eenvoudig met één afhankelijkheid tot een zeer complexe voorwaarde met meerdere afhankelijkheden. De voorwaarde ondersteund een aantal afhankelijkheden, zoals onder andere het antwoord op het vorige dilemma, de mood van een virtuele karakter en de tijd die is verlopen sinds het antwoorden op een ander dilemma. Het geschreven systeem is echter zeer generiek en laat toe dat nieuwe afhankelijkheden eenvoudig kunnen worden toegevoegd. Als een voorwaarde WAAR is, wordt de bijbehorende dilemma getoond aan de speler. ~ 25 / 47 ~

27 In figuur 18 is de belangrijkste aanpassing die is gedaan op het scenario XML bestand t.b.v. het ondersteunen van niet-lineaire verhaallijnen. Figuur 18: Aanpassing aan scenario XML bestand voor ondersteuning van niet-lineaire verhaallijnen Een voorbeeld van een eenvoudige voorwaarde zou zijn: op dilemma 1 is JA geantwoord. Een voorbeeld van een complexe voorwaarde zou zijn: op dilemma 1 is JA geantwoord OF op dilemma 2 is NEE antwoord OF de tijd dat is verlopen sinds het antwoorden op dilemma 3 is 5 seconden. De syntax van een voorwaarde is in werkelijkheid anders dan hierboven. De syntax van bijvoorbeeld de eenvoudige voorwaarde is: dilemma.1.answer = YES. Deze voorwaarde wordt bij het inlezen van het scenario geparsed door een zelfontwikkelde tokenizer. Een tokenizer leest een stuk tekst en splitst het op in kleinere tokens. Voor het bovenstaande voorbeeld voorwaarde zou het opgesplitst worden in de volgende tokens: Figuur 19: Eenvoudige voorwaarde ~ 26 / 47 ~

28 De dynamische variabel is een waarde dat elk moment in het proces kan veranderen. De equals comparator is de vergelijker. De constante string is een stuk tekst die niet veranderd. Deze vergelijking wordt in de Scenario Player elke keer als de game state veranderd, gecontroleerd of het vertaald naar waar. Als de vergelijking waar is en het dilemma is nog niet getoond, dan wordt het dilemma aan de speler getoond. Ook kan een complexe voorwaarde geschreven woorden, deze complexe voorwaarde houdt in dat de voorwaarde niet alleen bestaat uit een vergelijking, maar uit een logische expressie. Een complexe voorwaarde kan bestaan uit meerdere logische expressies door elkaar heen, zoals bijvoorbeeld: (dilemma.1.answer = YES ) && ((dilemma.2.answer = NO ) (dilemma.3.answer = YES )) In deze voorwaarde heb je twee logische expressies gecombineerd. De && vertaald zich naar een AND connectief (conjunctie ) en de naar een OR connectief (disjunctie ). Als deze complexe voorwaarde wordt geparsed door de tokenizer, krijgen we deze tokens terug: Figuur 20: Complexe voorwaarde Naast de equals comparator, worden voor vergelijkingen getallen ook de overige comparators ondersteund. Een vergelijking met getallen gebeurd bijvoorbeeld bij het bepalen van de mood van een virtuele karakter. Een voorwaarde op basis van de mood is bijvoorbeeld: npc.1.mood >= 3. Deze voorwaarde is WAAR als de mood van een virtuele karakter hoger is dan 3 (een mood van een karakter wordt opgeslagen middels een eenvoudig getal). Met getallen kunnen ook formules worden geschreven, wat handig is als er met tijd wordt gespeeld in de voorwaarde. Neem bijvoorbeeld de voorwaarde voor dat de dilemma pas wordt getoond 5 seconden nadat een andere dilemma is beantwoord: world_time >= (dilemma.1.answer_time + 5). Deze voorwaarde wordt vertaald door de tokenizer naar: Figuur 21: Wiskunde formules mogelijk in voorwaarden Middels deze voorwaarden kan een scenarioschrijver een niet-lineaire verhaallijn redelijk eenvoudig schrijven. Er kan op deze manier geëxperimenteerd worden met adaptieve spelmechanieken. Voor de scenarioschrijvers is een handleiding geschreven die uitlegt welke mogelijkheden en regels van toepassing zijn op de voorwaarde. Deze handleiding is te vinden onder de Publicatie in Bijlage B Systeemdossier. ~ 27 / 47 ~

29 Detecteren van einde spel Voor het detecteren van het einde van een scenario door de Scenario Player, zodat het spel kan worden beëindigd, is een speciaal mechaniek ontwikkeld. Niet alle dilemma s komen in een niet-lineaire scenario aanbod, omdat ze afhankelijk zijn van een keuze die niet is gemaakt en nooit meer kan worden gemaakt (omdat de speler iets anders heeft gekozen bijvoorbeeld). Met een voorwaarde op zichzelf kan alleen worden nagegaan of de voorwaarde, op het moment van vergelijken, vertaalt naar waar of onwaar. Het doet geen verwachting of deze voorwaarde ooit waar zal teruggeven. Er moet dus een systeem komen die verwachtingen kan doen of een dilemma überhaupt ooit zal komen op basis van zijn afhankelijkheden. Als er geen dilemma s meer komen, dan moet het spel worden beëindigt. De Scenario Player bepaalt of een spel moet worden beëindigt op basis van de volgende twee cases: 1. Zijn alle dilemma s al beantwoord? Ja; dan einde spel (eenvoudige manier) 2. Zijn er nog dilemma s die kunnen komen? Nee; dan einde spel (complexere manier) Voor case 2 is een systeem ontwikkeld die dat kan detecteren. Nadat de voorwaarde is geparsed door de tokenizer, wordt de geparsde voorwaarde omgezet in een dependency. Deze dependency geeft aan middels een boolean of de bijbehorende dilemma ooit nog aanbod zal komen. Deze dependency doet geen toekomstverwachtingen, bijvoorbeeld dat de game tijd altijd omhoog gaat, of dat de virtuele karakter nog boos kan worden als de speler bepaalde keuzes gaat maken. In plaats daarvan gaat de dependency na op basis van zijn type en de state van de game of de bijbehorende dilemma ooit nog kan komen. Als voorbeeld nemen we de volgende voorwaarde: dilemma.1.answer = YES. Deze voorwaarde hoort bij dilemma 2. De voorwaarde wordt omgezet in een dependency van het type DilemmaAnswer en houdt de state van dilemma 1 bij en onthoudt ook het antwoord JA. Als we nu willen controleren of dilemma 2 ooit nog aanbod komt, gaan we flow van figuur 22 langs. Figuur 22: Controleren of dilemma 2 ooit nog aanbod komt ~ 28 / 47 ~

30 Als dilemma 1 nog niet is beantwoord, weten we dat dilemma 1 nog zou kunnen worden beantwoord. Om die reden kunnen we herleiden dat dilemma 2 nog zou kunnen komen, namelijk als JA wordt gekozen op dilemma 1. Echter, stel nu dat er een dilemma 3 is, die alleen afhankelijk is van het antwoord van dilemma 2, dan zou met de flow van figuur 22, bepaald worden dat dilemma 3 nog zou komen, want dilemma 2 is nog niet beantwoord. Dat is fout en om die reden, is er ook nog een extra controle toegevoegd, zoals te zien is figuur 23. Figuur 23: extra controle bij nagaan of dilemma nog kan komen Het voorbeeld dat hierboven is gegeven geeft alleen de situatie weer bij één type voorwaarde. Bij andere types voorwaarden of zelfs de complexere voorwaarden met logische expressies, zijn andere types dependencies ontwikkeld, maar die allen uiteindelijk hetzelfde bepalen: of de bijbehorende dilemma nog kan komen of niet. Welke types er allemaal zijn is afhankelijk van welke types voorwaarden er kunnen zijn. Technische informatie hierover is te vinden in de SE Document, onderdeel van Bijlage B Systeemdossier. ~ 29 / 47 ~

31 Communicatie tussen cliënt en de Scenario Player server De Scenario Player laat aan de cliënt weten of de game state is veranderd, bijvoorbeeld door een nieuwe dilemma of dat er nieuwe informatie van een virtuele karakter beschikbaar is. Om dit te regelen, is de Scenario Player opgesplitst in twee controllers, een WorldAgent en een CharAgent. De WorldAgent beheert de game wereld in het algemeen en de CharAgent beheert één virtuele karakter in het scenario. Per virtuele karakter is er een CharAgent. De WorldAgent beheert van de wereld de logica, zoals welke dilemma s open staan en welke al gesloten zijn. Het communiceert met de cliënt via de world topic op de Message Broker. Als de speler een dilemma beantwoord, behandelt de WorldAgent dat door de game state aan te passen (dilemma is beantwoord). Bij het antwoorden van een dilemma, gaat de WorldAgent de flow langs zoals te zien is in figuur 24. Figuur 24: Activity Diagram van flow na beantwoorden van een Dilemma ~ 30 / 47 ~

32 De CharAgent beheert van een character de logica, zoals of het nieuwe informatie heeft op een bepaald tijdstip. Het communiceert met de cliënt via de world.char topic op de Message Broker. Als de speler bijvoorbeeld om advies vraagt, behandeld de CharAgent deze aanvraag en stuurt het een antwoord terug. Zie figuur 25 voor de flow bij het vragen van advies aan een virtuele karakter. Figuur 25: Flow in CharAgent als gevraagd wordt om advies van een virtuele karakter Het idee achter dit model is dat virtuele karakters moeten gezien worden als onafhankelijke denkprocessen, en dat de CharAgent deze beheert. Nu is zo dat voor een vooraf gedefinieerd scenario dit nog niet echt nodig, maar voor de geplande Virtual Storyteller toekomstige uitbreiding is het wel al handig dat dit concept uitgewerkt aangezien de Virtual Storyteller wel zelfnadenkende karakters heeft. ~ 31 / 47 ~

33 3.2.4 Scenario Replayer De Scenario Replayer is een server tool die wordt gestart door de System Manager. De Scenario Replayer regelt dat een bepaalde Replay wordt afgespeeld via de Message Broker. Met de Scenario Replayer wordt het voor T-Xchange mogelijk om bijvoorbeeld met klanten nog een keer door te gaan door de keuzes die de speler heeft gemaakt, ten behoeve van peer review. Voor deze uitbreiding is de Scenario Player aangepast zodat het alle communicatie die via de Message Broker verloopt opslaat. Aan het einde van het spel slaat de Scenario Player de replay op in een.xml file in de File Database. In de replay.xml file staan, naast de algemene informatie, alle namen van de topics die gebruikt zijn in de spelsessie en alle berichten die zijn verstuurd. Per bericht wordt gemarkeerd over welke topic het is verstuurd en op welk relatief tijdstip. Het eerste bericht is dus verstuurd op tijd 0. Zie figuur 26 voor een beeld van de structuur van een replay.xml file. De Scenario Replayer, krijgt bij het opstarten net als de Scenario Player een uniek game id, wat gebruikt wordt om berichten op een topic te kunnen filteren. Na het inladen van de replay.xml bestand wacht de Scenario Replayer op het start commando van de cliënt. De Scenario Replayer begint na het start commando een timer. Elk tijdstip wordt gecontroleerd of op dat moment een of meerdere berichten moet worden verstuurd. Zo ja worden deze verstuurd naar de Message Broker, gemarkeerd met de juiste game id, en hoort een cliënt deze op te vangen. Om alle acties goed op te vangen, was het nodig om ook triviale berichten, zoals het simpelweg heropenen van een dilemma, te versturen via de Message Broker zodat in een replay duidelijk te zien is wat de speler aan het doen was. Figuur 26: Structuur bestand replay.xml file ~ 32 / 47 ~

34 3.2.5 Scenario Analyzer De Scenario Analyzer is een onafhankelijke extra concept tool dat is gemaakt voor de analyse van een scenario met een niet-lineaire verhaallijn. Het tekent een graaf van de verhaallijn en geeft op deze manier de paden weer die een speler kan doorlopen. Daarnaast kan de Scenario Analyzer live een game meevolgen, en de vertices en edges van de graaf inkleuren. Ook kan een replay worden bekeken. Op deze manier kan een onderzoeker ondersteund worden bij het uitvoeren van een analyse op de keuzes van de spelers. In figuur 27 is een voorbeeld van een graaf te zien dat de tool kan tonen. Figuur 27: Een graaf van een niet-lineair verhaallijn De dilemma s worden weergegeven met een node (ronde vorm). Een edge stelt een afhankelijkheid voor. De pijl geeft de richting aan van het pad. Een startpunt is aangegeven met een diamand vorm in paars, dit is bijvoorbeeld de game tijd. De eerste dilemma is bijvoorbeeld afhankelijk van de game tijd en wordt pas na een aantal seconden getoond. Sommige dilemma s kunnen afhankelijk zijn van ~ 33 / 47 ~

35 meerdere voorwaarden. In de graaf van figuur 26 is het dilemma Helaas bijvoorbeeld afhankelijk van dat op dilemma Pensioen nee is geantwoord OF dat op dilemma Praktijk nee is geantwoord. Deze conditie wordt aangegeven met een vierkante node dat deze logische poort weergeeft. De graaf van figuur 26 geeft een actieve game weer. Het groene pad geeft het pad aan dat de speler tot zover doorlopen heeft. De rode paden geven de paden weer die de speler niet meer kan aflopen vanwege de keuzes die hij al heeft gemaakt. Zwarte paden kunnen nog komen en oranje paden zijn het dichtstbij een keuze die de speler op het punt staat te maken. Als een dilemma node is gevuld met een rode kleur betekent dit dat de speler nee heeft geantwoord, bij groen ja. Als de speler nog niet heeft geantwoord is de dilemma node niet gevuld. In de figuur 26 is de speler dus bezig met het dilemma Praktijk. De Scenario Analyzer is een onafhankelijke cliënt desktoptool. Het kan draaien op een andere machine dan de rest van de ISS software. Het communiceert net als de Flash Client via de Message Broker met de server. Omdat de Scenario Analyzer niet in een browser draait hoeft het niet te verbinden met een webserver voor communicatie met de Message Broker, zoals dat wel bij de Flash Client het geval is. Als de speler de tool opstart, krijgt hij eerst een lobby te zien, zoals te zien is in figuur 28. Figuur 28: Lobby van de Scenario Analyzer Deze data wordt opgehaald van de System Manager. Zodra de onderzoeker een keuze heeft gemaakt uit welke scenario, game of replay hij een graaf wilt bekijken krijgt hij een graaf zoals in figuur 26 te zien. Als de onderzoeker een Scenario kiest, krijgt hij alleen een graaf te zien van het scenario. De data van het scenario wordt opgevraagd bij de System Manager. ~ 34 / 47 ~

36 Als de gebruiker een game kiest, wordt een graaf getekend en begint de Scenario Analyzer te luisteren op dezelfde topics als de game cliënt en de Scenario Player. Op deze manier vangt de Scenario Analyzer dus alle communicatie op die loopt tussen de Flash Client en de Server. Als de onderzoeker een replay kiest, wordt door de System Manager een nieuwe Scenario Replayer gestart, net als wanneer in de Flash Client wordt gekozen om een replay te starten. Een graaf wordt getoond aan de onderzoeker en net als bij een live game, wordt het verlopen pad ingekleurd. Als de onderzoeker een replay herbekijkt, heeft hij tevens de commando s om de Scenario Replayer te pauzeren of te versnellen. Dit om het gebruikersvriendelijker te maken. Zoals vermeld is de Scenario Analyzer een onafhankelijke cliënt desktopapplicatie. Deze kan draaien op een machine op afstand en alle communicatie verloopt via de Message Broker. De gebruiker hoeft er alleen voor te zorgen dat de juiste configuraties zijn ingesteld voor de verbinding naar de Message Broker. Als er fouten ontstaan bij het laden van de graaf, kan er gekeken worden naar de logs om de fout te vinden. Als bijvoorbeeld een scenario een recursieve afhankelijkheid heeft, wordt dat niet ondersteund en komt er foutmelding te staan in de logs. Als een graaf niet juist kan worden getekend door een recursief pad wordt er een foutmelding aan de gebruiker getoond. Andere fouten zoals een verbindingsfout worden ook gelogd. ~ 35 / 47 ~

37 3.2.6 De File Database De File Database is onderdeel van de ISS server. Het is simpelweg een folderstructuur met bestanden. Het bevat alle scenario s en replays. Voor het toevoegen van een nieuw scenario hoeft alleen een het nieuwe scenario XML bestand in de folder voor scenario s geplaatst te worden. De System Manager hoeft niet te worden herstart. Er is gekozen voor een File Database vanwege een aantal reden. Ten eerste het is weinig terugkerende data die wordt opgeslagen, dus het opsplitsen van de data van een scenario in verschillende tabellen in een SQL DB en ze te verbinden d.m.v. referenties maakt het alleen maar onoverzichtelijker. Ten tweede worden scenario s geschreven in een XML bestand, en is het makkelijker te beheren aangezien scenario s in de File Database ook als XML bestand worden opgeslagen. Ten derde is er geen extra afhankelijkheid van een SQL DB XML validatie De File Database bevat naast de XML bestanden ook XSD bestanden. Een XSD bestand bevat de formatteringsregels van een XML bestand. Voor de scenario en replay XML bestanden zijn XSD bestanden geschreven. Deze XSD bestanden worden tijdens het inladen van de XML gebruikt om de XML te valideren. Hiermee kan een scenarioschrijver tevens snel controleren of zijn geschreven scenario voldoet aan de formatteringsregels. Alle berichten die via de Message Broker worden verstuurd zijn in het XML formaat. Voor elk bericht is een XSD bestand gemaakt die een binnenkomend bericht valideert. Dit voorkomt dat een bericht dat binnenkomt van een bepaald type met de verkeerde inhoud, de software zou kunnen laten crashen omdat het data probeert op te halen die niet beschikbaar is. ~ 36 / 47 ~

38 3.3 Documenten en Handleidingen Voor het ISS is een Software Engineerings document geschreven (SE document). Dit document bevat alle technische informatie over het ISS: 1. Requirements 2. Analyse 3. Ontwerp 4. Implementatie 5. Testing 6. Acceptatietest Dit document is met name handig voor toekomstige ontwikkelaars om meer te weten te komen over de achterliggende ontwerp en implementatiekeuzes. Dit document is onderdeel van het Systeemdossier, zie Bijlage B - Systeemdossier. De volgende handleidingen zijn geschreven: 1. Gebruikershandleiding Handleiding voor eindgebruikers van de nieuwe ISS software 2. Installatiehandleiding Handleiding over het opzetten van de ISS gebruikersomgeving 3. Ontwikkelaarshandleiding Handleiding over het opzetten van de ISS ontwikkelaarsomgeving 4. Schrijvershandleiding Handleiding over het schrijven van niet-lineaire verhaallijnen voor de SDMGame Deze handleidingen zijn onderdeel van de Publicatie in het Systeemdossier, zie Bijlage B - Systeemdossier. 3.4 Publicatie Voor de juiste oplevering naar de klant T-Xchange, is er een package gemaakt, genaamd de Publicatie, die alle ISS software en bijbehoren bevat. Het bevat ook de handleidingen, zodat een ISS omgeving kan worden opgezet voor gebruikersdoeleinden. De Publicatie is te vinden in Bijlage B Systemdossier. De volgende bestanden zijn onderdeel van de Publicatie: 1. Alle Handleidingen 2. De Software met bijbehoren, als release editie a. Server files b. Client files c. Debugging Tools d. File DB Deze Publicatie zal onder andere gebruikt worden bij het demonstreren van het ISS. ~ 37 / 47 ~

39 3.5 Kwaliteitsbehoud Voor het behoud van de kwaliteit van de producten zijn er vooraf regels vastgesteld in het Plan van Aanpak. In dit hoofdstuk wordt beschreven hoe het waarborgen van deze regels is verlopen Broncode De code is volgens de code conventie van T-Xchange geschreven. Daarnaast was het de wens van de opdrachtgever dat de ISS code volledig geïntegreerd zou zijn in het SDM Game project om het onderhoudsvriendelijk te houden. Dit is ook gelukt. Alle geschreven code is in Engels geschreven, dit houdt in dat alle variables, methodes, etc. in het Engels verwoord zijn. Ook code documentatie en log/error output is in het Engels. Alle geschreven code is gedocumenteerd volgens de Javadoc style, zie figuur 29 voor een impressie. Figuur 29: Code documentatie Het blauwe gedeelte is code commentaar op de methode validatescenario. Het beschrijft wat de methode doet, welke parameters het nodig heeft en wat voor waarde het teruggeeft. Daarnaast is er ook inline code documentatie geschreven op plekken waar de code niet straightforward is, zie figuur 30 voor een impressie. Figuur 30: Inline code documentatie Dit stukje code regelt dat een binnenkomend bericht op basis van het type van het bericht door de juiste parser wordt behandeld. Zoals ook uit het commentaar is te herleiden. De code is op documentatie, consistentie en code conventie gecheckt door een vaste werknemer van T-Xchange. De code is ook gepeerreviewed (samen met een andere programmeur nagelopen voor feedback). ~ 38 / 47 ~

40 3.5.2 Broncode versiebeheer De code is beheerd op de SVN server van T-Xchange. SVN is een versiebeheersysteem voor projecten, in dit geval de SDMGame. Dit betekent dat de code op een centrale server staat en dat alle aanpassingen aan de code worden gelogd. SVN ondersteund ook branching. Dit houdt in dat er een kopie wordt gemaakt van het project, en dat er dan gewerkt kan worden in die branch in plaats van de hoofdbranche. Uiteindelijk kan die branche weer gemerged met het originele project. Branching wordt vooral gebruikt als een nieuw stuk functionaliteit wordt ontwikkeld. De ontwikkeling wordt geïsoleerd en pas als het af is wordt het ingebracht in het eindproduct, op deze manier beveilig je werkende code van code dat nog in ontwikkeling is. Code in ontwikkeling kan namelijk compileerfouten of functionele fouten veroorzaken. Het ISS is een branch van de SDMGame. Alle uitbreidingen van het ISS op de SDMGame zijn te vinden in die branch. Het is aan T-Xchange nog de keus om deze te mergen met het originele project, maar dat staat niet in de weg van de mogelijkheid om met het ISS te experimenteren. Alle aanpassingen aan de code op de SVN zijn gelogd met een eigen comment, in z n comment staat beschreven wat de aanpassing precies inhoud. Op deze manier kan een ander teamlid, of in het geval van ISS waarschijnlijker een toekomstige ontwikkelaar, terugzien wat een bepaalde aanpassing inhield Documentatie Alle documenten van het project ISS hebben een interne versiebeheer. Hierin staat voor elke aanpassingen beschreven wanneer de aanpassing is uitgevoerd en wat de aanpassing is. Alle documenten zijn daarnaast beheerd op Dropbox, waarmee oude versies kunnen worden teruggehaald bij een fout. Alle ISS documenten, dit zijn het Plan van Aanpak, de handleidingen, het onderzoeksrapport en het SE document, zijn gereviewed door onder andere de bedrijfsbegeleider. Na de feedback zijn eventuele aanpassingen doorgevoerd. ~ 39 / 47 ~

41 3.5.4 Probleemoplossing Tijdens de implementatie van bepaalde functionaliteit zijn een aantal problemen ondervonden. Ten eerste was er een probleem met de verbinding tussen de Flash Client en Message Broker. Het bleek namelijk dat de Flash Client niet direct verbinding kan maken met een server (de Message Broker) behalve de webserver waar het op wordt gedraaid. Adobe Flash noemt dit een sandbox violation. Dit probleem is opgelost door in samenwerking met een medewerker van T-Xchange de webserver een gateway te maken voor de communicatie, i.p.v. direct vanaf de Flash cliënt verbinding te maken met de Message Broker. Zie figuur 31 voor een visualisatie van dit probleem. Figuur 31: Sandbox violation met Flash Ten tweede waren er implementatiebugs in de gebruikte 3rd party STOMP message protocol java library. Zo was er een concurrency issue in de library, namelijk een deadlocks. Voor het vinden van de deadlock is de debugging tool VisualVM gebruikt. Deze tool geeft de state van alle threads in een Java applicatie aan, zoals of de thread wacht op een lock en of het ownership heeft van bepaalde locks. Verder kan de 3rd party STOMP library niet detecteren of een connectie met de Message Broker abrupt is verbroken. Daardoor kunnen de server applicaties in die ongebruikelijke situatie niet juist een foutmelding tonen. Ten derde bleek de Message Broker (ActiveMQ), anders om te gaan met de STOMP library dan de standaard. Dit zorgde voor een bug in de communicatie tussen de Flash Client en Server. Gelukkig is op de website van ActiveMQ wel beschreven hoe ActiveMQ anders met de STOMP message protocol omgaat. Applicaties in het ISS kunnen alleen via tekstberichtjes communiceren, echter ziet ActiveMQ tekstberichten als binaire berichten als een content-length header in het bericht aanwezig is, dit is standaard van STOMP om in elk type bericht toe te voegen. Om deze bug te vermijden, is de STOMP library aangepast (het is opensource) zodat het geen content-length header meer verstuurd met berichten waardoor ActiveMQ de berichten correct als tekstbericht interpreteert. ~ 40 / 47 ~

42 3.5.5 Tests Delen van de code worden automatisch getest door uitvoerbare Unit Tests. Een Unit Test is een afzonderlijk stukje code dat een onderdeel van de functionele code test op correcte werking. Een Unit Test bevat meerdere (afzonderlijke) testcases die ieder controleren of de functionele code goed werkt en blijft werken. Goed werken houdt in dat het doet wat de tester verwacht, dus bij gegeven bepaalde invoer komt een bepaalde uitvoer en dat kan d.m.v. een testcase getest worden. Het ISS heeft een aantal Unit Tests. Niet alle functionele code van het ISS wordt middels een Unit Test getest. Dit is zo omdat sommige functionele code externe bronnen gebruikt en dit moeilijker is om te integreren in een test. Neem bijvoorbeeld de System Manager die een extern proces start. Sommige Unit Tests die zijn geschreven vereisen dat de Message Broker aanstaat, dit is een externe afhankelijkheid van de Unit Test. Een externe afhankelijkheid bij een Unit Test is niet gewenst, omdat het een extra afhankelijkheid toevoegt. Zie figuur 32 voor een voorbeeld. Figuur 32: Unit Test voor een connectie met een Message Broker Deze Unit Test checkt of alle berichten worden ontvangen in de volgorde zoals ze zijn verstuurd via de Message Broker. Deze testcase gebruikt de test topic op de Message Broker. Bij deze test is het belangrijk dat er geen concurrent proces naar de test topic berichten schrijft, want dan faalt deze test. Dit soort issues worden liever gemeden maar zijn, zoals in dit geval, bijna onvermijdelijk. Bijna onvermijdelijk omdat je het wellicht zou kunnen vermijden door een random topic te gebruiken. Naast Unit Tests is er ook een Acceptatietest gehouden. Een Acceptatietest is een vooraf opgestelde gebruikerstest waarin iedere Requirement wordt afgevinkt door de projectleider. Voor iedere Requirement is een korte testcase beschreven die tijdens een demo wordt uitgevoerd. De Acceptatietest is onderdeel van de SE Documentatie, zie Bijlage B - Systeemdossier. ~ 41 / 47 ~