What 71 Playtests Taught Us About Indie Games

Since the end of August, our playtesters have played 47 indie games through QAping across 71 sessions. Every session ends with the same questionnaire, and what they trip over becomes an issue on the developer's board. That added up to 236 player-reported issues from 44 of those games.

We read all of them. The first surprise was what wasn't there. Only 4 of the 236 were blockers, the crash-or-softlock kind of bug most developers picture when they think about QA. That's fewer than 2%.

The rest were quieter. Players missed a button, didn't know if they had hit an enemy, or couldn't read the tutorial. None of these would show up in a crash log. Most of them cost the game its first ten minutes all the same.

These were very different games: tactics, deckbuilders, cozy RPGs, platformers, browser puzzlers and shooters. They still failed in the same handful of ways. Here are the seven we saw most.

1. “Did that hit?” Actions without feedback

This was the most common problem by far. It came up in nearly half of the games. A player does something, and the game doesn't clearly answer.

• Bullets and melee swings that land with no flash, sound or number.
• An enemy is defeated and the battle simply stops, with no sign of who won.
• Items are picked up (or not) with no confirmation.
• Commands are issued to units with no visual lock-on.
• A skill silently fails because there isn't enough mana.
• Resting restores HP, but nothing says so.

From the inside, you know the attack connected because you wrote the damage code. A new player only knows what the screen and speakers tell them. When those stay silent, players assume the game is broken or they're doing it wrong. Either way, they stop trusting their inputs.

The fix: every player action needs a visible and audible answer. Hits get a flash, a sound and a number. Failures say why. State changes such as “item acquired”, “turn over” or “HP restored” get a moment on screen.

2. The tutorial knows things the player doesn't

Nearly half of the games had a tutorial or onboarding issue. Tutorials rarely failed by being too long. They failed by quietly assuming knowledge:

• “Open the strategic map”, without saying which key opens it.
• Troops won't move because the game is paused, and the tutorial never mentions unpausing.
• A stage won't complete because the player skipped an earlier objective, and nothing tells them which one.
• Pressing Back once breaks the tutorial for good, forcing a return to the title screen.
• The NPC who explained a hard mechanic disappears, so the player can't read the explanation again.

Developers test tutorials by following them. Players wander off, press the wrong thing first, and come back.

The fix: every instruction names its input on the device being used. A tutorial has to survive the player doing things out of order. If progress is blocked, say exactly what's missing.

3. Text players can't read

Roughly two in five games had a readability problem. Dev machines hide it: a big monitor, a fixed resolution and eyes that already know what every label says.

• Fonts that are tiny at laptop resolutions, especially in tutorials and item descriptions.
• HUD panels drawn on top of dialogue, tooltips or each other.
• Windows that render behind the map or minimap they belong to.
• Text on busy, glowing backgrounds.
• Messages that disappear before a player can finish reading them.

The last one hits non-native English speakers hardest. Players in two different games asked for log and dialogue text to wait for a button press instead of running on a timer.

The fix: play a full session on a 13-inch laptop. Audit the draw order of every overlay. Let players advance text themselves.

4. A UI that assumes you already know the game

In roughly two in five games, players met icons, numbers or terms the game never explained. These included stat modifiers with no legend, card keywords like “enter” and “play” that sound the same, ability icons with no tooltip, and tile types that look different for reasons nobody explains.

The flip side was affordance. About a quarter of the games had something that looked clickable but wasn't, or something important that didn't look clickable. The most common victim was the end-turn button. Turn-based games kept hiding it as an unlabeled icon or a tucked-away corner control. Playtesters ran out of moves and sat stuck, unsure which control would end the turn. Several games also had no clear sign of whose turn it was.

The fix: every icon gets a tooltip and every number gets a label. Teach each term before the first card that uses it. Interactive things should look different from decorative ones. In turn-based games, make whose turn it is the loudest thing on screen.

5. Controller support as an afterthought

When a player picked up a gamepad, things broke surprisingly often:

• Keyboard prompts (“Press V”) shown to someone holding a controller.
• Menus that ignore the D-pad, or dialogue choices that can't be confirmed at all.
• No stick dead zone, so the character drifts on its own.
• A sub-menu that traps a controller player with no way back to the game.
• The confirm button closes a dialogue and reopens it in the same frame.

These bugs only appear when someone actually plays with a pad. If your Steam page says “controller support”, a full session with one belongs on your release checklist.

The fix: swap button prompts based on the last input device. Make every menu work with the D-pad. Give every screen a back button.

6. The missing basics

Almost one in three games was missing something players expect from any game:

• A volume slider, so players don't have to turn the music down in their OS.
• A pause button.
• A way to quit or forfeit a match without force-closing the game.
• A retry after death, instead of a trip back to the main menu.
• Mid-level checkpoints in long platforming sections.
• An undo for an accidental placement.

These are rarely the fun part to build, so they slip. Their absence still reads as “unfinished” within minutes.

7. Invisible walls and sticky geometry

About a quarter of the games had a collision problem. Examples include an invisible barrier left behind after breaking an object, a tree whose hitbox reaches far past its trunk, and a slope that looks walkable but isn't. Players also got wedged in terrain with no way out except dying.

Hit detection belongs here too. Projectiles passed through bosses, and hitboxes in an arcade game were wide enough to feel unfair. Players forgive hard games. They don't forgive deaths they think weren't their fault.

Why developers miss these

None of these problems are hard to fix. Almost every issue above is an afternoon of work. They survive because the person making the game is the only person who can't see them. You know where the end-turn button is, you know the attack landed, and you read the tutorial text two hundred times while writing it.

That's why playtests with people who have never seen your game are valuable, and why the cheapest time to run one is before you share a demo. A first-time player gives you the next ten thousand players' first ten minutes.

A checklist before your next playtest

1. Does every action have a visible and audible result, including failures?
2. Does every tutorial step name its input, and survive being done out of order?
3. Is all text readable on a 13-inch laptop, and can players advance it themselves?
4. Does every icon, number and keyword have a tooltip or a first-use explanation?
5. In turn-based games, is whose turn it is obvious at a glance?
6. Does the game play start to finish on a controller, if you claim support?
7. Is there a volume slider, pause, quit, retry and undo?
8. Have you walked into every wall and broken every breakable object?

Then hand your game to someone who has never seen it, and watch them play.