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.