From Game Prototypes to Interactive Web: Analyzing 3D Creation Practices with Large Models

For the past few years, evaluating how “powerful” a large language model is has typically relied on benchmark scores: code challenge pass rates, math reasoning scores, and multiple-choice accuracy. While these numbers are important, they remain somewhat abstracted from real-world engineering output. Recent community practices offer an alternative perspective: looking directly at the artifacts. Developers have prompted models to generate open-world game neighborhood scenes—complete with streets, vehicles, and running characters; others have turned foldable device concepts into interactive web pages that expand and collapse in the browser; and some have created physics simulation demonstrations featuring wind-blown cloth and robotic hands with over 2,000 detachable parts. The common denominator here is that these outputs are directly runnable, operable, and deployable. Rather than debating “how many percentage points a model has improved,” it is more productive to deconstruct the technical paths, cost structures, and methodologies behind these works—which is exactly what this article does.

I. Four Typical Artifacts: Technical Profiles of Community Practices

1. Open-World Game Scene: ~10 Hours, 4 Million Tokens, $52

Among the cases shared by the developer community, the most impactful is an open-world game demo: procedurally generated streets, driving vehicles, and a controllable running character, combined with camera follow and lighting rendering to establish a classic open-world atmosphere. According to the author, this project took about 10 hours, consumed roughly 4 million tokens (the basic unit of measurement for how models process text and code), and cost approximately $52.

A particularly noteworthy detail: the author used natural language to ask the model to “enable graphics enhancement options.” The model then adjusted the rendering pipeline and demonstrated the visual difference before and after the change. This indicates that the model doesn’t just “write code”; it understands the terminology of computer graphics and can map domain-specific language to concrete engineering modifications.

The author estimated that completing similar work with a higher-priced comparable model could cost over $500. Setting aside individual variances, this comparison reveals a crucial point: in long-horizon, agent-based development tasks, the per-token price difference between models is significantly amplified by consumption volumes in the millions. Cost must be a core consideration during model selection.

2. Five-Minute 3D Short Film: $1.10

Another case is equally intuitive: a developer prompted a model to create a product launch-style short film. The visuals were generated using browser-based 3D graphics capabilities, featuring camera movements and dynamic lighting. The entire process took about 5 minutes and cost $1.10. While this use case is inherently interesting, the more substantive takeaway is that the conversion chain from text instruction to “3D visuals + dynamic camera movement” has been compressed to the minute and dollar level. Rapid prototyping of marketing materials and demo videos is becoming a reality.

3. Foldable Device Prototype: Bridging Modeling and Web Interaction

The third case demonstrates the completeness of the pipeline: the model was first directed to generate a foldable smartphone model within a mainstream 3D modeling software using its scripting interface. The model was then exported as a web-ready 3D asset format, creating an interactive page where the device could be folded and unfolded in the browser—with the screen content switching accordingly during the fold process. This took about 1.5 hours and cost $12.50.

The key here is not “looking good,” but rather the打通 of the complete pipeline: “modeling → export → web interaction.” Product showcases and creative proposals now have a new, low-cost expression method. Instead of rendering polished demo videos, you can deliver a “living prototype” that clients can interact with themselves.

4. Physical Simulation: Fluttering Cloth and Robotic Hands with 2,317 Parts

Static visuals are one thing, but natural motion is a better test of capability. A developer tested physical simulations: cloth fluttering in the wind and a robotic hand progressively disassembling into 2,317 independent parts. According to the developer, both cases were completed in under 10 minutes. This involves classic computer graphics and physics engine challenges—rigid body dynamics, soft body simulation, and joint constraints. The fact that the model can stably generate this type of code indicates its capabilities have penetrated highly specialized vertical domains.

II. Technical Deconstruction: A Pipeline from Instruction to Artifact

These artifacts may seem diverse, but they share the same underlying pipeline. Understanding each stage helps determine which tasks are suitable for the model and which still require human intervention.

1. Agent Workflow: Plan—Generate—Run—Feedback

Modern coding models accomplish tasks far beyond simple “Q&A.” They operate in a continuous loop around a goal: decomposing tasks, generating code, executing in a runtime environment, reading errors and logs, and fixing and iterating. A representative pseudo-code looks like this:

goal  = "Generate an interactive foldable device web prototype"
plan  = model.plan(goal)                # Task decomposition
for step in plan:
    code   = model.generate(step, context)
    result = runtime.run(code)          # Execute in a sandbox
    check  = verify(result)             # Screenshot, log, and assertion checks
    if not check.passed:
        context.append(check.feedback)  # Enter the next round with feedback

Consumption metrics like “4 million tokens, 10 hours” reflect the sheer volume of this loop: the more complex the artifact and the more iteration rounds, the higher the consumption.

2. Browser-Side 3D Rendering

Why do so many of these artifacts choose to run in the browser? Because browsers provide an installation-free, cross-platform, and easily shareable delivery environment. 3D rendering libraries based on open graphics standards like WebGL encapsulate concepts such as scene graphs, materials, lighting, and cameras into programmable APIs. What the model generates is essentially “code that calls these APIs,” and users can experience the result simply by opening a link. The browser is currently the lowest-cost distribution vehicle for interactive content, which explains the proliferation of short films, web pages, and interactive prototypes.

3. Scripting Interfaces for Modeling Software

Mainstream 3D modeling software generally provides scripting interfaces, allowing programmatic modeling, assembly, baking, and exporting. Driving modeling software via scripting interfaces and exporting the results as web-ready asset formats creates a clear division of labor: “professional tools do professional work, browsers handle delivery.” The foldable phone case is a prime example: modeling was done in professional software, while interaction was handled by the web page.

4. Physics Engines and Simulation Constraints

Fluttering cloth requires soft body simulation; disassembling a robotic hand requires rigid body and joint constraints. Such content has a high threshold for “realism”—the slightest clipping or jitter breaks immersion instantly. Generating this code means the model has a sufficient understanding of the physics engine’s parameter systems (mass, damping, constraint solving).

III. Token Economics: How to Estimate Your Project Costs

The three data points from community cases can outline a rough cost coordinate system:

Project Type	Time	Token Consumption	Cost
Open-world game scene	~10 hours	~4 million	~$52
3D launch short film	~5 minutes	—	~$1.10
Foldable device interactive prototype	~1.5 hours	—	~$12.50

Several directly applicable estimation methods:

• Unit Cost Baseline: Based on the game scene case, the blended token cost is roughly $13 per million tokens ($52 ÷ 4). Using this as a baseline, you can quickly estimate budgets by mapping “artifact complexity → estimated token volume.”
• Complexity Tiers: Minute-level tasks (a few dollars) correspond to single-file, single-scene outputs; hour-level tasks (tens of dollars) correspond to multi-asset, multi-round iterations; ten-hour-level tasks (hundreds of dollars) correspond to complete systems.
• Hidden Costs: Beyond token fees, there is human time for prompt debugging, validation, and secondary modifications. When evaluating ROI, don’t just calculate the token bill.

For cost savings, several practices have been repeatedly validated: streamline context by providing only the necessary history and files to the model; reuse verified intermediate artifacts to avoid generating from scratch each time; and separate “exploratory generation” from “deterministic polishing,” with the latter potentially handled manually or by a lighter model.

IV. Engineering Practices: From “Runnable” to “Deliverable”

1. Prioritize Task Decomposition. Don’t just say “make me a game.” Break it down into stage goals like scene skeleton, character control, camera, asset loading, and performance optimization, validating each segment. The game scene case took shape in 10 hours precisely because the author provided clear phase descriptions (city, vehicles, pedestrians, graphics options).
2. Establish a Runnable Baseline. Run the output in a real environment immediately after each generation, using screenshots, logs, and frame rate data as feedback. The self-repair quality of an agent heavily depends on the quality of the feedback signals.
3. Focus on Browser-Side Performance. Common bottlenecks for 3D artifacts are asset size and draw calls. Practical tips: compress textures and meshes, lazy-load as needed, control the number of on-screen objects, and implement graphics quality tiers if necessary—maxed out for high-end devices, downscaled for low-end. This is the engineering extension of the “graphics enhancement options” concept seen in the cases.
4. Cloud Delivery Loop. Once an artifact is complete, it needs distribution: static pages can be hosted, 3D assets can be placed in object storage and accelerated via CDN; if online interaction and inference are added later, GPU computing power and model service support are required. Leveraging general capabilities like object storage, static website hosting, GPU computing, and model inference services provided by cloud platforms (such as Baidu AI Cloud) can quickly bridge the pipeline of “local generation, cloud deployment,” ensuring demo links remain stable and accessible.
5. Compliance First. Before publication, confirm the sources of generated assets, model usage licenses, and protocols of any referenced open-source code to avoid legal risks post-launch.

V. Cold Reflection: The Boundaries Behind the Highlights

• Demos Are Not Products. Most of the above cases remain at the “impressive prototype” stage. To become maintainable engineering projects, they still require dealing with asset pipelines, exception handling, and multi-device adaptation.
• Long-Task Stability Needs Verification. In multi-round iterations consuming millions of tokens, context degradation and goal drift can occur at any time. Manual checkpoints are indispensable.
• Gap Between Simulations and Commercial Engines. Model-generated simulations typically stop at “looking right,” which is still far from “physically accurate.” Industrial-grade applications require separate validation.
• Lack of Evaluation Benchmarks. “Showcasing artifacts” is intuitive but suffers from obvious sample bias; community hype does not equal average capability. For formal model selection, blind tests on your own task sets are still necessary.

Conclusion

From game scenes and 3D short films to foldable interactive web pages and physical simulations, what is truly worth recording about these community practices is not how stunning a single generation looks, but a proven paradigm: natural language defines the goal, an agent loop generates the code, the browser handles delivery, and token costs are clearly calculable. For developers, rather than waiting and watching, pick a small project of your own and conduct a test using the cost framework in this article. For under ten dollars, you will likely form a completely new judgment about “visible capabilities.”