8 steps
Make your game better with data
For: A game that people have played, when you want to know what to fix next.
You do not need many players, you need the right questions in the right order: what to record, where people stop, where they die, and whether a change helped. Nothing here is about money.
The steps, in order
- 1
Game data
What to Measure in Your Game, and What to Skip
Measure what could change a decision about your game: where players stop, lose, retry or go quiet. Start with five events, each tied to one question.
Why here: Before any code: decide the five things worth recording. Recording everything is how numbers become noise.
- 2
Game data
Privacy in Game Tracking: Keep It Anonymous
Record what happened, never who played: no accounts, device ids, IP addresses or clock times. Ask first, as anonymous data can still need consent.
Why here: Second, not last: tracking starts switched off and anonymous, or you build on something you must tear out later.
- 3
Code recipe
Game event log
Your AI adds a small log to your game that writes down what happens, such as a level started or a player died, in a plain file or in the browser on the player's own device. It keeps no accounts, device ids or IP addresses, sends nothing anywhere, and records nothing until the player says yes.
Why here: The one format every later recipe reads. Get it in now and every question below is a query, not a rewrite.
- 4
Wiki entry
One bug sent the same event ten thousand times and ruined my numbers
Tracking data has its own bugs: retries that arrive twice, names nobody defined, broken timestamps and loops that flood the log. This entry shows a small filter that keeps the numbers believable and tells you what it threw away.
Why here: Real logs are dirty: one bug sends an event ten thousand times. Clean before you count, or every number below lies.
- 5
Code recipe
Where players drop off
Your AI takes the stops a player should pass, in order, and counts how many got to each one, which some people call a funnel because the list narrows from stop to stop. It names the stop where the most people leave, says how sure that is, and flags anything that does not fit your plan.
Why here: The first real question: where do people stop? A funnel answers it with ten players, and it tells you where to look next.
- 6
Wiki entry
The map shows most deaths in the corridor, but is the corridor really dangerous?
A heat map of deaths mostly shows where players walk, not where they are in danger. A busy hallway lights up even when it is harmless, and a side room with a nasty trap hides. This entry shows what to divide by.
Why here: Deaths mislead without visits: the corridor everyone crosses looks deadly. Divide, and the real trap appears.
- 7
Wiki entry
How many sessions end in frustration, with deaths piling up before the player leaves?
A player who leaves after a calm stretch is different from one who leaves after dying again and again. This entry shows how to tell the two endings apart from your event log, and what to leave out so the share is not inflated.
Why here: The number that predicts quitting: sessions ending in a pile of deaths. It separates hard-but-fair from frustrating.
- 8
Code recipe
Compare two versions
You changed something and a number moved, and your AI works out whether that is a real difference or could just be luck, and how many players it would take to find out. It works on counts such as wins and on numbers such as seconds, and it will not call a gap real on too few players.
Why here: Last, the discipline: a change helped only if the numbers say so with enough players, and this recipe tells you how many that is.
At the end
You can say which level loses players, whether a death was the player's fault, and whether your last change made it better.
What this rests on
- Making "Big Data" Work for 'Halo': A Case Study
Shows how a big studio collects player events live from the game so designers can see what players actually do, and what it takes to set that up.
- Opinion: Balance and Flow Maps
Explains why a plain map of where players die is misleading, and how subtracting deaths from kills shows which spots are really safe or dangerous.
- AI for Dynamic Difficulty Adjustment in Games
Explains why a game that is too easy bores and one that is too hard frustrates, and how measuring the player's performance can tune difficulty automatically.
- Why You Only Need to Test with 5 Users
Shows why a handful of testers already reveals most problems, and why several small test rounds with fixes in between beat one big test.
- Trustworthy Online Controlled Experiments: Five Puzzling Outcomes Explained
Explains how to compare two versions of something fairly (A/B test) and why surprising results often come from mistakes in the test, not from the players.
- Game Analytics: Maximizing the Value of Player Data
A broad book by industry and research experts on what to measure in games, from collecting data to maps and player behavior, as the general reference for this path.
Say this to your AI
Follow the Spielerando learning path "Make your game better with data" (get_path better-with-data) for my game, step by step, and tell me at each step why it comes now.Or skip this and connect the MCP: your AI then finds all of this by itself.Connect the MCP