Practical HY4 test: can a model create games and interactive websites

This article examines HY4 as a model for generating software prototypes, rather than as a ready-made game engine or website builder. The author tested it on four tasks: creating a 3D orc, an interactive aquarium, a puzzle platformer, and an unusual web interface. The test demonstrates HY4's strength: the model quickly assembles a cohesive project with graphics, object behavior, and an interface. At the same time, the experiment reveals a limitation: a working prototype does not yet mean an accurate model, polished animation, or a fully completable game.

All prices, time frames, and estimates below apply to this run and are reported according to the test author's account. They do not confirm the universal cost of HY4's work and do not replace a repeat test on another task.

How the HY4 practical test was organized

The author ran the tasks at the highest level of reasoning available to him through an Open Code Go subscription. The experiment tested not individual code fragments but complete interactive prototypes: the model had to create a scene, add objects, connect them through behavior, and allow the user to interact with the result.

This approach is more important than demonstrating a single attractive screen. In a game, it is not enough to draw a robot or an orc. The player must be able to move, receive clear feedback, activate mechanisms, and complete the level without dead ends. For a website, an 3D background is not enough: controls must respond to actions, and the mobile version must not destroy the composition.

So what exactly did the author measure? He recorded generation time, input and output token usage, the volume of cached tokens, launch cost, and the result of a manual check. One of the runs in the design test was interrupted, but the author included its time and total token usage in the final estimate.

3D orc: HY4 assembled the scene but did not bring the character to a polished state

The first generation of the orc project took 13 minutes 47 seconds. The run used 103 000 input tokens, 67 274 output tokens, and 2,862 million cached tokens. The author estimated the cost of this stage at approximately 0,187 dollars.

The scene included the character's main parts: a body, head, limbs, tusks, armor, ears, eyes, hairstyle, and an axe. That is a notable amount of work for a quick prototype. HY4 was not limited to the geometry of a single primitive, connected the character to the weapon, and added a visual glow effect to the axe.

The model's quality was uneven. The proportions looked problematic, the neck was missing, and the face and hairstyle contained errors. These defects matter for more than just appearance. Incorrect geometry affects the perception of movement, the weapon's position, and the credibility of the animation, especially when the character is supposed to perform a specific combat action.

The first axe attack worked poorly. In the author's observation, the movement looked more like a golf swing than a full weapon swing. The glowing effect on the axe was present, but it did not fix the weak movement mechanics. The test shows the difference between having an animation and having an animation that matches the intended concept.

An additional prompt improved the function but did not eliminate the underlying problem

After the additional request, HY4 used 412 000 input tokens, 123 000 output tokens, and nearly 23 million cached tokens. The author estimated the improvement at approximately 0,80 dollars and put the project's total cost at approximately 1,99 dollars.

After the iteration, the orc held the axe in front of himself. A side attack was added to the project. This shows that the model can continue working with an existing project and change its behavior in response to a textual instruction, rather than merely starting a scene from scratch.

But the iteration did not solve the main problem. Some details looked worse, the orc model did not improve substantially, and the animation quality remained weak. The author's result is important as a warning for developers: a large additional context and a new prompt do not guarantee a proportional increase in quality. Sometimes the model changes neighboring elements and affects parts of the scene that were already working.

Aquarium: strong behavioral logic with uneven 3D graphics

Generating the aquarium took 53 minutes. It used 576 000 input tokens and 178 500 output tokens. The author estimated the cost at approximately 1 dollars, while the exact number of cached tokens was not provided in the record.

The fish swam and moved their tails, and their movement logic, according to the author, worked without obvious problems. The scene also included a crab, snails, plants, and a castle with towers. The crab had claws, lateral movement, and separate claw movements, although the model contained some unnecessary protruding details.

The visual quality of the objects varied. One orange fish had a deformed snout. The snails were recognizable, but their shells looked inverted. The plants looked fine, and the author considered the castle with towers sufficiently convincing. The result was a scene in which the functionality of individual objects outpaced the quality of their geometry.

HY4 also implemented a number of environmental effects: an aerator produced bubbles, particles moved through the water, waves with bubbles appeared on the surface, and objects were distorted through the water layer. Some elements had noticeable repeating bands or reflections. Such artifacts do not break a demonstration prototype, but they become apparent when trying to use the scene as the basis for a finished product.

Puzzle platformer: the mechanics work, but completion remained questionable

The platformer generation used approximately 758 000 input tokens, 275 000 output tokens, and 36 million cached tokens. The author estimated the launch cost at 1,42 dollars.

The game included a robot, platforms, parkour, energy-recovery stations, and destructible obstacles. The central mechanic was a battery: the player carries it and inserts it into special slots to activate mechanisms and levers. This chain of actions already resembles game design rather than a simple demonstration of character movement.

The project revealed practical failures. Some destructible objects did not disappear, certain passages or obstacles sometimes failed to close, and the player could easily fall into a chasm. Enemies could not be destroyed; they could only be temporarily delayed. This limitation does not by itself make the game bad, but it needs to be clearly explained to the player and integrated into the level logic.

The author called the platformer interesting and noted that the result was better than expected. During the playthrough, he had to return for the battery several times and figure out the level logic. He later collected all the archives in the puzzle but could not understand how to proceed: jumps led to death, and it was no longer possible to activate additional elements. The author allows for two explanations: the problem may have been in the game itself or may have resulted from a playthrough error.

This episode shows why working mechanics do not guarantee a complete gameplay experience. AI can create an item, a trigger, and an activation condition, but it cannot check all of the player's routes in the way a tester does. To release such a prototype, manual testing of states, return points, collisions, victory conditions, and the ability to exit an erroneous scenario would be required.

Interactive website: an unconventional idea instead of a clear interface

In the design test, the author expected an unusual website, but HY4 generated an interface in the form of an intergalactic ship. According to the author's observation, the result looked strange and did not immediately make the project's purpose clear. The system chose an expressive concept but failed to keep the original task within the framework of a conventional web interface.

On the website, it was possible to change the size of the circular control, switch between nominal pages, and enter a custom message. The author noted that the button always opened the fifth screen, so the navigation logic cannot be considered fully tested. The project also contained sounds that the author considered more suitable for an intergalactic ship than for an ordinary website.

Responsiveness worked: the mobile version preserved the ship motif and 3D objects in the background. This is a strong result specifically for prototyping, since mobile layouts often break when complex backgrounds, unconventional elements, and animation are added. However, responsiveness only addresses display. It does not fix the unclear screen structure or the incorrect navigation button.

Creating the website used 186 000 input and 122 000 output tokens. The cache amounted to practically 10 million tokens, the author listed the cost as 44 cents, and the execution time was 31 minute 23 seconds.

Cost, tokens, and time for all experiments

In total, the author listed the cost of all tested projects as 3,85 dollars. The total execution time was 3 hours 17 minutes. These are the expenses of a specific test, not the HY4 rate for every project: the final amount depends on the volume of source code, the number of iterations, the reasoning mode, caching, and the complexity of the task.

Cached tokens noticeably increased the processing volume in some runs: nearly 23 million during the orc improvement and 36 million in the platformer. The exact cache volume for the aquarium was not provided. Such figures are useful for analyzing a specific session, but without an official pricing calculation scheme, they cannot be used to independently derive a universal price for each future generation.

Final assessment of HY4 for games and websites

The practical test shows that HY4 is suitable for quickly creating rich prototypes. The model was able to assemble a 3D character, an aquarium with animal behavior, a platformer involving battery transportation, and a responsive website with a 3D background. Its work with the aquarium's logic and basic game mechanics looks especially convincing: objects moved, responded to actions, and supported a coherent interaction scenario.

HY4 performed less well where artistic precision and prolonged state testing were required. The orc had problems with proportions and animation, the animals developed deformations and extra details, and the platformer contained questionable sections of the route. The web interface retained its responsiveness but was unclear in purpose, and one of the transitions did not work as expected.

The practical takeaway for developers is that HY4 should be used as a tool for initially assembling an idea, not as a replacement for a programmer, a 3D artist, and a tester. After generation, it will be necessary to check collisions, transitions between states, the availability of all routes, operation on a mobile screen, visual artifacts, and whether the result matches the original brief.

The test author considers HY4 interesting but too expensive for his own work, even with a discount. This assessment is subjective and relates to his experience, the tasks he used, and his comparison with other models. As a prototyping tool, HY4 demonstrated potential, but based on this experiment, it still requires a significant amount of human testing and refinement before it can reliably produce finished games and websites.