GameAnalytics, Chunk-based Levels

Ik heb mijn vizieren gezet op GameAnalytics, een gratis analytics systeem dat officieel Unity ondersteunt. Metrics worden bepaald aan de hand van gelogde events tijdens het spelen, dat is dus precies dezelfde aanpak als die ik heb gebruikt tot nu toe. Ik heb een aantal standaard events zoals het aantal unieke users, het aantal gameplays en de geografische distributie van users al aan de praat gekregen.

Ik heb een functie aangetroffen in het voorbeeldproject om bugs en opmerkingen te submitten, wat ik vervolgens heb gedaan, maar die heb ik nog nergens in de webinterface kunnen inzien. Als dat er in zit, customization toe laat en aan een gamelocatie gekoppeld is zit het qua aangeboden functionaliteit ontzettend dicht bij wat ik aan maken was.

Alhoewel ik maar al te graag een eigen systeem zou hebben ontwikkeld vind ik het niet erg om een bestaand systeem te onderzoeken, documenteren en er voor te zorgen dat SPIL Games het kan gaan gebruiken.

Ik ga deze week GameAnalytics ontleden en kijken wat de mogelijkheden zijn.


Alhoewel in games het veelal de conventie is dat levels van te voren ontworpen worden is het voor sommige games mogelijk om levels dynamisch te genereren. Dit kan volledig programmatisch zijn of door middel van het dynamisch arrangeren van prefabricated level segmenten (vaak 'chunks' genoemd).

Voodoo Runner -het spel waar ik mijn gameplay metrics systeem in heb geimplementeerd- is een zogeheten infinite runner game en heeft chunk gebaseerde levels. Dat betekent dat het rapporteren van posities compleet betekenisloos is omdat die positie iets heel anders betekent als je het spel nogmaals opstart.

Om in zulk soort games nog steeds relevante gameplay metrics te kunnen registreren wordt er nu in chunk gebaseerde games de positie gerapporteerd relatief aan de oorsprong van de chunk, en de naam van de chunk wordt meegestuurd als argument.

Blog Catch-up

Ik had mijn blog nog niet klaar gezet voor mijn werklaptop en toen ben ik het minder consequent gaan bijhouden. Het is nu opgelost, dus ik zal weer frequenter gaan posten. Hieronder is een korte samenvatting van wat er gebeurd is:

De interviews zijn afgesloten en ik heb nu een goed idee wat voor data nuttig is voor de developers. Ik heb er voor gekozen om nu data te leveren aan level designers en game designers, i.p.v. level designers en gameplay programmeurs, want die blijken weinig behoefte te hebben aan gameplay metrics.

Enkele concrete voorbeelden van data die nuttig is voor ze is het gebruik van menu's en de funnel fall-offs (als inzicht op monetization voor de game designers), de flow van de speler, de progressie van de speler vs. de tijd en de moeilijkheidsgraad van spelsegmenten (waar spelers af gaan en dergelijke).


De twee prototypes die ik ontwikkeld heb en gepitched heb waren een succes, ze vielen allebei in de smaak, en van een daarvan hebben we toestemming gekregen om het uit te werken als volledig spel. De ander heb ik gebruikt om mijn gameplay metric systeem in te integreren en te stress testen. Hiermee heb ik de functionaliteit van het systeem verbeterd en het gemakkelijker gemaakt om het te integreren.


Ik heb inmiddels wat meer gepraat met de tech mensen van SPIL Games, en ik heb mijn gameplay metric systeem gedemonstreerd en uitgelegd aan het Voodoo Runner team. Daarna heb ik mijn eigen branch gekregen waarin ik mijn gameplay metric systeem heb geïntegreerd. Hieruit zijn twee dingen naar voren gekomen: des te generieker data wordt opgeslagen des te rubuuster en flexibeler het kan worden toegepast in verschillende soorten games. Daarnaast zijn er een aantal bestaande systemen (bijv. Google Analytics of Flurry) die heel betrouwbaar data kunnen opslaan en tonen. De komende tijd ga ik dus onderzoek doen over hoe data het best zo generiek mogelijk kan worden opgeslagen en of er bestaande systemen zijn die flexibel, eenvoudig en gratis genoeg zijn om de rol van back-end tot zich te nemen zodat ik mijn lokale server op poort 1337 kan ontmantelen.

Game Event Batches

Het bufferen van game events lijkt van Unity af gezien te werken, maar als er geflushed wordt dan komt alleen de eerste game event van een batch aan bij de database.

Het idee van game events bufferen was dat ik één call kon maken met veel data i.p.v. tien calls met weinig data. Bij mijn implementatie werd echter de buffer geleegd door elk individueel element te submitten, wat alsnog tien WWW calls opleverde.

Een oplossing hiervoor zou zijn dat ik in een call naar de PHP back-end meerdere indices heb per argument.

Zo'n URL zou er zo uit kunnen zien: submit.php?items=2&name=hello,foo&value=world,bar

Dat levert dan twee objecten op:
{
name=hello
value=world
}
{
name=foo
value=bar
}

Het is voornamelijk back-end werk. Één van de dingen die ik moet oplossen is welke seperator ik ga gebruiken zodat alle soorten tekst kan worden opgestuurd zonder dat er per ongeluk splitsingen plaats vinden. Daarnaast kan het zijn dat een grote batch events een heel lange URL oplevert. Ik weet niet of er een limiet aan URL lengtes zit, anders moeten we grote event batches alsnog opsplitsen in losse calls.

Interviews & Jam

De interviews zijn begonnen alsmede het integratieproces van Voodoo Runner. Er is nu een mobile vriendelijke interface met instelbare buttons en pictogrammen, en game events hebben nu een uitgebreid buffer systeem zodat kan worden gekozen wanneer game events worden gepersisteerd naar de server.

De meest gebruikelijke opties zijn om de buffer te flushen zodra hij vol zit, om periodiek de buffer te flushen of om aan het einde van het level de buffer te flushen. Dit wordt allemaal ondersteund, en geeft zo meer controle aan de game designers over wanneer er toegenomen internet traffic plaats vind.

Dit voorkomt haperingen tijdens gameplay en gaat dataverlies tegen. Het scheelt ook qua performance om 1 request te doen met veel data i.p.v. 100 requests met weinig data.


Daarnaast had een andere stagiaire het idee om soort game jam te doen, zodat we ervaring konden op doen in het maken van Unity games in een kleinere, veiligere omgeving. Als het resultaat van deze jam bevalt kan het dan altijd door een echt team worden opgepikt en worden uitgebreid naar een SPIL Games IP.

Deels in mijn eigen tijd en deels tijdens rustige stage momenten heb ik twee prototypes gemaakt voor het soort games die we zouden kunnen maken, daarmee pitchen we het game jam idee deze week.


Nu kan ik de prototypes dus ook gebruiken om al vast een implementatie van mijn feedback systeem in een werkend spel te testen.

Integratie Prototype & Interviews

Het eerder genoemde SPIL Games project 'Voodoo Runner' wordt binnenkort intern verspreid zodat collega's het kunnen spelen en feedback geven. Mijn prototype wordt in het project geïmplementeerd zodat er ergens een tablet kan worden achter gelaten met het spel er op en mensen opmerkingen en feedback kunnen opsturen. Dat betekent dat ik mijn prototype in een echt project kan toepassen en echte, bruikbare data binnen krijg.

Ik pas de interface aan zodat hij beter werkt op mobile devices en ik bereid wat performance optimalisaties voor. Ik ga bijvoorbeeld game events bufferen zodat er misschien ook al gameplay metrics kunnen worden vastgelegd, alhoewel dat nog niet nodig is voor de eerste integratie.

Daarnaast heb ik een vragenlijst samengesteld om vast te leggen hoe op dit moment game design problemen worden opgelost en hoe metrics kunnen helpen bij dat proces. Ik ga enkele gameplay programmeurs, level designers en game designers interviewen hiervoor.

Laptop & Voorbereiding Onderzoek

Ik heb het eerste bedrijfsbezoek achter de rug en alles lijkt goed op schema te zijn. Ik ga nu voorbereidingen maken voor het onderzoek, dat zal beginnen met interviews van SPIL Games werknemers. Verder heb ik mijn werklaptop binnen, die ben ik nu aan het configureren met alle software die ik nodig heb.

De 3D schets die ik had gemaakt van een intern character design wordt nu gebruikt om de vorm van het personage beter te begrijpen. Ik heb er een hoge resolutie render van gemaakt in verschillende aanzichten en die wordt nu gebruikt om een drawover te maken. Het is erg leerzaam om het designproces van een personage in werking te zien en er zelfs deel aan te nemen.

Ik heb de laatste paar weken vrijwel non-stop kunnen werken aan mijn afstudeerproject. Alhoewel ik nog steeds de grote meerderheid van mijn tijd daaraan mag blijven besteden wordt er van me verwacht dat ik mee help met interne projecten. Nu wordt het de uitdaging om een gezonde balans te vinden tussen de twee. Ik merk wel dat ik op dit moment erg veel van leer door met interne projecten te helpen. Puur en alleen al door in de buurt te zitten van mensen leer ik allerlei nieuwe technieken en processen in het programmeren van functies en het ontwikkelen van design.

Data Gathering & Inwijding SPIL Projecten

Ik heb nu een aantal artikelen doorgenomen over data gathering. Het belangrijkste wat ik geleerd heb is dat je twee dingen doet met game data: analyse en synthese. Eerst ga je game data vastleggen en daarna ga je die data samenvoegen op een manier dat je er patronen in kan herkennen en dingen van kan afleiden.

Problemen in games vaststellen ligt heel erg dicht bij wetenschappelijk onderzoek doen. Er zijn over het algemeen twee manieren om problemen in games vast te stellen: hypothese gedreven en exploratief gedreven, twee begrippen die rechtstreeks uit de wetenschap komen.

Bij hypothese gedreven onderzoek heb je een vermoeden waar een probleem ligt en zoek je data om het te bevestigen of weerleggen, bij exploratief gedreven onderzoek weet je niet precies waar een probleem ligt en ga je steeds specifiekere data analyseren om steeds dichter bij de oorzaak te komen.

Eigenlijk doe ik dus een onderzoek over hoe je een tool moet maken die je helpt met onderzoek. Het klinkt gevaarlijk recursief maar ik denk dat het mijn onderzoek en eindproduct hechter bij elkaar brengt.


Verder wordt ik ingewijd om mee te kunnen helpen met SPIL Games' interne projecten. Mijn bestelde werklaptop verschijnt langzaam aan de horizon en ik heb mijn handen mogen leggen op SPIL Games code en concept art. Op dit moment ben ik bezig met een 3D model te maken voor een nieuw personage. Werken met professionele concept art is uitdagend, maar het lukt best goed. Ik zou graag een screenshot bijsluiten maar ik geloof dat dat tegen het bedrijfsbeleid is.

Data Gathering & iOS Platform

Vandaag heb ik eindelijk die meeting weten te regelen met iemand van SPIL Games die bezig is met datagathering. Ze zijn bezig met een uitgebreid framework om bepaalde features te implementeren in alle iOS games die hier worden ontwikkeld. Onder andere aan bod gekomen zijn gameplay recordings, heatmaps van statische menu's en in-game advertenties. Op dit moment is het framework ontwikkeld voor Xcode: de onderliggende code voor Mac, iPhone en iPad applicaties. Unity projecten die gecompileerd worden voor Apple platforms worden uiteindelijk ook Xcode.

Ik heb hem mijn eigen prototypes laten zien en hij heeft me verwezen naar de SPIL Games wiki waar alle documentatie op terecht komt. Ik heb al een hoop geleerd over hun gebruikte technieken. Mijn heatmaps worden bijvoorbeeld lokaal gerendered op basis van alle remark records die zijn binnen gehaald.

Hun heatmaps hebben voor elke pixel van het scherm een record, en daar wordt direct naar toe geschreven. De hele heatmap bestaat dus op de server en er is dus überhaupt geen sprake van renderen.

Verder hebben we het nog gehad over de schaalbaarheid van mijn prototypes en optimalisatie mogelijkheden van mijn databases. Hij weet veel over data gathering en heeft me een hoop blogs en links gegeven over artikelen waarvan ik de basisprincipes en jargon van datagathering (en Business Intelligence) kan leren.

HTML5 Grafiek vervolg

Grafieken tekenen is ingewikkelder dan ik dacht. Voornamelijk het tekenen van een grid op de achtergrond.  Als je de dichtheid van de lijnen niet goed berekent worden de waardes onoverzichtelijk en de tekst onleesbaar. Als je geen logische intervallen kiest begrijp je de context van de data niet.

Het is al helemaal een nachtmerrie als de oorsprong niet linksonder in het scherm zit omdat het hele grid dan verschoven is en de tussenlijnen niet op fijne plaatsen terecht komen.

Een grafiek waar de oorsprong off-center is.

Verder heb ik ondersteuning voor meerdere datasets ingebouwd zodat je data kan vergelijken. Je hoeft alleen meer data in te voeren. In het kader van alles automatisch doen zijn er al een aantal kleuren ingesteld en alle benodigde berekeningen om alle data goed in beeld te krijgen wordt voor je gedaan tenzij je expliciet aan geeft welk venster je wilt zien.

Grafiek die meerdere datasets toont

Als er lange waarden op de horizontale as verwacht worden kan de tekst verticaal worden gezet zodat het beter naast elkaar past. Dit is onder andere handig wanneer de x-as tijd moet voorstellen. Ik ben op dit moment bezig om grafieken te kunnen tekenen die tijd weer geven. In dat geval worden waardes op de X-as gezien als een 'epoch', ofwel het aantal seconden sinds 1 januari 1970, een veelgebruikte aanduiding van tijd als een getal. Het weergeven van waarden langs de as is nog brein-brekender dan normaal omdat er zo veel formaten van tijd zijn en dat ze allemaal voor andere situaties geschikt zijn.

Grafiek met tijd op de x-as.

Het weergeven van grafieken met tijd werkt nog niet 100%, voornamelijk het weergeven van waardes langs de as afhankelijk van de schaal. Daar ga ik nog mee verder. De afspraak die ik zou moeten hebben gehad met een collega is verschoven, dus die komt iets later.

HTML5 Grafiek & Javascript

Ik ben verder gegaan met HTML5 en het visualiseren van game event data. Om verandering weer te geven zijn grafieken een stuk handiger dan pie charts. Daarom ben ik begonnen aan een robuuste HTML5 script die grafieken tekent. Het idee is dat je er X en Y co-ordinaten in gooit en dat de boundaries, kleuren en afmetingen automatisch worden berekend.

Javascript vind ik verreweg de meest vieze lelijke programmeertaal die er bestaat, met PHP kort op de hielen, dus alles enigzins netjes aan de praat krijgen is lastig. Je kan zien dat het hele object oriented idee een nagedachte was bij JavaScript en PHP. Het declareren van variabelen en functies is ook vreemd. De scope is anders dan de meeste programmeertalen en variabelen hebben blijkbaar geen type.

Screenshot van mijn grafiekscript in actie

Na wat gevloek heb ik een script gemaakt die bijna precies doet wat ik wil. De dichtheid en plaatsing van het grid klopt bijvoorbeeld nog niet als de oorsprong niet linksonder in het scherm zit. Ik heb ook nog een bijeenkomst met SPIL collega's die met datagathering werken (ik weet dat ze met heat maps bezig waren, daarom was ik zelf ook met heatmaps begonnen). Verder heeft Voodoo Runner een tussentijdse demo maandag, dus ik moet stand-by staan om te helpen met het maken van assets. Waar mogelijk ga ik morgen verder om de script te verbeteren en te koppelen aan event data.

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.