▶ YouTube Summaries

• YT :: https://www.youtube.com/watch?v=QtsOHdJgOJQ
• Original title :: Dad and Son Vibe Code an RPG Game

Replay of a livestream in which Kun Chen and his 8-year-old son Eddie design and build a small 2D top-down RPG entirely by talking to an AI coding assistant. The session doubles as a demo of Kun's own AI app-building product, walking through its "throwaway prototype lab" workflow: instead of asking the assistant to build the full game in one shot, they spin up small disposable prototypes to explore each design decision (art style, spell mechanics, boss fight, cutscenes) in parallel, compare the results together, and only then tell the assistant to lock in the chosen options and assemble them into the real, playable game.

The product and workflow

The app (referred to in the transcript, garbled by ASR, as "Hibbit") is a chat-based building tool where the user talks to an AI agent named "Bit." Eddie describes it as "kind of like a chatting app where you can make a game," with Bit as "your buddy that will work with you when you're making the game." Input is voice, so the conversation between father and son is transcribed and interpreted by Bit directly — including its own name, which gets voice-mangled into "bet" and "bits" over the course of the stream.

The core workflow demoed:

• State an idea directly to Bit in conversational voice, including asides between the two humans deciding what they want.
• For any decision with multiple plausible answers (art style, attack type, boss design, fireball rework), ask Bit to spin up a disposable "lab" — a minimal standalone prototype — to explore 2-3 options rather than committing blind.
• Run several labs concurrently ("a factory" of parallel prototype projects) so exploration of unrelated decisions (art direction, spell mechanics, boss fight) doesn't block on each other.
• Playtest each prototype live, compare options as a family, and verbally lock in the winner.
• Once all the individual decisions are made, tell Bit to consider everything decided so far and assemble it into one real, playable build.
• After playing the assembled build, give consolidated feedback (bugs, missing controls, pacing) and let Bit revise in place.

Design decisions made through the labs

• Concept: a top-down 2D "rogue-like" RPG where a wizard's friends have been kidnapped by monsters; side quests along the way yield tools/information needed to reach and rescue them.
• Art style lab: compared pencil-sketch vs. pixel art; pixel art was chosen.
• Spell/attack lab: three prototype spells were tried in a 3D test scene — thunder (chains/jumps between targets), fireball (basic projectile), and beam of light (penetrates through multiple targets). Thunder and beam were liked for having "a unique mechanic"; fireball felt too plain by comparison. They also decided mid-stream that the real game must be 2D top-down, not 3D like the prototype.
• Fireball rework: asked Bit for more interesting fireball variants and it produced four options (remote burst — throw then trigger to detonate; flame trail; growing/charge-up fireball that trades size for speed and risk; and a fourth). "Remote burst" was chosen.
• Boss lab: originally prototyped as four escalating trial bosses with distinct dodge-pattern mechanics (ground slam/telegraphed attacks, a rotating "lane" beam, a cross-shaped double-lane attack, a randomized horizontal/vertical variant). After playing all four, Eddie decided he preferred a single boss with much more health (500-750 HP) and multiple combined attack patterns, rather than four separate bosses — "less predictable," and appropriate as a final boss. Losing to the boss means respawning at the current fight and dropping loot on the ground (Minecraft-style), which must be picked back up.
• Friends/rescue mechanic: the single boss drops one key on defeat, used to unlock a golden door that frees all captured friends at once (revised from an earlier idea of one key per boss). Friends are human, though some optionally have companion pets; pets exist for flavor and are not meant to be mechanically significant.
• Cutscenes: added in parallel to the rest ("polished animated story scenes"). Opening cutscene establishes the premise — friends camping and roasting marshmallows are abducted by monsters. Closing cutscene reunites everyone and sends them home. Mid-game cutscenes deliver story beats tied to side quests (e.g., a companion cat named Pip finding clues, a moon shrine granting a buff).

First playable build and revisions

The assembled first build used mobile-style on-screen joystick and tap controls (a default that didn't fit a desktop livestream) and was very short — a single mostly-empty room, one side quest, no real dungeon complexity. Father and son cleared it quickly and gave Bit a consolidated punch list:

• Swap mobile joystick/tap controls for PC-appropriate controls: WASD movement, mouse click to cast spells.
• Make the dungeon larger and more complex — more obstacles, consider procedurally generated maps — since the first pass felt too short.
• Add more side quests beyond the single existing one, with concrete examples from Eddie: a wobbly/partially-broken rope bridge requiring careful "parkour" jumping across safe boards, and a suggested (not built) hunger-bar mechanic where the player forages berries.

Bit then revised the build with cutscenes integrated and the new bridge side quest. Playtesting surfaced a genuine bug — after the bridge cutscene, the player character got stuck inside a wall and couldn't move — which they reported to Bit conversationally ("whenever we step onto the bridge, we get stuck into the wall") for a fix, alongside a smaller cosmetic note that the thunder spell's visual effect (a plain yellow circle) didn't read as electricity. They also tried a difficulty-select screen ("wizard storm" - more hearts/heals, faster cooldowns) that had reverted to on-screen mobile controls, confirming the control-scheme feedback hadn't been applied yet in that build.

By the end of the session they completed a full run of the revised level — crossing the bridge, activating a moon shrine buff, defeating the boss, collecting the key, and freeing the friends — closing with a "next trip: monster-proof marshmallows" story beat and a completion screen. They agreed to keep iterating on boss balance and mechanics in a future session.

Takeaways

The episode is less about the RPG itself than about a reusable pattern for building with an AI coding agent as a non-technical collaborator (here, an 8-year-old): decompose the target into independently decidable design questions, prototype each one cheaply and in parallel rather than asking for a finished product up front, make the comparison and decision a shared human activity, and only fold locked-in decisions into the "real" build once they're validated by play — treating bugs and missing features discovered during playtesting as just more input to hand back to the agent in plain conversational language.