Playtesting Your HTML5 Game Before Submission: A Practical Checklist

Portal review checks whether your game loads, follows content policy, and handles ads correctly. It does not check whether the tutorial is confusing, whether level three has an unfair difficulty spike, or whether a first-time player understands the goal within the first few seconds. That's on you, and it needs real playtesting, not just your own repeated runs — you've played your game hundreds of times and can't see it fresh anymore.

Watch someone who's never seen the game play it cold

Hand it over with zero instructions and stay quiet. Every urge to explain a control or point at the goal is a data point — if you feel the need to intervene, that's exactly the moment a real first-time player without you in the room would get stuck or quit. Write down each moment you wanted to help, don't act on it.

What to actually watch for

• Do they understand the goal within the first 10-15 seconds, without reading a wall of instructions first?
• Where do they die or get stuck repeatedly — is it a genuine skill wall, or an unclear rule they never had a chance to learn?
• Do they actually notice and read tutorial prompts, or click past them on reflex the way most players do?
• Does the pacing feel right for someone seeing this for the first time — not for you, after fifty playthroughs where everything feels obvious and slow?

Test on real hardware, not just your dev machine

Your development machine is almost always faster than the median player's device. Test on an older or mid-range phone, a different browser than the one you build in, and at least one smaller screen size — frame drops, layout overflow, and touch-target sizing issues that never show up on your setup are often the first thing a genuinely average player hits.

Keep a bug-report habit, not a memory

Write down every issue the moment a playtester hits it, with exactly what they were doing when it happened. Playtesters reliably forget to mention things unless asked directly right after — "anything weird happen?" a session later gets you a fraction of what you'd have caught by writing it down live.

One playtester isn't a pattern

A single person's confusion might be a fluke specific to them. Run at least two or three different testers before treating a stuck point as a real design problem worth fixing — if multiple people independently hit the same wall, that's a signal; if only one does, it might just be them.

This catches the UX and difficulty issues that live in the game itself — for the separate list of policy and technical reasons submissions actually get bounced, see why HTML5 game submissions get rejected, and check the submission rules before you send a build.