Why levels get measured
A level is a sequence of moments: an introduction, a challenge, a pause, a surprise, a finish. Designers arrange those moments on purpose, but players do not always experience them as planned. Playtest data is a way to compare the intended experience with the actual one.
This article covers three common sources of evidence, which are heatmaps, completion times and death locations, and the habits that keep you from drawing the wrong conclusion. Every number is hypothetical and is used only to show the arithmetic.
Level flow and what it looks like in data
Level flow is the rhythm of effort and rest as a player moves through a space. A good flow usually alternates tension and recovery, so players feel challenged without being worn out. Basic decisions about level layout, goals and guidance set up that rhythm, and data shows whether it landed.
Imagine a hypothetical level with five sections: a safe opening, a jumping challenge, a quiet courtyard, a combat arena and an exit. If the designer expects each section to take about the same time and testers spend most of their session in the arena, the flow is lopsided. The cause might be difficulty, weak encounter design, or an arena that is confusing to navigate. The numbers tell you where; they do not tell you why.
Heatmaps
A heatmap draws the places players went, stood, jumped or died as colored areas on the level map. Bright regions mean many events; dark regions mean few.
Heatmaps are useful for three questions:
- Do players take the route you intended? If a side path glows brightly and the main path is dim, players may be taking a shortcut or the main path may look uninviting.
- Do players see what you placed? An important item in a region nobody visits is an invisible item. Careful use of visual landmarks often fixes this.
- Where do players linger? Lingering can mean admiration, confusion or a hard fight, and only observation separates them.
A heatmap shows where, not what the player was thinking. Treat bright spots as places to watch the replay, not as conclusions.
Completion times
Completion time is how long testers take to finish a level or a section. Because a few very slow sessions can distort an average, the median is usually the steadier summary.
Here is a hypothetical example. Seven testers finish a section in 4, 5, 5, 6, 6, 7 and 21 minutes. The total is 54 minutes, so the average is 54 divided by 7, which is about 7.7 minutes. The median, the middle value of the sorted list, is 6 minutes. The 21-minute outlier is worth a closer look, since that tester may have been lost, but it should not set the target.
Spread matters as much as the center. If most testers finish in 5 to 7 minutes, the section is predictable. If times range from 3 to 25 minutes, the section probably depends on something that only some players figure out, such as a hidden trigger or a path that is easy to miss.
Death locations
For action games, marking where players fail is one of the most direct measurements available. Suppose 40 failures are recorded in a level across 10 testers. If 22 of them occur at one jump, that is 22 divided by 40, or 55 percent of all failures at a single spot. That deserves attention.
Then ask what kind of problem it is:
- A fair difficulty spike happens when the challenge is clear but demanding, and players improve on retries.
- An unclear spike happens when players fail because they could not see the hazard or did not know what to do. Retries do not help.
- A cheap failure happens when the player had no chance to react.
Counting attempts per player helps tell these apart. If most testers pass on the second or third try, the spot is probably a fair challenge. If several quit after eight attempts, the problem is more likely clarity or fairness. The distinction connects to how checkpoint placement affects the cost of each failure, since a long walk back magnifies frustration.
Avoiding over-fitting to a few testers
With small groups, it is easy to redesign a level around a handful of individuals. Over-fitting means tuning so closely to the testers you have that the design gets worse for everyone else. A few safeguards help.
- Look for repeats. One tester dying at a spot proves little. Four of ten dying there is a pattern.
- Mix experience levels. Testers who are all expert players will report a level as easy. Include some newcomers.
- Use fresh testers. People who have played earlier versions already know the solutions.
- Fix the cause, not the number. Making a jump wider will lower deaths, but if the real problem was an unreadable ledge, the number has improved while the confusion stays.
- Test again after changes. A fix is a hypothesis until another group confirms it.
Averages and totals from a dozen sessions are rough guides. They are enough to find big problems, but not to fine-tune a level to the second.
Combining the signals
The strongest conclusions come from several signals agreeing. If a section has long completion times, a dense cluster of deaths and a heatmap showing players circling the same area, something is wrong there. If only one signal flags a section, look more carefully before acting. Pair each number with a short observation or interview, and keep a record of what you changed so you can tell later whether it helped.