A developer rebuilt a 2D game as a 3D roguelite using Claude Opus and GPT Codex. Here's what it reveals about AI's limits in game dev.
Can AI actually build a full video game by itself? #
Not yet, and not without a person steering every decision. A YouTuber tested this directly by rebuilding a simple browser game called The Librarian into a 3D roguelite called The Librarian 2, using Claude Code with the Opus model to generate the initial build and GPT Codex to refine it afterward. The AI produced thousands of lines of working code and a playable 3D game in a matter of hours, but it also shipped with reversed controls, broken UI, buggy pickups, and balance problems that needed constant human correction. The experiment argues that coding models have gotten very good at generating game code, but game design, the part that makes a game fun, still depends on a person testing, judging, and iterating.
TL;DR #
- A developer used Claude Code with Opus to generate the first playable build of a 3D game from a single spoken prompt, then switched toGPT Codex for fine-tuning and balance work. - The original game, The Librarian, was a simple 2D loop where the player picks up books knocked off shelves by unruly kids before a chaos meter hits 100%. - The sequel added procedural level generation, permanent** meta upgrades**between runs, new boss types, and disaster events like earthquakes and tornadoes, aiming for the roguelite feel of an occasional “broken run.” - The first AI-generated build produced roughly 10,400 lines of code across 33 modules with zero external asset files, meaning every texture, sound, and character model was generated in code rather than imported. - Despite the impressive output, the initial version shipped with reversed movement controls, a meta-progression screen with no back button, and a bug where players couldn’t pick up visible books off the floor. - The creator used a markdown design document to hand off context between AI models, letting Codex pick up the project without re-explaining the entire game from scratch. - The takeaway is that AI can compress the grunt work of writing game code into hours, but playtesting, balancing, and taste still require a human in the loop.
How did the AI generate the initial 3D game? #
The process started with a spoken prompt rather than a written one. The creator used a voice-to-text tool to describe the game concept in detail: a 3D reimagining of The Librarian, with procedurally generated library layouts, new powerups, meta progression, boss encounters, and environmental disasters. That prompt was fed into Claude Code with the Opus model, along with a link to the GitHub repository for the original game so the AI had a reference point for the existing mechanics.
Claude Code ran for about ninety minutes, and during that time it did something notable: it opened the game in its own browser window, took screenshots, and used them to catch and fix visual bugs on its own. In one instance, it noticed the camera was clipping through the ceiling and corrected it. It also caught a balance issue where a “boss pressure” mechanic was dominating the chaos meter and rebalanced the systems so that death came from cumulative attrition rather than one dominant mechanic.
The output was substantial. The build totaled around 10,400 lines of code spread across 33 modules, and every visual and audio element, textures, materials, character models, sound effects, and music, was generated procedurally in code instead of using pre-made asset files. That’s a meaningful technical feat: no art pipeline, no downloaded sound library, just code generating everything at runtime.
What broke, and why does that matter? #
The AI’s own summary of the build flagged its weak points before the human even started playing: balance was untested against real players, a filing mechanic worked more like an instant pickup than a physical thrown object, and there were known bugs like a soft lock where players could carry books no shelf would accept.
Playtesting surfaced more problems immediately. The movement controls were inverted, making the game nearly unplayable until fixed. The meta-progression screen, where players spend earned currency on permanent upgrades between runs, had no way to navigate back to the main menu. A directional arrow on the in-game map didn’t actually point toward the player’s facing direction. And in one run, the player couldn’t locate a book sitting on the floor because the pickup logic wasn’t triggering correctly, despite the chaos meter clearly indicating something was on the ground.
None of these are exotic problems. They’re the kind of small, annoying issues that show up in any first playable build of any game, AI-generated or not. The difference is that a human studio would catch most of these in an internal playtest before anyone outside the team ever saw it. Here, they surfaced the moment a real person tried to play for five minutes.
Why switch from Claude Opus to GPT Codex mid-project? #
One coffee. One working app. #
You bring the idea. Remy manages the project.
The creator used two different tools for two different jobs. Claude Code with Opus was used for the initial generation phase, credited as the model currently best suited to producing visually impressive game output from scratch. Once the game existed as a working prototype, the project moved to GPT Codex running the 5.6 model for what was described as fine-tuning: fixing bugs, adjusting balance, and dialing in features that already existed rather than generating new systems wholesale.
To make that handoff work, the creator had Claude Code generate a detailed markdown design document describing the current state of the game before switching tools. That file became the bridge between models. Instead of re-explaining the entire game concept, mechanics, and bug list to a fresh AI session, Codex could read the markdown file and start with full context. The creator also pushed the project to GitHub, partly for backup and partly so earlier versions could be restored if a later change broke something or took the design in the wrong direction.
This two-model workflow, generate broadly with one tool, refine narrowly with another, reflects a practical pattern that’s emerging around AI-assisted coding generally: different models have different strengths, and treating them as interchangeable often produces worse results than picking the right one for each phase of work.
Does this mean game studios are becoming obsolete? #
The evidence here points the other way. The core argument of the experiment is that the roles game studios employ, like creative direction, art direction, systems design, and playtesting, aren’t disappearing just because code generation got faster. Before a AAA studio writes a line of code, it typically goes through mood boards, concept art, competitive analysis, and narrative planning. This project skipped almost all of that, focusing instead on a tighter loop: define the core mechanics, generate a build, play it, find what’s broken or unfun, and iterate.
Even with that narrower scope, the human input required was constant. Deciding what the “broken run” feeling should feel like, choosing which boss types and disasters fit the library setting, spotting that inverted controls made the game unplayable, judging that a menu screen “needs to look cooler,” these are subjective, contextual calls that the AI didn’t make on its own. It executed instructions and caught some of its own technical bugs, but the direction, the taste, and the definition of “fun” came from the person running the project.
The practical upshot for anyone building with these tools: AI coding models can now produce a playable 3D prototype with generated art and audio in a single working session, which is a real capability shift from a year earlier. But turning that prototype into something actually fun to play still runs through the same loop it always has: build, playtest, notice what’s broken or boring, and fix it. That loop is where the human judgment lives, and nothing in this experiment suggests it’s going away.
Frequently Asked Questions #
What is vibe coding?
Vibe coding refers to building software, including games, primarily through natural-language prompts to an AI coding assistant rather than writing code by hand. The developer describes what they want, the AI generates the implementation, and the developer reviews and course-corrects.
Which AI models were used to build this game?
The project used Claude Code with the Opus model for the initial 3D game generation, then switched to GPT Codex running the 5.6 model for bug fixes, balancing, and feature refinement.
Built like a system. Not vibe-coded.
Remy manages the project — every layer architected, not stitched together at the last second.
Did the AI generate art and sound assets too?
Yes. The build used zero external asset files. Every texture, material, character model, sound effect, and piece of music was generated procedurally in code rather than imported from separate art or audio files.
What genre is The Librarian 2?
It’s a 3D roguelite. Players clean up a library by chasing down kids who knock books off shelves, using procedurally generated levels, temporary in-run upgrades, and permanent meta-progression opened up between runs.
What were the biggest problems with the AI-generated build?
The first playable version had reversed movement controls, a meta-progression menu with no back navigation, a directional map indicator that didn’t track the player’s facing direction, and a bug that prevented picking up a visible book on the floor.