What to Consider When Building a Game with AI

EXPERIMENT 01 Combat presentation locked · Concept test before actual game design

Playing games as a kid made me want to become a programmer. I wanted to build my own. Practical realities kept me out of the industry — and now, in 2026, AI has revived that dream. This experiment checks how far one developer who has never built anything but Tetris can get with AI.

Steam already carries many shipped games made with AI. BCG's analysis of public Steam data through August 2025 counts about 7,300 games disclosing AI use. Roughly a fifth of new releases in Q3 2025 declared AI use, and 88% of disclosing games used AI for creative work and in-game graphics. Generative AI has settled in as a real shipping tool, owning part of the production pipeline.

Producing the assets and code you need is not the same as finishing.

Start building and the idea that AI makes the game for you hits two walls. The first is design. What carries a game — an RPG above all — is a story worth sinking into and gameplay that keeps pulling you back.

Generated assets are the second. Generating an image has become easy; producing a project's worth of illustrations in one consistent style and format, then filtering and fixing the wrong ones, is separate work. Astroloot's developer described generating the needed range of images, then personally selecting, adjusting, and integrating the results that matched the game's vision and quality bar.

In our experiment too, aesthetic judgment redirected the work more often than feature implementation did. A small arrow logically reached its target but went unnoticed on screen. Action beyond the viewport needed focusing, and a spell effect moved but looked like a vector icon, clashing with the world's art style. It confirmed once more that the judgment that carries an AI draft to a scene that reads as a game is still human work.

So we decided to build and ship a real game with AI.

If we ship a game built with AI on Steam and operate it, how far can it actually grow? What difficulties will we hit?

This series designs, builds, ships, and updates one role-playing game, checking that question stage by stage. The first stage verifies that the presentation approach is feasible. Next comes playable combat and a progression structure, then a Steam demo, release, operations, and sales.

This record is that first stage. Before talking about fun or marketability, we had to find a production approach we could sustain.

Across hundreds of tests, animation was the hardest part.

We initially expected AI to handle scenes of characters walking, swinging swords, even casting spells. We ran hundreds of tests across image and video generation models, adjusting prompts and input images. A single scene could come out plausible. But the moment one character's face, build, equipment, and motion had to stay consistent across frames, the difficulty climbed so sharply that we concluded it is, for now, close to impossible.

An RPG needs motion of a consistent standard for every added character, weapon, attack, and skill. Regenerating and patching every unstable result means costs grow with content. We removed sprite-frame asset generation for elaborate animation from the current production scope.

This is not abandoning animation forever. The realistic call, for now, is to fit the game's form to the work AI does relatively reliably.

First, the combat scene.

We built a tileset in a two-dimensional array suited to portrait card illustrations. Rather than shrinking the cards or letting them overflow the tiles, it seemed better to switch the battlefield to front-facing square cells and let each card fill most of its cell.

The map does not use the full rectangle. Only the 83 cells included in the per-row mask participate in movement, line of fire, and area adjudication. Rivers and cliffs block movement; forests cost extra movement. Allies can be passed through but not stopped on, and enemy cards cannot be passed. Art and adjudication are separated so that swapping the background image never shakes the combat rules.

The screen size is not fixed either. Players drag and zoom the battlefield. The camera follows a card as it moves, and before a long-range attack it reframes so attacker and target are visible together. Making static cards feel like they move owed as much to the camera as to the cards' own movement.

Full-screen presentation reinforced what the static cards do

On the first turn, the three characters each use a melee attack, an arrow, and a magic bolt once. The next turn extends the same weapons and magic into area skills. Adeline's Cross Cleave cuts three forward cells at once, and Mateo's Chain Volley fires distinct arrows at up to three targets. Lisette's Arcane Nebula drops star-shaped nebulae in succession on the nine cells around a chosen point.

When a skill starts, the map first darkens and the dedicated illustration and name appear. After repeated timing passes we separated full visibility at 1.8 seconds from the 0.08-second exit to the right — the result of refusing to solve reading time and exit punch with a single speed value.

It then telegraphs the affected cells and runs the skill body, per-target hits, damage numbers, and knockouts in order. Range is not fixed to a single shape like a cross. Each skill returns the set of cells it affects, so piercing lines, fans, and techniques that sweep several cells in sequence can be added to the same structure.

Every time something felt off, human judgment stepped in

When arrows and bolts read too small, we enlarged their bodies and speed lines and kept their size constant under zoom-out. When attacks beyond the scroll went unseen, the camera now frames both units before the attack. The Arcane Nebula that looked like vector design was rebuilt as a transparent image with a star core and a nebula tail. Even so, the quality still does not satisfy us.

Video had the same problem. Converting a real-time recording to 60fps did not remove the stutter of duplicated frames. We switched to advancing timers and animations on a virtual clock and capturing each frame directly. The demo plays at normal speed, and only the intro video's 1.5× speed is applied in post-processing.

These fixes do not mean AI failed. They mean the more important work is judging which approach fits real production and turning many outputs into one rule.

Next experiment

The next record implements this concept as a playable game architecture and builds a demo you can actually play.