Next-Generation LLM Creative Coding in Practice: From Game Prototypes to 3D Interactions

From “Can Chat” to “Can Deliver”: A New Lens on Model Progress

Traditionally, evaluating a large model has meant looking at benchmark scores: mathematical reasoning, code completion accuracy, long-text comprehension, and similar metrics. These indicators matter, but they remain one layer removed from real usage scenarios. After the release of a recent batch of next-generation models, an intriguing phenomenon appeared in overseas developer communities: rather than posting benchmark scores, people are more eager to share their “works.” Some have built open-world-style neighborhood roaming scenes, others have turned a foldable phone into a 3D web page that can be unfolded and closed in the browser, and still others have had a robotic hand disassembled into more than two thousand parts and spread out layer by layer.

What these demonstrations share is that they are runnable, operable, and reproducible. Whether a model can turn a natural-language requirement into an interactive 3D scene within tens of hours is itself a comprehensive stress test of code generation stability, long-context management, and multi-turn iteration capability. In other words, a “work” is an evaluation set closer to real engineering load than a benchmark score. The most intuitive way to judge whether a model has gotten stronger is not to hear “the parameters were upgraded,” but to see whether what it delivers can be directly seen, played with, and modified.

Technical Breakdown of Three Typical Works

Open-World-Style Game Prototype

The input for this type of work is usually a structured natural-language description, and the output is a demo that runs directly in the browser: streets, vehicles driving along paths, pedestrians walking randomly, and a character that can be controlled to run. From an engineering perspective, it tests at least four model capabilities simultaneously:

1. Scene organization: procedurally generating block layouts, buildings, and roads, without relying on hand-modeled assets;
2. Render loop: maintaining a stable frame rate and correctly handling cameras, lighting, and shadows;
3. Entity behavior: writing simple but natural motion logic for vehicles and pedestrians;
4. Performance awareness: applying frustum culling, instanced rendering, or super-resolution and other quality optimizations in appropriate places.

One interesting detail: a developer asked the model in the prompt to “enable the next-generation super-resolution quality option,” and the model adjusted rendering parameters accordingly and output comparison frames. This suggests that the model’s understanding of the rendering pipeline has moved beyond “being able to draw it” toward “how to draw it with less compute.” Of course, models occasionally invoke non-existent interfaces or rendering features with complete confidence, and such output must be human-verified before it can be trusted.

From 3D Modeling to Interactive Web Page: A Two-Stage Workflow

Another widely praised work is a “foldable phone concept showcase”: first the model generates a phone model in open-source 3D modeling software, then this is imported into a web page to implement a draggable unfold-and-fold interaction animation, with screen content updating in sync as the form factor changes.

The technical value of this case lies in connecting the full chain of “modeling—asset—interaction”:

• Modeling stage: the model generates modeling scripts, producing assets with bones and keyframes;
• Asset conversion: exporting to a web-friendly lightweight 3D model interchange format, controlling polygon count and texture size;
• Interaction stage: binding events in the browser and mapping the fold action to the animation timeline.

For product managers, creative proposal writers, and interaction designers, this chain means product concepts no longer need to stop at static renderings—they can be delivered directly as a “playable prototype.” For internal reviews, client proposals, and early user testing, communication costs drop significantly.

Physics Animation and Complex Assemblies

The third type of work tests whether things “move naturally”: cloth fluttering in the wind, a robotic hand disassembled into more than two thousand parts and unfolded layer by layer according to assembly relationships. The former typically relies on vertex animation or lightweight physics simulation; the latter is essentially an “exploded view” animation, modeling each part’s assembly relationship as a hierarchy and then choreographing motion along assembly paths. Community users reported that both cases went from requirement to completion in under ten minutes. What this reflects is the model’s combined control over animation timelines, spatial coordinates, and hierarchical relationships.

Procedurally Generated Short Films

There is also a representative use case: a user directly asked the model to generate a 3D dynamic launch short film for their own project, from script and storyboard to web-side rendered output, taking about five minutes end to end. Text instructions were converted into a finished piece with 3D visuals, camera movement, and text motion effects. This “using a model to promote a model” approach essentially hands repetitive labor in content production (layout, motion effects, timeline choreography) to automated pipelines, which is a real efficiency gain for independent developers and small teams’ release cadence.

Converting “Impressive” into Engineering Metrics: Tokens and Cost

A good-looking demo is only the first step; whether it can enter the production pipeline depends on cost and determinism. Large models are billed by token, the basic unit for processing text and code. Based on publicly shared real-world cases in the community, a rough order-of-magnitude picture can be established:

• Open-world-style prototype: about ten hours, millions of tokens, total cost on the order of tens of dollars;
• Concept short film: completed in minutes, costing one to two dollars;
• Foldable-screen interactive web page: completed in hours, costing around ten dollars.

For comparison, some developers estimate that using a higher-priced premium model for the same task could raise costs by an order of magnitude, to hundreds of dollars. This gap matters enormously during prototype exploration: creative work is fundamentally high-frequency trial and error, and every step down in per-attempt cost buys an order of magnitude more attempts.

On this basis, cost governance can be further applied:

1. Front-load requirements: write a clear feature list and acceptance criteria before starting, reducing the waste of “generate—reject—redo”;
2. Staged generation: first build a gray-box prototype to validate gameplay and interaction, then gradually replace with refined assets;
3. Control context: start new sessions promptly and discard irrelevant history to avoid token waste from context bloat;
4. Reuse and accumulate: save validated prompt templates and code skeletons as team assets for reuse in later projects.

Engineering Practice: How to Reliably Reproduce These Works

To turn “someone else’s impressive demo” into “your own output,” it is advisable to organize the workflow as the following loop.

Step one: structure the requirements. Do not open with a single sentence like “make an open-world game”; instead, write a structured prompt:

Role: You are an engineer familiar with browser-based 3D rendering.
Goal: Deliver a directly runnable neighborhood roaming demo.
Feature list:
  1. Third-person character control (keyboard movement + mouse view);
  2. Procedurally generated blocks, roads, and buildings;
  3. Vehicles driving along paths, pedestrians walking randomly.
Constraints:
  - Single HTML file, dependencies limited to general rendering capabilities available in the browser;
  - Target frame rate of 60 FPS on desktop browsers;
  - No paid-license online assets.
Acceptance criteria:
  - Runs immediately when the page is opened, with a loading progress indicator;
  - Each feature can be verified independently.

Step two: iterate in small steps. Have the model change only one module at a time, verify it in the browser immediately after the change, and then decide the next step. Breaking long tasks into short loops significantly reduces the risk of “generating one big blob at once and reworking everything because of one error.”

Step three: human code review. Focus on three types of issues: whether non-existent interfaces are invoked, whether there are resource leak risks (undestroyed timers and event listeners), and whether performance meets the target. Model-generated code also needs to go through human review, testing, and version management.

Step four: separate assets from logic. Models are good at rapidly producing runnable prototypes, but game logic and 3D assets should be decoupled early to facilitate later refinement and extension with professional tools.

Capability Boundaries and Risk Notes

Objectively, the capabilities demonstrated by these works still have clear boundaries:

• Hallucinated interfaces: the model may invoke non-existent rendering features or library functions, requiring line-by-line verification;
• Long-task drift: after dozens of rounds of dialogue, the model may forget early constraints, so key constraints should be restated each round;
• Mobile compatibility: smooth performance on desktop browsers does not mean it is usable on mobile; touch adaptation and load-reduction strategies still need to be filled in manually;
• Asset compliance: third-party assets beyond procedurally generated content must have their licensing sources confirmed;
• Execution safety: maintain a habit of reviewing network requests and local file operations in generated code, and avoid executing directly in untrusted environments.

For enterprise users, these creative coding capabilities can also be combined with cloud infrastructure: static page hosting can be handled by object storage and content delivery services, inference compute can be obtained on demand, and logging and monitoring services can be used to observe token consumption and call quality. Taking the general product categories of platforms such as Baidu AI Cloud as an example, capabilities such as object storage, log services, and monitoring and alerting are already relatively mature, allowing teams to focus on accumulating prompt assets and acceptance processes rather than building infrastructure from scratch.

Conclusion

From game prototypes and foldable-screen interactive web pages to mechanical disassembly animations and automatically generated short films, this round of community works collectively demonstrates one thing: the distance between natural language and “deliverable works” is shrinking rapidly, and the cost of a single attempt has dropped low enough to allow high-frequency trial and error. For developers, the preparation worth doing is to treat requirement description skills, acceptance criteria, and code review processes as new fundamentals. What determines output in the future is increasingly not typing speed, but whether you can state clearly what you want and verify it thoroughly.