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.
Monday, April 8, 2013
Wednesday, April 3, 2013
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.
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.
Subscribe to:
Posts (Atom)