Heat map optimalisatie & HTML5

Ik heb wat meer opties toegevoegd voor het renderen van heatmaps zoals de individuele radius en hitte van remarks en de brightness van de achtergrond en de hitte. Verder heb ik het renderen van de achtergrond wat geoptimaliseerd.

Ik heb een hekel aan Javascript en weinig ervaring met HTML5, maar na wat geworstel heb ik een systeem gemaakt om dynamische pie charts te renderen. Dit heb ik gebruikt om bepaalde event data weer te geven.

Het visualiseren van geregistreerde game events is best lastig, omdat de betekenis van een event compleet van de developer af hangt. Zo is het opzoeken van hoe veel procent van de userbase een game event heeft (heb ik occurrence genoemd) handig voor events die bijvoorbeeld worden afgevuurd wanneer je een level haalt.

Userbase occurrence. Hier wordt bekeken hoeveel spelers voorover zijn gevallen.

Je kan ook het argument weg laten om te kijken hoeveel spelers überhaupt zijn omgevallen.

Als je aan het einde van een level een event afvuurt die registreert hoeveel coins je hebt opgepakt betekent het vrij weinig om te kijken welke users allemaal die event hebben, daar gaat het voornamelijk om het meegestuurde argument. Daar moet je dus op een heel andere manier kijken naar dezelfde data.

Event types. Hier wordt gekeken welke varianten er bestaan van een event en hoe vaak ze voorkomen.

Dit zou je kunnen gebruiken om bijvoorbeeld te zien welke levels het meest worden gespeeld.

Ik probeer nu een aantal algemene manieren te bedenken hoe je game events nuttig kunt gebruiken, en om functies te bouwen die de meest gebruikte manieren om data te verzamelen ondersteunt.

Pie charts zijn handig om verhoudingen weer te geven, maar er bestaan nog een hoop andere soorten diagrammen. Ik ga nu verder met HTML5 en met na te denken over wat voor data je kan verzamelen met events en hoe die het beste weer te geven is.

Heat Maps II

Heat maps zijn nu volledig functioneel. Je kan een Unity script toevoegen aan de camera om na het laden van alle remarks de data te renderen naar een heatmap. De rendertijd neemt exponentieel toe naarmate je de resolutie vergroot, dus om zicht te geven op hoever het renderproces is heb ik een progress bar toegevoegd samen met de verwachtte rendertijd.

Het 'level' in beeld, met alle ratings geladen. De voortgang van het renderproces wordt weergegeven.

Je kan verschillende maps renderen. Op dit moment wordt data kwalitatief en kwantitatief weergegeven afhankelijk van welk type remark je selecteert. Sowieso wordt er altijd eerst een achtergrond gerendered zodat je begrijpt over welke locaties het gaat. Daarna wordt er een heatmap gegenereerd om de kwantiteit van remarks weer te geven, zoals de hoeveelheid bugs, of een map die kwaliteit van remarks in beeld brengt, zoals de score die spelers opgeven bij 'Rating' remarks. Zo kan je op verschillende manieren probleemgebieden vaststellen: gebieden waar veel bugs worden gereport en gebieden die niet worden gewaardeerd door de spelers. Een kwantitatieve heat map kan ook worden gerendered voor locaties waar spelers niet wisten hoe ze verder moeten.

Van links naar rechts: de achtergrondmap, heatmap en ratingmap.

Hierna ga ik het heatmap algoritme verbeteren en optimaliseren, alsmede experimenteren met manieren om de zogeheten game-event data op een gelijksoortige manier weer te geven.

Heat maps

Ik heb de eerste draft van het Project Initiation Document opgestuurd ter bevestiging, en ik wacht nu op feedback van mijn docentbegeleider. Ondertussen ben ik kort aan het uitproberen of ik heatmaps kan renderen van de data die op dit moment verzameld wordt (bijv. buggebieden of slechte flow of player waardering).

Ik maak een Unity script die voor een instelbare resolutie per pixel naar het level traced om terreindata te vergaren. Zo wordt eerst het level als achtergrond gerendered zodat je de context van de heatmap kan begrijpen. Daarna wordt de 'hitte' van remarks bepaald en over de achtergrond heen gerendered.

Het is nog niet helemaal af. Ik wil het nog uitbundig testen en allerlei variabelen in het algoritme verwerken.

Donderdag & Vrijdag

Ik was een beetje bang dat ik achter ging lopen, daarom was ik woensdag meteen weer naar werk gegaan terwijl ik eigenlijk nog niet genezen was. Dat merkte ik donderdagmiddag toen ik vroeg naar huis moest omdat ik hoestbuien had. Ik ben vrijdag thuis gebleven om een lang weekend te rusten. Dat heeft geholpen, en inmiddels voel ik me een stuk beter. De volgende dingen moet ik nog maken voor mijn PID:

Project Quality Plan

Initial Business Case

Initial Risk Log


De rest is al gemaakt. Als ik deze week goed door werk denk ik dat ik prima op schema blijf.


Daarnaast heb ik aanstaande vrijdag een afspraak met een groepje mensen van SPIL Games. Blijkbaar is er een groep hard aan het werk om een systeem te maken dat data verzamelt en weergeeft (met heat maps! Ik wil graag ook heat maps maar het lijkt me een hoop werk om te ontwikkelen.).

Aanstaande vrijdag heb ik een afspraak met hun om te kijken waar overlap zit in onze projecten en om te kijken hoe we elkaar kunnen helpen.

Weer naar werk

Bewapend met een paracetamol en een extra pakje tissues ben ik weer naar werk gegaan. Ik ben meteen weer verder gegaan met het Project Initiation Document. In de template die ik ergens op Fontys' Sharepoint vond stonden allemaal Prince2 termen die ik nog niet kende. Alles wat ik al wel begreep heb ik zo veel mogelijk gedaan (projectmanagementstructuur, planning, etc.) en ik heb een begin gemaakt aan de dingen die ik nog niet goed ken (quality plan, communication plan, tolerances).

Via Fontys heb ik voorbeelden van scripties weten te vinden, en vandaag bedacht ik me dat er waarschijnlijk ook Project Initiation Documents zitten in de bijlagen. Die gebruik ik nu als voorbeeld voor de layout en opmaak. Morgen ga ik er mee verder.

Ziek

Een golf van verkoudheid is nogmaals over SPIL Games gespoeld, waarvan ik één van de slachtoffers was. Van zaterdag tot gisteren ben ik ziek geweest, en ik heb me dan ook twee dagen ziek gemeld.

Ik heb een bescheiden beginnetje gemaakt aan het Project Initiation Document terwijl ik ziek was, maar uiteraard heb ik minder kunnen doen dan normaal. Ik heb twee weken voor het document dus ik ben optimistisch dat ik het nog op tijd af krijg.

Laatste dag eerste week

Omdat het prototype dat ik wilde maken al klaar was heb ik vrijwel de hele dag uitgetrokken om aan Voodoo Runner te werken. Er waren een aantal assets die niet de juiste grootte hadden en foute textures hadden, die heb ik gefikst. Laat op de dag moest ik voor technische redenen switchen tussen versies van 3DS Max, waardoor ik niet meer verder kon werken.

Ik heb een stand-up meeting bijgewoond, gezien waar iedereen mee bezig was en hoe ze werken, en ik heb een uitgebreide demonstratie gekregen van een aantal Unity technieken, waaronder het gebruik van layers, light probes, scrollende textures, texture atlassen en lightmaps.

Ondanks die kleine tegenslag heb ik toch kunnen helpen en nieuwe dingen geleerd.

Afronding Prototype & Voodoo Runner

Donderdag heb ik mijn prototype afgemaakt. Ik heb alle functionaliteit in één Unity script gestopt, die met de back-end praat die vervolgens alle toegang tot de database regelt.

Je kan nu standaard op twee manieren 'remarks' plaatsen: onder de cursor of op de huidige positie van de speler. Welke je gebruikt is instelbaar in het script. Verder is er een optie om alle remarks voor het huidige level te laden zodra je begint met spelen.

De Remark Managing Behaviour script bevat alles om remarks te plaatsen en in te laden

 De remarks kunnen nu aan het begin van het level geladen worden. Ratings worden weergegeven met een duim. Welke kant de duim op richt en de kleur geeft de waardering van de speler aan. De rest heeft een eenvoudig icoon.

Daarnaast heb ik nog zogeheten 'events' ingebouwd. Je kan nu vanuit game logica een event signaleren dat in de statistieken database wordt opgeslagen. Voorbeelden van game events zijn dood gaan en het level afmaken. Er wordt gerapporteerd van wie de event is, wat er gebeurde, wanneer het gebeurde en in welk level. Daarnaast is er nog ruimte om een argument mee te geven. Zo kan je in plaats van elke keer als een speler dood gaat een event te sturen ook aan het einde van een level een PLAYER_DEATHS event sturen met als argument het juiste aantal keer dat de speler af is gegaan.

Overzicht van gerapporteerde game events

Ik heb nog vrijwel geen aandacht besteed aan security en schaalbaarheid, maar ik heb er al wel over na gedacht. Zo kan iemand met Wireshark opvangen waar remarks en game events naar toe worden gestuurd, en vervolgens een eigen programma bouwen om deze te versturen. Alle data wordt wel ge-escaped, dus er is geen SQL Injection mogelijk, maar het is een ongewenste feature. Een oplossing zou zijn dat de gamesessie zich voor een gelimiteerde tijd moet authenticeren aan de gameserver voordat er remarks kunnen worden verstuurd.

Verder kan een ietwat afwezige programmeur de server spammen door events heel vaak op te sturen. Een oplossing zou zijn om alle events in een buffer te stoppen en deze pas aan het einde van het level te versturen. Ik weet echter niet of je de buffer ook nog kan flushen als Unity abrupt wordt afgesloten, als dat niet zo is zou dat betekenen dat als spelers stoppen met spelen de statistieken van hun laatste level verloren gaan. Een oplossing hiertegen is om op willekeurige intervallen de buffer te flushen, dan kan je nooit meer dan 1 interval aan data mislopen.


Daarnaast heb ik nog wat meegeholpen aan één van Spil Games' projecten; Voodoo Runner. Ze hebben wat hulp nodig met 3D assets, dus gezien mijn prototype functioneel is was ik van plan vrijdag de hele dag in Hilversum mee te helpen met dat project. Dan zie ik meteen hun werkwijzen.

Prototype Eindproduct

Ik heb bijna de hele dag aan mijn prototype kunnen werken. Ik heb nog even nagevraagd hoe dataopslag en databases worden geregeld in SPIL Games' Unity projecten, maar blijkbaar is daar geen standaard voor.

Sterker nog, meestal wordt alles lokaal opgeslagen. Daarom koos ik er voor om te doen wat ik tijdens een eerder Fontys project heb gedaan: vanuit Unity PHP pagina's aanroepen en de back-end alles op laten lossen.

Nu heb ik een prototype waar bugs, commentaar en gameplay problemen kunnen worden gerapporteerd tijdens het spelen en in een database terecht komen. Morgen ga ik maken dat als je het spel opstart in developer mode dat alle relevante opmerkingen uit de database in het level worden geplaatst. Daarna is de kernfunctionaliteit volledig functioneel.

Ik wil nog een stuk meer functionaliteit in bouwen en ik moet nog een hoop onderzoek doen, maar dit zal een solide basis zijn om bovenop te bouwen.

Bugs die geplaatst zijn door de speler worden in het level weergegeven met een icoon

Eindhovense Vestiging

Op dag twee ben ik naar de Eindhovense vestiging gegaan. Mij was verteld dat de nieuwe Eindhovense vestiging nog niet klaar was, maar blijkbaar is de oude vestiging nog steeds in gebruik.
Het is een klein kantoortje op de High Tech Campus in Eindhoven. Dat scheelt per dag zo'n twee uur aan reistijd (vergeleken met het hoofdkantoor in Hilversum).

Het is een veel kleinere vestiging, met een stuk minder personeel. Best een groot verschil met het hoofdkantoor, maar het is er dan ook veel rustiger, en dat kan nooit kwaad als je lang moet programmeren.

Ik heb een beetje meegekeken wat iedereen aan het doen was en vragen gesteld over de werkwijzen van SPIL Games. Dat is geen dagvullend programma, dus ik heb tussendoor al wat dingen voor mijn eindproduct uitgeprobeerd in Unity. Als het zo door gaat heb ik aan het einde van de week een bescheiden prototype voor het product waar ik naar toe wil. Eigenlijk heb ik heel week twee en drie om aan het PID te werken. Dat klinkt heel ruim, maar misschien blijkt dat het niet te zijn. Ik kan altijd nog eerder beginnen aan het project als ik al vroeg klaar ben met het PID.

'Remarks' kunnen worden geplaatst en bekeken. Ze worden nog niet opgeslagen.

Ik ga de rest van de week nog de laatste dingen regelen die nog van het bedrijf moeten (ID kaart en wat accounts) en nog wat documenten klaarzetten die school nodig heeft (urenverantwoording),

Eerste dag

Ik heb de eerste dag achter de rug. Het was vooral rondlopen, kijken waar iedereen zat en wat er gedaan werd.

Ik heb allerlei accounts gekregen en wachtwoorden veranderd. In de tussentijd heb ik een beetje notities gemaakt van welke systemen er worden gebruikt en dingen waarvan ik nu al verwacht dat ik er rekening mee moet gaan houden tijdens het ontwikkelen van het product, alsmede wat kleine uitprobeersels die ik heb gemaakt in C# en 3DS Max.

Het toppunt was toen ik met een broodtrommeltje met een krentenbol aan kwam zetten in een gigantische kantine waar je gratis brood, soep en salade mocht opscheppen. Dat onthoud ik voor de volgende keer.

Het was een prachtig gebouw, ik kon goed opschieten met de mensen en ik heb de meest belangrijke dingen geregeld. Morgen moet ik in de oude Eindhovense vestiging zijn (ze gaan verhuizen) om zo'n beetje hetzelfde te doen als gisteren: oriënteren.

Afstudeerstage Blog

Dit is een blog om mijn persoonlijke voortgang/dagelijkse bezigheden te omschrijven tijdens mijn afstudeerstage bij SPIL Games. Het mocht ook in een Spreadsheet maar ik heb een fobie voor Excel.

Nu kan ik ook fatsoenlijke opmaak gebruiken en eventuele afbeeldingen/video's embedden, en gezien het een game design stage is zal dat waarschijnlijk handig zijn.

Ik weet nog niet of ik per dag een blogpost doe of elke keer als ik iets interessants gedaan heb, ik zie wel. Veel leesplezier, en als je een ander slachtoffer bent van een Fontys Hogescholen afstudeerstage dan veel succes.