The fastest way to build a game with AI is to stop asking it for “a whole game” and start asking it for the next verifiable layer.
The workflow that actually works
Most people fail at AI game development for a simple reason: they hand the model a vague fantasy and expect a coherent game loop to appear. That is not how this works. A useful AI game build has a strict order of operations.
Keep the project clean. In the original notes, the folder started almost empty except for the AI skill folders. That matters. You want the model to reason about the current project, not wander through unrelated code.
Use public/assets. Put every downloaded art pack there. If the assets are not organized correctly, web loading paths become fragile and AI will waste time fixing file-path problems instead of building gameplay.
This is the big unlock. Ask the model to inspect the asset folder and create an assets.json index that describes backgrounds, sprite sheets, frame dimensions, tilesets, decorations, and animations.
Even if the AI knows the individual assets, it still needs a visual target. A mockup tells it where the ground should sit, how the parallax should feel, and what kind of scene composition you want.
Do backgrounds first. Then the tiles. Then the player. Then collisions. Then controls. Then animations. Then parallax. Then attack. Then props. Each layer should be visible and testable before the next one lands.
When the model can open the game, press keys, and inspect screenshots, it can catch obvious breakage faster. This is especially useful for movement, jump arcs, idle animations, attack triggers, and layout bugs.
Never ask for final polish before the movement loop feels right. If walking, jumping, collisions, and animation states are broken, decorations are a distraction.
The minimum stack
Use Phaser when you want a browser-based 2D engine with sprites, animations, camera handling, tilemaps, and physics primitives that AI can reason about well.
A Phaser-focused skill gives the model a framework memory: how to load sprite sheets, how to define animations, how to use scene lifecycle, and how to avoid common mistakes.
Use a consistent asset pack with character sheets, backgrounds, props, and tiles. Mixed art styles or random sprite dimensions create needless ambiguity.
Playwright-style automation is what lets the AI move from code generation into actual verification. It can load the page, press movement keys, and compare the result against the expected scene.
Why the asset index matters so much
Game assets are not self-explanatory. A sprite sheet does not tell the model where idle starts, where run ends, or whether the frames are square. A tileset does not explain how many tiles it contains or which dimensions the scene expects. AI gets much better once you force all of that into one machine-readable file.
- What backgrounds exist, and in what order should they render?
- Which image files are sprite sheets versus static props?
- What are the frame width and frame height for each character sheet?
- Which animation rows or frame ranges correspond to idle, run, jump, attack, fall, roll, or death?
- What tileset dimensions exist, and how should they be used for the ground?
- Which decorations can be dropped into the level without animation?
If you skip this, the model keeps rediscovering the asset folder from scratch. If you do it once, every later prompt becomes cleaner and more reliable.
The practical prompt sequence
These do not need to be clever. They need to be explicit. The original notes effectively used two anchor prompts and then a series of tight correction prompts.
Prompt 1: build the asset index
Study the assets in the public/assets folder and create an assets.json
that indexes the assets for Phaser.
Account for:
- sprite sheet animations
- frame dimensions
- tilesets
- backgrounds
- decorations
Use the Phaser skill.Prompt 2: build the baseline scene in steps
Use the Phaser skill to replicate the mockup.
Plan it out first.
1. Add the three background layers.
2. Add the tileset for flat ground in a single layer.
3. Place the character and add controls.
Reference assets.json for the list of assets.
Do this step by step, not as a one-shot build.Prompt 3+: tighten one visible problem at a time
The idle animation is wrong. Refer to assets.json and fix the frame sizing.
Take a screenshot to verify.
The run animation is bleeding from the row above. Fix the frame height.
Add infinite scrolling to the right with parallax.
Add an action button that plays the slash animation.
Add props and decorations, but keep them grounded to the tile layer.When the output is visual, ask for a screenshot after the change. That forces the loop from “generated code” into “observed behavior.”
The build order I would recommend
- Initialize the project and confirm Phaser runs a blank scene.
- Create
public/assetsand drop in the entire art pack. - Generate
assets.jsonand manually spot-check the animation frame ranges. - Save a mockup image of the target scene.
- Implement layered backgrounds only.
- Add the ground tiles and basic camera framing.
- Add the player sprite with physics and standing collision.
- Add left/right movement and jump.
- Bind idle, run, jump, and fall animation states.
- Add parallax and infinite scrolling.
- Bind the attack animation to a key.
- Place props and static decorations.
- Do a final pass on feet-to-ground alignment and camera feel.
Where AI usually gets it wrong
The repo notes show the exact kind of failure you should expect: the model got very far, but a few small mistakes created ugly visual bugs. Those bugs were not random. They came from predictable blind spots.
This creates ghosting, sprite bleeding, and duplicated body parts. It is the most common issue when the model guesses frame dimensions from a sprite sheet.
If idle or run starts on the wrong frame, the state machine may technically “work” while the character looks broken.
AI often places the player slightly inside the tile layer or floats decorations above the ground. This is a collision box and anchor-point calibration problem.
Some models ignore the request to go step by step and rush ahead. That creates more surface area for bugs. Push them back to incremental execution.
- If the sprite looks doubled, inspect frame width first.
- If the run animation pulls pixels from the row above, inspect frame height next.
- If jumping works but the feet clip into the ground, adjust body size, sprite origin, or ground Y offset.
- If props float, stop placing content and fix scene anchoring first.
- If the model starts changing too many systems at once, reset the prompt to one isolated bug.
What browser automation is actually good for
Browser testing is not magic. It will miss some issues. But it is still one of the best upgrades you can add to an AI game workflow because it gives the agent a rough visual and interaction loop.
It can verify that the page loads, that the character appears on the ground, that a keypress moves the sprite, that there is no right-hand level boundary anymore, or that an attack animation fires when the action key is pressed. It is not perfect at judging feel, but it is good at spotting obvious breakage.
If the model has multiple bugs at once, browser automation can misread them. A character might move right because of a rendering artifact rather than a correct movement loop. Treat screenshots as evidence, not truth.
How to know when the game is “good enough”
You do not need a full RPG before publishing a build log or demo. For a first playable, the bar is lower and clearer:
- The player can stand, move, jump, and attack.
- The background layers create believable depth.
- The level scrolls without obvious seams or hard stops.
- The art pack feels coherent.
- The animation states do not visibly break.
- The scene has enough props to avoid looking empty.
That is already enough to share a video, collect feedback, and start the next iteration. Add enemies, pickups, combat hitboxes, level design, and sound after the basic loop is stable.
The bigger lesson
AI does not remove the need for game design judgment. It compresses the distance between idea and playable. The human still decides the scene, the feel, the order of operations, and what counts as acceptable quality. That is why a disciplined workflow beats a clever prompt every time.
Good AI game development is less like “wishcasting” and more like directing a very fast junior engineer with excellent tool use and inconsistent visual instincts.