DeepSeek V4: Optimizing AI Game Generation on a Budget

Can affordable models make browser games that people actually want to play? Over the past week, we have been testing that question in OpenGame Studio. The latest addition is DeepSeek-V4.1-Flash-1017, the October 17 release in the DeepSeek V4 family.

We also tested Grok 4.6, Xiaomi MiMo V2.6 Flash, MiMo V2.6 Pro, GLM 5.3 Flash and Claude Haiku 5.5. The aim was to improve the balance between generation expense, waiting time, playable behavior and visual quality. A game that opens successfully can still move right when the player presses left, award coins too early or keep falling while paused.

The latest DeepSeek runner passed the core gameplay checks we exercised. Its artwork was modest. Earlier experiments exposed different problems, including a fault in our own delivery validation. Those details are more useful to a creator than an unexplained model ranking.

The original DeepSeek-V4.1-Flash-1017 runner. The character, lanes and coins are distinguishable; the environment remains a basic prototype.

Optimizing for affordable game generation

For a small game maker, repeated experiments matter. A first version may need another attempt at its camera, controls, collision rules or art direction. The practical question is how much useful, testable game we get from that process.

A powerful flagship such as Claude Opus 5.5 is an obvious alternative for demanding coding work. Its official description also discusses working with subagents. We wanted to explore a more affordable shortlist before choosing a larger workflow. A model name alone does not guarantee a good game, and using several agents is a workflow choice that can add work and consumption.

Our shortlist had different roles:

• Grok 4.6 provided a general-purpose reference. It was a less budget-focused choice for us, with subscription access part of its appeal. The official release page describes coding access through Grok Build and other tools.
• Xiaomi MiMo V2.6 Flash and Pro let us compare two options from one family. Xiaomi positions Flash around efficient, frequent use and Pro around more demanding reasoning and project work. Pro is a flagship within its own family; it was still a candidate in our budget exploration.
• GLM 5.3 Flash offered another efficiency-focused option. Its official introduction explains that positioning. We wanted to see how it handled the entire game request.
• Claude Haiku 5.5 added an overseas, cost-sensitive option. Anthropic describes Haiku for fast, high-volume work. We tested it as a game builder, with a limited review described below.
• DeepSeek-V4.1-Flash-1017 was the newest experiment. The release announcement includes project demonstrations. We used our own runner request to see what transferred to OpenGame Studio.

There are more China-based model families here because affordability put several of them on our shortlist. That reflects our selection process, rather than a conclusion about model quality by country.

One runner, six model experiments

Our shared game was Colossal Runner, an original third-person, three-lane endless runner. The character moves forward automatically. Players change lanes, jump over barriers, slide under overhead obstacles, collect coins and restart after a collision. Keyboard and touch should produce the same visible result.

The original request also included pause, earned-coin revives and a giant obstacle blocking two lanes, leaving one safe route. These interacting rules make the request more revealing than a moving scene with a score counter.

We reused the same original request in these experiments from October 11–17, 2026:

These are individual developer-run experiments. They offer a practical comparison fixture, with clear limits: each model produced its own brief and implementation, including different visual choices. Tests happened on different dates and the website environment was not frozen. MiMo Flash needed another discussion before its build. Times exclude discussion, specification work and playtesting; the GLM figure ends at rejection.

For the DeepSeek runner, we retained the existing generation constraints and the same 3D builder instructions used for the MiMo experiments. No manual source repair preceded its acceptance checks. This series does not establish a statistically reliable speed or quality ranking.

What MiMo, GLM and Haiku added to the picture

MiMo Flash produced an inspectable game with useful controls, including bounded keyboard, touch and pause checks. Its coin rule was the problem: rewards could arrive before the runner reached a coin. The source read the wrong position field during the collection check. A convincing scene and a rising counter had hidden a broken interaction.

MiMo Flash's original output, before later curated repairs. The collection timing defect came from gameplay and source checks; this frame alone cannot prove it.

MiMo Pro also delivered a playable prototype, and its directional and coin-contact checks were encouraging. Pausing in mid-air exposed a different flaw. Distance and coins stopped, while the character continued falling. A complete pause needs to freeze the relevant simulation, including vertical movement.

MiMo Pro's original city scene. Its pause defect required a mid-jump test, which an attractive still image would not reveal.

GLM needs two separate findings. The Studio run failed delivery because our validator misread inline game code as forbidden resource markup. That was a platform error. It would be misleading to count it as evidence that GLM could not generate the game.

We recovered the unchanged original and inspected it separately. Bounded direction, touch and pause checks worked there, while restarting could leave a stale coin display. That inspection tells us something about the artifact's behavior; it does not turn the failed Studio flow into a successful delivery.

GLM's recovered original under separate inspection. This image is not evidence of successful delivery through Studio.

Haiku 5.5 delivered its preview relatively quickly in this sample. The start screen appeared, then we ended the test after an initial visual review. We did not finish keyboard, touch, collision, revive or restart acceptance. The initial impression did not displace our preference for the MiMo experiments, but we lack the gameplay evidence to give Haiku a firm quality verdict.

This distinction matters when keeping a testing diary: delivered, visually reviewed and behaviorally verified are different milestones.

Why can left become right?

The Grok runner exposed the clearest control failure. From the center lane, ArrowLeft moved the character to the right side of the screen. Left swipes did the same thing.

Before: the runner is centered.

After ArrowLeft: the runner is visibly on the right. Both captures show the unmodified generated build.

The source explained it: the handler moved toward negative world X for “left,” while the camera direction made that movement appear right on screen. Keyboard and touch shared that lane controller, so both inherited the error.

The player's reference is the visible track. A decreasing coordinate does not establish correct leftward movement. A following camera also needs a check of the character relative to the lanes, since the character can stay centered on screen as the track moves.

A separate racing experiment exposed a weakness in our evaluation too. An automated controller could compensate for reversed steering and finish a lap. We now check each direction independently from a fresh start. Finishing the course had not verified the control labels.

What DeepSeek V4 did in our runner test

The latest runner took about seven minutes to build after brief confirmation. We exercised the original result through the website preview:

• Directions: ArrowLeft, ArrowRight, A and D moved toward the correct visible lane. Repeated input stopped at the outer lane.
• Touch: left/right swipes worked in portrait and landscape emulation. Up jumped; down brought the character down into a slide.
• Obstacles: keyboard play cleared a ground barrier, slid under an overhead bar and took the safe lane past the giant blocker.
• Coins and revives: collection began on reaching coins. A revive spent earned coins and resumed safely; an unaffordable revive spent neither coins nor a use.
• Pause and restart: pausing mid-jump held height and distance steady and blocked track input. Restart reset the center lane, distance and visible coins.

One obstacle run continued beyond 216 meters with 51 collected coins. Browser automation sent normal gameplay inputs. We did not alter coordinates, scores or collision state to obtain that result.

A left swipe reaches the visible left lane in portrait browser emulation. Physical-phone compatibility remains untested.

We did not exhaust every random obstacle sequence, train-roof route, revive limit or late-game state. Within the tested scope, this was a working prototype with encouraging rule handling.

Logic, artwork and readability need separate judgments

The DeepSeek runner made important objects distinguishable: a teal character, bright lane edges, gold coins and contrasting hazards. Its dark, sparse environment and simple buildings left considerable room for visual improvement. That single result does not establish a general claim that DeepSeek is better at logic than art.

Our separate Neon Harbor Sprint experiment had strong neon styling, but the car's silhouette and road were harder to read. A performance revision lowered rendering resolution, improving responsiveness while losing definition.

A separate DeepSeek racing prototype. It used a different request and is outside the shared-runner comparison.

We returned to the runner because a different game would obscure the comparison. The racer still supplied a useful lesson: judge the character, hazards and lane boundaries at actual playing size, with the game in motion. Effects and interface decoration can coexist with poor readability.

Are prompts and skills too restrictive?

Our runner request was deliberately detailed so we could reuse it. An ordinary creator should be able to start with a much shorter idea. Helping turn that idea into a useful brief is part of the product's job.

We have not run a controlled short-prompt versus detailed-prompt comparison. Prompt length therefore cannot explain the reversed controls on its own. The failing source provides a direct camera/input explanation, and other outputs from the shared request got the directions right.

Some constraints protect the experience: consistent controls, meaningful coin contact, a complete pause and a clean restart. Other choices can stay open, including theme, palette, camera presentation and how the model constructs the scene. A rigid build process may also leave too little room to inspect and improve the first implementation. More revision opportunities are worth testing; their benefit remains a hypothesis here.

Earlier attempts showed why workflow deserves attention. One MiMo attempt exhausted its response allowance before delivering a game. Another wrote code but lost the final delivery when a provider stream failed. Those failures had different causes and should be recorded separately from gameplay defects. They also prevent us from treating every historical attempt as a model-only A/B test.

A creator could begin with:

Make a quick 3D runner with three lanes. Let me dodge left and right, jump over barriers and slide under beams, using keyboard or touch. I want a clear character, satisfying coin pickups and a quick restart when I crash. Choose the setting and visual style.

This is a suggested starting point, not the original comparison prompt. Studio can clarify missing rules, confirm the brief and preserve room for creative choices. Then a short playtest can identify the next useful revision.

What these tests change about our next experiment

For us, optimization now includes delivery reliability, inspection time and the amount of repair a playable result needs. Cheap generation is useful when the result survives ordinary input and can improve through a manageable revision loop.

We will keep original outputs, record the stage each attempt reached, and test keyboard and touch against visible behavior. A future comparison can hold the game steady while changing one workflow variable, such as brief length or revision opportunities. These observations alone do not tell us which model will win that experiment.

For a playable example, visit Colossal Runner. Its public curated versions include later repairs and are separate from the original experiments shown here. You can also browse other browser games for ideas about the experience you want to create.

Have a small game idea? Start a brief in OpenGame Studio, agree on the core loop, and test the first version with real inputs.

Source note

Official sources establish model names, release context and vendor positioning: DeepSeek's October 17 release, Grok 4.6, MiMo V2.6 Flash, MiMo V2.6 Pro, GLM 5.3 Flash, Claude Haiku 5.5, and the untested flagship background example, Claude Opus 5.5.

Gameplay observations and build times come from our own OpenGame Studio experiments and their retained originals. The eight images are unchanged captures from those inspections, with original procedural art or OpenGame M0 character assets licensed CC0-1.0. No image is a provider demonstration or an enhanced reconstruction.