Vibe Arcade Blog

Dev stories, game design, and the art of building with AI

When Kids Playtest Your AI-Built Games, They Don't Lie

The best product feedback comes from users who won't tolerate bad UX, won't read instructions, and will tell you directly when something is wrong. Our kids are that user.

· Vibe Arcade

game design playtesting UX behind the scenes

The Accidental QA Team

There was never a plan to build a playtesting program. We build games, and there are kids in our house. My kids, their cousins, their friends. When a new game goes up, someone says "can I try it?" and then they're playing. We watch. They talk. And without meaning to, they've become the most effective QA team we've ever worked with.

This isn't structured usability testing. Nobody is filling out a survey. It's a kid on a tablet on the couch, or three kids crowded around a phone arguing about whose turn it is. The feedback is immediate, unfiltered, and often loud. When something doesn't work, they don't file a bug report — they just close the tab and walk away. That signal is the most useful of all.

Over the past year, this accidental feedback loop has driven more meaningful improvements than any automated test or analytics dashboard. Kids don't care how clever your code is. They care whether the game is fun, whether it's fair, and whether it works on the device they're holding. If any of those answers is no, they're done.

"It's Not Fair If Someone on Easy Gets a Higher Score Than Me"

Several of our games have multiple modes — easy, medium, hard, different board sizes, timed and untimed. When we first launched leaderboards, all scores went into the same ranking regardless of mode. We knew it was a simplification, but it seemed fine for a first pass.

The kids found the problem within about ten minutes.

"It's not fair if someone playing on easy gets a higher score than me on hard."

Delivered with the absolute moral certainty that only a child can muster, that sentence described an architectural problem we'd been hand-waving past. A leaderboard that mixes scores from different difficulty modes isn't just imprecise — it's unfair. Why would anyone play on hard if easy scores ranked higher?

The fix wasn't trivial. It meant rethinking how leaderboards stored and queried scores, supporting per-mode rankings across every game that had multiple modes, and updating the display to let players filter by the mode they cared about. A real architectural change — and it made the product genuinely better. All because a kid refused to accept something that wasn't fair.

Adults would have noticed this eventually. But adults tolerate imperfection in software. Kids don't. They see unfairness and name it immediately, without hedging.

The Surprise Hit Nobody Planned

We didn't set out to build an idle clicker. Pulse came from AI research that identified a gap in our library — action games, puzzle games, strategy games, but nothing idle. The AI designed the progression system, the energy mechanics, the prestige loops. We built it and put it up.

Among the kids, Pulse became the most-played game almost overnight.

They'd come back unprompted asking "can I check my energy?" They'd compare progress with each other — who had unlocked more generators, who had reached a higher prestige tier. The competitive element wasn't something we designed; they invented it by turning a single-player idle game into a social contest.

Idle clickers are typically associated with older audiences who understand exponential growth and optimization. But "tap, watch number go up, come back later and it went up more" turned out to be universally compelling. The kids didn't need to understand prestige math to enjoy progression. The AI had designed something genuinely addictive, and the kids proved it.

Tablet-First UX: Bugs That Only Surface on Kids' Devices

Kids mostly play on tablets and phones. Not desktops. Tablets on the couch, phones in the car, hand-me-down devices with older browsers. Our development and testing happened on desktop. The gap between those environments turned out to be where the most consequential bugs lived.

Pulse had an issue where energy generation broke when the tablet screen turned off. On desktop, you close the tab and reopen it — the game calculates offline progress. On a tablet, the screen turns off with the tab still open, entering a suspended state the offline logic didn't handle. Kids found this immediately because that's how they use tablets: play, set it down, pick it up later, expect progress.

Prism Break worked perfectly with mouse clicks but not swipe gestures. On a tablet, the natural interaction is to swipe, and the game didn't register it. Kids don't adapt to bad input — they don't think "I should tap instead of swipe." They just swipe, it doesn't work, and they leave.

The tap responsiveness problem was the most widespread. Across multiple games, interactive elements had a subtle delay on mobile. The fix was a single CSS rule applied globally — identified because we watched kids tapping impatiently on unresponsive screens. Adults tap once, wait, tap again. Kids tap five times fast and declare the game "broken." Only one response forces you to fix the problem.

"What Does This Do?" — The How-to-Play Problem

Adults who play games carry decades of accumulated genre knowledge. They know what "prestige" means in an idle game. They know that matching three of something clears them. They can figure out mechanics through trial and error, which masks a lot of instructional gaps.

Kids don't have that library of conventions. A kid staring at a nonogram grid full of numbers isn't going to intuit the rules — they're going to ask "what do the numbers mean?" and if nobody explains it, they're going to close the tab.

This feedback drove how-to-play sections across multiple games. Not lengthy manuals — kids won't read those either — but clear, immediate explanations of core mechanics. What do you tap? What are you trying to achieve? What do the symbols mean? The games that had these from the start performed better with the kid test group. The games that assumed genre familiarity lost players in the first thirty seconds.

The lesson extended beyond tutorials. If a mechanic isn't self-explanatory from the visuals alone, it needs an explanation. If the explanation is longer than two sentences, the mechanic might be too complex. Kids taught us that by simply not understanding things we thought were obvious.

What Kids Teach You That Analytics Can't

Analytics tell you what happened but not why. A high bounce rate could mean the game is bad, the load time is slow, or the start button is hard to find. Kids sitting in front of you eliminate that ambiguity. You see the exact moment they get confused. You hear "this is boring" or "this is so cool" or "that's not fair." You watch them ignore a tutorial popup and get stuck on the exact thing it was explaining.

Kids also actively request things. "Make a trivia game." "Make a racing game." "Can you make one where you draw stuff?" Some align with what our AI research identified as gaps. Some are entirely new. Our community ideas system exists partly because of this — the realization that players have strong opinions about what should be built next, and those opinions are worth capturing.

Why We Keep Doing It This Way

There's a version of this that looks more professional — structured sessions, A/B tests, formal user research. We'll probably get there eventually. But right now, the most valuable feedback comes from handing a tablet to a kid and watching what happens.

The leaderboard architecture that supports per-mode rankings — that came from a kid. The how-to-play sections that made several games accessible — those came from watching kids get stuck. The mobile UX fixes that made every game more responsive — kids tapping impatiently on screens.

The pattern is consistent: kids identify problems faster, articulate them more bluntly, and have zero tolerance for workarounds. They won't read your instructions. They won't adapt to your bad UX. They won't give you the benefit of the doubt. And they'll tell you exactly what's wrong, usually at a volume that ensures you hear it.

Every game on Vibe Arcade is built with AI. But the games get better because of the humans who play them — and the youngest, loudest, least patient humans have consistently given us the best feedback. We didn't plan it that way. We're glad it happened.


Related reading: How We Built Pulse · How We Built Prism Break · What Is Vibe Coding? · Vibe Coding Tools: From Chatbots to AI IDEs