How Far Has AI Game Development Actually Come?
I have been working in the AI Game space for the past few months, which happens to be our company's core business. In this article, I want to share my assessment of the boundaries of AI capabilities in this gaming track: what AI can achieve right now, where it gets stuck, and some of the pitfalls I've encountered while building an AI game generation platform.
Since models entered the era of Fable 5 and Opus 5, achieving one-shot generation for most games (generating a game directly from a relatively professional prompt) has become largely possible. For example, back in July, I fed in a single prompt and directly generated a Chinese ink-wash style Xianxia tower-climbing game, and even had the AI playtest it itself to guarantee the rationality of its numerical balance—and the numbers did indeed turn out very reasonable.
At present, the boundaries of AI capabilities in game generation are very clear, and this boundary has little to do with how difficult the game itself is.
1. What Determines the Ceiling Is Actually the Engine, Not the Model
Let's start with a counter-intuitive conclusion: whether AI can help you build a game depends on the game's representation format, not the model's intelligence. LLMs can only manipulate text; therefore, the closer an engine is to pure text, the stronger the AI will be; the more it relies on visual editors, the weaker the AI becomes.
There are two layers of reasons for this:
Ranking mainstream engines under this framework:
Therefore, my judgment is: choosing the engine is far more important than choosing the tools; the engine determines 80% of an AI game's ceiling. The capabilities of different frontier models are heavily homogenized, crowded within the same performance tier. The differences between Agents lie primarily in workflows rather than the intelligence of the models themselves. Picking the right game engine is the single most important decision, and the trouble saved down the road scales geometrically.
1️⃣ Why almost all AI games seen today are H5 and Canvas web mini-games
The apparent simplicity of generating these games is just a surface phenomenon; the root cause is that code for their tech stacks is the most densely represented in training data. For a tower climber or match-3 game implemented in Canvas, there are tens of thousands of variants lying in various tutorials on GitHub. From render loops to collision detection to state machines, the coding patterns are highly convergent. The model has seen them countless times, so generating them is almost like walking a well-trodden path, with syntax-level issues rarely occurring.
Conversely, when looking at a complete commercial engine project, public, full-fledged projects are virtually non-existent; all you can find are snippets and demos. The model's understanding of them is pieced together, making it prone to errors whenever holistic consistency is required.
Judging which genre AI is strong at depends not on how difficult the genre is, but on how much public code exists. This rule holds true not just for games; no matter what tech stack you test AI with, the same pattern applies. This is also why I don't really buy into the narrative that AI will soon be making AAA games. With models entering the 5 era (Fable 5 / Opus 5), what models lack for gaming is not intelligence, but a massive volume of corresponding public engineering data.
2️⃣ Easy with mostly static assets, hard with mostly dynamic assets
This boundary has proven remarkably consistent throughout my testing, and it is also our team's consensus: the more static elements a game has, the easier it is to make and the more stable the generated output; the more dynamic elements it has, the more prone it is to errors, making quality hard to guarantee.
Genres that are easy to make: Strategy, Tower Climbers, Card Games, Idle Games, Puzzles, and Management Sims. The visual focus of these games is primarily static—an image sits there, and interaction progresses through clicks and numerical changes. These types of games usually yield great results in a single one-shot generation.
Genres that are difficult to make: Action, Fighting, and Platformers. The core experience of these games lies between frames: an attack animation requires a startup, active hitbox frames, and recovery frames, and must also align with physics rules, invincibility frames, and the player's tactile feel.
The fundamental difference is that games with dynamic assets demand extreme consistency across multiple dimensions simultaneously: animation frames must be coherent, animations must align with hitboxes, and hitboxes must match player feel. When AI generates a game, these aspects are handled separately, often leaving one or more links disconnected in the final generated product.
Therefore, when choosing a topic, first see whether the core experience of the game relies on static or dynamic elements. Games that hinge on dynamic elements can rarely be achieved in one go; they require continuous polishing until they have sufficient "game feel."
3️⃣ AI Deep Waters: Multiplayer, Frame-Level Sync, and Build Pipelines
Categorized by strengths and weaknesses, AI's capable and weak zones are very clearly demarcated. Gameplay scripts, boilerplate code, shaders, procedural generation, and debugging visible errors fall into AI's strong zone—it executes these quickly and stably.
However, multiplayer networking, frame-level audio-visual synchronization, and build pipelines remain fixed weak zones. These areas are still deep waters for models, making it difficult to generate appropriate results consistently.
Of course, this doesn't mean this part is completely impossible to implement. It's just that relying on AI alone to handle everything in one shot is still extremely difficult right now; it requires extra reinforcement at the engineering level. For instance, our platform has already implemented multiplayer online games.
This actually follows the same pattern mentioned earlier: networking and frame-level synchronization do not need vast lines of code, but rather cross-process consistency judgment. Public engineering data of this type is extremely scarce, leaving AI with very little to learn from.
2. Code Is No Longer the Bottleneck; Assets and Numerical Design Are What Get People Stuck
This point may run counter to many people's intuition: for code at the scale of web mini-games, there is essentially no need to worry about current coding capabilities. It writes it out, runs it, and the logic is correct, with almost no bottlenecks. At the code level, there are probably only two remaining issues.
One issue that arises is that AI cannot detect non-syntax bugs in its own games. For example, there might be a "Start" button on the splash screen, and we often encounter situations where this button cannot be clicked or clicking it yields no response. The AI doesn't realize this problem because it directly calls the button's corresponding code for verification rather than attempting to mock an actual click. Non-syntax bugs like this still appear frequently.
Another issue is AI's page design, which is often unsatisfactory. The overall layout lacks aesthetic appeal and frequently ignores the spacing between elements and the width of container boxes, leading to pages that are either overly cramped or excessively loose, along with occasional text overflow. This situation can be avoided by providing reference images to the AI in advance.
AI productivity gains are real on small projects, but once a project exceeds roughly 10,000 lines of code or coupling becomes tighter, productivity reverses. Experimental data shows that 16 senior developers using AI on mature repositories were actually nearly 20% slower, despite feeling faster themselves; in high-adoption teams, while merged PR volume doubled, review time nearly doubled as well. Therefore, the conclusion that "code is not the bottleneck" holds true only for web mini-games generated entirely by AI.
What truly determines whether an AI game is fun are two things besides code: assets and numerical values. Assets determine whether it looks like a game, while numerical values determine whether it feels right to play. Neither of these can be resolved simply by the model's code generation.
3. How to Stably Generate Game Assets
4️⃣ Level 1: The Failure Rate of Image Generation Itself
As an AI game generation platform, we typically use multiple models at the engineering level to generate assets. For these diverse models, constructing a unified superset parameter interface is essential. The real challenges in game image generation are unstable output quality and ensuring consistency across a complete visual style.
A high failure rate is far more fatal in game scenarios than in others. You don't just need a single good image; you need a complete set of stylistically consistent images: different states of the same character, different buttons of the same UI suite, and different scenes within the same worldview. An 80% success rate for an individual image sounds decent, but the probability of getting all 20 images in a set to meet the standard becomes extremely low.
Therefore, the true metric for the asset stage is not individual image generation quality, but the consistency of the entire image set. The gap between these two metrics is where I have spent the most time across this pipeline.
5️⃣ Level 2: Transparent Backgrounds
Game assets almost always require a transparent background—characters, items, and UI elements must all be able to layer over scenes.
Image generation models provide complete images with backgrounds, and the models do not support generating transparent backgrounds directly via API, requiring programmatic background removal.
I spent dedicated time debugging the processing and export of transparent assets. It sounds like a minor step, but in practice, it acts as a critical choke point across the entire pipeline: if cutouts are unclean, even the best upstream generations cannot be used; if batch processing is unstable, asset production cannot scale.
This type of procedural challenge is easily underestimated because many shapes are irregular. Cleanly cutting out irregular shapes as much as possible while ensuring the final image quality is quite a complex engineering task.
6️⃣ Level 3: Animation
To make characters move, 2D development has two primary routes.
Sprite Sheets (frame sequences): One image per frame; playing them in sequence creates animation. The approach is straightforward and offers the highest artistic freedom, but the trade-offs are large file sizes, inability to procedurally interpolate, and having to redraw an entire set to modify a single action. When I built our platform's sprite sheet generation capability, it ran right back into the set consistency problem mentioned above: character drift across frames is a fatal flaw—clothing details, weapon lengths, and facial features all shift, causing issues like jittering and restricted movement in dynamic animations.
Skeletal Animation: Building a bone hierarchy for the character and binding sliced parts to the bones, where the animation records keyframe transforms of the bones. The mainstream industry tool for this is Spine, which exports skeletal data and texture atlases with runtimes available across various engines. The benefits are small file sizes, reusable actions, and procedural blending (e.g., a hit reaction can blend naturally from any pose). However, AI cannot design skeletal animations and often violates numerous laws of physics. AI can help you generate sliced texture assets, but how to rig bones and design keyframes for each action is a matter of design, not generation. It requires structured output paired with aesthetic judgment in motion design—and public data of this kind is extraordinarily scarce.
In the end, we adopted the sprite sheet route, and after multiple iterations of tuning, the final results turned out quite well.
7️⃣ Audio and Video
AI can now generate usable background music and short sound effects (clicks, hits, coin pickups), and mature asset libraries are also sufficient, so this area is not a bottleneck; procedural special effects like particles and shaders are essentially code, which AI can also handle.
What remains truly unsolved is enabling an Agent to understand audio-visual content and make judgments accordingly—generating background music matching the game's style, selecting appropriate short sound effects, and so on. Furthermore, in the realm of audio, using specialized APIs or dedicated models still yields significantly better results than generating directly from general-purpose large models.
4. Numerical Design: AI Provides Balanced Solutions, Not Experience Curves
8️⃣ Why AI-Generated Numbers Often Look Reasonable
Numerical structures for games like tower climbers, card games, and idle games are abundant in public materials: growth curves, damage formulas, drop rate designs, and economic loops are covered in piles of tutorials and teardown articles. As a result, the initial numerical values provided by AI are usually self-consistent, avoiding ridiculous scenarios like one-shot kills or needing 300 hits to defeat a basic mob.
However, self-consistency and being fun are two completely different things. My observation is that AI tends to provide balanced solutions where values are mutually balanced and curves are smooth. Yet game experience demands precisely a curve with peaks and valleys: getting distinctly stuck on a certain level, experiencing a rush of satisfaction after clearing it, and being given a game-changing variable in between to turn the tables. AI will not proactively introduce this kind of deliberate imbalance, because its optimization target is reasonableness, not dramatic fluctuation.
9️⃣ How to Validate Numerical Values: I Think It Should Be Handled by Agents
Whether numerical design is good cannot be verified by playing a few matches manually—the sample size is simply too small.
A more reliable approach is running simulations: writing an automated script or agent to play thousands of runs, observing win-rate distributions, clear-time distributions, and which floors see the highest concentration of bottlenecks. Numerical issues become instantly visible on distribution charts, making this far more effective than manual playtesting.
This happens to be where agents in gaming scenarios become far more interesting than elsewhere: games are one of the few software formats where an agent can run and generate evaluation data on its own. The reason many model releases now have models build games follows the same logic: games involve coding, asset generation, numerical gameplay design, and more, allowing multi-dimensional validation of model capabilities—and executing game evaluation well is exceptionally challenging.
5. My Current Assessment
At this stage, what AI can complete independently are web mini-games dominated by static assets—from code to playable state, one-shot generation is entirely feasible. Moving toward action games or genres requiring continuous animation, it delivers semi-finished products rather than finished ones, leaving humans to fill in precisely the most time-consuming parts.
The pipeline for code has already been cleared for AI, but the pipelines for assets and numerical design have not.
Assets are blocked by full-set consistency and motion design; numerical balance is blocked by the lack of cheap, sound validation methods. Going forward, what is worth watching is not whether models will become smarter, but whether specialized tools will emerge along these two pipelines: a tool that can stably output stylistically consistent sets of assets, and a tool that can automatically run numerical simulations or game balance design.
There is also an operational takeaway for everyday creators using AI to generate games, which comes from my recent practice: choose your engine before choosing your tools, build the playable core loop first, prioritize games that generate mostly static content, and connect the Agent to a closed validation loop (enabling it to run the game and inspect results on its own).
If this article was helpful to you, feel free to leave your feedback in the comments, and I will swiftly roll out Part 2.