Telemetry in the QA Process
13 October, 2021
When people play games nowadays, we measure everything: the characters that they select, how many times that they’ve died, all of that stuff. This enables us to make better decisions as we conduct playtests -- we can hone in on a level where more people are dying more frequently, to name one example. The boss is too hard. There are a million possible problems.
I was at an industry show and saw some stuff that got me thinking a lot about telemetry in gaming. This was before telemetry was really a thing in our industry. Some people were unsure about it at first.
I ended up asking two of my QA folks to go through one of our games and to keep track of various stats, such as how many times that they died throughout the level. Instead of capturing events and dumping them out to a log, I asked them to count each tally manually on an Excel sheet by hand.
They played the whole game through and counted how many conversations and combat encounters that they had, among other things. We generated a nice report that outlined all of this information and sent it back to the Director of Design.
They were ecstatic; they described it as being like a window into the game that they had never had before. It was objective data that they would be able to rely on. They asked for more.
It was not practical to have human beings with stopwatches document all of these things, which was when introducing telemetry into the fold started to interest me greatly. Building the technology into our game gave us so much more to work with. Our developers were super excited about what we were showing them.
The guy who got me into telemetry at the conference was actually a programmer themselves; they ended up working with us as we implemented it into our work and process. Two or three of our own Engineers took these insights back to their desks; after a couple of days, they had come up with a prototype for a new system.
The technology was cool, and it was giving everybody the thirst. Within a few weeks, we had all of this new stuff, all of this extra data at our fingertips. This new source of information taught us so much about our own gameplay that we would be able to refer to later on.
- Once I was able to show our Director of Design the value of data like this, there was no turning back. Some people rely on what their gut tells them when deciding whether or not they’re going in the right direction. It’s good to have this type of intuition, but nothing beats real data.
- When workshopping toys based on kids’ shows, R&D teams will do something similar. They will have some kids watch a show in a room full of toys and when the kids lose interest in the show to play with the toys, they take note of the time to review the show's content and adjust it. It’s low-tech, but it’s still first-hand feedback from a real user of the product.
- Sometimes, you get a wall put in front of you. The goal for me is to make the best game possible, which is where I find the energy to continuously push forward. Nothing should be “just a QA thing”; everybody should feel some responsibility.
Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader
This was not a high point in my career. It's a story of single metric bias, how I let one measure become a 'source of truth', failed to manage up and ended up yelling at one of the most respected engineers in my team.
Chief Technology and Product Officer at Hive Learning
Your Org Team may as well be a Sports team. Let's explore how this cohesive, multi-skilled team can be optimized for Great Group Playoff.
Google Cloud Practice lead at Contino
Why DevSecOps matter and what's really in it for you, the team and the organisation?
Head of Engineering at Xero
Mrunal Kapade, an Engineering leader, based in Silicon Valley, shares tips that helped reduce attrition in the remote engineering teams while leading multiple teams from startups to Fortune 500 companies.
Director of Engineering at Inspire Energy
Teams have tremendous impact on the products on they build. T.E.A.M definition - Together Everybody Achieves More is true. A collaborative and empowered team builds great product versus the good ones.
Senior Software Engineering Manager at Anaplan