Large Language Models Push Coding into New Territory: Building 3D Web Pages and Game Prototypes

Recently, the overseas developer community has been showcasing a wave of experiments built around the code generation capabilities of newer large language models. Some developers have created open-world-style game scenes that run in the browser, complete with streets, vehicles, and pedestrians. Others have turned foldable-screen devices into interactive 3D web models that unfold and fold while the on-screen content changes in real time. Still others have had a robotic hand disassembled into more than two thousand individual parts, or simulated cloth moving naturally in the wind. Compared with simply saying that “the model got stronger,” these visible and operable results are far more convincing.

This article does not focus on any specific product. Instead, it treats these examples as a set of stress-test samples and examines the technical principles, cost structure, and engineering methodology behind them.

Why 3D interaction has become a new benchmark for model capability

For a long time, the community has evaluated LLM coding ability mainly through short-chain tasks such as algorithm problems, code completion, and question answering. These tasks have standard answers and can be scored automatically, but they are far removed from real engineering work. Real frontend and graphics development has several defining characteristics:

1. Long-chain dependencies: A runnable game prototype involves initialization, resource organization, the main loop, state management, event handling, and several other modules. If any link breaks, the page goes blank or the logic deadlocks.
2. High spatial and mathematical density: Coordinate transformations, rotation interpolation, collision detection, and lighting models all require the model to have solid knowledge of geometry and linear algebra.
3. Feedback is hard to quantify automatically: Whether a scene “looks right” or “runs smoothly” is difficult to cover with unit tests. This is exactly what tests the model’s ability to understand the semantics of a requirement.

The recent community projects happen to hit these pain points directly. Their common trait is that the output is no longer a code snippet, but a complete work that can be seen, played with, and operated—ranging from game visuals to 3D interactions.

Technical breakdown of four typical task types

The following table summarizes representative cases shared publicly by developers. All figures are self-reported by the developers:

Task type	Time spent	Cost	Core technical points
Open-world game prototype	About 10 hours	Around USD 50	Procedural generation, entity system
Foldable-phone 3D interactive web page	About 1.5 hours	About USD 12.5	Modeling scripts, state machine linkage
3D launch video	About 5 minutes	About USD 1	Timeline orchestration, camera paths
Mechanical disassembly / cloth simulation	Within 10 minutes per case	Not disclosed	Scene graph hierarchy, instanced rendering

1. Browser-based open-world game prototype

One developer reported that an open-world-style game demo took about 10 hours in total and consumed roughly 4 million tokens, with the overall cost controlled at around USD 50. By the developer’s estimate, completing the same task with a higher-end proprietary model could cost nearly an order of magnitude more. From an engineering perspective, the main challenges in this type of project include:

• Entity system organization: Vehicles, pedestrians, and buildings need a unified entity manager and update loop. Otherwise, the frame rate collapses linearly as the entity count grows.
• Procedural generation: Road grids and block layouts are usually generated through noise functions and layout rules rather than manual modeling. The model needs to translate a sense of “urban feel” into executable generation logic.
• Visual quality tuning: Shadows, fog effects, and post-processing form a very large parameter space that requires multiple generate-preview-feedback iterations. For people who want to use AI for game prototyping, the combination of visual output and production cost is genuinely attractive.

2. From 3D modeling to an interactive web page

Another interesting case involved a foldable-screen device. The developer first had the model build the model in professional 3D modeling software, then converted it into an operable web page where the phone can be unfolded and folded while the screen content switches accordingly. The process took about 1.5 hours and cost about USD 12.5. The value of this type of task lies in connecting two usually separate pipelines: asset production and engineering implementation. The model needs to understand the scripting interface of the modeling software, the export format of mesh data, and the state machine design on the browser side. The folding angle is a continuous variable, and the screen texture, UI layers, and occlusion relationships must all respond to that variable. Product demonstrations and creative proposals therefore gain a more intuitive form of expression.

3. Physics simulation and large-scale part disassembly

Cloth simulation and mechanical disassembly belong to another category of hardcore tasks. One developer had a robotic hand disassembled into 2,317 individual parts and reported that two such cases were each completed within 10 minutes. The technical essentials include:

• Hierarchical scene graph: More than two thousand parts must be organized into a sound parent-child hierarchy so that progressive disassembly animation can be supported.
• Instanced rendering: Similar parts reuse geometry data to avoid an explosion in draw calls.
• Physics approximation: Effects such as cloth and hinges usually rely on simplified physics models, balancing realism against performance.

4. Short dynamic videos and marketing assets

Another developer had a model produce a 3D launch video in about 5 minutes at a cost of about USD 1. The core of such a video is timeline orchestration: camera paths, object entrances, and text appearances need to be precisely aligned in the temporal dimension. Using a new model to make promotional material for a new model also shows that text instructions can now be reliably converted into finished videos with 3D visuals and motion effects.

The underlying technology stack behind the capability leap

Regardless of how the task forms change, they all depend on the same browser-based 3D technology system built on open graphics standards such as WebGL or WebGPU:

// Typical skeleton of a browser-based 3D scene (illustrative code)
const scene = createScene();
const camera = createCamera({ fov: 60, aspect: innerWidth / innerHeight });
const renderer = createRenderer({ canvas, antialias: true });
let foldAngle = 0; // Folding state machine
function animate(t) {
  foldAngle = updateFoldState(t);   // Advance fold angle based on input
  syncScreenTexture(foldAngle);     // Screen content responds to form factor
  updatePhysics(dt);                // Simplified physics for cloth/hinges
  renderer.render(scene, camera);
  requestAnimationFrame(animate);
}

For a model, writing this skeleton is not difficult. The challenge is maintaining clear module boundaries, consistent naming, and coherent state flow across thousands of lines of code. This is a combined reflection of long-context capability and code planning ability. In addition, calling the scripting interfaces of modeling software—typically through scripting languages such as Python to batch-generate meshes and set materials—falls under tool-use capability. The model must accurately grasp the parameter semantics of external interfaces rather than making them up.

Cost structure: token economics

The cost data is one of the main reasons these cases attracted attention. The cost of an AI-assisted prototype can be broken down into three parts:

1. Generation cost: Proportional to token consumption. Complex tasks such as game prototypes can consume millions of tokens, including many generate-error-fix round trips.
2. Iteration cost: Visual quality tuning and feel adjustment are subjective iterations, and each round generates new token overhead.
3. Labor cost: Time spent on prompt design, result acceptance, and integration and deployment.

Compared with traditional engine development, which often takes weeks of human effort, the scale of “tens of dollars plus ten hours” is highly attractive to independent developers and small teams. However, it is worth noting that token consumption scales superlinearly with task complexity. The vaguer the requirements and the more rework involved, the faster the cost rises. The key to controlling cost is phased generation and front-loaded acceptance.

Engineering practice: a four-step workflow for improving first-pass success

Drawing on the community cases, a reusable methodology can be distilled:

1. Deliver in phases—skeleton first, then flesh

Phase 1: Scene skeleton (renderer, camera, lighting, ground grid)
Phase 2: Core gameplay (entity system, input mapping, collision)
Phase 3: Visual polish (materials, post-processing, animation curves)
Phase 4: Performance optimization (instancing, LOD, object pooling)

Each phase should be accepted independently to avoid the total collapse caused by a single oversized prompt.

2. Explicitly constrain the technology stack

Specify the rendering approach, target frame rate, and whether external assets are allowed in the prompt. The more specific the constraints, the smaller the model’s search space and the more stable the output. For example, requiring that “all geometry is generated procedurally without relying on external model files” can avoid common failures such as asset loading errors.

3. Build a closed feedback loop

Feed browser console errors, screenshots, and frame rate data back to the model to form a generate-verify-fix loop. Visual tasks especially depend on screenshot feedback: the model cannot see the rendered output, but it can adjust parameters based on descriptions of the visuals.

4. Maintain modular prompt assets

Organize successful prompt fragments into templates, such as entity system templates, physics configuration templates, and performance optimization checklists. Assembling them as needed for future projects can significantly reduce marginal cost.

Capability boundaries and a rational perspective

Beyond the excitement, the boundaries should also be acknowledged:

• Limited physical realism: Cloth, fluids, and similar effects are mostly approximate simulations. There is still a gap in accuracy compared with professional physics engines.
• Performance ceiling: Browser-based rendering of large scenes has limited room for optimization. Beyond a certain scale, professional engines and human intervention are still required.
• Maintainability: A large codebase generated by a model in one pass may have inconsistent architectural styles. Long-term maintenance cost needs to be evaluated.
• Design judgment still belongs to humans: A model can efficiently implement “what you describe,” but “what is worth building” still depends on people.

Conclusion

From game prototypes to interactive web pages, the biggest takeaway from this round of community demonstrations is that the evaluation of LLM coding capability is shifting from “can it write code” to “can it deliver a result.” For enterprise teams, mature cloud-based model services and elastic compute resources make it possible to quickly set up this kind of iterative development environment, lowering the threshold for validating an idea to the scale of “one person plus one afternoon.” When prototyping becomes cheap enough, rapid experimentation itself becomes a competitive advantage.