From a Single Prompt to a 3D Game: How LLMs Develop Interactive Prototypes

1. The Phenomenon: Running Deliverables Speak Louder Than Parameter Lists

Recently, a batch of projects circulating in the developer community has sparked widespread discussion. Developers have created open-world style game demos featuring streets, vehicles, and controllable characters. Others have imported a foldable phone model into the browser, where screen content syncs dynamically as the device folds and unfolds. There are also examples of mechanical hand models progressively disassembling into over 2,000 parts, alongside cloth simulation instances fluttering in the wind. Crucially, the creators publicly shared the resources invested:

• Open-world game prototype: ~10 hours, ~4 million tokens, totaling ~$52.
• 3D promotional short: ~5 minutes, costing ~$1.1.
• Foldable phone (from 3D modeling to an interactive web page): ~1.5 hours, costing ~$12.5.
• Mechanical hand disassembly demo: 2,317 parts, with similar cases completed in under 10 minutes.

(Tokens are the basic unit models use to count and bill for text and code; one token roughly corresponds to a word or a few characters.)

The common denominator among these cases is that the deliverable is not a text description, but a fully runnable, operable program that works directly in the browser. This points to the essence of the current capability leap: model output has evolved from “describing how to do it” to “directly doing it.” The following analysis breaks this down across four dimensions: technical principles, case studies, cost models, and engineering practices.

2. Technical Principles: Code is the Scene

2.1 Models Generate Programs, Not Pixels

A common misconception is that large models are “drawing” 3D images. In reality, the model acts more like a programmer. It writes HTML/JavaScript code that runs in the browser, leveraging open standard Web 3D rendering APIs (such as WebGL/WebGPU). It defines the scene graph, camera, lighting, materials, and animation logic, while the final image is rendered in real-time by the GPU.

This “code-as-scene” approach offers three significant advantages:

• Editable and versionable: Since the scene is code, it can be put under version control, supporting diffing and rollbacks.
• Zero-friction distribution: Simply open a browser to run it; no dependency installation required.
• Composable and reworkable: Changing parameters, swapping models, and adding interactions are fundamentally just code modifications.

A minimal runnable scene skeleton typically looks like this (pseudocode):

// Pseudocode: A typical 3D scene skeleton generated by an LLM
const scene    = createScene();
const camera   = createPerspectiveCamera({ fov: 60, near: 0.1, far: 1000 });
const renderer = createRenderer({ antialias: true });
const car = buildCarProcedurally();   // Procedural geometry + materials, no external assets needed
scene.add(car);
function tick() {
  car.position.x += readInput().throttle * 0.1;  // Keyboard input -> entity state
  cameraFollow(camera, car);                     // Third-person follow camera
  renderer.render(scene, camera);
  requestAnimationFrame(tick);
}
requestAnimationFrame(tick);

Real-world projects are far more complex than this skeleton. Entity-component architectures, event systems, state machines, asset loading management, and performance optimizations—these are the true tests of a model’s “engineering capabilities.”

2.2 From Natural Language to Spatial Parameters

The difficulty of 3D development lies in the precision of “numbers”: camera field of view, object coordinate systems, quaternion representations for rotation, keyframe interpolation curves, rigid body mass/friction/elasticity coefficients, and joint constraints. A prompt like “fold the phone along the left edge of the screen” must be translated by the model into a specific rotation axis, pivot point, angle, and animation pacing, while maintaining consistency with the screen content mapping. Illustrated below:

// "Foldable phone" -> Structured parameters (example)
foldAction = {
  axis: (-1, 0, 0),        // Rotation axis: horizontal axis at the screen's left edge
  pivot: leftEdgePoint,    // Pivot point
  angle: 180,              // Target angle
  duration: 0.6,           // Animation duration (seconds)
  easing: easeInOutCubic,  // Easing curve
  onAngleChange: syncScreenContent  // Screen content syncs with angle changes
}

This level of advancement stems from substantial improvements in the model’s spatial relationship and mathematical reasoning capabilities behind the code. This is why earlier models could only write “a rotating cube,” while newer models can produce “a foldable phone” and “a mechanical hand with thousands of parts”: the latter requires long-chain structural planning and numerical reasoning.

2.3 Generation-Debugging Loop: Models Can “See” Their Work

Another key mechanism is the iterative loop: generate code -> run -> feed runtime errors, console output, and even render screenshots back to the model -> correct -> run again. Leveraging multimodal understanding, models can “see” the rendering result, identify issues like “character floating” or “texture stretching,” and fix them autonomously. This loop transforms the near-impossible task of “writing flawless 3D code on the first try” into an engineering process of “rapid multi-round convergence.”

3. Case Breakdown: Three Capability Facets

3.1 Open-World Prototype: Long-Task Planning and Consistency

The open-world style demo (~10 hours, 4 million tokens) tests “long-task” capabilities: road networks, vehicle physics, character control, and camera following must be built simultaneously without conflict. Four million tokens sounds massive, but considering that each iteration must carry the existing code context, plus error logs and correction consumption, this volume is reasonable (see the cost model in Section 4). Notably, the author also had the model adjust rendering quality settings and compare visual differences—human-model interaction is no longer just “writing code,” but an engineering dialogue involving tuning and debugging.

3.2 From Modeling Software to Web: Bridging Desktop Toolchains and Browsers

The foldable phone case demonstrates another path: complete detailed modeling in professional 3D modeling software, export to a web-loadable format, and then have the model write the interaction logic—folding/unfolding driven by a state machine, with screen content syncing to the fold angle. This bridges the “desktop-grade production pipeline” with “web-grade distribution capabilities.” Fine assets produced by designers can be rapidly converted into clickable, operable product demos, suitable for product showcases, creative pitches, and interactive web pages.

3.3 Physical Simulation: Structured Capability Behind 2,000 Parts

The mechanical hand disassembling into 2,317 parts and cloth fluttering in the wind test physical simulation and scene organization capabilities:

• Over 2,000 parts mean the scene graph must have solid hierarchical organization. The disassembly animation is essentially “sequentially removing constraints + moving along a path,” requiring the model to plan the entire sequence at once.
• Cloth is usually based on general algorithm families like mass-spring or position-based dynamics. Parameters like wind force and damping directly determine whether the visual feels natural.
• Both similar cases were completed in under 10 minutes, indicating that the model is highly proficient at invoking general physics modules.

The commonality across these three cases: they are not mere showmanship of isolated tricks, but comprehensive assessments of planning, conversion, debugging, and integration engineering capabilities.

4. Cost Model: Where the Money Goes and Why It’s Cheap

The cost of an AI-driven development task can be approximated as:

Total Cost ≈ Σ(Input Tokens × Input Price + Output Tokens × Output Price) for each iteration

This leads to three conclusions:

1. Context is the major cost driver: In later iterations, each round must carry existing code and error information. Input tokens far exceed output tokens. Controlling project scale and modularizing code directly saves money.
2. Iteration count dictates the magnitude: Clearer task decomposition and acceptance criteria mean fewer rework rounds and lower costs. Ambiguous requirements might lead to dozens of rounds of back-and-forth.
3. Cost structure has changed: Traditional development is heavily weighted toward labor and time. In AI-assisted development, token expenditure is transparent and controllable, while human time shifts toward requirement description, review, and acceptance.

It must be emphasized: the above amounts are actual data shared by individual case authors. Real costs fluctuate significantly based on model pricing, task complexity, and iteration strategies, and cannot be directly extrapolated. Qualitatively speaking, however, “spending a few dollars to tens of dollars to produce a runnable interactive prototype” has rewritten the cost baseline for prototype validation. Compared to the labor costs of traditional manual prototyping, this expenditure is virtually negligible.

5. Engineering Practices: How to Reliably Reproduce These Results

Drawing on common patterns from community cases and general engineering experience, we recommend following these six practices:

1. Task Decomposition: Break “make a game” down into milestones like “scene skeleton -> character movement -> camera -> interaction -> UI,” completing and validating them one by one.
2. Modular Code Organization: Have the model output code in modules (rendering/physics/logic/UI) to avoid single-file bloat, which leads to context overflow and modification difficulties.
3. Runnable Checkpoints + Version Control: Commit a runnable version at each milestone. If the model “breaks it while fixing it,” you can roll back at any time.
4. Clear Acceptance Criteria: Define “runnable” as verifiable conditions—target frame rate met, no console errors, interaction functional.
5. Manual Review is Indispensable: Generated code must undergo security reviews (prevent injection, prevent loading untrusted external resources), dependency audits, and performance profiling. AI accelerates coding, but the responsibility for quality remains with humans.
6. Standard Performance Optimization: Batch draw calls, reuse instances, avoid creating objects every frame, and introduce Level of Detail (LOD) when necessary. These general optimization points can be proactively prompted to the model.

At the environment level, mainstream cloud platforms now provide complete support for these workflows. For example, leveraging general capabilities provided by cloud platforms (such as Baidu AI Cloud)—including model services, cloud-hosted GPUs and container environments, object storage, and monitoring alerts—developers can complete the aforementioned “generation-debugging-deployment” loop directly in the browser without building expensive local hardware.

6. Boundaries and Realistic Expectations

• Prototypes are not production-grade: These cases prove “speed from 0 to 1.” Commercial projects still require team investment in asset quality, gameplay depth, networking, and long-term maintenance.
• Consistency drift: As projects grow larger, a model modifying old code might cause regressions elsewhere. Version control and regression testing are particularly important.
• Numerical and spatial errors: Models might output incorrect transformation matrices or physical parameters. Visual validation, such as screenshot inspections, is a necessary step.
• Risk of cost overrun: Automated iteration loops might repeatedly trial-and-error, continuously burning tokens. Iteration limits and anomaly alerts should be set.

7. Conclusion

From open-world prototypes to disassembly animations of over 2,000 parts, the real signal conveyed by this round of community showcases is that the capability boundary of large models is shifting from “writing snippets” to “powering complete interactive systems.” For developers, the most valuable response is not to simply marvel at the cases, but to master the underlying methodologies—task decomposition, upfront acceptance criteria, modular organization, and rigorous review—and to incorporate “let the model run a prototype first” into standard daily development routines. When the cost of validating an idea drops to a few dollars and a few minutes, the question worth pondering is no longer “Can AI do it?” but “What other ideas are worth prototyping first to see?”