I vibe-coded 5 games. Only 1 was worth playing.

We wanted to stress-test a claim that keeps showing up in every AI product launch: that vibe coding has gotten good enough to make real games.

So we ran an experiment. Five different AI game-making tools. Five different genres. Same ground rules for each: one natural-language prompt, no manual code edits, no follow-up refinements. Whatever came out of the first generation was what we played.

The results were honest, sometimes impressive, and mostly disappointing.

---

The setup

We picked five genres that cover a wide range of game design challenges — movement physics, spatial reasoning, real-time action, narrative systems, and speed-based feedback. For each, we wrote a prompt that a normal person might actually type. Nothing hyper-specific, nothing adversarial. Just a clear description of a game we'd want to play.

Then we played each one for fifteen minutes and asked a single question: would I keep playing this if nobody was making me?

---

Game 1: The platformer (Tool A)

The prompt: "A 2D platformer with wall-jumping, double-jump, and collectible gems across 5 levels with increasing difficulty."

What we got was technically a platformer. A square character moved left and right, jumped, and could wall-jump off surfaces. Gems existed. Five levels loaded in sequence.

But playing it felt like controlling a cardboard cutout on a rail. The character had no acceleration — full speed the instant you pressed a direction, full stop the instant you let go. The double-jump had identical force to the first jump, which made it feel less like a deliberate mechanic and more like a bug. Landing produced no visual response. No squash, no dust, no camera settle. The character simply was in the air and then was on the ground.

It worked. But it felt like a physics demo, not a game.

Game 2: The puzzle game (Tool B)

The prompt: "A Sokoban-style puzzle game with crates, pressure plates, and 10 levels that teach mechanics one at a time."

This one got surprisingly close. The grid-based logic was sound — crates pushed correctly, pressure plates triggered doors, undo worked. As a puzzle, it functioned.

The problem was everything around the puzzles. Crates teleported to their new positions with zero animation. Pressure plates activated with no feedback — no click, no color shift, no particle. Doors opened instantly. The camera was static and slightly too zoomed in, so on later levels you couldn't see the whole board without memorizing it.

A puzzle game lives or dies on whether solving a puzzle feels satisfying. This one felt like filling out a form correctly. You got the right answer, but nobody celebrated.

---

Game 3: The top-down shooter (Tool C)

The prompt: "A top-down twin-stick shooter with waves of enemies, weapon pickups, and a score counter."

This was the most visually complete of the five. Enemies spawned in waves. Weapons dropped. The score went up. It even had a game-over screen.

And it was miserable to play. Bullets left the gun with no muzzle flash, no recoil animation, no screen response. Enemies died by disappearing — no death animation, no hit effect, no audio feedback. The character moved at a constant speed with zero momentum, making dodging feel robotic rather than desperate. Weapon pickups changed your bullet pattern but gave no indication of what changed or why it mattered.

The whole experience felt muted. Like watching a shooter through soundproof glass.

Game 4: The RPG (Tool D)

The prompt: "A simple RPG with a town, a dungeon, turn-based combat, and an inventory system."

Tool D produced the most ambitious output. There was a town with NPCs. A dungeon with rooms. Turn-based combat with attack, defend, and item options. An inventory with potions and equipment.

But ambition without polish is just scope. Walking into combat had no transition — the screen just changed. Attacking played a generic slash animation while a number floated up, disconnected from any sense of impact. The inventory was a flat list with no icons, no descriptions, and no feedback when equipping items. Exploring the dungeon felt like clicking through a slideshow.

Every system existed. None of them breathed.

---

Game 5: The racing game (Tool E)

The prompt: "An arcade racing game with drifting, boost pads, and 3 tracks."

This was the one.

Not because the prompt was better — it was arguably simpler than several others. Not because Tool E generated more code or more features. The track count was right, boost pads worked, and the drift mechanic existed, just like the other tools delivered on their respective prompts.

The difference was in how it felt. The car had weight. Turning at speed built up visible tension before the rear broke loose into a drift. The camera pulled back slightly during boosts and pushed forward during tight corners. Hitting a boost pad produced a brief speed-line effect and a subtle zoom. Colliding with a wall sparked and scrubbed your speed with a satisfying deceleration curve instead of a dead stop.

None of these details were in the prompt. The tool added them because it understood, at some level, what makes a racing game feel like a racing game.

We played it for forty-five minutes. Nobody had to be convinced.

---

The pattern

All five games "worked." If you defined success as does the thing the prompt described, every tool passed. Crates pushed. Enemies spawned. Cars raced.

But only one was worth playing. And the gap between "functional" and "worth playing" was always the same set of missing pieces:

• No movement polish. Characters and objects had no weight, no momentum, no physicality.
• No feedback loops. Actions happened in silence. Hits didn't feel like hits. Wins didn't feel like wins.
• No camera intelligence. The camera either sat still or followed rigidly, never anticipating, never creating drama.
• No micro-transitions. Every state change was instant — menus, deaths, pickups, level loads. Instant reads as broken.

These aren't advanced features. They're the minimum standard for a game that feels like it respects the player's time. And four out of five tools ignored them completely.

---

What this actually tells us

The vibe coding debate has been stuck on the wrong question. People argue about whether AI can "really" make games, as if the bar is functional completeness. Can it generate combat? Can it handle inventory logic? Can it build a level?

Yes. Clearly, yes. All five tools proved that.

The real question is whether the output is something a human being would choose to play for more than ninety seconds. And the answer, for most tools, is no — not because the games are broken, but because they're lifeless.

The difference between a game and a tech demo is feel. It's the three frames of hit-stop that make a punch land. The slight camera lead that makes a race feel fast. The crate sliding into position with a satisfying thunk instead of teleporting.

Vibe coding that ignores feel is just scaffolding. It's fast scaffolding, impressive scaffolding, but scaffolding all the same.

---

Where this is heading

The tool that made the racing game got something right that the others missed. It treated game feel as part of the generation process, not as a cosmetic layer you add afterward. Polish wasn't a follow-up prompt — it was built into the first output.

That's the approach we're building at Exekite. Not just generating games that work, but generating games that feel like someone gave a damn. Controls with weight. Feedback that lands. Cameras that know what matters. The stuff that separates "I made a game" from "I made a game people want to play."

Because vibe coding was never supposed to be about producing prototypes. It was supposed to be about making games.