Claude Opus 5.5 Builds a Retro J2ME Shooter From a Single Prompt

A Reddit user's experiment has once again pushed the boundaries of what AI can do with code. With just one sentence, he had Claude Opus 5.5 build a fully playable 3D shooter for a twenty-year-old feature phone — and by his account, the experience rivaled commercial titles from Gameloft back in the day.

One Prompt, One Complete Game

The user's request was remarkably simple: make a Duke Nukem 3D-style shooter for an old J2ME phone. What's surprising is that Claude didn't just return a pile of disconnected code — it delivered a complete, integrated game project.

It wrote a Wolfenstein 3D-style pseudo-3D engine in Java, with one critical design decision: integer-only arithmetic throughout — the key constraint that allows the game to run smoothly on ancient hardware. The engine supports textured floors, a moonlit sky, fog effects, and other visual elements that would have been considered technically impressive on feature phones of that era.

The choice of integer math reveals something worth noting: the model didn't just understand the surface-level request of "make a shooter" — it also inferred the implicit constraint that old phone hardware can't handle floating-point arithmetic, and made the correct engineering trade-off accordingly. That kind of platform-aware judgment has traditionally required experienced developers to get right.

J2ME (Java 2 Micro Edition) was a Java mobile platform specification introduced by Sun Microsystems in 1999, designed specifically for feature phones with severely limited memory and processing power. A typical J2ME device had less than 1MB of heap memory, a CPU running below 100MHz, and generally no floating-point unit (FPU). This meant any math involving decimals had to be emulated in software by the CPU — tens of times slower. As a result, J2ME game developers universally relied on fixed-point or pure integer math for trigonometry, distance calculations, and other geometric operations — typically by scaling all values up by 1024 or 4096, storing them as integers, and scaling back down after computation. This technique has nearly vanished from modern development and represents fairly obscure historical knowledge. The fact that Claude automatically identified and applied this constraint suggests its training data includes substantial depth on retro platform development.

Full-Pipeline Generation: Art, Music, and Sound

What makes this case truly remarkable is how far the scope extends beyond writing code.

For the art, Claude didn't rely on existing assets — it wrote its own 3D renderer in Python, modeled every monster, every weapon, and the player character, then rendered them out as sprites. Wall textures, floor textures, and the night sky were all procedurally generated in code. The user described the results as "looking pretty good."

The audio pipeline was equally complete: the model designed four maps, composed eight MIDI music tracks, generated voice lines using TTS, and used ffmpeg to edit everything together — producing tough-guy one-liners and various monster sound effects.

This means a large language model simultaneously played the roles of programmer, artist, level designer, composer, and audio engineer — and integrated all of those outputs into a working whole.

A sprite is a core visual element in early 2D and pseudo-3D games: a character, item, or object pre-rendered as a bitmap and blitted directly to the screen at runtime, rather than computed as real-time 3D geometry. Classics like Wolfenstein 3D and DOOM made heavy use of sprites — enemies were "billboard" sprites that always faced the player, combined with raycasted walls to create a pseudo-3D effect. Claude rendering these sprites from scratch with Python means it not only understood the target visual style, but also grasped the full pipeline from 3D modeling to 2D pixel art — and produced output in J2ME-compatible formats and dimensions.

A 500KB JAR, Copy-and-Play

The end product was a ~500KB JAR file. The user copied it directly onto the old phone, and the game ran immediately — no additional debugging or patching required.

That "works out of the box" result is the most compelling part of the whole story. Getting AI-generated code to compile is the baseline; having it run first-time on severely constrained target hardware means the model handled packaging format, asset size, and runtime compatibility correctly. Fitting an engine, textures, four maps, eight music tracks, and multiple voice lines into half a megabyte is itself a demonstration of disciplined engineering.

A JAR (Java ARchive) is Java's standard packaging format — essentially a ZIP archive containing compiled bytecode (.class files), resources, and a manifest. For J2ME specifically, a JAR must be paired with a .jad (Java Application Descriptor) file that declares the app's name, version, size, and entry class, which the phone's OS uses to decide whether to allow installation. The 500KB size matters because many J2ME devices imposed hard limits on application package size — early handsets often capped at 64KB or 128KB. Even on devices supporting larger packages, fitting an engine, textures, four maps, and eight MIDI tracks into under half a megabyte reflects sound judgment about resource formats and compression strategy.

What This Case Tells Us

Viewed as a single user's experiment, this is more of an extreme capability demonstration than a standardized product benchmark, and reproducibility still needs broader validation. But the trend it reveals is worth thinking about.

Traditionally, "making a game" has been divided into programming, modeling, composing, sound design, level design, and more — each requiring its own toolchain and expertise. In this case, all of those phases were compressed into a single conversation. What the model demonstrated wasn't just code generation — it was cross-domain engineering coordination: understanding platform constraints, managing diverse outputs, and delivering a finished product.

The user described the experience as "amazing and terrifying" — an apt framing. Amazing because the barrier to creation has dropped so dramatically that an idea can become a finished product at near-zero cost. Terrifying because when AI can independently complete an entire creative pipeline, the value of many traditional specializations is being reassessed.

A Note of Caution

It's worth stating clearly: this article is based on a single user's self-reported account, without independent third-party verification. "Rivaling Gameloft" is a subjective judgment — actual visual quality, gameplay, and code robustness can't be fully assessed from a text description. The relatively fixed technical constraints of the retro J2ME platform and the small asset scope may also be objective factors that made the task more tractable.

Even so, this case offers a valuable observation window: today's top models can already independently complete complex creative projects spanning code, art, and audio under clearly defined constraints. Whether this is an outlier or the new normal is worth watching closely.