Claude Opus 5.5 Recreates Pokémon Red in Code: No Images, Pure Pixel Programming

Claude Opus 5.5 rebuilt all of Pokémon Red in 25,000 lines of JS — no images, pure code.
A developer used a single natural language prompt and Claude Opus 5.5 to generate ~25,000 lines of JavaScript in about three days, fully recreating Pokémon Red in the browser. The project, Pokémon Claude Red, uses no image or audio files — all 151 Pokémon are drawn from geometric shapes, and music is synthesized in real time via JavaScript. It includes 224 maps, 8 gyms, the Elite Four, and classic bugs like MissingNo., with map data sourced from the pret/pokered disassembly. Automated bot testing ensured stability, and the source code is open on GitHub.
A developer used a single prompt to have Claude Opus 5.5 rebuild the entirety of Pokémon Red from scratch — without using a single image file. All 151 Pokémon, 224 maps, every line of dialogue, and every melody are rendered pixel by pixel in the browser through code alone. The project, called Pokémon Claude Red, is playable directly in desktop or mobile browsers.

One Prompt, Three Days, 25,000 Lines of JavaScript
The entire project began with a single message typed into Claude Code: "using only pixels directly remake a beautiful pokemon red remake … absolute pixel art perfection. keep the story exactly as pokemon red."
According to the author, Claude Opus 5.5 produced approximately 25,000 lines of JavaScript over roughly three days. The human's role was reduced to support work — playing through the entire game, documenting bugs, and feeding that feedback back to the model for fixes. This division of labor — "AI writes code, human tests" — hints at one possible future shape of software development collaboration.
No Image Files: Every Pixel Is Code
The most counterintuitive aspect of this project is that it loads zero image assets. The game screen is drawn into a 320×180 canvas, generated pixel by pixel.
Each Pokémon is not a sprite but defined by a set of geometric shapes — ellipses, polygons, and spots — colored and outlined at runtime. In other words, Pikachu is not a PNG file; it's a piece of code that draws Pikachu. This approach transforms "art assets" entirely into "program logic," placing significant demands on the model's spatial understanding and visual abstraction capabilities.
The same applies to background music: the original melodies were rewritten as JavaScript to be generated in real time, rather than playing audio files.
This technical approach is known in graphics programming as Procedural Generation. Unlike traditional games that rely on pre-made bitmaps or sprite sheets, procedural graphics encode visual content as algorithmic descriptions — every shape, color, and positional relationship is computed at runtime. The advantage is an extremely small file size (the entire game is pure text code) and lossless scaling at any resolution. But the demands on the generative model are high: it must "imagine" the outline of a Pikachu in its context window and decompose it into geometric primitives with precision, without referencing any existing image. The Web Audio API used for background music follows the same principle: notes, rhythm, and timbre are all synthesized in real time via JavaScript — essentially a code-written score interpreter.
Completeness: 8 Gyms, the Elite Four, and Even the Bugs
In terms of scope, this is no tech demo — it's a claimed fully completable game:
- All 224 maps
- 8 gyms and the Team Rocket storyline
- The Elite Four and Champion battle
- All 151 Pokémon
Map and data sourced from the well-known pret/pokered disassembly project, while every line of dialogue was rewritten from scratch. Even more remarkably, the author rebuilt the classic original bugs by their underlying mechanics — including the famous MissingNo. glitch and the "catch Mew" trick — reconstructed based on how the original code actually worked, not just mimicking the surface behavior.
pret/pokered is a community-completed full disassembly of Pokémon Red/Blue, reverse-engineered from the original Game Boy ROM into readable, annotated Z80 assembly code. This allows developers to precisely understand the coordinate layout of every map, NPC trigger conditions, and the implementation details of battle formulas — without guesswork or visual inference. MissingNo. could be recreated "by principle" precisely because its spawn mechanism — the interaction between player name bytes and specific offsets in the map encounter table — is documented in the disassembly code. This also shows that the project isn't purely "AI reconstructing from memory," but rather uses structured historical source code as a foundation, with the model responsible for translating that data into modern JavaScript.
Bot Testing and Mobile Layout Switching
To verify the stability of such a large generated codebase, the author used automated bot testing: having bots talk to every NPC on every map and run thousands of random battles. Regression testing at this scale is practically impossible to achieve through manual effort alone.
Mobile support was also implemented: holding the phone vertically gives a Game Boy button layout, while landscape switches to a GBA layout. The author also recommends players seek out a few classic moments — watching the old man's Pokémon catching tutorial, flying to Cinnabar Island, and surfing up the eastern coast.
Notably, the promotional trailer and explainer video were reportedly "oneshotted" by Opus 5.5 as well.
The automated regression testing approach the author used combines what game QA teams call fuzz testing and traversal testing — script-controlled bots systematically triggering every reachable game state to expose crashes and data anomalies at edge cases. For AI-generated codebases, this method is especially necessary: models generating long code can introduce implicit dependencies or variable naming conflicts between different functions — errors that are hard to catch by reading the code but surface randomly at runtime. Thousands of random battle tests effectively apply Monte Carlo coverage to core logic like damage calculation, status effect stacking, and AI decision-making, which surfaces probabilistic bugs far more effectively than manually enumerated test cases.
What This Means
Setting nostalgia aside, Pokémon Claude Red reads more like a stress test of the upper bounds of large model coding capabilities. It simultaneously challenges several hard problems: consistency across long contexts (25,000 lines without breaking down), visual abstraction for purely procedural graphics, and holistic modeling of complex game systems (combat, maps, branching narrative).
A defining characteristic of projects like this is the shift in the human role — from "author" to "reviewer and tester." When a model can continuously produce and iterate on projects of this scale based on feedback, the development process itself may need to be redefined.
One note: this is a free fan project with no official affiliation with Nintendo. The source code is open on GitHub (github.com/levy-street/pokemon-claude-red), and interested developers can explore its pixel rendering and generation logic firsthand.
Related articles

Gaussian Process Bandit Optimization: Exploration Strategies and Inference Regret Guarantees
Cumulative regret guarantees in Bayesian optimization fail to reflect final recommendation quality. This article examines a new study that provides inference regret guarantees for Gaussian process bandit optimization through exploration query strategies and fill distance analysis, validated on hyperparameter optimization and control tasks.

The Most Detailed Codex Guide on Bilibili: From Installation to Real-World Practice
The most detailed Codex guide on Bilibili: from app store installation to daily work mode configuration, with a real coffee shop project demonstrating file organization, data extraction, dashboard creation, and other practical tasks. Learn to use Plan Mode and desktop pets to leverage Codex efficiently.

Appearance Compensation in Volume Rendering: Why RGB Accuracy Cannot Guarantee Density Correctness
Volume rendering research reveals that volumetric data perfectly reproducing external RGB views may still contain density errors: appearance compensation can double central density and keep external rays unchanged even when L2 error exceeds 14.52%. Density recovery depends on appearance capacity, spatial resolution, and measurement design.