Building Game Prototypes and 3D Interactive Web Pages with LLMs at Low Cost

1. From Code Completion to Artifact Generation: The Nature of the Leap

Early code models mainly solved the problem of completing the current function. Architecture design, module assembly, and debugging remained the developer’s responsibility. But a recent wave of community showcases—open-world-style driving game demos, foldable 3D phone web pages operable in a browser, and dynamic launch videos generated in minutes—points to a new mode of working: developers describe goals in natural language, and the model handles technology selection, code organization, error fixing, and polish across multiple rounds of interaction, ultimately delivering a directly runnable artifact.

Three technical factors underpin this mode:

1. Long context and engineering-grade code generation: The model can “see” multiple files and thousands of lines of code simultaneously, maintaining cross-module interface consistency.
2. Agentic execution and feedback loops: After generating code, the model can run it automatically, read errors, and self-correct, significantly reducing manual back-and-forth.
3. Sufficient coverage of domain corpora: Fields like game development, 3D rendering, and web interaction have accumulated vast public tutorials and examples. The model’s mastery of these mature patterns far exceeds that of niche domains.

2. A General Technical Breakdown of Three Representative Task Types

2.1 Open-World-Style Game Prototypes

One developer shared an open-world-style driving demo: streets, vehicles, running pedestrians, a follow camera—the familiar game atmosphere was immediately apparent. According to the developer, the project took about 10 hours, consumed several million tokens, and cost roughly $52. He also estimated personally that completing a similar task with other mainstream models could cost nearly an order of magnitude more (this figure is a personal estimate and is for reference only).

From a technical perspective, the core subsystems of such a prototype include:

• Scene and entity management: Generation, recycling, and per-frame updates of street grids, buildings, vehicles, and pedestrian entities.
• Procedural asset generation: If textures, models, and sound effects were all handcrafted, costs would spiral. Generating them in bulk via code according to rules is a common approach.
• Control and physics: Vehicle acceleration, deceleration, steering, and simplified collision detection.
• Camera and rendering: Third-person follow camera, lighting, and post-processing. Some developers also try enabling options like super-resolution rendering to improve visual quality.

The advantage of large models in such tasks is that they can generate a complete scaffold in one pass, organizing the above subsystems at a runnable granularity, so developers can focus their energy on tuning “what doesn’t feel like a game.”

2.2 3D Product Showcase Web Pages

Another representative case is a foldable-screen device showcase: first, a device model is created in 3D modeling software, then converted into an interactive web page in the browser—dragging a slider unfolds or folds the device, and the screen content changes in sync with the fold angle. According to the author, it took about 1.5 hours and cost roughly $12.50.

Its technical pipeline can be abstracted as:

3D modeling → export to a common model format → browser-side 3D rendering (based on open standards such as WebGL/WebGPU) → interaction state machine driving model pose and UI synchronization

A simplified state machine pseudocode looks like this:

// Pseudocode: core state sync for fold interaction
const device = { foldAngle: 0, screenMode: "cover" };
function onDrag(delta) {
  device.foldAngle = clamp(device.foldAngle + delta, 0, 180);
  device.screenMode = device.foldAngle > 30 ? "flexible" : "cover";
  syncModelPose(device);   // 3D model pose changes with angle
  syncScreenUI(device);    // screen content syncs with form factor
}

This combination of “modeling + web interaction” has direct value for product showcases, creative proposals, e-commerce detail pages, and similar scenarios.

2.3 Dynamic Short Video Generation

Another developer had a model generate a launch short video in about 5 minutes for roughly $1.10: defining a 3D scene, camera movements, and timeline animations in a declarative way, then rendering the final video in the browser. This shows that the pipeline of “text instruction → 3D visuals → dynamic video” is now connected, and the production barrier for lightweight video content has been significantly lowered.

3. Token Economics: Where Costs Come From and How to Control Them

Tokens are the unit of measurement for how models process text and code. A piece of code or a conversation history is converted into tokens and counted toward costs. The “millions of tokens” consumed in the cases above mainly come from three parts:

• Input cost: In multi-turn conversations, historical code and context are repeatedly fed into the model. The larger the project and the more re-reading, the faster input tokens balloon.
• Output cost: Generating code itself, especially full-file rewrites.
• Iteration cost: Runtime errors and visuals that don’t meet expectations both require additional rounds of correction.

Corresponding cost-control practices:

1. Modular prompting: Dispatch tasks by subsystem separately, rather than cramming all requirements into one giant prompt.
2. Incremental generation: Only have the model modify the files and functions that need changing, avoiding full-repo rewrites.
3. Context slimming: Large assets (model files, textures, datasets) should not enter the conversation—only references and descriptions.
4. Acceptance criteria upfront: Clearly specify “runnable, frame rate, interaction items” and other acceptance conditions in the prompt to reduce wasted round trips.
5. Track usage: Maintain a ledger of tokens and costs for each task to facilitate retrospectives and budget management.

4. A Reusable Workflow: Five Steps from Idea to Artifact

Step 1: Structure the requirements. Organize natural-language wishes into structured goals:

Goal: open-world-style driving demo
Tech stack: browser WebGL rendering, no backend
Constraints: single-page, target 60 FPS, keyboard interaction
Acceptance: vehicle can accelerate/decelerate and steer, camera follows, street scene procedurally generated

Step 2: Confirm technology choices. Have the model first propose 2–3 options with trade-off reasoning. After a human decision, begin work—avoiding token burn in the wrong direction.

Step 3: Generate module by module. Proceed in the order of “scene → entities → interaction → polish,” validating each module independently.

Step 4: Run and close the feedback loop. Feed error logs, symptom descriptions, and performance data back to the model for correction. This is the key to efficiency: the more specific the feedback (“camera jitters when turning left” is better than “the visuals are wrong”), the faster the fix.

Step 5: Deploy and showcase. These artifacts are essentially a static page plus asset files. They can be hosted on object storage or static website hosting and distributed via CDN to get a shareable link. On platforms such as Baidu AI Cloud, model services, storage, and distribution are provided as general product categories, and developers can combine them as needed to go live.

5. Capability Boundaries and Engineering Caveats

Amid the excitement, several boundaries must be kept in clear view:

1. Generated code must be reviewed: Performance issues (memory leaks, per-frame object creation) and security issues (external dependency provenance, script injection) do not disappear just because the code was written by a model.
2. Beware of interface hallucinations: The model may fabricate non-existent APIs or parameters. Critical calls should be verified against official documentation.
3. Asset compliance: Procedural generation can avoid most copyright risks, but if external assets are introduced, authorization still needs to be confirmed.
4. Maintainability: AI-generated code equally needs comments, module boundaries, and naming conventions. Otherwise, the cost of subsequent iteration will backfire on the efficiency gains.
5. Complexity ceiling: Single-module prototypes are the current sweet spot. Projects exceeding tens of thousands of lines with hard real-time and high-concurrency requirements still need traditional architecture design skills as a fallback.

6. Conclusion: An Order-of-Magnitude Drop in Prototyping Cost Changes How We Iterate

The most noteworthy takeaway from this wave of community showcases is not a few stunning visuals, but a signal: the time and cost from idea to interactive artifact has dropped to the scale of “an individual developer’s afternoon.” For developers, what’s worth building immediately is not a project, but a personal workflow of “structured requirements → module-by-module generation → runtime feedback → deployment and showcase.” For enterprises, scenarios such as 3D product showcases, lightweight promotional materials, and interactive proposals now have the conditions for low-cost pilots. Get a small project running end-to-end first, then talk about scaling—that’s the most pragmatic path right now.