I run a community Playtesting and Design Slam every other month for devs in Sydney. It’s a chance for devs of all sizes (commercial to indie) to meetup, get feedback on their games and debate game design. This month I’ve asked Aussie devs to share their tips and techniques for gathering player data to help guide their game design.
What are you using to analyse player behavior in game?
James Murchison (UNSW): “Parse along with UniWeb and UniParse to interface with Unity. It is a little more work on the setup phase, in that you have to design how you’re going to store your data, but all of your data classes can have a many to many relationship, which means you can mine SOOOOOO much information from them. We’re at a point now where with a little more work we can essentially reconstruct every play through from every player.
This method comes after a couple of months of testing various solutions on Unity. Besides rolling your own server, that is the cheapest and best solution I’ve found. Something I will note for web developers, is that it has a rest based API, which means you can easily build your own website to analyze the data in real time!
Ben Britten Smith (Tin Man Games) “We use Flurry for all our mobile stuff and Playtomic for the desktop stuff. Both super easy to setup. Flurry is pretty basic but still quite powerful once you wrap your brain around the best ways to record events, and Playtomic has a ton of really useful things like heatmapping etc.”
Bruce Thomson (Nnooo): We use old fashioned standing and watching. It helps us immensely in early development, and as we develop for consoles and handhelds we can’t access all the fancy desktop and mobile tools. It’s important (and hard to resist) to NOT interact with the player while they’re playing! We ask 3 questions at the end: What did you like? What didn’t you like? What confused you?”
Ben Britten Smith (Tin Man Games): “Ahh yes, the classic three questions! I do love me some super fancy heat-mappy-clicky-county analytics, but yeah, nothing really beats being able to watch people as they fumble around the interface that you thought was so user-friendly, get stuck and confused about what to do next because you haven’t signposted the gameplay well enough, ignore all of the instructional text that you spent so long writing, find all of the crashing bugs you thought had been fixed, etc. 🙂
Standing and watching (or even better, getting video) is absolutely the 100% best thing you can do during early playtesting and design. Can’t recommend it enough!”
Rebecca Fernandez (Convict Interactive): “We do surveys. Working out the correct questions, however, and the way in which those questions are worded can be quite difficult.”
Nikhil Suresh (REVISION.9): /sarcasm ON “My game is so good people don’t make any mistakes in it and it’s the best implementation ever and never has to change.” /sarcasm OFF. “At least that’s I thought when I first showed off a game.”
Nikhil’s last point underscores why playtesting is so critical in game development.
You are making an experience that requires the presence of a player. You can have all the sound, art and code done, compiled and ready to go – but until a player sets hands to controls you don’t have a complete game.
The sooner you involve a player in your game design the sooner you can start developing across the whole experience.
Can you imagine how horrible it would be to spend years pouring sweat and time and money into development only to release something that players don’t enjoy?
Oh wait, that happens all the time. And how well does it turn out for those studios who develop in isolation, relying on the occasional focus group test safely quarantined away from production, gambling everything on a positive player response at launch?
Well, there aren’t many of them around anymore.
Now I’m not arguing for releasing your game into the wild before it’s ready, but player interaction is one of the few elements distinguishing a game from other mediums (film/music/story) – and it’s what makes game design so damn COOL! Not only are you designing an experience but you’re designing HOW another person experiences that subject for the first time.
Case in point: One of the indies I coach just called me over to test the first pen and paper prototype of his new game. He started trying to tell me how to play and I shushed him – I wanted to see how well he designed the “interface” to guide me through play.
After the first move I was stumped, there was too much data on the table to see what I could do next to progress play. He saw that and immediately realised what he could do to help guide my eyes to the next action he wanted me to take – without me being AWARE of being guided.
In fifteen minutes he could have another version of the game ready for me to play.
Compare that to a studio waiting until launch to realise that they’re losing players within the first few minutes of gameplay.
Edit – More tips from stealth indie James Murchison:
“Totally also forgot this awesome article series on rolling your own analytics system. Would be handy to roll your own local database at an event like Bits and Pieces 😉