The handcrafted Opus 5 AAA game has exploded in popularity, and Karpathy poured a bucket of cold water on it.
A single prompt consumed 690 million tokens and cost 423 US dollars.
Vyom finally got Wave Racer, a boat racing game with a built-in physics engine.
This game is built on Three.js, features a cel-shaded rendering style, and its track is an infinitely large procedurally generated ocean. Every spray in the scene is calculated in real time by code, without relying on any external asset packs.
All the code has been uploaded to GitHub, and anyone can play it directly in their browser.
Experience access👉: https://wave-racer.vercel.app/
"Generate One Game at a Time"
Claude Opus 5 was released on July 24, and in the following days, a number of striking browser game prototypes emerged on social media.
AI investor Matt Shumer released a first-person shooter entirely built by Opus 5. All elements on the screen, including code, textures, physics, and enemy behaviors, are generated independently without using any external assets.
Prompt:I want you to build a first-person shooter at the level of the most recent Call of Duty games. It should be utterly perfect, visually beautiful, with every single thing done at AAA quality—from textures to physics to anything you could think of.
Fan out sub-agents and have sub-agents tackle each one individually so that the game is utterly perfect. You should /loop on each item and have a separate sub-agent check it visually to ensure it looks triple A. That separate sub-agent should be a really harsh critic, and if it doesn't look triple A, it should keep going.
Don't stop until each sub-agent is utterly wowed with the quality when compared with the actual Call of Duty game. It should literally compare them side by side blind and say which one looks better. Do this in ThreeJS. /loop until it's utterly perfect. Fan out sub-agents and ultracode.
As mentioned above, Shumer never specified the renderer, nor listed the game's system, let alone defined what elements "AAA quality" should include.
He calls this method the "Gauntlet Loop": give the agent a real, verifiable standard instead of vague instructions; let it break down the task into small pieces; and submit each piece of task to an evaluator, who can never see the reasoning process of the builder when making choices.
Later, @mikeluan123 transformed Shumer's prompt framework into a Homeworld-style cosmic real-time strategy game, consuming 68,600 input tokens and 4.6 million output tokens at a cost of 632.65 US dollars.
However, there are also less expensive ways to play. Andrej Karpathy used less than a fraction of the budget to make AI render the entire Middle-earth world.
He gave Opus 5 the original text of the first paragraph of *The Lord of the Rings*, set a budget of 1 million tokens (about 10 US dollars), and asked the model to render the story.
Two hours later, 5500 lines of code were written, and a procedurally generated Middle-earth world was running in the browser. He uploaded it to karpathy.ai/lotr-movie, and casually said: "Looking forward to GTA Shire dropping before GTA VI."
In traditional 3D development, developers assemble scenes from asset libraries, textures are image files, and physics depend on engines, which is a bit like building Lego blocks;
These Opus 5 outputs are more like plastic particles starting to form building blocks: geometries are procedural, textures are represented by shaders, and physics and controls are all written into the same HTML file that can run as soon as you open it.
A survey from the 2026 Game Developers Conference shows that 52% of game developers have a negative view of generative tools, and 53% believe that such tools will increase the bug risk of projects. The obvious shortcomings are also prominent: art direction, narrative depth, and the kind of "exquisite feeling" that is hard to describe but can be perceived by players in a second, are still obvious weaknesses.
Developer Leon Lin made an interesting comparison. He directly wrote a detailed design document with as many as 20 chapters, clarifying everything from ragdoll physics simulation to cascaded shadow mapping, then fed it to Opus 5, and generated "Dust Corridor", which also runs in the browser, looks great, and is more stable than the "short prompt version" in some dimensions.
But that document was written by Leon himself. He could write it because he knew what AAA quality meant. The model performed well under his framework, because the framework itself came from years of human accumulation and experience.
Generation Is Only the Starting Point, Vision Determines Everything
The cost of generation is rapidly approaching zero, which is one of the most important changes happening right now.
From a longer-term perspective, this will bring an extremely exciting thing: players can enter the story of *The Lord of the Rings* as a bystander NPC, or play as a character in it, "some kind of on-demand generated GTA X".
This is the real future of games. It may no longer be a canned product with fixed content, but can generate a world experience exclusive to you in real time according to your preferences, rhythm and interests. Every player has their own Middle-earth, their own Shire, and their own exclusive story.
But "generation" is only the starting point, and the work after that is where the problem lies.
https://the-decoder.com/claude-opus-5-pushes-prompt-to-game-ai-from-rough-color-blocks-to-full-3d-prototypes-with-physics-and-music/
Karpathy revealed a fundamental technical obstacle in his *Lord of the Rings* experiment. In the process of generating rendering code, Opus 5 had to take screenshots at different time points very slowly and painfully, and then infer the dynamic runtime state based on these static screenshots. As a result, it still made several mistakes and created a lot of chaos.
His conclusion is : "The domain of games and worlds reveals a weakness of large language models: they have difficulty auditing their own work, because they cannot perceive video efficiently and natively, nor can they truly participate in the games within."
The model can write code that makes the car drift beautifully on the water, but it cannot play this game itself, and cannot notice that "players have started to get bored after three consecutive S-curves". It infers based on screenshots and static code analysis, and the accuracy and coverage of such inference are far from real game evaluation.
This leads to a corollary: when generation is almost free, the vision to judge the quality of output is the truly scarce resource.
Judgments like "the physics here feels wrong", "the rhythm of this level dies at the fifth minute", "this mission description is too vague, players will give up directly" cannot emerge automatically from the amount of code, nor will they appear automatically as the token budget increases.
People who know how to inspect and criticize model outputs have higher value at the moment.
What Is Still Missing to Let the Model Learn to Look at Its Own Work
What needs to change to make large language models really perform well in this field?
Current models can analyze a single screenshot and understand what is happening in one frame of image, but "continuously perceiving a running game in the time dimension" is a completely different matter.
To truly "see" a game, the model needs to track state changes between frames, recognize patterns that can only be discovered across frames such as "the player died three times here", and feel that "the player's operation rhythm in this section has become chaotic, there may be something wrong somewhere".
Some pragmatic engineering directions can be seen at the research level. The field of automated game testing is already exploring to let LLM agents capture game state through multi-modal perception, conduct self-reflection after performing actions, identify stutters and crashes, then adjust strategies, and compress the "screenshot→analysis→action" link into a near-real-time feedback closed loop.
This kind of method does not wait for the model's native "watch video" ability to mature, but uses the architecture to make up for the perception shortcomings first, which is the most practical engineering path at present.
The model knows how to write WebGL code that can correctly render normal maps, because such code exists in large quantities on the Internet and can be learned.
But judgments like "which corner in this corridor will create a sense of oppression for the player", "how heavy the weapon recoil should be without making people feel out of control", "what kind of reward rhythm makes players want to play another level after finishing one" have not been "written into code" and stored on the Internet for models to learn.
To make the model truly acquire this perceptual ability, relying only on code corpora is probably not enough. A large amount of interaction data generated by "the model actually playing games" may be needed to accumulate judgment benchmarks on hand feel, feedback, rhythm and frustration in the real game process.
To some extent, this is similar to the logic of AlphaGo, which learns to play chess by accumulating a sense of chess through massive self-play. But the game world is far more complex than the chessboard, and the perception interface is much wider, so this path will take much longer.
A truly personalized game experience, in addition to generating a track with an infinite ocean, also needs to know what rhythm this player likes, what type of challenges this player will find pleasant, and what this player's aesthetic preference is.
Both Wave Racer and the Middle-earth world in Karpathy's browser are very interesting, but at least by the summer of 2026, "one prompt to beat *Call of Duty*" has not happened yet.
When can the model really play the game it made, feel that "the rhythm of the seventh level collapsed at the second minute", and learn design-level lessons from it?
Before that moment comes, staying excited about this matter and learning to examine that excitement with a critical eye is the most valuable thing you can do now.
This article is from the WeChat Official Account "APPSO", authored by APPSO that discovers tomorrow's products, and is published by 36Kr with authorization.