How to build a site with 3D models and a browser game using AI: a Kimi and DeepSeek test

A site with 3D models and a browser game combines interactive objects, model selection, and game launch without a separate installation. In the described experiment, the author combined previously created 3D racing car models and game projects into two versions of a responsive site prepared with Kimi and DeepSeek.

The main conclusion of the test concerns not finding a universally best model, but choosing between speed, cost, and completeness of integration. According to the author’s assessment, Kimi completed individual tasks faster. In his scenario, DeepSeek required more time, cost less, and produced a slightly higher-quality final result.

Project objective: combine 3D models and a game

The initial set included three racing cars, game projects, and requirements for the site design. The author wanted not a separate model demonstration or a standalone game, but a unified interface connecting the presentation section with an interactive scene. Visitors were supposed to see project descriptions, select a car, examine it, and proceed to launch the game in the browser.

This scenario requires the generator to perform several related actions. The model must read the structure of the existing files, understand the paths to the 3D resources, transfer the objects into the game project, preserve the controls, and build a clear web page on top of this. A single missing file path or incorrect resource name can turn an attractive layout into a page with a broken interactive block.

Preparing the source files and prompts

For each version, the author created a separate project folder. In the requests, he specified the paths to the prompts, the directories for new files, and the locations of previously created projects containing the car models. This arrangement is important: the generator receives not an abstract task to “make a site with a game,” but a specific file environment where the models and code are already located.

The experiment used OpenCode and OpenRouter, and the maximum reasoning level was enabled for both models. This fact applies to the specific test setup. It does not prove that the same result will be obtained through a different interface, plan, provider, or level of computation.

Before starting generation, the project should be arranged into a predictable structure. Place 3D models, textures, game source files, prompts, and site files in separate directories. The prompt should clearly describe which resources may be reused, where new files should be created, and what should count as a completed result. The less uncertainty there is in the paths and names, the easier it is to verify the agent’s work.

Comparing generation time and cost

The author compared not one operation but several stages: creating 3D models, developing the game, and subsequently assembling the site. In the first task, Kimi finished the work in approximately 34 minutes, while DeepSeek worked for about 1 hours 5 minutes. According to the author’s estimate, the costs were 1 dollars 59 cents for Kimi and 43 cents for DeepSeek.

During the game-creation stage, Kimi took 25 minutes 50 seconds and cost 1 dollars 2 cents. DeepSeek completed the task in 43 minutes 41 second, and the generation cost was 32 cents. The author estimated the price difference at roughly threefold in DeepSeek’s favor, although the specific amounts apply only to his run and depend on the model, provider, context size, and number of requests.

In the experiment materials, the time for the individual stages and the time for the final assembly differ because they refer to different tasks. These values cannot be added together and treated as the total duration of the entire project. The cost likewise describes the author’s specific expenses, not an official price list or guaranteed development budget.

3D model quality

Kimi created three cars that the author classified as “classic,” “electric,” and “retro.” The models included seats, steering wheels, and disc brakes, but the inspection revealed shortcomings: some mounts did not reach the body, while the glass in one model passed through the seat. In the author’s subjective assessment, the level of detail looked acceptable but did not exceed expectations.

DeepSeek’s models showed similar problems with mounts and glass geometry. The author rated DeepSeek’s level of detail higher, especially in the third car, where he noticed a grille and fewer conspicuous defects. This observation applies to the specific set of generated objects. It does not replace technical checks of geometry, materials, normals, collisions, and performance.

For a commercial project, an 3D model cannot be accepted solely based on its appearance on a single screen. You need to check whether the holes are closed, whether parts intersect, whether transparent materials are displayed correctly, and whether the file size is excessive. In the game scene, additionally check the colliders, the wheel rotation centers, the object scale, and the camera behavior.

Checking game integration

In the Kimi version, the models were transferred into the game, and car selection, keyboard controls, reversing, wheel rotation, and collisions worked. The author considered the game functional, although he noted some errors. The opponents drove too slowly, so the race seemed insufficiently intense to him, and the declared game mechanics did not always create a noticeable challenge.

The DeepSeek project also had working car selection and controls. The author noted a more distant camera view, collisions, and a mini-map with turns, a start, and a finish. In his impression, the opponents moved more actively, and the game turned out to be slightly more dynamic and interesting. He still called the challenge nominal, so the result cannot be described as a complete racing game without further refinement.

In the tested game, the car could be turned around and driven in the opposite direction. After a collision, the car returned to the track, while the interface indicated the wrong direction of travel. The cars displayed speed characteristics: in the description, the author mentioned the values 106 and 100. He also noticed that the selected car sometimes overtook opponents that were supposed to be faster based on their characteristics, and suggested that this setting made the game easier to complete.

What the final site achieved

At the final stage, the author combined the 3D projects and game projects into a single site. The Kimi version used the corresponding models and the Kimi game, while the second version used DeepSeek materials. Generation was performed at the maximum reasoning level. The Kimi K3.1 Pro project was created in 44 minutes 58 seconds, while the second project took about 28 minutes. The name of the model used for the second final site cannot be reliably established from the original description, so this result should not be attributed to a specific DeepSeek version without qualification.

The difference between the sites proved significant specifically in their interactive content. In the Kimi version, according to the author’s description, images were used instead of fully interactive models. In the other version, the user could rotate the 3D model, choose a car, and launch the game directly in the browser. Both sites supported a browser game and responsive layout.

The interfaces were similar in structure. The author associates the main differences with the colors, generation time, and expenses rather than with a completely different design concept. The comparison demonstrates a limitation of such tests: a model can assemble a convincing layout, but it does not always transfer complex interactive components into the visual part of a site equally well.

Why a faster result is not always better

Fast generation reduces the time to the first prototype, but does not guarantee that all requirements will make it into the final build. In this experiment, according to the author’s assessment, Kimi handled the tasks faster, but in the final site version the interactive 3D model was replaced with images. If the project’s sole purpose is presentation and a visual layout, such a compromise may be acceptable. For a product demonstration, game, or digital catalog, it changes the meaning of the result.

In the described scenario, DeepSeek worked longer and required less money. The author considered its result slightly higher quality, especially in terms of model detail and the game component, but did not claim that the advantage was radical. The choice between generators depends on what costs the project more: waiting for completion, API expenditure, or manually refining omitted features.

The claim that an OpenCode Go subscription for 10 dollars provides a virtually unlimited DeepSeek limit is not confirmed in the presented material. This is the author’s opinion about the plan’s capabilities, not an established universal condition. Limits should be checked against the current terms of the specific subscription, selected model, provider, and access method.

How to accept a site created by a neural network

The final review should assess not the impression made by the interface, but whether the requirements have been met. For a project with 3D models and a game, it is convenient to use a sequential checklist.

• Open the site on a computer and a mobile device; check the menu, block grid, fonts, and the absence of horizontal scrolling.
• Check that each model loads after refreshing the page and when moving between sections.
• Rotate the object in all directions, change its scale, and make sure the camera does not fall inside the geometry.
• Select each car and check that the name, image, characteristics, and actually loaded model correspond to one another.
• Launch the game without reloading the site; check keyboard controls, reversing, collisions, and returning to the track.
• Compare the stated car characteristics with their actual behavior in the game.
• Check the mini-map, start, finish, direction of travel, and reaction to leaving the track.
• Inspect the browser console and network requests to find errors when loading files, textures, and JavaScript modules.
• Assess the size of the 3D resources and the time required to open the page for the first time on a typical mobile connection.
• Save the working version of the project separately from the experimental files so that a subsequent generation does not destroy the fixes.

Practical workflow

First, prepare the models and check them separately from the site. Then launch the game with one model, make sure the controls work, and only afterward connect the remaining cars. The final stage is assembling the interface, with the presentation blocks, 3D viewer, and transition to the game tested separately. This order makes it possible to determine at which layer an error occurred.

It is better to formulate the prompt for the generator as a technical specification with measurable results. It should list the required sections, the behavior of the 3D scene, the car-selection rules, the method of launching the game, the responsiveness requirements, and the files that must not be replaced with images. The phrase “make a beautiful interactive site” leaves the model too much freedom and does not guarantee that the key function will be preserved.

The author’s overall conclusion from the experiment can be phrased as follows: in his scenario, Kimi was oriented toward speed, but cost more and did not fully preserve the interactive 3D component in the final site. DeepSeek worked longer, but the author assessed its result as more cost-effective and slightly higher quality. This is not a universal model ranking, but an observation based on a specific chain consisting of 3D models, a game, and a responsive site.